Git good practices

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:

  • fixup can meld two commits into one,
  • reword lets 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).

4 réflexions au sujet de « Git good practices »

    1. That seems to be a great way to validate the rules, indeed, I didn’t know that this existed. Thanks for sharing !

Laisser une réponse

Votre adresse de messagerie ne sera pas publiée.