On 03/15/2012 09:43 AM, Vincent van Ravesteijn wrote:
Op 15-3-2012 14:01, Kornel Benko schreef:
Am Donnerstag, 15. März 2012 um 13:37:11, schrieb Vincent van
Ravesteijn<v...@lyx.org>
Op 15-3-2012 13:25, Kornel Benko schreef:
git pull % sync your repo first
git merge myfeature % assuming you're on 2.0.x or master branch
--or--
git checkout myfeature
git rebase 2.0.x --or-- git rebase master
git push
I did the second, but the commit is _not_ part of master, only in
this shit branch.
This was the sentence:
git checkout -b cmake
git commit
git pull
git rebase master
git checkout master
git pull
--> Changes are not there
Sorry, after the rebase, the cmake branch is on top of master. After
'git checkout master' you can do 'git merge cmake'. Now, the master
branch will be fast-forwared to cmake. This mean that the commits in
the
cmake branch are added linearly to master.
Vincent
But then, why the need for a branch? I don't understand. It is more
and more confusing.
Kornel
It's easier to have a separate branch in case the repo has new
commits. If you do 'git pull' with local commits in your tree and with
new commits in the repo, you will get an unnecessary merge.
If you keep the master branch clean, you can always safely 'git pull'.
Whenever you want to push a feature to the repo, you rebase it onto,
merge it into master and push.
A simpler answer, I think, is given in a different message of mine.
Having a separate branch gives you several advantages. First, it lets
you keep the work you're doing their separate from everything else. You
might think it's going to take a minute and be easy, and then it turns
out to be not so easy, and you have a merge conflict, or who knows what.
It's always possible to create a new branch if need be and roll back the
old one, but once you get used to it creating a new branch for
everything you do becomes second nature. The thing to remember is: Make
sure you base the new branch on the right thing. I.e., if you're already
in some branch bugs/7914, go back to master before creating the new branch:
git checkout master
git checkout -b bugs/6754
I think one can also do:
git checkout -b bugs/6754 master
The other advantage is history re-writing. In this new branch, I can
commit as often as I like, even little pieces, and then use "git rebase
-i HEAD-5", say, to restructure the last five commits.
Granted, for really, really tiny things, it isn't such a big deal. But,
as I said, once you get used to it, it's painless.
Richard
