Thanks for your quick and descriptive answer. And sorry for the question which is not properly written.
Actually, I have no detailed understanding of the Git flow or Trunk based development. So, what we manage is based on our requirements.
like, there is 3 environments of the project.
- Dev environment where integration testing will be done. all team completes their small or big feature development. Unit test in their local environment and merge it into the release/dev branch for integration testing.
- This release dev branch is initially created from the master branch only.
- when any new feature development started, a new branch is created from the release/dev branch.
- Stag environment where all the features will be merged which are to be released on the next production release. We don't have any concept of setting a TAG. So, whenever it is decided that in the next release feature1, feature 3, and feature 5 will be released, we merge those branches into the release/stag branch. resolve merge issues if any.
- This release stag branch is also initially created from the master branch only.
- Production environment where all last tested stage branch code will be used. This is a master branch. Stag code is merged to the master branch when required to release.
I also read one post https://www.toptal.com/software/trunk-based-development-git-flow
If I compare the above commit workflow then it is not a pure git flow or pure trunk based.
I have always advocated (assuming you don't have a very unique scenario, and truth be told, very few orgs have such scenarios) to only have one integration branch—that is your development branch (you can call this main, develop, master—I'll refer to it as main hereon).
Everything is created off this branch, and disappears as soon as a release is done (I am assuming some variant of the GitFlow model here, and not trunk based development). How would this work?
- You are ready to release—create the "release" branch from the commit on main that is going to production. This is the code that represents the next release
- Deploy it to whatever environment, test it, and make sure all is well. If you find bugs, fix them on the release branch
- Once you are done, the tip of the release branch represents the version that you will take to production
- Deploy that to production
- Tag the commit on the release branch (more on this in a minute)
- Merge the release branch back to main - This is important b/c you want all the fixes you detected on testing and the tag you just created to be part of the main history
- Delete the release branch
The reason for the tag is so if you have a production bug, you can check out the tag, create a branch, make a hotfix, deploy that to production, and then merge that "hotfix" branch back to main.
I think this is really a very good way if it is rapid development and rapid release. But what if we have already merged 3-4 features in the main branch and also resolve merge integration issues on the main branch too (That is the same dev branch). But after that, it is decided that only 1 feature should be taken out of it and released on production?