On Fri, 11 May 2012 04:24:07 -0700 (PDT) Nikos Chantziaras <rea...@gmail.com> wrote:
> I'm a bit puzzled on how to best forward-port commits from a stable > branch ("master" in this case), to my experimental branch (let's call > it "exp"). Both branches are pushed to a public repo. Work that goes > on in master should be forward-ported to exp (I prefer > forward-porting rather than back-porting; that is, working on master > and porting the commits to exp is preferable to working on exp and > porting the commits back to master.) > > What's the best way to deal with that? Should I use rebase to apply > the commits from master to exp, or should I merge them? I tried > rebase in my local repo (I pushed nothing to the public repo yet), > but I'm not sure I understand what's going on :-P Rebasing it no magic: when you rebase your "exp" branch on top of your "master" branch, what happens is basically this: 1) Git chops off all the commits your "exp" branch currently has on top of your "master"'s tip commit. 2) Then it takes each removed commit one by one in the chronological order and applies them as if they were patches (.diff files if that feels more familiar), recording a new commit each time (this is very important, see below). That's why it's called "rebasing": your series of commits in "exp" was originally based on some old "master"'s tip, and you make it be based on the new "master"'s tip. And so are the logical consequences: the rebased series of commits contains *different* commits while containing logically the same changes. This appears to be weird at first sight but it's not: * Each commit records the time that commit was created at; obviously this will be the time of the rebasing for each rebased commit in the series. * The content of the branch you're rebasing onto is usually changed as well, and so will be the content referenced by your rebased commits. The consequence is that if you push a branch containing commits ...->A->B-C (with C being the tip commit) to a public repo, then rebase these three commits to produce ...->A'->B'->C' and push it again (this would require a forced push), everyone who happened to fetch the original state of your branch and base their work on it (on the commit C, that is) will have pain in the neck when their next fetch from your repo will suddenly replace a series of tip commits on that branch. Everyone will be required to rebase their work in turn, to follow your rebase. That's why rebasing a public branch in most cases should be a properly documented decision. See how Git developers implement such a policy with their "next" branch . > Yes, I've read Scott Chacon's awesome Git tutorial, but it talks > about rebasing local branches, that were never pushed to a public > repo, back to master. My case is different; both branches are on the > public repo, while the commits made to master are not yet pushed > anywhere, and it's with those unpushed commits where I'm not sure > whether to merge or rebase to exp. Considered you understood the implications of rebasing a public branch, you should make a decision yourself. I'm inclined to think most people prefer more conservative approach as there's nothing wrong with merges; some even think that there should be no fast-forward merges except for trivial cases, see . To make merge commit messages be more sensible ("merged feature X") `git merge` supports the --editor command-line option which allows to edit the commit message before actually committing a merge, and with older versions you can either use --no-commit to commit the merge manually or -m <message> to provide the commit message directly. 1. http://git-blame.blogspot.com/p/note-from-maintainer.html 2. http://nvie.com/posts/a-successful-git-branching-model/ -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To post to this group, send email to email@example.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.