GIT workflows work with teams

GIT workflows are the code governance experience accumulated by teamwork. In agile development, selecting reasonable, flexible and reliable code management mode can optimize the limitation of wIP quantity in each stage of production and research, improve the efficiency of cooperation and ensure production safety.

Each team has its own code management process that needs to adapt as the business grows and the project size changes. Like agile, it is methodological rather than rote.

What does the workflow look like?

• Centralized workflow

Similar to centralized version control, where the central repository is the single point entity for all changes to a project, in Git we use the Master branch as the trunk branch and all changes are committed to the Master, whereas in a centralized workflow we use only the Master.

Using the strategy

Set branch protection to prevent conflicts from forcing overwriting

When a code conflict occurs, the change save temporary area is first merged into the workspace to resolve the conflict, and finally the temporary area is committed

• Functional branch workflow

Functional branch workflow is to solve the problem of functional module collaboration in the development process. It is not developed on the master branch. Each functional module is based on a special branch. Feature development leads to a Pull Request workflow, with each PR having the technical lead review the code, check it, and merge it into the master branch.

Using the strategy

Pull the remote warehouse, create a new branch feature based on the master and synchronize it to the remote, stipulate that the functional branch is the cooperative branch of the minimum requirement unit. In the process of raising and testing, Merge the branch request to the test branch, and Merge the branch to the master on the release line.

Git Flow workflow is a strict branching model around project release for managing large projects and strictly regulating the release process.

As the interaction center for developers, the remote repository collaborates with the four branches of Master, Release, Develop and Feature (feature is collectively more than one) to complete multi-environment and multi-task code management.

Using the strategy

Feature function branches are created based on Develop, and feature development is carried out on feature branches for a cycle. Multiple feature parallel development requires the establishment of multiple feature-XXXX branches

If a feature is ready to go live, merge it into the Develop branch and create a release-xxxx branch based on the Develop branch

Develop release tasks on the release branch, such as bug fixes, document updates, etc., merge the release branch code to master and Develop on production day, and record the version number of the merge on master and tag it.

Summary: This workflow is suitable for 2C products or projects with strict control over release products, as well as large projects dealing with parallel development of multiple requirements, with the Release branch for pre-production testing and develop for development testing.

• The Fork workflow

Open source secondary development projects such as fix React framework defects support business development while remaining consistent with future community releases.

• Making the workflow

Developed based on GitHub repository, open source projects strictly manage PR.

Workflow is a methodology to help code governance and production control. Problem-oriented workflow combined with classic workflow can help us accumulate our own practical experience.

Pre-design, task pool in the same project each module can be multiple people to deal with multiple requirements. Faster overall iteration requires code to be released independently of agile, fine-grained tasks. This is where the functional branching development process needs to be introduced.

• Need to merge

In multifunctional development, merging code into the trunk can cause conflicts. Conflicts are allowed if requirements are not explicitly split and there is strong coupling at the code level, resulting in code risk. Discussing the reasons for this can be complex, and it is recommended to consider the design process in advance and incorporate dependency requirements to avoid too much fragmentation. If objective reasons can not merge, special circumstances can use temporary version independent verification, independent online, all needs to give way.

• The risk assessment

Production risks may include inconsistency of data from multiple environments, so the same set of codes cannot guarantee the safety of the online process. Therefore, the testing stage will have strong constraints on the code, and different codes are not allowed in multiple environments. From the agile point of view, small and fast running, high-speed iteration, is bound to appear such differentiation. Risk needs to be properly judged for different projects, not one size fits all.

The front-end module division can be developed collaboratively on a main branch using a centralized workflow through multiple codebase folders. For projects with high scale complexity, involving cross-work and modular development, git sub-project association, or similar to lerna sub-project versioning can be adopted.

Promoted PR workflow, code base production code unified control, can achieve the technical level of code review. With the help of gitLab’s issue management and code annotation functions, the version code can be traceable and the knowledge base can be precipitated.

Versioning requires the establishment of a unified version tree from the required version to the deployed application version. The higher the project complexity, the uncertainty and uncontrollable are the obstacles to requirements advancement. The establishment of integrated version tree can assist team collaboration and promote the self-examination and application of each module

With version control, production risks are not always eliminated. Instead, the version is used to lock the scope of the accident and quickly locate the problem.

conclusion

The methodology comes before the workflow.

I advertised for a front-end development engineer at Autohome,