Here are a few git tips that I find essential :
1. Use git on all your projects, even your personal projects
When you work on a project on your own, you might think you won’t need git because you don’t need to share your code. However, git is not just a way to share your code but rather to retain history. So that means that by using git, you are going to be able to look up older versions of your code. For example, if you find a bug that you didn’t have before, you can use
git bisect to find out which commit introduced the bug. This makes debugging much easier. You will also be able to develop many features separately, and merge them back into your
master branch whenever they are finished. Most importantly, if you do changes that you think will lead to nowhere, you can reset your code to the latest commit with
git reset HEAD --hard, or you could also save those changes for the future by creating a stash with
git stash save "stash message" . If you don’t have good memory, you will also be able to see if and when you developed a new feature.
2. Rewrite your history, because a clean history makes things simpler
I very often do interactive rebases, with the git command
git rebase -i <commit-id>. It gives you the possibility to change the commits after . Be careful not to change published history. What I use most of the time:
fixupcan meld two commits into one,
rewordlets you change the commit message of a commit, when you made a typo in your commit message, or just want to add a summary to that commit message.
With clean history, you will be able to understand the project history much better : what features where developed, by whom, and what parts of the code were changed to achieve that new feature. Lots of people are impressed to see that I don’t need to ask someone how he added a specific feature, the secret is just to look at project history.
3. Have strict convention for your commit messages
I personally like to have my commits written in english, in active present form, eg:
BAD: added XYZ feature GOOD: Add XYZ feature
Also, I recommend to follow advice from tpope’s blog post about commit messages.
4. Don’t use git commit -m « message »
I think it is bad practice to use the -m option of git commit, because it doesn’t enforce you to take time to think about your commit message. It’s also a few letters less to press to start (no ‘-m « »‘). Just start using your editor to write those commit messages, you will see that the quality of those messages will increase significantly.
5. Don’t add unrelated stuff to a commit message
If you find a typo somewhere whenever you’re coding a new feature and want to commit it, don’t put it in the same commit than your feature. The problem if you do so is that it is no more possible to tell when you fixed the typo from the commit messages. Also if you
git revert that commit because you want to remove that feature, you will also revert the correction of the typo fix, which you might not even see.
6. Use git add –patch or git add –interactive
When using git add file, or even git add . , you lose a lot of control about what you put inside your commit and what you don’t. By using
git add <file> --patch, you will be able to select which lines you would like to put into your staging area and which line you want to keep out of it.
7. It’s ok to work however you want, as long as the published history is clear
I personnaly use tig, which is a text-based interface for git that runs inside the command line. They are many GUIS that can manage your git repository, for example SourceTree. Be aware that knowing the command line api of git is very useful for all advanced tasks. Also, it will work even if you don’t have a display (such as when you ssh).