Hi Steve, Thanks for your reply. Your input is helpful. I've spent the past five days reading through this book:
http://www.amazon.com/gp/product/B008Y4OR3A My hesitancy around rebasing was around the fact that (if I understood correctly) all rebased checkins are deltas, having different hashes from their original with the implication that if others have checked out your branch, they will feel pain after you perform a rebase. I'm not sure if I captured this correctly, but in general it seemed like rebasing can be inconsiderate to others with whom you're working. What advice do you give to people you're training around this? And, if rebasing does introduce certain risks, is merging possible while avoiding polluted PRs? Thanks... -Ben On Monday, December 28, 2015 at 1:43:54 AM UTC-5, GadgetSteve wrote: > > > 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?) > > > > Thanks! > > -Ben > > > > -- > > 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+...@googlegroups.com <javascript:> > > <mailto:git-users+...@googlegroups.com <javascript:>>. > > For more options, visit https://groups.google.com/d/optout. > > Ben, > > 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 > explanation. > > 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 to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
