0

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.

Pedro
  • 1,134
  • 11
  • 26
  • The commits that are being merged, on `temp`, are they local to just you? If they're shared or merged into main branches `rebase` isn't really recommended, but `git rebase -i` can squash commits together into one big commit if you follow some relatively straightforward screens. If `temp` is **only local to you** and not shared yet, you could use `git rebase -i HEAD~N` to merge the `N` most recent commits, but it relies on you not having shared that branch since you're rewriting history and removing a bunch of commits. – Leigh May 04 '14 at 11:34
  • @Daan "'rewriting history' refers to changing branches after they've been published." ***I strongly disagree.*** Rewriting history applies to when you rewrite commits, **period.** –  May 04 '14 at 14:15
  • @Pedro "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." Anything that you do to rewrite history will require that your developers have some proficiency with git, whether you use rebase or not. Squashing commits into a single commit is rewriting the history of those commits. Have your developers read [Pro Git: 6.4 Git Tools - Rewriting History](http://git-scm.com/book/en/Git-Tools-Rewriting-History). –  May 04 '14 at 14:17
  • @Daan you're **effectively** rewriting the commits, even if the commit objects themselves are not the same. –  May 04 '14 at 14:20
  • The `dev` branch has indeed been published and is "shared" by every developer (pretty much like a subversion branch), and this is my main problem as makes rebasing a whole lot more problematic. What I'd really want to is being able to `merge --squash` 2 branches, say `dev` into `integration`, multiple times (something like: "do the merge, record the merge, but give me just one commit"). unless I'm doing something wrong, the second time I --squash I get all sorts of conflicts. – Pedro May 04 '14 at 22:28
  • @Pedro I initially interpreted your question as wanting to delete `dev` post-merge, and branch it off again from the new, cleaned-up history. But reading your last comment, I get the impression that instead you want to continue working on your old `dev` post-merge. Is that correct? – Daan May 05 '14 at 17:48
  • Yes, precisely. I want to __periodically__ merge a series of commits from `dev` into `integration` and "squash" them into 1 commit. Now of course this is what I _want_, not necessarily what I will get :) I'm starting to explore other alternatives as I wouldn't want for this process to be complex to start with. – Pedro May 05 '14 at 18:57

1 Answers1

0

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?

Community
  • 1
  • 1
Michael Durrant
  • 93,410
  • 97
  • 333
  • 497