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.
