Working on an open source project, we're so lucky to receive many merge -and pull requests. Not unlike dating, we see a number of different git personalities. Do you recognize yourself or one of your colleagues in one of them? Let us know in the comments or tweet about it with #gitlab.
1. The Build Breaker
Oh this is a small change, I'll just push it to master..
We all do it. A small change, preferably at the end of the week, it's not going to hurt anyone..
How wrong you are. You just broke the build for everyone else. Either you'll have to fix this yourself quickly or you're leaving your team to clean up your mess.
Fixing the breaker
Run relevant and fast tests locally, always work with merge requests and only merge when the build passes.
2. The Repeater
bf30a5b - cool new feature dfd934s - cool new feature 98dfjek - cool new feature
If git history was like actual history, the repeater's history books would only contain only a single sentence, repeated ad infinitum. The repeater repeats a single sentence with every commit. To know what a Repeater did, the SHA tells you as much as the commit message.
Fixing the broken record
Write clear commit messages that highlight the intent of the commit. This makes it easy to navigate through git history, to judge commits and find potential sources of problems.
3. The Wipper
You thought you were almost done and created a merge request, but still had to make a few more changes. Maybe while making those changes, you could refactor a bit more. And possibly improve the alignment in some other places and before you know it, your merge request is open for more than a month.
If this sounds like you, you might be a Wipper. The Wipper leaves their merge requests on WIP forever. Ask yourself:
Do you believe that your work will ever stop being in progress?
Merging the Wip
Try to follow test-driven development. Start with high-level tests and go from there. When those tests pass, you're done. Stop it. Ask someone to review and merge it and start with something new. Progress is many small steps.
4. The Premature committer
bf30a5b - add capital 9d5550a - add missing period 179c001 - remove 'the' 983hfk2 - remove trailing space
Young premature committers save their reports every sentence. Growing up with the magic of git, they took it one step further and commit every singly tiny change.
Premature committers and rebasers are natural enemies and are known to annoy one another. Don't put them in the same team if you can prevent it.
Squashing the premature committer
Let's be honest, premature committer, you don't really push every commit to the remote, do you? If not, then you win nothing by committing every single change!
If that doesn't wake you up, you should know that the next remedy is rebasing..
5. The Rebaser
Adding a new import utility to an open source project? UI, tests, back-end all in place? Awesome! In one commit? Not awesome.
You probably mean well, Rebaser. You write beautiful code and you know some git-fu. But remember that with great power comes great responsibility: If your feature breaks it'll be more likely to be stripped out in its entirety as a single commit, rather than having someone go through your history to see where it went wrong.
Grounding the Rebaser
You're probably forgiven. Most open source projects welcome you, but keep your merge requests reasonable. We use git for a reason.
6. The Merger
00fd402 - Merge branch 'master' into 'feature_x' 34jkdi9 - Merge branch 'master' into 'feature_x' svc98u2 - Merge branch 'master' into 'feature_x'
As the Merger, you worked really hard on that new feature. At night or during lunch breaks: where everyone is being paid for this, you are not. That comes with a cost, you start to run behind on changes and the easiest solution? Just merge in master!
The Merger's merge request will merge, that's for sure, but it's not pretty.
Cancelling the Merger
Keep your merge requests small and only start on what you can actually finish. Only merge when needed. Not even before the merge request. Just make sure it merges cleanly.
7. The Denier
The Denier is the evil twin of the Build Breaker.
But really, the tests were all green on your machine! It only broke after someone else did a commit! Or even worse: the failing test is not related to your code!
Sure, Denier, sure. We'll see what git bisect tells us..
Admitting being a Denier
You are responsible for more than your contribution. You are responsible for the healthy continuation of the project. Show you responsibility, be proud to be solver of problems, not a creator of issues and fix those failing tests. Everyone will like you a little bit more.
