[gingerlime]

slightly OT, but I wonder if anyone has an answer for this.

We use feature branches and rebase before merging to master (mostly for the reason stated above - keep things clean and treating the branch as a single logical unit, not caring about higher-resolution history within the branch).

However, some times, especially since we typically merge on Github from a PR, it's easy to forget to rebase, or notice that there are more commits. So our history is mostly clean, but occasionally contain some "messy" commits.

I know we can reset master, but it feels a bit too risky compared to living with a bit of noise when mistakes happen.

Anyone knows of some way to prevent / alert / notify or otherwise help us avoid this rather common mistake before it happens?

[hayd]

I recommend regularly updating your branch of master via fast-forward. That way if you are working with a slightly different git history, git will complain loudly (refuse to update).

This also has the benefit of complaining if someone else has force pushed (changed history / removed commits) to upstream/master.

Catch it early.

https://leanpub.com/sanegit (I consult/train on this in SF/Bay area.)

[gingerlime]

I'm not sure I understand how this will solve my problem to be honest, and unfortunately it's not something we would seek to hire a consultant for.

[hayd]

I guess it's unclear what you meant by "mess". Some companies think training their devs is worthwhile, especially after losing days/work/$ through git messes. :)

[jes5199]

when you look at the PR in github it doesn't look obvious that some of the commits are bad?

[gingerlime]

The commits aren't bad as such, just noisy, typically. Github gives you a nice diff of the whole branch against master, so we normally don't pay attention to individual commits. We look at the change as a whole before merging it.

There is an indicator for the number of commits and you can view each one individually, but somehow it's so easy to forget.

[kansface]

Stop merging from Github?

[gingerlime]

Yes, that's one possible solution, but feels like we're punishing ourselves for every merge for the sake of avoiding a reasonably-rare issue. We're reviewing PRs on github, so it's much more convenient to merge them on the spot.