On Thu, Mar 26, 2009 at 08:53:22AM -0700, François Montel wrote:
> Some advice needed on the best way to go about the following scenario:
> I have a branch "master" which my production site runs on (in this
> case, using git for a web app).
> I have a branch "testing" where I create new features and which my
> development site runs on.
> Both of these branches reside in an online public repository. The
> development test site pulls from the 'testing' branch in the online
> repository. (I also test on my own computer, but I also have a
> development test jail that's identical in setup to the production site
> jail so I can make sure that it runs correctly under the same
> conditions.)
> I push my 'testing' branch to the online repository, for a final test
> on my development site.
> Once I'm satisfied, I merge it into my 'master' branch, and push that
> branch to the online repo.
> My question is about the merge. I currently have to do:
> (I'm on branch 'testing'.)
> $ git stash save current (maybe I have something else going on right
> now)
> $ git checkout master
> $ git merge testing
> $ git push
> $ git checkout testing
> $ git stash pop current
> That works, but it's so many steps that I feel I must be doing
> something wrong (I have a script that does it with a single command,
> but still...). What I would like to do is to be able to merge all the
> commits from 'testing' into 'master' without having to checkout master
> first and then go back to my 'testing' branch. In other words a sort
> of "push-merge" instead of "pull-merge". Is that possible? Is there
> another way I should be doing this? I've read through the git docs but
> couldn't find a better scenario though I probably missed something.

Can master ever diverge from testing? I.e. does it have any changes
testing doesn't? If so, you need to do the checkout since some files
need to have their content merged, potentially; you could work this
around so that this merge does not destroy your current working tree
state using low-level plumbing commands, but it would be pretty
hard-core so I wouldn't go that way unless you *really* care.

But I suspect you just want to say "now, make master point to the same
commit as testing", that is this merge is actually always a
"fast-forward" merge? In that case, this is much easier; one way might
be simply to

        git branch -f master testing

which will forcibly re-create master, pointing at the same commit as
testing. Alternatively, if the only thing you ever do with master is
pushing it out, you can do the push right away, pushing local branch
testing to remote branch master; you can do and automate that using
refspecs, described in git-push(1) in detail.

                                Petr "Pasky" Baudis
The average, healthy, well-adjusted adult gets up at seven-thirty
in the morning feeling just terrible. -- Jean Kerr

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to