I’ve been working heavily with Git, and the more I get into it, the more well-designed I find it to be.
I recently received a request to create a document detailing my method of using Git, targeted towards those who have not used it before. The method I use is very simple, and it’s evolved from the needs of small teams with short-term projects.
So if you’re in that situation, here’s a handy quick-to-learn way of treating your git repository. You’ll never have broken code at the eleventh hour again.
Branch-By-Feature using GitHub
I use branch-by-feature. The general principles are as follows:
- The master branch should never be broken
- Which implies that all development must go on in a separate branch
- All branches should ideally be independent sets of changes
- If two branches depend on each other, they should be only one branch - since you have to merge both or neither, you cannot treat them as separate entities.
- The only exception to this rule is if the changes in one branch extend the changes of another. In the vast majority of cases they should be one branch (or you should only pull request from the most recent branch, not both).
These principles lead us to the following workflow:
- Branch from master & develop on that branch
- Merge the current master into the feature branch. Handle merge conflicts here.
- When the feature branch is working (and tested), submit a pull request (for record-keeping as well as discussion).
- Merge the feature branch into master.
This workflow prevents master from being broken ever - neither merge conflicts nor broken code can enter master if this is followed.
I created a cheat-sheet for this method. Keeping this visual map in your mind as well will help you understand what’s going on in your repository.
If you want to read more, the blog post detailing GitFlow is a fascinating read which details a method of using Git for larger projects and larger teams. It is rock-solid, and is worth learning about even if you never use it - you can adapt it to your own needs, as I have here.
If you still want to read more, check out Thou Shalt Not Lie, an excellent post detailing some Git antipatterns.