DEV Community

Cover image for Keep your Git history clean - 101

Keep your Git history clean - 101

Manuel Sidler on September 01, 2019

Cover photo by JESHOOTS.COM on Unsplash I've been working with Git for a few years now and admittedly, a clean commit history wasn't always that...
Collapse
 
rubberduck profile image
Christopher McClellan

Something I’d love to see edited into this is you can specify any commitish when interactively rebasing. When I’m squashing I almost always use git rebase -i origin/master. This way, you automatically get the right number of commits.

Collapse
 
manuelsidler profile image
Manuel Sidler

Hi Christopher

That's a good point. But careful if your branch doesn't originate from master :-)

Collapse
 
rubberduck profile image
Christopher McClellan

Fair point. I’ve been practicing trunk based development for quite some time now.

Collapse
 
absinthetized profile image
Matteo Nunziati

I declare the rebase point only if it has not been pushed yet. E.g. when I rebase only the last half of my local commits. Otherwise I keep it implicit.

Collapse
 
simbo1905 profile image
Simon Massey • Edited

GitHub has a feature squash-and-merge that works very well with team development. Devs create a feature branch for an issue and make as many commits as they want without any tidying. When the issue is finished you squash-and-merge it and it lands back onto the main integration branch as a single commit. The full history can still be seen on the feature branch. On the main integration branch the history shows when feature landed as an atomic commit which is always far more helpful than seeing the work in progress commits of the feature branch. Using this technique the history of a large project can be kept extremely clean with zero effort.

Collapse
 
chriskarpyszyn profile image
Chris Karpyszyn

Not always useful as a feature branch may contain multiple units of work that could benefit from seperate commits. Really just depends on the scope of project and workflow.

Collapse
 
simbo1905 profile image
Simon Massey

sure. we prefer to break down work into small units that can be continuous integrated if we can. sometimes something large cannot. shipping something bigger in chunks hidden by a feature flag can reduce the integration risks. many teams work in sprints and try hard to make atomic tasks that can land as single commit where possible.

Collapse
 
bpappin profile image
Brill Pappin

I really prefer to be able to trace each commit through history. That's pretty much the only time I practically need a history.

Sure, it's nice when it looks all tidy and orderly, but you lose information.

Collapse
 
sscsps profile image
Sahil Soni

Can't have dirty garbage 😘

Collapse
 
kmehran1106 profile image
Mehran Kader

Couldn't help but mention
git reset - -hard ORIG_HEAD!