On 27/12/2015 15:09, Ben Rubinger wrote:
> Hi there,
> I'm pretty new to GIT. I've got a feature branch which I created off of
> origin/master, and after some time I created a pull request to be
> reviewed. I noticed that instead of saying that my branch could be
> automatically merged with master, it said that there were conflicts that
> hand to be manually resolved. This made sense because there was a lot of
> other activity in master during my work.
> So I thought that I would be considerate and merge master into my branch
> before creating the pull request to resolve the conflicts. Then I was
> thinking that I can just periodically merge master into my branch during
> my work on my branch. But my pull requests became SUPER bloated,
> indicating that I was trying to merge a TON of files into master.
> I'd therefore like clarity on when (if ever) one should (re)merge master
> into a feature branch during work on that branch. As well, let's say
> that when you merge master back in, you also pull in changes (other
> activity in that branch), for example inside "a.html" the string "Hello"
> becomes "Good morning". This is not something you touched in your
> feature branch, but changes others were working on. Now, during a later
> merge, "Good morning" has changed to "Good day". Should this show up as
> a conflict even though I never touched the file in my branch? Does my
> having pulled the change in during my previous merge cause this file to
> "activate" and show up as a change that I made in my branch? (If 'no,'
> what traps must one avoid in a situation like this that may result in a
> very polluted PR?)
> 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 to git-users+unsubscr...@googlegroups.com
> For more options, visit https://groups.google.com/d/optout.
I think that you are missing from your vocabulary a magic word - rebase
- what you have done is create a branch & put some changes onto it, then
pull & merge from trunk other changes onto your branch - these are still
changes on your branch.
What you needed to do was pull the trunk changes onto your local trunk
and then rebase your branch to tell git that you effectively wish to
base your branch on the trunk as it is now, (rather than as it was back
when you branched). See
https://git-scm.com/book/en/v2/Git-Branching-Rebasing for a much clearer
I always advise people that I am training how to use version control
systems, (git, hg or svn), that they will save themselves a lot of pain
if they try to keep their branches in step with the trunk at least
weekly, more often on very active projects.
Hope that helps.
Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect
those of my employer.
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.