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
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.
----- 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
Thanks for your reply. Your input is helpful. I've spent the past five days
reading through this book:
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?
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?)
> 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
> 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 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
For more options, visit https://groups.google.com/d/optout.