3

We have a simple workflow with three main branches

staging i.e the test environment

master i.e the production environment

dev/XXX where XXX is the ticket number

  • Clients log tickets
  • we create a branch e.g dev/2332
  • we work + commit + push
  • we merge the work when ready into staging
  • client approves the work on staging
  • we merge the work into master and ticket is deployed on production

The problem:

If multiple developers are working on their respective dev/XXX branches; when they merge into staging, sometimes, they create conflicts. They fix those conflicts on staging and push.

The problem is when the client approves those specific tickets and we merge the work into master, we have to fix the conflicts again

Important:

  • we cannot merge staging into master -- because of unapproved tickets
  • all branches by default are created from the latest master
  • multiple tickets are being developed simultaneously but are deployed when approved
  • rebasing from master to avoid conflicts is only an option if the work has been approved + deployed already
  • rebasing from staging is not an option -- because of unapproved tickets

Any ideas on how to fix this issue? Is our workflow flawed? Are we missing some git hack?

Basically, I do not want the team to repeat the same thing twice

Thank you

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
hbt
  • 1,011
  • 3
  • 16
  • 28
  • Because of the way your `staging` branch accumulates unapproved changes, the merge conflicts that arise on `staging` and `master` are not always the same. So I don't see how you can avoid having to merge twice. The obvious fix (though you may have reasons why it won't work) is to get rid of `staging` and test/verify the changes inside the `dev/XXX` branch, which is rebased off of master. In my organization, staging is a server that gets the latest `master` just before production for one final sanity check. As such, it's not allowed to diverge. – grossvogel Oct 03 '12 at 17:40
  • ...continued... If you think about it, testing your change the way you currently do is not ideal. What if changes from `dev/123` only work if `dev/456` (an unapproved change hanging out on `staging`) is also applied? Then merging `dev/123` into `master` will cause a break that you could never detect in your dirty `staging` branch. – grossvogel Oct 03 '12 at 17:43
  • 1
    The branch is based off master. That implies it can (and should) be rebased on later master any time during it's development and in particular just before attempt to merge into staging. – Jan Hudec Oct 03 '12 at 17:59
  • @grossvogel Thanks for the reply. Eventually, staging catches up to master. However, while working on dev/123 -- because it is developed and tested in its own branch -- a dependency on dev/456 is found prior to merging into staging. – hbt Oct 04 '12 at 11:09
  • @JanHudec Yeah, that's what we do right now but sometimes we have to deal with the conflicts during the rebase. We always fast-forward when merging into master – hbt Oct 04 '12 at 11:12
  • @hbt: But rebase before merging into **`staging`** reduces the number of such conflicts later on. There will always be some conflicts now and then; the point is minimizing their number. – Jan Hudec Oct 04 '12 at 11:18

2 Answers2

2

Look at branch per feature. You should get my post about this very subject. I also answered a question here about Sharing rerere cache

Community
  • 1
  • 1
Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • Thank you. `git rerere` is exactly what I was looking for -- disappointed he did not include it in his book http://git-scm.com/2010/03/08/rerere.html – hbt Oct 04 '12 at 11:41
0

You need to keep master and staging as close to each other as possible. You could try handling it the way git itself the pu branch. That is when a new task is completed, the branch is deleted, recreated from master and all features pending approval merged in. The advantage of that is that the branches don't diverge and that there are no issues for unmerging rejected features. Disadvantage is that you can't base any work on it, but you don't anyway.

When conflict arises, you either tweak the dev branches to merge cleanly and run the "octopus" merge (merge with more than 2 parents) creating staging again, or you wait for any dependencies or conflicting features to be approved before trying to stage the dependent one.

In any case, the feature branches should be rebased on (or merged with) latest master just before trying to stage them. They were made from master when created, so rebasing them on later master is like they were started later and developed faster which obviously wouldn't be wrong.

Jan Hudec
  • 73,652
  • 13
  • 125
  • 172