Git usage specification && Git common commands

branch specification

master branch

The branch HEAD of the master and the historical commit are both in a stable and releasable state.
Each commit of the master branch needs to be tagged, such as v1.0, v1.1, v1.2, v2.0, etc.
It can only be merged from the test branch and the hotfix branch.
Merging of hotfixes must be verified through code review and testing.
When merging from test, both the quality status approved by the test and the functional status approved by the product must be achieved.
Only the team leader and the person in charge of the master branch have permission to submit code

dev branch

The main development branch, cloned based on the master branch, theoretically speaking, the code of the dev branch is consistent with the master branch

feature branch

When the scope of code changes is large, a feature branch can be cut from the dev branch for development.
For code refactoring, cut a feature/feature_security branch.
Multiple feature branches can exist at the same time
New changes cannot be merged from the dev branch in feature branch iterations.
If only one person is responsible for the development of the corresponding feature, and there is no need for collaborative development, it should only exist in the local warehouse and not be pushed to the remote warehouse.
Theoretically speaking, the feature branch is pulled by the team leader before the development of the requirements. The branch naming convention is: feature/feature_function name. For example, the security transformation 2.0 development branch is: feature/feature_security2

test branch (only the team leader merges the code)

Test branch, after the feature branch is merged into dev, in the testing stage, bug fixes can be directly modified on this branch or directly merged from the feature branch to the test branch
The test branch can be merged by the team leader when testing
During codereview, you can compare the test branch with the master branch.

hotfix branch

Patch branch, based on master branch clone, mainly used for BUG repair of online version
After the online bug fix is completed and launched, the content of the hotfix fix needs to be merged into the current testing branch
pulled by the team leader

git submission process

insert image description here

Code merging (unified all use rebase)

command mode

git pull --rebase
或者
git fetch    # 将远端代码更新到本地仓库
git rebase origin/master # 将代码合并到当前分支

IDEA way

insert image description here

Tag usage specification

The major version of the demand version is based on: V1.0.0 and V1.1.0 will be added later

Bug fix minor version online: V1.0.0 will add V1.0.1 later

# 查看当前所有tag
git tag --list
git tag -a V1.0.0 -m "xxxxx需求上线"
git push --tags

Common git usage commands

Create a branch and push it to the remote end

git checkout -b feature/feature_security dev  # 基于dev分支创建
git push origin feature/feature_security

You can also directly push the branch based on the dev branch

git push origin dev:feature/feature_security  # 这样会创建分支并且将分支push到远端分支

git stash temporary storage

git stashThere are generally two scenarios used:

Many people modify the same branch. After I modified it locally, I found that the remote branch has been modified. At this time, it is impossible to pull.

git stash #先将本地代码暂存至缓存区域
git pull --rebase #再更新代码至本地
git pop   #再将暂存区域代码重新加载到本地

Accidentally changed other branch codes. For example, originally feature/feature01developed on a branch, accidentally switched to master a branch, and mastermodified the code on the branch, at this time I want to switch the code to feature/feature01the branch

git stash #先将本地代码暂存至缓存区域
git checkout feature/feature01 #再将分支切换到feature/feature01分支
git pull --rebase # 非必须步骤，更新远程代码到本地
git pop  #再将暂存区域代码重新加载到本地

submit code

Suggestion: Every time you submit the code, if it is the same function code, submit it to the local when submitting, do not push to the remote end every time, it is the same function that is merged into one submission, less invalid submissions, such as the same The file has been modified multiple times, submitted multiple times, and a comment has been modified and submitted multiple times.

git add .    # 添加提交内容 ‘.’表示当前目录所有，如果需要单独添加某一个文件：git add xxx.txt
git commit -m 'feature(bin): add first commit'  # 提交代码到本地仓库
git push origin master   # 将代码推送到远程仓库

View all remote repository refs

git remote

View the list of remote branches

git branch -a

merge a commit

git cherry-pick 'commit-id'

View the status of files in the workspace, staging area, and local warehouse

git status

Modify the submitted comments (not pushed to the remote record)

git commit --amend

Press i to enter edit mode (same as vim usage). ta

Press ESC to exit edit mode

wq: exit save

q!: Exit without saving

Save and exit, and then check whether the submitted content has been modifiedgit log

Modify the comment of a certain submission (not pushed to the remote record)

First of all, you need to find the commit it that needs to be modified, and git log find the commit id of the submission. Only two or more submissions can be used. If there is only one submission, use git commit --amendit

git log 
git rebase -i 28b197a00473ea1b46fab13263c294cce0d7401c

After modifying the comment, you need to pickchange it to reword.

Modify the submitted comments (push to the remote record)

You can also use the above method

After the modification here, it needs to be forced to push to the version branch.

git push origin master -fSo you need to pay attention here, don't do this under normal circumstances

Update the code locally and merge it

git fetch    # 将远端代码更新到本地仓库
git rebase origin/master # 将代码合并到当前分
git rebase origin/feature:test # 将代码合并到测试分支

git pull --rebase # 将代码更新到本地仓库并且合并到当前分支

local and merge

git fetch    # 将远端代码更新到本地仓库
git rebase origin/master # 将代码合并到当前分
git rebase origin/feature:test # 将代码合并到测试分支

git pull --rebase # 将代码更新到本地仓库并且合并到当前分支