Hi Ben, Rebase is a good way to go. I see you have a couple of misunderstandings / false viewpoints that are common.
Git does not use deltas at its primary interface. Yes, there are lots of internal implementation details that use deltas, along with often showing diffs between commits, but after rebasing it is still a set of commit snap shots, based on the new start point. (more in a minute) Your temporary branch is, as a social convention, 'private' - i.e. in some way it's just your problems... even if other can 'see' it - or at least it should be seen as private in that way. This means it should come as no surprise to others when you rebase it - if others are trusting your commits then there is a bigger problem, you've already said you want your update to be based on the most recent master! There are number of ways of handling personal temporary branches depending on the local organisation - you could have a personal fork of the whole repo, you could have a personal branch namespace, etc. I said that Git doesn't use deltas. However, you are wanting to create some changes to master, so git rebase will summarise your older changes as diffs, then re-apply them to the new master, and if there are any merge conflicts local to your changes, rebase gives to a chance to fix them as you go. I'd suggest that you first create a branch at the current head as 'just in case' marker (or a tag, or write down it's sha1...). Then I'd use the interactive 'git rebase -i', probably with --onto and the start and end points given, just to be sure. The interactive rebase allows you to ask rebase to pause at any spot you might be worried about (I set the selected 'worry' commits to 'edit', you can just 'git rebase --continue' if it's ok), and then step through it all. If it all goes wrong I can reset hard back to the previously marked point (Git also keeps a ref ORIG_HEAD to that same point but you might not trust it just yet). Remember, the control has been distributed to you. As long as you are working inside your own local clone you are in charge. It only when your upstream accepts your work and merges it into their master/workflow is it really public. [Caveat, some big company schemes may not have properly bought into DVCS and misconstrue the push of a temporary branch as having 'quality' and try to do automated testing / continuous integration, rather than just being a short term backup that will be overwritten by a forced push after your rebase..] Hope that wasn't too rambling... In short, 'git rebase -i' is for you. Philip ----- Original Message ----- From: Ben Rubinger To: Git for human beings Sent: Monday, December 28, 2015 2:46 PM Subject: Re: [git-users] Question about when to merge master into my feature branch 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 [email protected] > <mailto:[email protected]>. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout. -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
