-
Notifications
You must be signed in to change notification settings - Fork 12
How to work with git
PLEASE,
read this: http://randyfay.com/content/avoiding-git-disasters-gory-story - especially "Disaster 2: Merging Without Understanding"
"Automatic" merge commits form one branch to the SAME branch (usually happenning when doing git pull with some stuff already commited locally) are always bad and showing only your ignorance. Please read carefully what git tells you and DO NOT push back when you see something like "merge made by the recursive strategy". This commits make the commit history quite unreadable - as they merge together your and someone's work. Result is one huge commit of not only your work and makes it completely impossible to do i.e. codereviews, git-blame or reverting the commit.
http://cl.ly/image/2G2S000J2q2f - left screen creates new commit and pushes it, while right one makes new commit too and tries to push it as well (later and without fetch/pull BEFORE the commit "c" is created). However git denies it and tells you to run pull. So you do it and viola - BAD mergecommit is there. http://cl.ly/image/2N3R3n053L1C. - See, even though there were 3 commits done at all (init, x, c), there is ONE MORE automatically created - containing both changes, from commit x AND c.
EASIEST SOLUTION
just run git pull origin --rebase
instead of just git pull origin
.
HARDER SOLUTION
if have you already created the commit and git rejects it, you can git reset head~1
(the number depends on how many commits have you created locally) to revert the commit (and move changes to unstaged area), then you can git stash
your changes, do proper git pull
and finally git pop
and git commit
your changes on the TOP of the index.
Creating merge commits between two branches (i.e. master and your thematical branch) is bad too but it requires a little bit of advanced skills (git rebase) and im not explaining it here. Learn something on your own.