Blog Insights 7 Git personalities, which one are you?
January 27, 2015
4 min read

7 Git personalities, which one are you?

Working on an open source projects we receive many merge and pull requests and see a number of different git personalities. Do you recognize yourself?

git_personalities.jpeg

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.

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert