I usually only 'lurk' on this forum, since I am pretty new to Git myself,
too. But there are two things that stood out here I feel I need to speak up
about: 1) be very, very careful about following the 'guidance' from a Stack
Overflow post where neither the question nor any of the answers got a
rating higher than 3 2) rebase is NOT part of the normal Git workflow. Its
use should be rather rare. I cannot imagine why you would want to do it
after every checkout.
In particular, the man page for git-rebase (recall that to look up git
commands in man, you need to add the '-') has two warnings that are likely
1) Rebasing (or any other form of rewriting) a branch that others have
based work on is a bad idea
2) You should understand the implications of using git rebase on a
repository that you share.
Those implications can be rather complicated, as the length of the man page
Taking a slightly different approach, the online Git book covering rebase
(http://git-scm.com/book/en/Git-Branching-Rebasing) seems to imply that if
what you want to do can be easily done with merge, then you should do so,
resorting to rebase only when you want to do odd things like apply not the
whole current branch, but only a patch in it to another branch.
I have never had to use rebase yet, but before I do, I will read that whole
chapter. I heartily recommend you do the same, especially since one of the
sections is (sub)titled, "The Perils of Rebasing".
On Friday, July 4, 2014 1:11:57 AM UTC-7, ayrshi...@gmail.com wrote:
> I am fairly new to the concept of rebasing with Git, and I have been
> following the guidance from a StackOverflow post
> by doing this:
> git fetch
> git checkout CRM-my-feature-branch
> git rebase -i origin/develop
> git push -f origin CRM-my-feature-branch
> This has generally worked well for me. I done this in mid-May to bring
> CRM-my-feature-branch up to date with origin/develop which other developers
> are working on.
> However, I have just tried to do the same thing again and I have been hit
> with a vast number of conflicts. Now, conflicts are fine but some files
> seem to almost be in a permanent state of conflict. For example, commit 2
> will show as a conflict of commit 1 so rather than git realising that
> commit 2 comes after commit 1 - it shows as a conflict.
> Is this a symptom of rebasing on top of a branch that I have previously
> rebased on?
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.