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
For more options, visit https://groups.google.com/d/optout.