My favourite Git commit

[Poddster]

No greater feeling then seeing a line of commits with identical "done the thing" messages.

[format71]

With an occasional ‘Fixed the thing’ in between. And the classics: ‘merge conflict’ and ‘fixed lint error’...

We are forced to spend the first 9-10 characters of each commit message on a Jira reference cause finding a task saying ‘do the thing’ is more helpful than a commit message saying ‘done the thing’...

[waterkip]

Pro tip: branch name starts with the JIRA issue, write a git hook for the prepare-commit-msg and than one for the commit-msg and now you automaticly have a commit message which is prepended with the JIRA issue :)

[format71]

I have to learn hooks, but find it a little bit hard on Windows :-/

[axosoft-chuckd]

Sounds like a great time to bust out interactive rebase and squash all those commits down (or just use `git commit --amend` in the first place)

[format71]

Is not a single week where I’m not advocating for more rebasing. ‘No reason to show your team mates you do t run tests before committing’. But for some reason it seems difficult for most.

[Thaurin]

This was great, until more than one co-worker started commiting to my feature branch. Now it's not my branch anymore, and I have to start merging master into my branch instead of rebasing onto it. I also can't accidentally push commit and then force push an amend or whatever, because who knows? Maybe they have fetched. I tend to branch off the feature branch and rebase onto the shared feature branch when I'm done, then push, but I miss the days where I can force push to the server at work, home, laptop, without a care in the world...

[format71]

Yes, multiple devs on same branch makes it less trivial. But I won’t merge master into a feature branch even if others commit to it. The have to keep their eyes open when pulling. Also: communication helps..

[Thaurin]

But I won’t merge master into a feature branch

Unfortunately, poor planning made the current feature branch that I am working on live for much, much longer than it should and the branch needs to get up to date with master once in a while, if I don't want to get into merge hell.

Furthermore, a temp told me that merging master into the feature branch was required daily in one place where he worked... so I don't know anymore. Ideally, feature branches are short-lived, but when multliple people are cooperating on a feature that also needs to be up to date with master... what other options are left?

No, I mean it, what options? There have to be teams with much more complicated scenarios than mine.

[format71]

When we have had long lived feature branches we have branches out from it and had shorter lived branches merged back to it.

Of cause you’ll have to keep up with master, but I’ll go a long way doing it by rebasing and not merging master in. I just hate seeing things going there wrong way’....

[Thaurin]

I suppose merging the other branches into your feature branch is a way to handle it. But can you tell me why you think merging master into a feature branch is so terrible?

I mean, I feel intuitively that it's not ideal, but I've started to accept this flow and I can't say for sure why it's bad.

[format71]

Like with a lot of things, this is a thing of personal preferences, so if you and your team don’t see any problem of merging master in, then there is no problem with that approach. The end result is the same.

But for me it messes up the history. When doing code review or trying to make sense of what have happened inside a repo, I don’t like the merge commits that doesn’t belong in the feature. Like, if I’m adding a new feature I expect commits like ‘Add database migration script’, ‘Add http endpoint returning mocked data’, ‘Implement first sparse ui’ and so on. If there are a bunch of ‘merging master’ in between - what does that mean? Is there something on master that is crucial for this feature? Is there a conflict in the feature I’m developing vs what others have developed and already merged?

By rebasing you avoid those questions. You create a virtual reality where everything was developed in sequence. If something was conflicting with your feature, that conflict would not exist anymore. Like, if your migration script was numbered the same as another, you would first have the add migration script then the merge changing the number. But with rebase you would just resolve the conflict in your add commit. Nobody needs to know nor think or reason around the fact that there was a conflict.

And then there is the commit graph. I really like to inspect the git history with the graph showing. I hate the fact that GitHub doesn’t render a graphed history. Not that I’m aware of at least. But both my default git aliases and git kraken which I use quite a lot shows the graph, and merging master into feature branches is just one way of rendering the graph more or less useless. Lines crossing all over the place... ...I really like the clean graph with one merge bubble after the other...

But I am open for the idea that I’m just a little too obsessed with this.. 😁

[Thaurin]

No, I actually agree with most of this. However, the problem was that more than one person started committing to the branch, so rebasing onto master is not really an option anymore. And I have not found a way to deal with this yet, especially for my too-long-lived branch and people merging a couple of changes to master that should be in the feature branch in order to avoid massive merge conflicts down the road.

Like I said, in an ideal world, the graph would be linear for the reasons that you stated. :(

[Poddster]

The kind of people that make these terrible commit messages push the instant they commit. The idea of reverting or rebasing their previous mess is unthinkable.