git development workflow with branches

https://git-scm.com/book/en/v1/Git-%E5%88%86%E6%94%AF-%E5%88%A9%E7%94%A8%E5%88%86% E6%94%AF%E8%BF%9B%E8%A1%8C%E5%BC%80%E5%8F%91%E7%9A%84%E5%B7%A5%E4%BD%9C%E6% B5%81%E7%A8%8B


Long-term branch
Since Git uses a simple three-way merge, it is not difficult to merge a branch into another branch repeatedly for a long period of time. In other words, you can have multiple open branches at the same time, each branch is used to complete a specific task, and as development progresses, you can always merge the results of a feature branch into other branches.

Many developers using Git prefer to work this way, such as keeping fully stable code only in the master branch, ie code that has been released or is about to be released. At the same time, they also have a parallel branch called develop or next, which is dedicated to subsequent development, or just for stability testing - not necessarily absolutely stable, of course, but once in a certain stable state, It can be merged into master. This way, after ensuring that these completed feature branches (short-term branches, such as the iss53 branch before) pass all tests and do not introduce more bugs, they can be merged into the main branch and await the next release.

Essentially what we just talked about is a pointer that keeps moving right as the object is committed. Stable branch pointers are always a long way behind in the commit history, while leading branches are always ahead