10

Git still confuses me from time to time!

I have a staging and a master branch. Usually development occurs on the staging branch, which gets merged into master periodically.

However some commits have been made directly to the master branch. This means that the updates are missing from the staging branch.

How to I bring my staging branch back up to date with the master? Am I right in thinking merges should always occur in one direction (i.e. staging > master) and the merging master > staging is not the way to go?

Improve this question
1
  • What's the fear of merging master into staging? I'm not necessarily advocating that, but from a git point of view there's no harm done. It does get untidy looking at the history when taking that approach, which is why I don't advocate it. Commented Jun 26, 2013 at 10:22

3 Answers 3

Reset to default
12

I think it is a perfectly reasonable process to merge master into staging every now and then. This brings staging up to date with the latest patches in master.

You can keep developing on staging after that, occasionally bringing it up to date again with a merge.

When staging has reached a stable state, you merge it to master.

Merging between branches does not have to be unidirectional, nor does it have to be a one-time deal.

(The above is, of course, not the only possible branching strategy. See this for an example of a more advanced model)

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

I would recommend using git rebase vs. a git merge to bring any changes on the master branch to staging and use 'git merge' when moving staging to master.
@Jordan I would agree, if staging is a local branch. But with a name like staging it does not sound local.
Why does it matter if staging is a local branch vs. a remote branch?
@Jordan You should not rebase commits that you have pushed to a public repository. It disturbs other people's work since they may have based their commits on the original commits that he rebase copied. See git-scm.com/book/ch3-6.html
0

In situations, I commonly use git rebase to bring my branch up-to-date with changes made to and or merged into master.

Common workflow:

  • branch from master
  • work on branch
  • rebase from master to capture changes in master not present in branch
  • merge to master after resolving any issues
Improve this answer

Comments

-1

Yes. While merge can go in either direction technically, if you merge master into a featire branch, it is no longer a feature branch, just a dump of random stuff with elements of a feature. Do that only if the final merge will be a squash.

If you plan to merge back in the normal way, your primary plan is to be fast. Ignore the master, and resolve differences at the final merge. And just elave your branch alone.

If you can't go fast, better rebase your branch on top of the master time-to time. (making sure every commit still works fine!) A halfway solution is to merge back some part and rebase only the rest.

Another practical alternative is just cherry-pick some really-must-have patches.

Improve this answer

3 Comments

I'm not sure I'd agree with that assessment. What about bringing your feature branch up-to-date when there are things that would conflict on master? That's random stuff? Rebase works when others are dependent on your feature branch. If it's shared in any way, then rebase causes more problems than it fixes. Also cherry picking isn't a nice solution either if you're merging it back to master. It's confusing to see the same change in two different places, and it's hard to discern where the change actually happened first.
feature branch shall have patches that present the feature, right? If my merge you pick up a ton of bugfixes, other features, etc, what will the delta be? All the patches you pick up with merge are considered contained. Certainly branching strategy and tactics must be agreed upon and any advice is suspect stripped from context.
If the goal is to merge it to master, then I really don't see the problem. And the OP was talking about a staging branch, not a feature branch. It sounds like master == stable branch, and staging == development branch.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.