What is Git Workflow and how to use it?
4 types of git workflows you should know about, and how each type looks. What are the pros, cons, and usage guidelines?
- Simple branch — This is the simplest and clearest. That is, we are only working on the branch master, with every commit of the change going on this branch together, not having a separate branch, it is better suited for small projects with few teams or to do it.
2. Feature branch — That is, in the pre-editing phase, we have to break the branch from the Master branch. This is the first simple branch problem fix, that is, our Master will not move quickly and reduce the merge conflict problem, with the features being developed before being able to merge to the Master branch. This feature branch will disappear once we’ve developed it. (Short-lived) For this method, it is necessary to be careful as the feature branch is too long and far away from the master branch, the solution is to gradually merge the master into its own branch, and the other is to provide features that each person makes to be smaller. It will help reduce these problems as well.
3. Develop branch — What if users want to try out the programs our team is developing? If we let the user test on the master branch using the two patterns mentioned above, then the problem will arise. That is, there will always be various features or bug fixes that may affect the user experience. Can cause many errors Therefore, the following format is an attempt to create a long-lived branch, followed by a master branch, for development only. If asked when to use it, imagine when we want to let the user test the program. Without wanting our development to affect its use
4. Release branch — From method 3, we can divide the source code into 2 types of usability, that is, the master branch is used for the user to actually use the development branch, the line of the development team. That may be used to try to test the integration code to see what is the problem So as not to affect the actual user But when the feature is released, usually they will not be released after the development is complete. But there will be a test first to see if the features in that period can work as expected or not. It also has a business-side effect that releasing new features sometimes requires promotion and a clear schedule. Thus, the idea of creating one more branch is the release branch that will hold the finished feature first, then merge it back to the Master when it is tested. This concept is similar to the feature branch but looks at the fact that many features are put together as a release cycle.
This is the link about the Release branch if you want to learn more.
A Branching and Releasing Strategy That Fits GitHub Flow
Of the 4 points above, here are the Git workflows that we usually meet when starting a project. But there are many people who start out with Git-flow, who may forget the origins of the branch breakdown or the design of this kind of implementation. Studying the basic concepts and understanding them well will help, so we don’t have to follow them all forever. But choose a position that is suitable for the problem we face.
