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
(with C being the tip commit) to a public repo, then rebase these three
commits to produce
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.
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
For more options, visit this group at