-1

We are redefining the way we move commits from dev branch to prod branch. We are mostly following Kanban based approach where stories comes in develop it, move to QA, stays at QA and then moves to preprod when it was tagged for release and finally to release.

We got a dev branch, then we got a QA and Release. Developers will work on dev branch then cherry pick the commit to QA and QA team validates the story. The changes will stays at QA and moved only when it was tagged to a release. Once it is tagged then cherry pick to Release.

Since the tickets was not moved immediately after the developing it, working on a release is a pain full tasks to cherry pick all the changes from QA to Preprod. There are some situations where some commits missed during cherry pick.

Proposed approach

Another approach was discussed that the user will create a feature branch from dev and merge the changes back to dev once the MVP completed. Then cherry pick the merge commit to QA and release. So for a release of 25 stories, we will have only 25 commits ideally all of them are merge commits with Jira Id.

Please suggest any drawbacks any other suggestion to improve our process. The use of feature flags are not considered at the moment.

We are using GitLab as the source control application Thanks for your time.

James Z
  • 12,209
  • 10
  • 24
  • 44
kbvishnu
  • 14,760
  • 19
  • 71
  • 101

1 Answers1

4

There are dozens of git workflows out there, but I have never seen anyone recommending either of the options you're describing, for two very fundamental reasons:

  • Cherry-picking changes removes all tracking of the relationship of that commit to any others. It means your branches have no relationship to each other.
  • Merging is something that should happen after you're happy with a change, not before. Otherwise, you are always testing an essentially random mixture of approved and unapproved changes.

The details vary, but nearly all git workflows follow some variant of this basic pattern:

  1. Develop on a short-lived per-task branch. Keep it up to date by merging in / rebasing onto a central branch if necessary.
  2. Test the task on that branch. Until it has passed quality checks (e.g. manual and automated tests, peer review, style checking, etc) you don't want it to affect other people's work.
  3. Merge (not cherry pick) to a long-lived branch of some sort. That might be the main branch that gets released directly, or a "development" or "QA" branch of some sort, depending on the workflow and task type.
  4. If necessary, periodically merge everything (always using a true merge, never a "squash" or "rebase") from one long-lived branch to another. For instance, you might create a release by merging everything from "development" to "production", or from "qa" to "release", etc.

Note that once something is merged at step 3, there is no way to forget it at step 4 - unless you actively revert it, it will be included when you merge to another branch. At any time, you can see which commits will be included in such a release by comparing the branches.

See also my answers to this question and this one.

IMSoP
  • 89,526
  • 13
  • 117
  • 169