Re: [git-users] Reset branch to master after merge
- Original Message -
From: Paul Smith
To: git-users@googlegroups.com
Sent: Monday, March 11, 2013 3:33 PM
Subject: [git-users] Reset branch to master after merge
I've been searching but I've not found anyone else asking about this. In my
workflow I tend to do a bunch of work on a topic branch, merge it to master,
then do some other things and come back a few weeks later and pick it up again.
Obviously when I start working on it again I want to start with the current
master HEAD, not with the content that existed on the branch prior to my merge
to master: master now contains all the code from my topic branch, plus all the
new code people have added, already merged and ready to go.
Certainly I can merge again from master back to my topic branch, but this
creates a new commit on my topic branch for the merge. This seems unnecessary
to me. I believe I'd prefer to reset my branch to master after I merge it, so
that when I merge from master it does a fast-forward, until I decide to start
working and make changes on the branch. Does this make sense? How do other
people handle this situation? Do people just do the merge and accept the extra
commit? We have a number of developers making lots of changes and our git repo
is REALLY complicated (I can rarely make any sense out of gitk etc. as there
are so many branches all over the place). This model seems to add to that
confusion (for me).
Or do people delete their topic branch after the merge and re-create it later?
I've tried a "git reset --hard master" and that works for my local branch,
but I've had trouble figuring out how to deal with the remote branches (I need
to push my local branches to our main repo so it can undergo code review etc.
before merging to master).
On the assumption that the branch is your private branch, you can always force
push it to overwrite waht it had previously, once you have reset it to master.
But in a public situation this results in real problems with everybody getting
confused when they can do a nice fetch/pull.
I am now using the 'git fetch ' then 'git reset --hard @{upstream}'
when I want to transfer a rebased private branch between machines (Windows <->
Linux machines, via github) http://stackoverflow.com/a/15284176/717355 This
works quite nicely for my personal workflow, but it's not nice in a shared
environment.
Thoughts about this situation are welcome;
Cheers!
--
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/groups/opt_out.
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 2641/6162 - Release Date: 03/10/13
--
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/groups/opt_out.
Re: [git-users] Reset branch to master after merge
Yea, that last bit is a bit outside the norm, and yes, I'm saying that you should just delete it and recreate it later on. It basically has the same effect as resetting it to master, but it's less hassle and you don't have an extra topic branch laying around. What I was getting at was that this is really a mentality issue. You shouldn't think of what you're doing as "continuing" the feature. Once you merge it into master, that feature should be considered "done," and any subsequent work should be considered a "new" feature--hence the new topic branch. This mental model should help keep things a little more organized. Ryan On Mar 11, 2013 12:23 PM, "Paul Smith" wrote: > On Mon, 2013-03-11 at 10:54 -0500, Ryan Hodson wrote: > > > > 1) Use the topic branch as a short-lived branch that just serves as an > > isolated environment for you to do some work on a particular feature. > > This means you would delete it as soon as you merge it into master, > > because that "feature" is done, at least for the time being. When you > > want to start work on it again, create a new topic branch for it, and > > repeat. > > > 2) Use the topic branch as a long-running feature branch. If you were > > to do this, you should *not* merge it into master until it's > > completely done. This means the topic branch would co-exist with the > > master branch as long as you're still working on it. If you need to > > pull in updates from master, then you would either a) rebase the topic > > branch onto master or b) merge master into the topic branch (but *not* > > the other way around). > > I do #2... I work and merge from master periodically, then when I'm > ready to deliver I merge my topic branch back to master and I'm off > doing other things. But then after a while I often pick back up the > branch to implement further features etc. It's this last bit that seems > outside the norm... but I do it fairly often. > > So your opinion is that it's better to delete the branch after I merge, > then recreate it later, rather than trying to force it to point to the > master post-merge commit so I can ff-merge it later? > > > > -- > 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/groups/opt_out. > > > -- 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/groups/opt_out.
Re: [git-users] Reset branch to master after merge
On Mon, 2013-03-11 at 10:54 -0500, Ryan Hodson wrote: > > 1) Use the topic branch as a short-lived branch that just serves as an > isolated environment for you to do some work on a particular feature. > This means you would delete it as soon as you merge it into master, > because that "feature" is done, at least for the time being. When you > want to start work on it again, create a new topic branch for it, and > repeat. > 2) Use the topic branch as a long-running feature branch. If you were > to do this, you should *not* merge it into master until it's > completely done. This means the topic branch would co-exist with the > master branch as long as you're still working on it. If you need to > pull in updates from master, then you would either a) rebase the topic > branch onto master or b) merge master into the topic branch (but *not* > the other way around). I do #2... I work and merge from master periodically, then when I'm ready to deliver I merge my topic branch back to master and I'm off doing other things. But then after a while I often pick back up the branch to implement further features etc. It's this last bit that seems outside the norm... but I do it fairly often. So your opinion is that it's better to delete the branch after I merge, then recreate it later, rather than trying to force it to point to the master post-merge commit so I can ff-merge it later? -- 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/groups/opt_out.
Re: [git-users] Reset branch to master after merge
Paul, It sounds like you have one of two options: 1) Use the topic branch as a short-lived branch that just serves as an isolated environment for you to do some work on a particular feature. This means you would delete it as soon as you merge it into master, because that "feature" is done, at least for the time being. When you want to start work on it again, create a new topic branch for it, and repeat. 2) Use the topic branch as a long-running feature branch. If you were to do this, you should *not* merge it into master until it's completely done. This means the topic branch would co-exist with the master branch as long as you're still working on it. If you need to pull in updates from master, then you would either a) rebase the topic branch onto master or b) merge master into the topic branch (but *not* the other way around). Either way, you should pick one or the other. You typically shouldn't have a long-running feature branch that you continuously merge into master. As you've discovered, this makes for a lot of superfluous merge commits. We have a number of developers making lots of changes and our git repo is > REALLY complicated That sounds...not good. You should generally be able to make sense of your git repository. If you have so many branches and cross-merges laying around that you can't understand your history, you probably need to enforce some integration rules about which branches can get merged into which other branches and when they're allowed to do this. Have you read through http://nvie.com/posts/a-successful-git-branching-model/? It might help you keep things organized. This is another option if you need something a little more flexible: http://scottchacon.com/2011/08/31/github-flow.html. Hope that helps. Ryan -- 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/groups/opt_out.
