Snowing Code

Personal notes on software development

Git Tutorial for Beginners

(Publish date: 13/03/2011)

A few weeks ago I've been asked to come up with a rather simple git tutorial for beginners, something that could introduce developers to the most basic day to day functions you'd use. So after I've finished it, I took the time to adapt the tutorials to the 'wider public', so that as many people could use it and so it would be ready the blog. Hope this will help others to get to know git.

1. Initializing a git repository & committing changes locally:
right click on your chosen directory => Git Bash :
  • git init
  • Add content to your directory and then
  • git add -A (stages all changes, ready for commit)
  • git commit -m 'initial commit' (-m for the message)
(First commit, git would set your user name & email according to your LN email/username)
When you have only files that have been modified and no new files to commit you can:
git commit -a -m 'my message'

2. Branching
To list your branches:
git branch
To create a new branch (called feature):
git checkout -b feature
To switch from one branch to another:
  • git checkout master
  • git checkout feature
if you add/modify some files and stage then commit them, switching back to the master branch, the files would go back to their state in the original branch.

3. Reverting
When you wish to revert changes before they were staged :
  • git checkout -- MyFile.txt (reverting a modified file)
  • git reset --hard (reverting all changes done in current repository)
When adding new files to git, as long as they're not staged you can just delete them. Try it: add a new file then git status then delete the file then again git status. git status will tell you what changes were made and how to revert them.
EXERCISE: try renaming a file then revert it.
If you staged already the changes you wish to revert just:
git reset MyFile.txt (unstage MyFile.txt) or git reset . (will unstage all)
After unstaging is done, checkout or reset (as above) to revert.

3.B Shelving / Stashing
When you have done some changes in your project and need to go and do some work on another feature but do not want to commit your current changes locally yet, you can stash your modifications. to stash your repository current state
  • git add -A
  • git stash
if not staging changes and checking out to another branch, your changes will be seen on the other branch, and will not be saved obviously. Upon stashing your changes you could go to other branches or do whatever you want to do on your current branch and when the time will come, you could bring back your code to the state it was when you stashed it with
  • git stash apply
and will need then to
  • git add -A
again to stage the changes you have just unstashed. On every 'git stash' you add another stash, so that
  • git stash list
will show a list of all the stashes you've got. If you wish to apply a certain stash:
  • git stash apply stash@{1}
when stash@{1} is the number of stash that you wish to unstash, as it appears on the list.

4. Merging
When you finished working on your feature/user story on your branch and you're ready to merge your changes into master :
  • git checkout master
  • git merge feature (or whatever your branch name is)
If master hasn't changed since you branched from it, the merge will show up as a commit on master (also called a fast forward). In the GUI go to Repository => Visualize current master's history, all commits sit on the master life line.
If however master has received commits since you branch it, the history would show separated life lines (line per branch).

4.A. Merging conflicts
Before you start working with conflicts you need to set up your visual diff tool to work with git.
Since I use p4merge at work, the following are the steps for using p4merge with git :
Go to, choose Clients, Visual Merge Tool, download & install P4Merge. Open C:\Users\user-name\.gitconfig and paste the following :
tool = p4merge
[difftool "p4merge"]
cmd = "p4merge.exe $LOCAL $REMOTE"
tool = p4merge
keepBackup = false
[mergetool "p4merge"]
cmd = "p4merge.exe $BASE $LOCAL $REMOTE $MERGED"
trustExitCode = true
Now if you modify a file then before staging the modification run
git difftool
p4merge will show up and display your changes.
Now change the same file in both of your branches so it will conflict. You should see:
CONFLICT (content): Merge conflict in One.txt
Automatic merge failed; fix conflicts and then commit the result.
In order to bring up your merging tool:
git mergetool
In P4Merge merge the conflicting commits, save the result and exit. (P4Merge will show 4 versions: the original file, your current branch version, the other branch version and the result)
then to finish the conflict merging :
  • git add -A
  • git commit -m 'conflict merged'

5. Rebasing
If you wish to merge your branches while keeping one visual life line, rebase your master onto your working branch :
  • git checkout feature
  • git rebase master
This will temporarily remove your commits, update your working branch to the latest version of master then re-apply all of your recent commits. You could then fast-forward your branch to master.
If you visualize the history, you'll see one history line where the master commits will come before your commits on the working branch, even if they were made after (time-wise).
ATTN: rebasing though could lead to a lot of problems when reverting your rebased commits and re-writing history.

6. Amending commits errors
If you noticed your commit message (for example) wasn't what you wanted to leave:
git commit --amend -m 'good message'
This will amend your commit message. You could then also add or correct files you've forgotten.
Make sure you only amend local commits!

7. Cloning/Pushing/Pulling To/From remote repository
To clone a remote 'source' repository, first create your 'source' repository (say on c:\source) with:
git init --bare
This will create a bare repository, one that you will not work on. Now go to where you want to clone this source (say c:\One), open bash and:
git clone c:/source
You'll see a new repository on c:\One\source. Repeat this on a different directory (say c:\Two).
add a file baring under c:\Two\source, stage & commit, then:
git push origin master (to commit / check in your changes to the remote repo)
Now go back to c:\One\source and:
git pull origin master (to get latest changes that were pushed to source)
Origin is the name of the remote repository you've cloned from; by default when cloning a repository, the remote original repository is called origin.

8. Remote branching
To add someone else's repository as a remote (continuing from the preceeding example, supposing you're on c:\One\source):
git remote add Two c:\Two\source
git fetch Two (get all branches)
Suppose repo Two has a branch called featureTwo, you could:
git checkout featureTwo bash will display:
Branch featureTwo set up to track remote branch featureTwo from Two.
Switched to a new branch 'featureTwo'.
To update your branch pointing to the remote branch:
git pull Two featureTwo
If you have branches sharing the same name (like master), make sure you don't
git pull Two master
- this will merge Two master changes into your current (repo One) master.
Tags: git
blog comments powered by Disqus