1. What is Git

Git is a distributed version management tool that is divided into remote repositories (cloud repositories stored on back-end servers) (repository: repo) and local repositories. The maintenance mechanism for both the local and cloud repositories is similar in that they are maintained using a tree-like data structure. Each change to the contents of the file is a node (blob node), and each COMMIT is a Tree node, which carries information about the actions of the code and the node type. See: Portal.

2. Advantages of Git

  1. Git is distributed and has local branch management, so you can maintain it locally even if you don’t have a network.
  2. Every change to Git is a node, so every change to the contents of a file can be saved separately and managed on a case-by-case basis. All changes can also be seen after all the code has been merged, whereas other version management tools cannot.
  3. Git is very fast because it takes a full snapshot of the file with each change. Trade space for time.
  4. Because Git has memory problems, it has its own memory maintenance mechanisms, such as deleting useless nodes, packing history, etc.
  5. Git has many commands that can be used flexibly. See: Portal

3. GitFlow Collaborative workflow

In fact, GitFlow is not a technology, but a code development merge management process mindset or management method. A soft contract that everyone developed together.

3.1 The origin of GitFlow

Why do we need GitFlow as a Git management process? There are several reasons

  1. There is a stable version of the code branch that can be safely released online.
  2. Before the code is put up for test, or the code reaches the pre-release state, programmers can continue to work on the next version during test delivery (squeezing out every second of development – – “).
  3. There is a branch that allows us to fix bugs online in a timely manner, and we don’t want to commit code under development to online production in the process.

Due to the above requirements in the development process, GitFlow and Guozuo flow came into being. The corresponding point is 0

  1. Code sharing
  2. Code in different environments does not interfere with each other
  3. Manage code consistency with the environment

3.1 Branch roles in GitFlow

  1. Master branch: A branch of stable version code that is used as a release environment and can be released on every commit.
  2. Feture branch: Function branch for developing functions (requirements) for the development environment
  3. Developer branch: Development branch that merges the code in Feture into the Developer branch once the function development within the Feture branch is complete. When the merge is complete, the function branch is deleted. This branch corresponds to the integration test environment.
  4. Release: The pre-release branch, which does the pre-release work, corresponds to the pre-release environment. This branch will ensure that development continues to move forward and will not be held up by a release. Once the Release branch reaches the publishable state, we need to merge the Release branch into both the Master and Developer branches to maintain code consistency, and then remove the Release branch.
  5. Hotfix branch: The online bug repair branch, which is maintained with Hotfix every time a bug is fixed in the online code and merged with Developer and Master. Delete the branch when done.

These are all the role branches in GitFlow, from which we can see the following:

  1. Master and Developer need long-term maintenance and are also the main line of our development.
  2. The operations of relesase and Hotfix branches are fragmentary and troublesome, and errors are easy to occur in the process, leading to code inconsistencies. So we need a good tool or script to do this.
  3. This set of processes is cumbersome, but it can be applied to almost any development process: Waterfall, Agile

3.2 Advantages of GitFlow

  1. Adapt to multiple scenarios
  2. The development schedule is not affected
  3. Branch use is relatively organized
  4. Ensure that the online version is stable

3.3 Disadvantages of GitFlow

Of course GitFlow isn’t perfect, it’s just a management idea. Here are some of its weaknesses:

  1. This is because git-flow uses git merge –no-ff to merge branches. In a multi-branch environment like Git-flow, the whole project’s log can become very messy.

If the feature is merged into the developer branch, use the -no-ff parameter. If the feature is merged into the developer branch, do not use –no-ff **What is git merge –no-ff:

--no-ff indicates that the fast-forward mode is forcibly closed. In fast-forward mode, when conditions permit, Git directly points to the HEAD of the merge branch to complete the merge. In this case, if you delete the branch, the branch information will be lost. Commit git merge --squash is a way to compress any commit that you don't need. For example, if your feature has a messy commit during development, you don't want to bring that history with you. So --squash is used to merge the file. At this time, the file is the same as the merged file, but the HEAD is not moved and the commit is not done. An additional COMMIT is required to "wrap up" and complete the final merge. Conclusion: --no-ff: The fast-forward merge is not used, and the commit history of branches is preserved. -- Squash: The commit history of branches is compressed into oneCopy the code
  1. Maintaining both the Master and Developer branches is often not necessary because in many cases the content in Master and Developer is similar. Especially if you want to roll back someone’s submission, you may find it a little tricky. And in the process, you switch back and forth between branches of work, and sometimes you don’t switch, and you commit to the wrong branch, and you have to roll back and resubmit, and so on.

conclusion

GitFlow is a good way to look at it, because it has a comprehensive application scenario, solves the problem of branch chaos during development, and provides a strategy and thinking for code branch management. But it’s not perfect. I feel that this branch management standard is only one of the myriad branch management strategies, and we can completely modify and adjust it to find the management strategy suitable for our own team. Here are a few things we can look at when looking for our own strategy:

  1. Different teams develop in parallel

  2. Consistency between software versions and code

  3. Environment and code consistency

  4. Make sure you have a stable source of code online

  5. Incorporating a DevOps based development process (which is the root, the future)

Here are some other strategies for those interested to check out: 6. GitHub Flow 7. GitLab Flow