No matter what project or team I find myself working on one thing that is a constant variable is the act of committing. How branching, flow and deployment is handled, how often commits are made, the mentality behind a commit as well as the standard, or lack there of, of commit messages and processes.
Obviously everyone is different, and people have various reasons for doing it ‘their way’. As a consultant I’m constantly trying to keep visibility on projects that are some way through their development cycle, as well as communicating my additions and improvements to the team.
So how do we best git?
After all of the projects I’ve worked on, and git setups I’ve seen, I’ve settled on five very basic principles of Git / Code management:
- Branching is your best friend
- Most commits aren’t production so commit early, often and with tenacity
- Don’t fall too far behind the main branch if possible
- Have an agreed structure to and make relevant, commit messages
- Automate your dev & staging environments, but not production. *
Branching is your bud:
I have had many a conversation with fellow devs in various corners in the world on their branching strategy and most agree that some variant of git flow is the way to go. In a nutshell this is the idea:
- You have a master, a dev and release branch.
- For each new feature you create a ‘feature branch’
- When a feature is complete you merge to dev
- When your dev is ready for release you push it into master
Having an actual standard branch structure means that your code base is kept clean and all code can be reviewed via pull requests 😉
The structure I am most happy with is a variation of git flow, that follows the following branch structure:
Master (most recent completed release)
— Dev (working towards the next release)
—– Feature branches
Releases (each release has its own branch)
So an example flow for making a feature and submitting a release would be:
- Create a feature branch (off dev)… and build your feature
- Submit a pull request to dev… and get it peer review & approved
- Once you & your team is happy with the state of dev, create a release branch
- Test your release branch to the max
- Make any hot fixes or patches
- Release to the wild!
p.s. If you want to do some more in depth reading on git flow, check out this epic piece by Vincent Driessen.
Committing early, often and with tenacity:
Code management is great because it allows us to back track, stash, explode, destroy and play with our code bases without having to either set up an entirely new environment or risk breaking our software. This we know. Yet many people out there seem to be convinced that a commit or two a day is enough…. Ok yes depending amount of time spent working, but most of the time people make 2 commits within an 8 hour coding sesh. The problem is that those unnamed individuals view a repo as some divine space where only perfect code may reside .. or they just don’t give a shit.
Either way the more commits you make, the more freedom you have to play with and improve your code.
GitTip: To avoid any nasty merge conflicts, pull in your development branch whenever possible.
Git commit messages, the silent killer of team communication..
Commit messages generally are a mess… and don’t really do anything. ‘updates’, ‘code changes’ and ‘stuff’ are NO GOOD at telling you one week, one month or one year from now what changes you made here. More importantly they communicate absolutely shit all to your team, making it much more likely for the need of ‘catch up’ meetings, which are an even bigger killer of productivity. So rather than continue with this madness, make a team standard and stick to it. In my ideal world we all agree to a standard, that way everything is clear for everyone no matter what team or project they find themselves on.
A potential standard?
- Feature / feat: <added a feature for the first time>
- Increment / inc: <update to a feature, following commit often perfect later>
- Chore: <linting, updating deps e.c.t>
- HotFix: <update to fix a very specific issue>
- Patch: <publicly released update to a known bug>
- Style: <update / new styles>
- Merge: <a merge>
How do you do Git? Is there anything you agree or disagree with? Lets chat about it on Twitter 😉