William Lasiewicz <lasiew...@gmail.com> writes:
> I am looking in to it and the cherrypick command looks like what I am 
> lookng for.

I'm no expert, but I think you can make that work.

> Developers will check in to the staging branch and we we are satisfied with 
> the changes,  we want to merge those checkin to release.  We won't want to 
> merge the whole branch only certain checkin ( in perforce they are 
> changelists)

I think that with Git it might work better to use a different model:
Developers push their changes back to the server, with each change being
its own branch off of the main branch.  (Since branches are cheap in
Git, this is not a problem.)  Then once "you" are satisfied with any
particular change, you can run git-merge in a working copy of the main
branch to merge the commit/branch of a particular change.  (And delete
the branch-name of the change; the change's commit will live forever in
the repository.)  If the git-merge fails, there is some conflict between
the change and the changes in the main branch since the change's commit
was created, and the developer has to rebase his change to a newer
commit on the main branch.

If a developer creates a series of changes that have to be installed in
order (one depends on another), that can be pushed as a branch with two
commits.  Then a git-merge can be done in the main branch from the
oldest of the the sequence of commits, then later a git-merge from the
next-oldest of the sequence, etc.

There's not much to be gained from forcing all the changes to be put
temorarily on a staging branch (unless you intend to move the changes
from the staging branch to the main branch *in order*.)


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