Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Automatically rewrite full git history to get rid of simple merge commits

Our team uses a purely merge-based git workflow, and we're discussing the possibility of just asking all team members to push all work to server one afternoon and do an evening of rebasing the server repo.

I (think) what I would like to do automatically is that as long as all the commits are only on the same set of branches AND the number of parallel commits are below a given threshold I would like to rebase the series and remove the merge commit(s). But I am open to suggestions ?

Anyone know how to do this ?

like image 314
krosenvold Avatar asked Oct 28 '09 08:10

krosenvold


People also ask

Should I rewrite git history?

A few general suggestions: never rewrite history in an integration branch (especially if other people are using it) be very careful when deleting commits entirely (usually it's safer to squash them) know what you are changing / squashing.

How do I do a clean commit history?

Steps to get to a clean commit history:understand rebase and replace pulling remote changes with rebase to remove merge commits on your working branch. use fast-forward or squash merging option when adding your changes to the target branch. use atomic commits — learn how to amend, squash or restructure your commits.

Does git force push rewrite history?

The --force option for git push allows you to override this rule: the commit history on the remote will be forcefully overwritten with your own local history. This is a rather dangerous process, because it's very easy to overwrite (and thereby lose) commits from your colleagues.

Does git squash rewrite history?

No history is rewritten. From the high-level commands, only git rebase and git commit --amend perform history rewrites.


1 Answers

In my opinion you should avoid the temptation to re-write history just to make it "look nice". There really is no point. The history, as it is, is a more accurate representation of reality and git's reporting tools are all designed to be useful even with lots of little merges.

If you're not interested in viewing a lot of merges you can suppress them from many reporting tasks, e.g.

git log --no-merges

What you're proposing (an evening of rebasing, presumably causing all developers to have to reset) seems like creating work for work's sake.

like image 107
CB Bailey Avatar answered Sep 24 '22 15:09

CB Bailey