CODEWITHSUNDEEP
gitgitlab
PaszaVonPomiot
PaszaVonPomiot

Reputation: 199

Proper git flow with testing branch

I'm struggling with designing proper git flow and I wonder if you could help me. We have 3 developers and requirements are:

Current solution is a bit complicated and I'm not sure if git was supposed to be used this way. For example developer1 always pulls from "develop" branch to his local "dev1", if needed he can push to "test" branch where automatic build will happen on TST environment. Once developer is sure it works he can push changes to his own remote branch "dev1" and merge it to "develop" where code review happens. Here's how it looks:

enter image description here

Do you have better idea how this should be set up?

Upvotes: 0

Views: 2534

Answers (2)

Schwern
Schwern

Reputation: 165586

For example developer1 always pulls from "develop" branch to his local "dev1".

This is the problem: long-lived per-developer branches. This implies ownership of the code in the branch, as well as many different features and bug fixes getting mixed together. Git Flow should not have them. Remove per-developer branches from your workflow. Developers can still have them if they like, but they're not part of the normal process.

Instead, use one short-lived branch per feature. "Feature branches". They're used for one and only one feature. This could be an individual issue or task which provides an easy naming scheme: issue/#1234 is the branch for issue 1234. When the feature is done they're merged and deleted. A fresh branch is opened for the next feature.

Feature branches fit into Gitflow, they are branches off develop.

we need to have a branch that developers do merge requests where code review happens

Feature branch, pushed and made into a merge request.

we need to have branch where developers can push anything for testing without code review (this branch is source for building on TST environment in OpenShift)

Feature branch, pushed and used as the source for your TST environment.

Upvotes: 1

Khalil Khalaf
Khalil Khalaf

Reputation: 9397

Short answer:

Branch off of master and create branch called "Integration". Devs will branch off of master as well, but push into "Integration". Test "Integration" (or code review) all day all week all month, once you are satisfied, merge it into "master". Devs at this point could (would want) to rebase their branches with master, or delete their branches (done developing the feature) and create a new branch based off of (the new updated) master.

This way, master is always ready to be delivered since 1) It is stable at all times (no Devs are pushing half baked unreviewed code directly into it) and 2) it is tested at all times (from "Integration").

Upvotes: 1

Related Questions