Git rebase and the golden rule explained
medium.com
Git rebase and the golden rule explained
1–5 of 5 posts
Re: Git rebase and the golden rule explained
#2Posts like these make me feel like I don't know anything about git even though I've been using it forever.
I normally always do git pull --rebase. Is that bad or what is being talked about here? I never liked normal 'git pull' as it muddies up the logs with merge commit messages if there are changes upstream.
Most docs say pull with rebase is cleaner[1]
[1]http://gitready.com/advanced/2009/02/11/pull-with-rebase.htm...
Re: Git rebase and the golden rule explained
#3Posts like these make me feel like I don't know anything about git even though I've been using it forever. I normally always do git pull --rebase. Is that bad or what is being talked about here? I never liked normal 'git pull' as it muddies up the logs with merge commit messages if there are changes upstream. Most docs say pull with rebase is cleaner[1] [1] http://gitready.com/advanced/2009/02/11/pull-with-rebase.htm…
Instead of doing a "git pull", some people[1] advise doing a "git fetch" followed by a "git merge".
[1] - http://longair.net/blog/2009/04/16/git-fetch-and-merge/
Re: Git rebase and the golden rule explained
#4Posts like these make me feel like I don't know anything about git even though I've been using it forever. I normally always do git pull --rebase. Is that bad or what is being talked about here? I never liked normal 'git pull' as it muddies up the logs with merge commit messages if there are changes upstream. Most docs say pull with rebase is cleaner[1] [1] http://gitready.com/advanced/2009/02/11/pull-with-rebase.htm…
There is nothing wrong in itself with keeping up-to-date with master by rebasing. That's not the issue which is described by the link. The main problem is that the feature branch is being actively developed on by multiple persons.
The problem arises when, you rebase commits which have already been shared. The smoking gun is that you need to force-push, i.e., rewriting someone else's history (in other words "messing" up someone's chain of commits.)
Re: Git rebase and the golden rule explained
#5Posts like these make me feel like I don't know anything about git even though I've been using it forever. I normally always do git pull --rebase. Is that bad or what is being talked about here? I never liked normal 'git pull' as it muddies up the logs with merge commit messages if there are changes upstream. Most docs say pull with rebase is cleaner[1] [1] http://gitready.com/advanced/2009/02/11/pull-with-rebase.htm…
Yes, I do use git pull --rebase constantly when pairing. If everybody uses it, no problems, just simply works.
I have been seen only issues and completely messed up git histories when some other colleague completely refused to do pull+rebase, arguing was not professional.
So, in my experience, you will have problems if in your team does pull+rebase and other does a simple pull :)