2

We have 2 main branches on our project. The first one is stable(the current successful build) and the second is unstable(experimentation). I branched out from unstable and started working on a functionality. I now need to get the latest update from stable.

I would like to know if git rebase origin/stable is a viable option to get the latest changes from stable.

user12222
  • 197
  • 2
  • 11
  • Check this post: http://stackoverflow.com/questions/1683531/how-to-import-existing-git-repository-into-another – A. K. Jul 19 '13 at 18:16

3 Answers3

0

Yes, absolutely, if you're okay with possibly having to merge your unstable changes commit-by-commit on top of the commits being brought over from the stable branch.

Generally, if you've only made a few changes in the unstable branch, especially if they are in different files than any changes made to the stable branch, rebasing is fairly simple. I rather like it. Now, if there are a bunch of changes, and both branches have changes to the same files, it may be better to use git merge. Also, if you care about such things, git rebase will change your history, whereas git merge will not.

pattivacek
  • 5,617
  • 5
  • 48
  • 62
  • I created a branch from unstable and now would like to merge to stable. In this case I hope git merge would be a good idea. – user12222 Jul 19 '13 at 18:29
  • `git merge` may indeed be a good idea, but you asked if `git rebase` is viable. It is a viable option, depending on your circumstances and what you want. – pattivacek Jul 19 '13 at 18:32
0

While you can rebase, I would strongly suggest merging, as the process for that tends to be simpler and you history will not be a lie – unless you only did a handful of commits on your private branch.

**edit: Just realized: No. you can not rebase, since that would duplicate commits on unstable and cause a horrible mess once you merge your work with unstable or stable later on.

Chronial
  • 66,706
  • 14
  • 93
  • 99
  • Thankfully `git rebase` is smarter than that. If a commit is duplicated, the second time it would be applied, it just gets skipped because there's nothing to do. – pattivacek Jul 19 '13 at 18:34
  • No, that’s not true. Since the commits he would move on top of of `stable` do not belong there, he will have to resolve conflicts during that rebase, which will break the `git rebase` duplicate detection, as it works with patch-ids. But that’s not even relevant, because it can be assumed that the branch will not be rebased again, but merged once the work there is done, and then you have guaranteed duplicate commits anyways. – Chronial Jul 19 '13 at 19:52
0

git fetch then git merge is the way to achieve this. As you are on a different branch on your own you can do git pull and then git merge. This will make your branch cleanly able to merge back into the stable one (after you fix any conflicts).

To do that git checkout stable then git merge unstable and then when you are happy git push origin stable.

If you rebase you can do some really cool things like merge your code from stable from a point in time before you changed things and single commits will be added at a time. This is handy for remote working (with no access to the main repo) when you wish to get code back in with a patch that you would like to be clean. In your case I think that fetch and merge in your branch is what you want. You can then merge back into stable when you are happy.

dirvine
  • 57,399
  • 2
  • 18
  • 19