I was assigned to a project that uses Git for its source code repository. I have been reading about Git for quite some time now and this is the first time that I will actually use it. I would like to share some of the things I learned with Git.
Git is different with SVN
For many years I have been using Subversion as my primary source code repository. After using Git, I realized that aside from being a distributed CVS, it also has many differences with SVN. Storing of data is already different in which SVN stores the “changes in the file”, while Git stores the “snapshot of the whole file”. You have a local repository with Git where you can do all of your work. For SVN, you almost always need to connect to the remote repository. Even HEAD is different. SVN head is the most recent revision in a branch while in Git, you can think of the head as the current branch you are pointing to. You can point to any revisions in your repository and that will be called the head.
Local Repository and Committing is not enough
When you clone a remote repository, you are actually creating your own local git repository. This is an actual git repository containing all the details like commit messages, history, code changes, etc. At the start of the development, I thought committing is already good, that is, other developers can already get my codes. But no. Committed means only my local repository is updated and if I want to share it, I would need to push.
Pushing and the Dreaded “Non-fast forward updates were rejected”
When you are the only one working on a project, which rarely happens pushing should always go smooth. But when you are working with other developers, you might encounter the error “Non-fast forward updates were rejected”. This just means that someone already pushed their codes before you. So you need to first get their codes before you push. To prevent this error, I share codes using these steps:
- Commit your codes to your local repository. git commit -m “Message”
- Get the codes from the local repository. git pull
- Resolve any conflicts. You can use git status to check if there are any.
- Then push your codes. git push origin master
Git can merge your codes unless there are conflicts
I was surprised before when there are messages like this “Merge branch ‘master’ of https://github.com/your-org/your-repo-name” when I pull codes from the database after I commit. It turned out that git will try to merge the codes from the remote to your local repository and that is the default message. So after merging, you will have at least 2 commits for pushing. One is when you first commit and the other one is after git merged the codes.
Git cannot always merge your codes automatically. Sometimes a conflict occurs. This happens if you and another developer edited the same file. So for example dev1 updated login.jsp and pushed the codes to the remote repository and you happen to edit the same file. When you try to do a git pull, git will stop the merge and will inform you this message: CONFLICT (content) : Merge conflict in login.jsp. So you need to manually resolve the conflict. Git adds markers to help you do this. When you open the file you should see something like this:
<<<<<< HEAD:login.jsp dev1 codes ======= your codes >>>>>> master
Branching and Final Thoughts
We are still in the phase where we only need the master branch. So we have yet to use the git “killer feature” (at least according to some developers http://git-scm.com/book/en/Git-Branching), branching. Switching between git branches should be really fast which make it more appealing on situations where you are working on an enhancement and at the same time supporting a production environment. One could create another branch for the enhancement. Then if a production issue arises, the developer can easily switch to the master branch by just invoking the command git checkout master assuming master is your production branch name.
So far I like Git. It can do what other repositories can do and much more. The learning stage can be tough but when you get used to it you will start to appreciate what it can do. Lastly I would suggest in reading the git book first before dwelling into the world of git.