Git best practice for one or more branches
I am currently working on a remote team with several developers. We are all from different places. Sometimes or most of the time we work on different things, sometimes on the same things.
If, for example, I am working on a feature A
(on branchA) and my colleague is working on a feature B
(on branchB), what would be the best practice to commit our work.
- Merge branch A to master, build / run tests / deploy
- Merge branch B to build, build / run tests / deploy
or
Detach branch name develop
from master
and then merge branchA
and branchB
and then execute / execute tests.
If all goes well, do step 1 and 2 and deploy the master to prod.
I mean using develop
- a way of getting features from multiple branches into one version for QA.
But by using a development branch, you get another additional branch to maintain, and you basically merge the same branches to master again.
What are the approaches that work for your company / similar situations? Are there best practices for these situations?
source to share
Using feature branches (branchA and branchB) is great practice.
In general, a production project should have a separation between stage / QA and production. Whether you are doing this in source control or with system packages, or whatever your project is.
If you decide to separate staging from production in Git, I would recommend mastering the development tree and producing the production tree. What for? The developers are going to merge as usual in order to cope, all the documents speak of merging with the owner, do not fight with him.
The manufacturing industry is not a big service problem. Basically you will be doing simple master merges that should be fast forward, very easy and cheap in Git. You might want to force the merge to record every time production is updated, or you can use tags. The important thing is that merging with the master to production should only be done by the release manager, not by random developers (in a small store, the developer can also be the release manager).
Another advantage to the manufacturing industry is hot patch recording. If the emergency and the production master are not ready for production, you can hot-patch directly for production. Then that hot patch can be cherry-picked, returned to the master for proper testing.
You might want to have three branches. master for development, QA and production for production. the master merges into the production and, if he passes the tests, the production merges with the production. This gives QA a stable branch to work with, while production remains a faithful replication of what is in production.
You can also implement this with tags, have an intermediate and production tag that you move around, but this is not as flexible as a full branch. Tags in Git are just branches that don't move, and you'll want to move those tags. Hot fixes and cherry picks are trickier with tags and problems if major permutations will arise.
Basic workflow ...
feature_branch <---> master --QA--> staging --Release Manager--> production
Note that merging is always done the same way, except between feature branches and master.
Manufacturing Emergency Workflow ...
staging + hot patch --Release--> production --cherry pick--> feature_branch
... and then the normal flow from feature_branch. By fixing a stage first, you can at least start it with an accelerated QA process. A hot patch may cause conflicts in the next merge, so get the correct patch via ASAP.
source to share
If you want to mark the release of ready-to of QA, idiomatic way to do this is to git with tag , While other SCM tools such as ClearCase or AccuRev, use the hierarchy to refer to the development / test / release phases, I've never needed it in none of my projects or teams, and I don't foresee it. The main purpose of git branches is to do parallelism. Unless there is parallelism between the various development efforts, your branch branchA
and branchB
should be sufficient.
source to share
All of these methods ultimately point to one goal - to deploy your code to production, or more generally to release a version of your product as quickly as possible. You almost never want to link to the branch master
that is being used to deploy to production. A clean and QA approved feature branch is everything that needs to be merged with master and nothing else (unless you are doing some basic refactoring).
With a separate branch develop
, you don't have the risk of unnecessary commits made by developers just for testing on prod master
. In most cases, features created by developers should have a set of commits just for testing. Doesn't make sense to change the flag or add a debug-only log in the prod master branch? You just dump your commits on the branch develop
and continue testing. But leave a cleaner history in the prod master branch just for committing commits that code the logic. If you generally want to keep track of a specific feature and its development workflow after the code has been deployed, you have a cleaner and smaller set of meaningful commits to look for in prod.master
... It just gets a lot easier and allows your team to spend less time on issues like this.
Plus, with a separate branch, develop
you don't have to worry about your developers using code when deploying. Not to mention, the QAs task becomes much easier with a separate branch develop
.
source to share