0

Disclaimer: I don't know a lot about merging or rebasing. I use merge because it's the default effect of git pull.

I am on a team of software engineers that goes through periods of intense testing and deadlines as well as periods of less intense experimentation and exploration. Here is a brief overview of the phases:

Phase 1 (explore): Each engineer works in his own branch and periodically merges his branch into the master branch when reaching a good stopping point, e.g. when a new feature is completed. If the feature fails to be useful then it is dropped (no merge occurs).

Phase 2 (combine): Engineers work more closely in the master branch, trying to get the product ready for the deadline. Weekly demonstrations are common.

Phase 3 (panic): The ~2 weeks leading up to the deadline are usually quite intense. Short-term hacks are common and many of the changes made during this phase must be reverted or refactored after the deadline.

Phase 4 (reflect): A post-mortem takes place after the deadline and changes made during Phase 3 are either integrated, thrown out, or refactored.

Currently our team strictly uses merges instead of rebasing. However, when cleaning up in Phase 4 it seems that it might be beneficial to use rebasing in Phase 3. For example, we are not able to perform an interactive rebase in Phase 4, because when we try to do so we end up being bombarded with merge conflicts all through the rebase process. We usually end up using git revert to "remove" unwanted commits from Phase 3.

What I have in mind is to work in separate branches during Phase 1, using rebase to pull master into the feature branches and merge to pull features into master. I am not certain of the correct workflow for Phases 2 and 3, but I would ultimately like to be able to run an interactive rebase in Phase 4 and not be hit with a merge conflict every time a commit is replayed.

Question 1: Is there a workflow that my team can follow for Phases 2 and 3 that will allow us to perform a seamless interactive rebase in Phase 4 so that removing and squashing old commits is easy?

Question 2: Am I correct to be using separate branches in Phase 1, where we rebase master onto the feature branches and merge the feature branches into master when feature development is complete?

Jake
  • 7,565
  • 6
  • 55
  • 68
  • Question 2 - Typically you keep a stable and reliable "master/trunk/whatever" branch while you develop new features in their own feature branches. Then, when those features are done and stable, you merge them back into the stable "master/trunk/whatever" branch. While developing on those feature branches, it is good practice to routinely rebase your branch off of "master/trunk/whatever" in order to minimize conflicts when you finally merge your feature branch back into "master/trunk/whatever". – matmo May 02 '16 at 23:57
  • I see there is already one vote-to-close as opinion based. This is probably right; there is no single best work-flow. There are lots of bad ones, and some really bad ones. :-) Rebase vs merge really is not answerable in general. I do, however, think the default for `pull` probably should have been rebase, and using merge just because that's pull's default means "think about it some more". – torek May 03 '16 at 00:08
  • @torek I think that the questions themselves are specific and answerable. I already have an answer for Question 2. All I need is a way to do a seamless rebase, or an explanation as to why that's not possible. Good thing SO uses a 5-vote close system :) – Jake May 03 '16 at 00:14

1 Answers1

0

We using a "forking" workflow, which is also described at Atlassian's site with GitHub. The Atlassian link also explores the other 3 major styles of git workflow.

I feel like that forking workflow scales the best and keeps the complexity to the minimum in our environment. We use a "master" branch for what is in production and "development" for what is in QA. We use GitHub PRs (pull requests) as a place to talk about the proposed changes plus we have TeamCity (build test server) hooked up to the PR system.

Community
  • 1
  • 1
tgharold
  • 721
  • 6
  • 15