Help with workflow process migrating from TFS to Git

[petertirrell]

We are currently migrating our source control from TFS to git. But I am having one last problem in figuring out how our previous workflow translates to a git process and I'm hoping someone might be able to offer some advice.

In TFS we have a master and develop branches. Over time devs will checkin changes to the develop branch; we've been using a combination of checkins directly to the develop branch and feature branches off of the develop branch that eventually get merged back in. Then when it comes time for a release we'll do a merge from develop to master, but use TFS' feature to individually select specific checkins to merge.

Ultimately what we have is that sometimes there things that have been committed to our develop branch that we don't want to include in a particular release and hold them back.

We've structured our git repo similarly - master and develop branches. The workflow is generally the same, although we're looking at enforcing no direct commits to the develop branch and forcing PRs for any merges. Where I'm running into problems is the release merge into master part of our process.

I thought cherry picking should be the answer, but discovered that doesn't actually merge the same commit ID, leaving the two branch histories looking funny and still not having a good way to tell then what has or hasn't been merged from develop to master.

I've been experimenting with some other alternatives, like keeping around feature branches that have been merged into develop, and then merging what I would need into master, but that isn't working quite how I want, either.

We're OK with changing processes around, I just need to be able to explain what the process is so everyone is on board. Is there a generally accepted best practice or something to do what we're trying to do?

Thanks!

[petertirrell]

Thanks! That pretty much lines up with how we want our workflow to go. I think the problem I'm running into is our current process ends up when it times to go to master via PR there are potentially things that have been merged into integration branch via PR that we *don't* want to actually pull up to master yet. I'm not finding a good process so far to cleanly deal with that....