Git is a free and open source distributed version control system. Git is designed very differently from tranditional version control system like Subversion (SVN). It may confuse a SVN user at first. In oder to benefit Git’s effeciency and speed, it’s really important to uderstand it and use it wisely. This article is not a “getting started” tutorial neither a deep discussion of Git, but will provide relevant tips, references, links to help professionals understanding and using Git for their daily work. I suppose that you, my dear reader, have already the basic undersatding on version control system such as SVN or CVS.
first of all, make sure those basics are clearly understood:
- Git is distrubuted, you have everything the server has
- Git is a story of snapshorts not deltas
- Think Git as a filesystem
- Git is fast because it works locally most of the time
- 3 states: committed, modified, and staged
- GIT use SHA-1 algorithm to hash cryptographically its contents
This “getting started” documentation explains very well these basics in a simple way. Understanding the differences between Git and SVN in the first place is vital because this is where mistakes often happen. This article explains very briefly the fundamental differences between the two systems.
Now, let’s try Git. If you haven’t installed Git yet, here are links for installing and setup.
Working with Git
This documentation explains very well the basic daily work commands. There is no need to say more, I just sum up the most used commands as following:
- Recording changes to the repository
- Viewing commits history
- Commit message model
- Undoing Things
Be careful, because you can’t always revert some of these undos. This is one of the few areas in Git where you may lose some work if you do it wrong. Anything that is committed in Git can always be recovered. Even commits that were on branches that were deleted or commits that were overwritten with an —amend commit can be recovered. However, anything you lose that was never committed is likely never to be seen again. It’s good practice to commit things regularly.
- Working with Remotes
- Making Git easier
Here is a BASH script to make Git experience simpler, easier and familiar.
Branching with Git
Branching is the “killer feature” in Git, it changes the way we develop. I still remember how painful to manager a branch with SVN. But with Git, it’s so lightweight that swiching between branches is almost instantaneous. You can read this documentation to know about Git branching. I list out just some important tips:
- Understand what branch is in Git is most essential, this documentation helps you understand it very well
- Branch & Merge are day-to-day tasks, here is a basic story to show how these things are done
- The above example just shows a simple use case, however the real life work are more complicated and branches are managed by different levels of stability especially when dealing with large projects.
In Git it’s common to create, work on, merge, and delete branches several times a day. Comparing to SVN, branches are largely used and encouraged in Git giving its effeciency and simplicity. Remember all those merge, branch operations are managed loacally, no server communication is happening.
- See this documentation for Remote Branches management
- And this documentation for Rebasing.
Rebasing results in changes as the merge, but offers a cleaner commit history. The following commands are often used when dealing with rebasing.
NEVER, never, never rebase commits that you have pushed to a public repository. This could generate a lot of useless work for everybody of your team
At this point, you should be confortable with Git basic commands and concepts, but for working on real projects, you still need define a workflow model and some rules for your team, here is a list of very good guidelines and practical recommandations:
- Common project workflows
- Tips for merging
- The book: Pro Git