William Lasiewicz <[email protected]> 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*.) Dale -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
