Clever Geek Handbook

Handle git branching for testing and production

When working with git (stream) and having a scene / test environment where the client does their reviews of things developed, what is the best way to handle features that are not approved along with features that are there?

Consider a scenario in which multiple developers work with different features in a sprint or continuous workflow. Features need to be reviewed by the client and in order for features to be viewed in the stage environment they need to be merged into a dev branch and deployed.

If, say, two features were developed, reviewed by the dev team and ported to dev. The client reviews them and approves ONE of them. But now the client wants to release an approved feature for production. The dev branch is currently "polluted" with unapproved feature code that cannot be ported to production.

What is the best way to handle such a scenario? Of course, it's actually more difficult. Cherry is building a solution or should the overall process and branch handling be revisited?

+1


source to share


2 answers


This issue (a dev branch polluted with "unapproved but already integrated" feature branches) is exactly how Raman Gupta describes it in How Git Creators Branching .

In your case (gitflow) you will need to undo the merge commit of the invalid features before the dev merge for release.

But "gitworkflow" uses ephemeral branches as opposed to gitflow:

GitFlow proponents having two perpetual branches - master

anddevelop

Both workflows (gitflow or gitworkflow) use the "feature" or "topic" branches:

Section branches use all of the work in progress - one branch for each issue, bug, or feature, and there may be many topic branches that develop at once.

The topic ends up merging into a " next

" branch in gitworkflow.
The key difference, however, is that a branch is next

never merged into master

(as opposed to an eternal branch " develop

" which should be merged into master

/ release

in gitflow)



Now that topic

finished before next

, it could be part of a beta or release acceptance. Thus, each next theme can now go through the second stage of stabilization, which is the goal of beta release / acceptance testing.

Note, however, that with gitworkflow we still haven't committed (no pun intended!) To have this topic

as part of our next production release - it still hasn't been merged with master

.
This is similar to the concept of the GitFlows branch release

, but much more flexible and powerful as it master

does not have any dependencies on it next

, and it also next

never merges into an option master

(unlike the corresponding GitFlow branches develop

and release

) .

If the next one isn't merged with the wizard, how do you end up releasing the product?

Once a theme is considered stable enough to be released, theme graduates will again be merged with master

(or possibly maint

) again with help --no-ff

to preserve the full history of the theme branch.

Why is it better:

Note that in gitworkflow, unstable and stable development work is never mixed in the same branch.

Unlike GitFlow, I have two options:

  • I can test my theme separately in my branch, or
  • I can combine it for development for testing.

None of the options are attractive.

  • The former does not offer a genuine test of stability to topics when deployed alongside other ongoing work, and
  • the latter obliges this topic to evolve, possibly before it becomes stable.

Value:

In short, in GitFlow there is always a "strong" unresolved tension between keeping development work clean and branch-isolated from the theme, and integrating theme branches with other work, merging them for development to make them visible and verifiable and to check for conflicts.
Gitworkflow allows you to achieve both goals without sacrificing one for the other.

+2


source


I think here's the correct way:

  • production (...)
  • master (dev branch)
  • feature123
  • feature234
  • feature345
  • function [number]

Provide the domain [number] .example.com to clients if possible. This way you can show the whole function before the merge in the master branch. If a function is refused, it should never be merged into master. If the function is accepted, it needs to be merged.

A good alternative is also a "staging" area where you need to deploy code when needed. Suppose your client needs to see feature42, ... just deploy feature42 to the domain customer.example.com

.

Where to develop a new feature?

feature[number] branch

Where to show the new feature?



feature[number].example.com

Where to see the next sprint code (master) at work?

next.example.com

or

master.example.com

Where can I see the production code?

www.example.com
+1


source






More articles:


All Articles