Git workflow to merge and squash commits and not keep history

Question

I appreciate there are lots of questions and blog posts on this sort of thing, but small variations with what I'm looking for combined with my lack of experience with Git are making my efforts fail and I'm now a bit lost.

So, I have a local Git repository that looks like this:

temp: (A)----[bunch of commits]----(Z)

• There's only one branch called temp
• There's no master (don't ask...)
• A is the very first commit in the repository
• Z is the tip of temp (what it looks like now)
• Between A and Z there's a lot of garbage (merge/"oops" commits, bad commit messages, etc)

Now I want to take this and start a workflow that looks (roughly) like this:

There are 3 branchs:

• dev
• integration
• master

dev is public (pushed to central repo) and its where everyone commits, with CI, and is expected to become full of garbage like temp above.

At the end of a development cycle (sprint, feature, ...), dev is "merged" into integration. I am not interested in maintaining the history here so I guess it's not a proper merge, I just want one commit with all or potentially some of the changes in dev .

When doing a release, the process repeats from integration to master . History is also not important and I want one single commit with the changes in integration .

And most importantly, the process should be repeatable with minimal effort.

I guess that as a starting point I can just rename temp to dev and start from there. Then I'm not sure how to handle the "merges" without actually doing the merge so I can keep a clean history in integration and master .

I've checked merge --squash and it looks like what I want but it doesn't seem to be suitable when we want to do multiple squashes from the same branch.

Could someone shed some light here? Not looking for a full recipe, just some pointers in the right direction.

Background:

I understand that the proper way to achieve this would be with a rebase workflow. Although I'm under the impression that for that to work, every developer must have some good knowledge of Git and be ready to potentially handle some messy situations. Unfortunately where I'm at this is not possible and people still use the repository as a "checkpoint". This will have to change but takes time. In the meanwhile I'm trying to split the repository between clean and "dirty" areas and maintain the code transition myself.

Answer 1

I would use interactive rebasing ( git rebase -i HEAD~10 )

I have found that it is best to do the changes one-by-one and exit and save your changes between each or you may do a lot of work that eventually can't be effectively saved in case of error or issues in the merges.

You can also see more info on it at git branch, fork, fetch, merge, rebase and clone, what are the differences?