Simple Introduction to Git Versioning
Git is an Open Source Distributed software Version Control System.
Let’s take a look at a few steps on how to get started with Git versioning.
Step 1: Download git.
This link has details on how to install Git in multiple operating systems:
https://git-scm.com/book/en/v2/Getting-Started-Installing-Git
Verify if Git is installed by using the following command in the command prompt:
git — version
Step 2: Create project repository and git repository.
Create your local Git repository:
In your computer, create a folder for your project.
Let’s call the project folder ‘simple-git-demo’.
Go into your project folder and add a local Git repository to the project using the following commands:
cd simple-git-demo
git init
The git init command adds a local Git repository to the project.
Step 3: Add code to the project.
Let’s Add some Small Code now:
Create a file called demo.txt in the project folder and add the following text into it:
Initial Content
Here we will be demoing with just plain text instead of actual code, since the main focus of this article is on Git and not on any specific programming language.
Step 4: Staging and Committing the code.
Committing is the process in which the code is added to the local repository.
Before committing the code, it has to be in the staging area.
The staging area is there to keep track of all the files which are to be committed.
Any file which is not added to the staging area will not be committed.
This gives the developer control over which files need to be committed.
Staging:
Use the following command for staging the file:
git add demo.txt
In case you want to add multiple files you can use:
git add file1 file2 file3
If you want to add all the files inside your project folder to the staging area, use the following command:
git add .
Use this carefully since it adds all the files and folders in your project to the staging area.
Committing:
Use the following command to commit the file:
git commit -m “Initial Commit”
“Initial Commit” is the commit message here.
Enter a relevant commit message to indicate what code changes were done in that particular commit.
Step 5: Git Forensics — Checking commit status and logging.
Git Status and Git Log:
Now modify the demo.txt file and add the following snippet:
Initial Content Adding more Content
Status:
Use git status to find out information regarding what files are modified and what files are there in the staging area — it shows other information as well, which we can ignore for now.
Use the following command to see the status:
git status
The status shows that demo.txt is modified and is not yet in the staging area.
Now let us add demo.txt to the staging area and commit it using the following commands:
git add demo.txt git commit -m “demo.txt file is modified”
Log:
Use git log to print out all the commits which have been done up until now.
The command used for this is:
git log
The log shows the author of each commit, the date of the commit, and the commit message.
Step 6: Embracing Advanced Git techniques.
Branches:
Up until now we have not created any branch in Git.
By default, Git commits go into the master branch.
What is a branch?
A branch is nothing but a pointer to the latest commit in the Git repository.
So currently our master branch is a pointer to the second commit “demo.txt file is modified”.
Why are multiple branches needed?
Multiple branches are needed to support multiple parallel developments.
However the Branches and the Master Branch can be merged using git merge.
Create a New Branch in Local:
Create a new branch called test using the following command:
git branch test
This command creates the test branch.
We are still in the context of the master branch.
In order to switch to the test branch, use the following command:
git checkout test
Now we are in the test branch.
You can list out all the branches in local using the following command:
git branch
Do Some Commits in the New Branch:
Modify demo.txt by adding the following snippet:
Initial Content Adding more Content Adding some Content from test Branch
Now stage and commit using the following commands:
git add demo.txt git commit -m “Test Branch Commit”
This commit was done in the Test Branch, and now Test Branch is ahead of Master Branch by 1 commit — as the test branch also includes the 2 commits from the master branch.
You can verify the commit history in Test Branch using:
git log
Merging:
Currently, Test Branch is ahead of the Master by 1 commit.
Let’s say that now we want all the code in the Test Branch to be brought back to the Master Branch.
This is where git merge is very useful.
In order to merge the code from the test branch into the master branch, follow these steps:
First go back to the master branch:
git checkout master
Then run the merge command:
git merge test
After running these 2 commands, the merge should be successful.
In this example, there are no conflicts.
But in real projects, there will be conflicts when a merge is being done.
Resolving the conflict is something which comes with experience, so as you work more with Git you will be able to get the hang of resolving conflicts.
Run git log now and you will notice that the master also has 3 commits.
Remote Git Repository:
Until now, we have been working only in the local repository.
Each developer will work in their local repository but eventually, they will push the code into a remote repository.
Assuming you’re using Github,
start a project to create a new Git repository.
Give the repository a name and click “Create Repository”
Give the name as git-blog-demo.
This will create a remote repository in GitHub, and when you open the repository, a page will open up:
The repository URL is the highlighted portion and will look like https://github.com/Your-Git-Username/git-blog-demo.git
In order to point your local repository to the remote repository, use the following command:
git remote add origin [repository url]
Git Push:
In order to push all the code from the local repository into the remote repository, use the following command:
git push -u origin master
This pushes the code from the master branch in the local repository to the master branch in the remote repository.
Git Pull:
git pull is used to pull the latest changes from the remote repository into the local repository.
The remote repository code is updated continuously by various developers, hence git pull is necessary:
git pull origin master
Git Clone:
git clone is used to clone an existing remote repository into your computer.
The command for this is:
git clone [repository url]
Writing a .gitignore file:
Repositories often have a file called .gitignore and we are about to make one shortly.
In this file you specify which files you want Git to ignore when users make changes and add files.
Examples include temporary Word, Excel and Powerpoint files, .Rproj files, Rhist files, etc.
Some files you might want to only have on your local repository (i.e. on your computer), but not online as they might be too big to store online.
Go to Create new file and write a .gitignore file within your main repository (not within any folders).
You need to call the file .gitignore and then add the types of files that Git should ignore on separate lines.
You can make this specific to your needs, but as a start, you can copy over this code:
Copy contents below and paste into your .gitignore file.
# Prevent users to commit their # own RProject
.Rproj.user .Rproj
# Prevent users to commit their # own .RData and .Rhistory in
# mutual area
.RData .Rhistory .Rapp.history
# Temporary files
*~
~$*.doc*
~$*.xls*
*.xlk
~$*.ppt*
# Prevent mac users to
# commit .DS_Store files *.DS_Store
# Prevent users to commit the
# README files created by
# RStudio
*README.html *README_cache/ #*README_files/
Contributor Attributes:
If you have just installed Git, the first thing you need to do is provide some information about yourself, since it records who makes each change to the file(s).
Set your name and email by running the following lines, but replacing “First Last” and “user@domain” with your full name and email address, respectively.
$ git config — global
user.name “First Last”
$ git config — global
user.email “user@domain”
Thanks!
Thanks for taking the time to read this post.
Find me on;
Github: Github.com/VakinduPhilliam
Twitter: Twitter.com/VakinduPhilliam
LinkedIn: LinkedIn.com/in/VakinduPhilliam
