1

If there are multiple developers working on a feature branch, and we need to periodically bring in changes from master, there are two approaches that I know of:

  1. developers communicate that they have the latest changes from the published feature branch. Then one developer rebases onto master and force pushes. Other developers pull down the new feature branch and everyone continues developing.
  2. any developer merges master in whenever they like, no one ever force pushes.

my questions:

  1. am i right that these are the possible workflows?
  2. with the second workflow, when it's time to bring the feature branch into master, how can this be done with the cleanest history possible? Will a rebase onto master clean up/remove the other merge commits, or will it be a mess?
John Bachir
  • 22,495
  • 29
  • 154
  • 227
  • http://nvie.com/posts/a-successful-git-branching-model/ gives a good workflow – Zac Wrangler Oct 12 '13 at 18:24
  • i'm familiar with gitflow and have used it for years, but it does not suggest or dictate a strategy for continually merging changes from master into the feature branch. – John Bachir Oct 12 '13 at 18:26

1 Answers1

0

  1. Yes.

  2. yes, unless you rebase with the --preserve-merge option, those merge commit would still be there, but without any parent on master.

I tend to favor the first approach because:

  • it does enforce communication within the dev team
  • it avoids "back-merge" (from master to a feature branch)
  • it doesn't require those merge commit from master that you would want to keep during a final rebase.
  • it facilitates the final integration of that feature branch into master
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • interseting, thanks. could you make more explicit answers to my questions? (to make sure i understand) – John Bachir Oct 12 '13 at 23:00
  • @JohnBachir Sure, I have edited the answer to address more directly your questions. – VonC Oct 13 '13 at 10:13
  • thanks! but #2 seems to conflict with itself... do you mean "**if** you rebase with the `--preserve-merge` option, those merge commits would still be there"? – John Bachir Oct 13 '13 at 18:14
  • 1
    @JohnBachir no: the merge commit are there, but they have lost their parent from `master`. Because you didn't use the `--preserve-merge` option. But my point is: those merge commit shouldn't be here in the first place: rebase allows for a cleaner history, with your commits applied on top of `master`, instead of `master` "injected" (merge commit) in the history of the feature branch. – VonC Oct 13 '13 at 18:19