2

Here is my git setup (we use Git + Atlassian Stash in our corporate network):

upstream:
  master

origin (my fork of 'upstream'):
  master
  branch1 (branch of master, with a few commits on top of it)

clone (local; clone of 'origin'):
  master
  branch1 (ahead of 'origin:branch1' by 1 commit)

What I want to do:

I want to merge upstream:master -> clone:branch1. I know there will be conflicts with this merge (since I changed files in my branch1 that others have changed in upstream). Once this is done I hope to push my changes back to origin:branch1, which will include my 1 commit + latest base from upstream (I want to keep up to date with the master branch, since that's the one I branched from). Along with this I want it to be a rebase, so that the commit history is clean and doesn't spider-web all over the place.

Another note is that I do not use git command line directly. On Windows, I'm using SmartGit, so if anyone knows instructions for that tool that would be most ideal.

How can I properly merge like I have described above?

void.pointer
  • 24,859
  • 31
  • 132
  • 243

1 Answers1

3

If no one else has cloned or is working with branch1, you can rebase it on top of master, once you have updated master to upstream/master.

  • First, fetch upstream (SmartGit: Remote/Pull, select "Fetch Only")
  • Then reset master to upstream/master (SmartGit: Local/Reset)
  • Now rebase branch1 on top of master (SmartGit: In the Branches view, you can right-click on a branch like master and select Rebase HEAD to rebase your current HEAD onto the selected branch master)
    Resolve merge conflicts if necessary.
  • Finally push (force the push) of branch1 to origin (SmartGit: In the context menu of the Branches view, you can invoke Push and Push To on local branches).

enter image description here

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • The rebase terminology is confusing and somewhat scary. I see "rebase onto the selected branch", and since `master` is the branch I'm "selecting", it makes it sound like I'm merging `branch1` into `master`. Am I reading this backwards? – void.pointer Oct 31 '13 at 21:02
  • Think of "rebase onto" as "replay after", e.g. "replay commits from `branch1` after commits in `master`". – dahlbyk Oct 31 '13 at 21:24
  • @dahlbyk To me that means "Take commits from `branch1` and put them into `master`". Is this correct? I want to do the opposite... I want the latest changes in `master` to be placed into `branch1` (to keep up with latest progress in the original mainline). – void.pointer Oct 31 '13 at 21:26
  • *onto* not *into*. `master` stays the same; `branch1` changes to start from `master` and then changes are applied from there. – dahlbyk Oct 31 '13 at 21:28
  • @dahlbyk Sorry for complicating what seems to be minor, but he said "rebase `branch1` on top of `master`". To me this should read "rebase `master` on top of `branch1`", which is effectively making `branch1` the target of the rebase (which it is). The way I'm reading it makes it sound like "The chair jumped onto the dog" (doesn't make sense), instead of "The dog jumped onto the chair" (makes sense). – void.pointer Oct 31 '13 at 21:47
  • @RobertDailey what I propose it to replay `branch1` on top of `master` (`rebase master`) rather than merging `master` back to `branch1`. This is what it detailed in https://www.atlassian.com/git/tutorial/rewriting-git-history#!rebase. – VonC Oct 31 '13 at 22:13
  • @VonC The git tutorial you linked really helped put it into perspective. However, if you rebase doesn't that basically make you lose information about *when* you branched? So in other words, when you merge the feature (branch1) back to master, there will be no commits on master between the start of branch1 and the end of it? – void.pointer Nov 01 '13 at 14:33
  • @RobertDailey with a *distributed* VCS, the goal isn't to see when you merge, but to see a coherent sequence of commits. The goal of a rebase, followed by a merge to master, is to have that `branch1` sequence integrated on top of the most recent `master`. The **"when" which matters** it *not* when you *started*, but when you *integrated back* your feature branch, because that is when *others* will be impacted by it. – VonC Nov 01 '13 at 18:56
  • Note that @VonC's stance (with which I agree) is not necessarily how everyone uses DVCSes. Some will happy merge from master into feature branches, and then merge back into master. Personally, I like to think of my feature branches as "changes since `master`" and as `master` shifts over time, my branch does as well. – dahlbyk Nov 04 '13 at 03:16