2

We have main two Git branches at our company: During our Sprint,

Everyone has (local branches)

Release branch: Contains prepared/developed code, ready for testing, and

Master branch: Production- final ready code

I read in Git, Cherry picking is bad.

https://blogs.msdn.microsoft.com/oldnewthing/20180312-00/?p=98215 http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html

After items are placed in master, they are ready to be deployed. Sometimes , we do not move all Release items into Master, many reasons:, delay schedule, conduct more testing, late issues. What is the proper Git Devops strategy to only move certain items into Master? Should we backout commits, so we can do a clean merge?

Databases are different, as we are conducting change scripts, and not overwriting binaries like applications, etc.

Example:

Release branch ------- -------------> Master

Commit A, B, C, D, E -------------> Commit B,D

2 Answers 2

2

I read in Git, Cherry picking is bad.

Be careful of such blanket statements. They take on a life of their one, and after a while you have a lot of myths in your team (or workplace) about no cherry-picking, no re-basing, no xyz. These are all just tools; there are times to use them, and times to not use them. Nothing is generally bad.

Sometimes , we do not move all Release items into Master, many reasons:, delay schedule, conduct more testing, late issues. What is the proper Git Devops strategy to only move certain items into Master?

Adam Dymitruk's Branch per Feature works splendidly for that. In short:

There are these branches:

  • 1 master branch
  • 1 qa branch
  • n feature-123 branches

The general principles:

  • Every branch starts at master.
  • Only feature-123 branches receive regular commits.
  • qa is created by starting fresh from master, and then merging any feature-123 branches that should be in testing. Whenever qa needs to be changed, it is created fresh again, there are no other commits into it. This happens very frequently.
  • When qa has been released/deployed, it is simply renamed to master and replaces the previous one. At this point, all remaining feature-123 branches are rebased onto the new master. The git rerere cache is used to avoid having to do repeated conflict resolution.

This scheme works great if you have developers who can stomach the rebases. You frequently find people who think they are bad, or who simply do not allow it - then you're out of look obviously. But if you get it to run in your team, it is very smooth, and ultra flexible. You literally never ever need to "back a commit out" or do cherry-picking to revert a commit, or whatever.

Read Adam's page, it explains this in more detail, but basically that's about it. You'll need to create your own tooling for the individual steps (for example, to pull the feature branches which are supposed to go into qa from your Jira instead of manually doing that), but that's not too hard.

Addendum:

  • Trivially, you can have more than one qa-type branch at any point in time. For example, you will likely start with one that always has all features which are deemed close to "done" (but which may not have successfully passed test yet); and maybe another one (let's call it rc - release candidate) which contains a subset of that for the very next release.
  • Adam also describes a ci branch; it is nice, but optional (we don't use it at all, and are not missing it).
0

we had the same problem, so now we have:

  • jira (stories and tasks)

  • bitbucket (git)

  • bamboo (automated builds all branches and before pull-request)

brachces:

  • production (only production release any time)

  • master (development but ready to production branch)

  • feature-branches (from master) -> (completed story/task + all tests) -> master

  • hotfix-braches (from production) -> all-branches-> production -> master -> feature-branches

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.