The first link says exactly what I'm saying, you want to put your changes on
top of what everybody else has done.
'So "git rebase" is not wrong. But it's right only if it's YOUR VERY OWN
PRIVATE git tree.'
When you do a pull --rebase, you're rebasing only your commits on the top of
the others commits, nothing before the origin/HEAD indeed.
The 2nd and especially the 3rd links tell as well what I'm saying, they do a
final merge because there are on branches, in between they rebase their own
commits:
clone the remote repo
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature
git checkout master
git merge --squash my_new_feature
git branch -D my_new_feature
The 4th link:
Reason #1: Resolve conflicts once, instead of once for each commit
This case is rare but easy to resolve, you abort your rebase on multi
commits conflicts and to simplify your life, exceptionnaly, you do what he
says, you do a merge, messing the history though.
Reason #2: With rebase, there is no undo!
Doesn't apply, because, you will never rebase your feature branch on the
develop one but merge it and if you work directly on the develop branch, you
will push a few of rebased commits which are yours.
And I'm tired now, I haven't read the last one.
-Fred
-----Message d'origine-----
From: Justin Mclean
Sent: Tuesday, March 19, 2013 4:20 PM
To: [email protected]
Subject: Re: [3/3] git commit: Merge branch 'develop' of
https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
Hi,
NO, that's the opposite
Really?
https://wincent.com/wiki/git_rebase:_you're_doing_it_wrong
Dozen of stack overflow question on the issue which warn about rebasing. For
instance:
http://stackoverflow.com/questions/8939977/git-push-rejected-after-feature-branch-rebase
"Rebase and a shared repository generally do not get along. This is
rewriting history. If others are using that branch or have branched from
that branch then rebase will be quite unpleasant."
http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions
"It really kills me that people are recommending a rebase workflow as a
better alternative to a merge workflow for conflict resolution"
"With rebase, there is no undo!"
Also
http://git-scm.com/book/en/Git-Branching-Rebasing#The-Perils-of-Rebasing
Again I'll ask do we really want this option to be the default?
Justin
