background

Currently, the team is relatively small, and there is no set of specifications for the operation of Git in collaborative development. So much so that in development, branch names were arbitrary and there was no clear specification for the test/live branch. The submitted message is also arbitrary. As a result, there are frequent conflicts during merge branch deployments, and the commit log can be viewed haphazardly, not allowing other maintainers to see at a glance how the code has changed or why it has been modified.

Based on the disadvantages mentioned above, referring to git specification documents on the Internet, we sorted out a set of Git operation naming specification and development process. We hope that we can use this as a yardstick to unify git naming and operation specifications and improve the efficiency of collaborative development.

Branch management

Branch type and naming

1. Permanent branches

Git repositories have two main branches: Master and Develop.

The master branch

  • The master branch is automatically created after the version library is initialized and is used to deploy branches in the production environment. Ensure the stability of the master branch

  • The Master branch is usually combined with the Develop and Hotfix branches, so you can’t change the code directly at any time

  • Only the administrator can push the master branch. To merge the master branch, the administrator needs to submit a Merge Request for code review before merging the master branch

Develop branch

  • developFor the development branch, always keep up to date with development completion as wellbugFixed code
  • In general, when developing new features,featureBranches are all based ondevelopbranch-created
2. Temporary branches

Function branch feature

  • When developing new features fromdevelopCut off the branchesfeaturebranch
  • Branch naming conventions:feature/Start with a meaningful new feature or module name, such as:feature/user_management(User management requirements),feature/power_manangement(Power Management)
  • If multiple people share a functional branch, then native codepushBefore must pass the self-test, at least to ensure that the main process goes through, the page is normal access.

Test branch test

  • whenfeature/XXAfter the branch development is complete, merge the code intotestBranch and deploy to the test environment and enter the test phase
  • If the test process existsbugIf fixes are needed, it is up to the developer to branch in its functionalityfeature/XXFix and merge totestBranching regression test
  • When the tests pass, you need to branch out the functionalityfeature/XXIncorporated into thedevelopBranch for regression testing
  • Test branchtestMultiple development branches may be merged simultaneouslyfeature/XXDifferent development requirements may come online at different times, sotestBranches cannot be merged directly intodevelop

Fix branch hotfix

  • If an emergency occurs on the line and needs to be handled in a timely manner, you need to repair the branchhotfixforbugrepair
  • Branch naming conventions:hotfix/xxx, naming rules andfeaturesimilar
  • Repair branches frommasterCreated on the main branch and needs to be merged intodevelopandmasterbranch

Common operations

1. New functions

When receiving a new requirement, you need to create a branch, develop the requirement, and submit the code

(master)$: git pull                           # pull the latest code before creating a branch based on the master branch
(feature/xxx)$: git checkout -b feature/xxx   Create new branches of functionality
# coding...
(feature/xxx)$: git add -A                    The code to be submitted will be modified, deleted and added to the file in the staging area
(feature/xxx)$: git commit -m 'Submit content Description'    Add the staging code to the local repository
(feature/xxx)$: git push origin feature/xxx   Upload the local branch version to the remote repository
Copy the code

Git add. includes content modification and additions, but does not include deletions

2. Merge to the test branch

When the requirements are developed, they need to be merged into the test branch

(feature/xxx)$: git checkout test             Switch the current functional branch to the test branch
(test)$: git pull origin test                 # pull the latest code from the test branch
(test)$: git merge feature/xxx                # Merge the functional branch into the test branch
#If there are conflicts, resolve all conflicts locally now(test | MERGING) $: git add - A # deposit just modified files to the staging area (test | MERGING) $: git commit -m 'resolve file conflict.. '# staging area code added to the local repository (test | MERGING) $: git push origin test # upload local branch version to remote warehouse#If there are no conflicts, push directly to the remote repository
(test)$: git push origin test                 Upload the local branch version to the remote repository
Copy the code
3. Perform other common operations
$: git clone xxxxx.git                        Clone code locally from remote code base
(develop)$: git status                        Display the current modified file
(develop)$: git branch                        # View local branches
(develop)$: git branch -r                     # View remote branches
(develop)$: git checkout [filename]/This command restores specified files/all modified files (excluding new ones).
(develop)$: git log                           You can view the [HEAD] and [message] of the commit record.
(develop)$Git diff: git diffIf the file name is not specified, the difference between all files is displayed
Copy the code

Note:

Git fetch is to pull the latest content from the remote host to the local, which the user checks and decides whether to merge into the working native branch.

Git pull is used to pull down the latest contents of the remote host and merge them, that is, git pull = git fetch + git merge. Conflicts may occur and need to be resolved manually.

The log specification

Git is the most popular version control tool, and a well-written Commit message can greatly improve code maintenance. Not only does this serve as an important reference to the release log, but it also gives future maintainers a clearer picture of why the current code is changing.

1. What specifications

One popular approach is Conventional Commits, which are inspired by, and largely based on, Angular Commits. The contracted commit specification is a lightweight convention based on commit messages. It provides a set of simple rules for creating a clear commit history; Describe new features, bug fixes, and disruptive changes in your commit information. Its message format is as follows:

< type >[Optional scope]:< Description >[Optional text]Copy the code

2. How does it work

We agree that the format for submitting a message is :< type >[optional scope]:< Description >

Description:

  • Feat: Add a new feature
  • Fix: Fixes bugs
  • Style: Tightly modified style
  • Refactor: Code refactoring

Feat and fix are commonly used

The value is mandatory

Scope[Scope]:

Scope Specifies the scope of this code modification, such as the modified user module, account module, etc. The scope is optional

Disc < description > :

Describe the major changes. For feat you can write the title of the requirement. For bug you can describe the specific problem solved.

The content must be a meaningful description, no use of AAAAA submission code, etc

For example:

(feature/xxx)$: git commit -am 'Feat [user]: Add profile picture upload function to User Center'
#or
(feature/xxx)$: git commit -am 'Fix: Fixed a bug where users failed to upload their avatars'
Copy the code

For the front end, the lack of constraints on commit Messages in daily development can result in arbitrary, uneven quality, and poor readability. In addition to consciously complying with our agreed specifications, plug-in tools can be introduced to verify the format of commit Message and combine with Git hook to verify the format when submitting code. If the conditions are not met, commit is prohibited. You can search for the verification tool and configuration method.

Documents that respond can be searched based on these keywords:

commitizen & cz-conventional-changelog

commitlint & husky

Collaborative development process

Code conflicts often occur when multiple people are working on the same repository, so good practices can minimize unnecessary code conflicts.

The specific operation process is as follows:

  • Before you create a new branch, make sure youpullThe latest code, and then create the branch
  • commitBefore we do that, we need to put the codeaddGo to the staging area in case the code is not committed
  • commitAfter that, firstpullHere is the latest code for the current branch (if multiple people share the same branch development)
  • If you want to merge the current branch into branch B, you cut to branch B first,pullRemerge the latest code
  • If the merged branch has a conflict, the conflict must be resolved locally, and thenaddandcommitcode
  • And then at the endpush

In general, before committing or merging code, always pull to make sure the current branch is the latest code.

The resources

Front end test treasure book

Front-end Git operation naming conventions and collaborative development processes

Git branch development specifications you must know

Front-end project Git operations naming conventions and collaborative development processes

Git commands and methods