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 git-users+...@googlegroups.com 
    > <mailto:git-users+...@googlegroups.com>. 
    > 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.

-- 
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.

Reply via email to