For code versioning, we went from dumb management when we didn’t have tools, to SVN later, to pervasive Git management. Git branch management strategy has evolved into several versions for teams of different sizes and different project development processes. The following is a general introduction.

Several version control methods

Local management

  • Each version corresponds to a folder; Iteration and version maintenance by copy and paste.

Centralized management

  • A central server to manage versions;
  • Download the version from the central, and synchronize the changes to the server;
  • Multiple people working on a version.

Distributed management

  • More local warehouses on a central basis;
  • Local repositories can handle version iterations independently;
  • A central warehouse allows for multi-person collaboration.

Comparison between Git and SVN

  • SVN centralized management, git distributed management;
  • SVN branch management is not as flexible as Git.
  • SVN is simple and simple to use, git needs to learn the cost;
  • SVN needs network support. Git has local repository support and is not strongly dependent on network.

flow

The following are the current mainstream branch strategies.

git flow

  • The basic Git workflow consists of five branches (master, development, features, release, repair) and two master branches (master, development).
  • The development and repair branches are cut off from the Master branch, and the two branches are merged into the Master branch. The repair branch also joins the current development branch;
  • The feature branch is cut off from the development branch;
  • The release branch is cut off from the development branch; Publish branches and merge them into the master branch and tag them.
  • Advantages: should have all;
  • Disadvantages: Complex, long-lived branches cause more conflict.

github flow

  • Very simple Git workflow, 2 branches (master, development branch), 1 master branch (master);
  • Branch off from master;
  • Rely on github pull Request to operate;
  • There is a process for reviewing mergers;
  • Advantages: Not so many branches; Each branch has a corresponding version number after merging.
  • Cons: This is fine for small to medium sized teams, larger teams can’t handle multi-branch management.

trunkbased

  • Git workflow for conflict resolution, 2 branches (master, release branch), 1 master branch (master);
  • Everyone develops on the Master branch;
  • Branches can meet the requirements of release at any time. Release branches are created and marked with the version number.
  • Bug fixes are performed in the Master branch;
  • Advantages: Simplify, agile is the most suitable, conflict resolution is basically gone;
  • Disadvantages: Multiple environment deployments can be problematic and you need to make sure every commit works.

aoneflow

  • Ali’s Git workflow; 3 branches (Master, feature branch, publish branch), 1 master branch (Master);
  • Three principles: a. Cut feature branches from master; B. Development branch Flexibly create release branch; C. Delete the feature branch and release branch and tag them.
  • Advantages: Flexible arrangement of release branch, support long time branch;
  • Disadvantages: With long branches, there will be conflicts.

The current practice

  • Requirements:
    • More than the environment; Many branches; Flexible release; Reducing conflict;
  • branch

    • Master, the trunk branch, the most stable version, all versions cut out to the source.

    • Development branch, DEV1.0.0, followed by iteration number, development environment common development version;

    • Test branch, Release1.0.0, ready to publish branch, merge from Dev1.0.0, deploy test environment and pre-release environment;

    • Feature branches, which cannot be released with the release, are cut from the master and merged into the development branch of the week to be released, requiring that the master be merged weekly;

    • Master, which is maintained by the administrator and manages branch creation;

    • Test branch plus protection, relying on pull Request, merging in Gitlab/Github bill of lading.