We want to switch to GIT, but we need a workflow

Question

We want to switch to Git, but whats holding us back is a workflow. We use perforce. We have several teams all sharing the same codebase. We currently have two branches, Stage and Release. We merge from stage to release every day by changset. We never will be ready to merge all of stage to release. This works very well as we can merge in one dev's changes or a whole team. Its all automated and devs only get involved if there are conflicts.

I looked into merging with Git, which works very well for branches but not on the changset level.

What would be the best way to move our workflow to Git without giving up the flexiblity we have now to merge any changeset we want?

Answer 1

cherry-pick is a command that could be used to merge arbitrary changesets.

You may also rethink your workflow when bringing the new tool. Branching for instance in git is fast and cheap, you can pick one of basic strategies described here or figure out your own. And you don't need any tool for merging, it just works.

Answer 2

You can merge by changeset in git; it is called cherry-picking. With no conflicts, cherry-picking can proceed without developer intervention. You may also be able to periodically rebase your development branch(es) off release to make the actual points of divergence between them more clear.

Answer 3

There are three techniques that can help you.

First, while on Release you can cherry-pick just the change-sets (commits) you want.

Second, if some (prefix) fraction of Stage is merge-able, you can merge just up to the latest commit you want, leaving the rest of the branch un-merged. This may be an unlikely scenario for you.

Finally, instead of adding change-sets directly to Stage, you can make little branches for each new feature; merge such a branch into Stage for testing along with all your other features; then when that feature is accepted, merge just the original small feature branch into master.

I strongly recommend the third approach. It gives you the greatest control and still meshes with the workflow to which you are accustomed.

Answer 4

You can merge your branches with cherry-pick Git command. It can used for merging range of commit.

Example command cherry-pick A..B and cherry-pick --stdin. Read Git create branch from range of previous commits?

Answer 5

While others have rightfully pointed you to git cherry-pick, you should understand that "the changeset" might have broader meaning that you might originally maintain.

The thing is, most people, supposedly including you, mean that "the changeset" is the same as "the commit". But it might be more productive to think about features the developers implement, and which got staged, tested, possibly refined and then propagated to the production-ready line of development.

Once you think about features and not changesets, your approach to branching and merging might become less rigid.

You may have each developer/team have a separate branch for each feature or bug fix they're working on. That is, don't develop everything on a single staging branch. Then when a feature/bug fix is ready, that branch gets merged into a testing branch (it might be your single "stage" branch or a separate branch), may be quick-fixed with the fixes cherry-picked back into the branch which changes they fix, and then that branch might be deemed as "ready" merged again — this time into the "production" branch.

Another approach is to have a policy of not having more than a single "feature" branch curently being tested on the "testing" branch, and then when the testing gets finished the testing branch itself might be merged into production branch (Git is fine with repeatable merges).

You might consider reading the "Repositories, branches and documentation" section in this document which details how the development of Git itself is maintained, and this one is considered to be a "go-to guide for Git workflow" by many. Please do not treat these guides as dogmas though — they are there to demonstrate you what approaches people use successfully in production. To contrast, github uses a radically different approach which is also interesting.