当前位置:网站首页>Git operation and branch management specification

Git operation and branch management specification

2020-11-08 16:58:59 LHH

One 、git Operation specification

git Operation flow data flow diagram

image.png

  1. Remote: Remote main warehouse
  2. Repository: Local repository
  3. Index:Git Tracking tree , Temporary storage area
  4. workspace: Local workspace

The normal code submission process

//  work area 
git status                         //  Check the status 
git add .                          //  Add all changes to the staging area 
git commit -m " Submission description "            //  Submit the code to the local repository 
git pull origin < Remote branch of co development > //  Pull the remote branch of joint development , And merge it into the local branch 
git push                            //  Update local warehouse code to remote warehouse 

git add Advanced

  • scene 1: work area

When you change a file in the workspace , Want to restore the original , Command git checkout -- <filename>

  • scene 2: Temporary storage area

When not only a file in the workspace is changed , Want to restore the original , also git add When added to the staging area , Want to discard changes , A two-step ,
The first step is to order git reset HEAD <filename>, Back to the scene 1;
Step 2 press the scene 1 operation .

git commit Advanced

  • scene 1: change commit Information

git commit --amend -m " New submission "

  • scene 2: Missing submission
  1. git add <filename> git commit -m " Submission of information " // git There will be two commit
  2. git add <filename> git commit --amend --no-edit // --no-edit Indicates that the submitted message will not change , stay git Last only one submission
  • scene 3: Error file submitted , You need to git reset or git revert

git reset

Delete specified commit

  1. --mixed The default option , Will reset the contents in the staging area to the specified commit state , And the pointer points to the commit .
  2. git reset --soft HEAD~1

Modify the version Library , Keep staging area , Keep the workspace ;
Back off the version library 1 A version , Soft fallback means to reset the header pointer of the local version library to the specified version , And move all changes after this commit to staging area . 

  1. git reset --hard HEAD~1 

Modify the version Library , Modify staging area , Modify workspace ;
Back out the version Library 1 A version , It's not just to reset all the head pointers of the local version library to the specified version , It also resets the staging area , It will also roll back the workspace code to this version .

  1. git reset --hard commit_id 

git Version rollback , Go back to a specific commit_id edition , Can pass git log View the submission history , In order to determine which version to roll back to ( commit After that is ID ) 

git revert

Undo an operation , Before and after this operation commit and history Will keep , And make this revocation the latest submission .  

  1. git revert HEAD 

Undo the last time commit 

  1. git revert HEAD^ 

The last time before cancellation commit 

  1. git revert commit-id 

Undo the specified version , Undo will also be saved as a single commit . 


git revert Is to submit a new version , Will need revert The content of the version of is modified in reverse , The version will be incremented , Does not affect what was submitted before

git branch

  1. git branch ,git checkout -b [name_new_branch] 

see , Create and view project branches . 

  1. git branch -d [name_branch] 

Delete the branch .

  1. git checkout [branch-name] 

Switch branches . 

  1. git merge [your_branch] 

Merging branches . Be careful : You need to merge under the main merge branch , For example, to merge a branch into master , First you need to switch to master Merge under the branch .

  1. git diff [branch] [branch] 

Branch comparison . Compare the last of the two branches commit The difference in the content of

  1. git branch -m [branch] [new_name_branch]

rename branch

git stash

Be able to put all uncommitted changes ( Workspace and staging area ) Save to stack , For subsequent recovery of the current working directory .

  • git stash save

git stash save and git stash It's the same thing , The difference is that the former can add a corresponding stash The name of

  • git stash list

View the current stash The contents of the list

  • git stash pop

Will the current stash The content in the pop-up , And apply to the working directory corresponding to the current branch . This command will delete the most recently saved content in the stack .
If from stash The contents recovered in the current directory conflict with the contents in the current directory , It will prompt you to make mistakes , Conflicts can be resolved by creating new branches .

  • git stash apply

Apply the contents of the stack to the current directory , The order is different from git stash pop The content is removed from the stack .
have access to git stash apply <stash_name> ( Such as stash@{1}) Specify which... To restore stash Go to the current working directory .

  • git stash drop <stash_name>

Remove a specified... From the stack stash.

  • git stash clear

Clear everything in the stack .

  • git stash show

Look at the latest saved... In the stack stash Differences from the current directory .
git stash show stash@{1} View the specified stash Differences from the current directory .
Can pass git stash show -p See the details of the differences .

  • git stash branch

From the latest stash Create a branch , Can be used to solve stash The content in conflicts with the current workspace content .

long-range remote

  1. git remote add origin [git_address] 

Add remote address  

  1. git pull 

Pull the update of a branch of the remote host , Then merge with the local specified branch ( Equivalent to fetch Add the operation of merge branch function ) 

  1. git push origin master 

Branch push to remote version  

Optimize operation

  • Pull the code git pull --rebase

Let's assume that the line chart is being submitted pull It was like this before :
image.png
If it's execution git pull after , This is how the submitted line chart will turn out :
image.png
The result is more H It's unnecessary to submit records . If it's execution git pull --rebase Words , This is what happens when you submit a line chart :
image.png
F G Two submissions passed rebase The way to reassemble in C after , The extra bifurcations have been removed , To achieve .

  • tip:rebase stay git in , It's kind of 『 Dangerous behavior 』

Use git pull --rebase Than directly pull It is easy to lead to conflicts , If you expect more conflicts , The suggestion is direct pull. 

  • Be careful :

git pull = git fetch + git merge
git pull --rebase = git fetch + git rebase

Two 、git Branch management specifications

git Branch management data flow diagram


bigpicture-git-branch-all.png

Introduction to the main branches

master Branch

  • master Main branch , With stability , The deployed code has been tested in production environment ;
  • master Branches are usually made up of develop Branch or hotfix Branch merging , It is forbidden to direct to master Branch to modify directly .

develop Branch

  • develop Branch is development branch , It can be used as a conjunction master Alternative branches of a branch , This branch stores the latest developed features and after testing bug Fixed code ;
  • In general, when developing new functions , It's all based on develop Branches create new feature Branch ;
  • from develop Branches always get the latest development code for the project .

feature Branch

  • feature The branch is used to develop a separate new function , be based on develop Branch creation ;
  • Developing new features requires creating new functional branches , The naming format can be as follows feature- or feature/ As the beginning , Such as feature-login perhaps feature/login, However, it is better to unify the naming format of the beginning in the same project ;
  • feature Finally, the branch also belongs to develop Branch or be deleted .

release Branch

  • release Branching is based on develop Branch creation , For pre launch branches , In the pre release testing phase , Will release The branch code is the benchmark to measure ;
  • release In the end develop Branch or master Branch . Branches can be named with relseae- start ;
  • release Branches can be used to prepare elements such as version numbers 、bug Repair of 、 Preparation before release , establish release The best time to branch is develop The branch has completed the function development of the corresponding version , new function feature The branches have joined develop Branch and basically reach the expected state . If there is bug Need repair , It can be directly based on release Branch repair and commit , This process does not add new features , The new features are still based on develop Branch Development ;
  • When the test is completed and verified, nothing new bug after , take release Branches merge into master Branches and develop Branch , here master A branch is a branch that has the condition of going online .

hotfix Branch

  • hotfix Branching is based on master Branch creation , It is used to deal with the unexpected emergency found after the project goes online bug;
  • hotfix The branch is ultimately attributed to develop Branch or master Branch , Branches can be named with hoxfix- start ;
  • To set up hotfix The reason for the branching , It's to avoid scheduling new features online bug Influence .

Operation specification

commit messages standard

The good ones in the project commit messages Specification writing helps multiple people maintain projects and review project , As a developer , Also should be a project collaborator , Write a standard commit messages It's a basic requirement .
Angular Team code commit messages Norms are more reasonable and systematic in the community , Here's the picture :
image.png
Angular Git Commit Guidelines
https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines

The specific format is
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
  • type: This time commit The type of , Such as bugfix docs style etc.
  • scope: This time commit The scope of the impact
  • subject: The next time I'm going to talk about it in a nutshell commit The main idea of , Several points have been specially emphasized in the original text :
  1. Using imperative sentences , Is it a very familiar and strange word
  2. Do not capitalize
  3. No punctuation at the end
  • body: Also use imperative sentences , In the main content, we need to put this commit Describe in detail , For example, the motivation of this change , If you need a new line , Then use |
  • footer: Describe the... Associated with it issue or break change, Such as Closes #123 You can turn off the corresponding issue, Details visible

Closing issues using keywords
https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue, Use jira when , We are commit message You can fill in the effect of JIRA_ID, To enable this function, you need to get through jira And gitlab. Reference documents :https://docs.gitlab.com/ee/user/project/integrations/jira.html
once commit In the process ,type and subject For information that must be described , Other information can be selected according to the size of the change submitted .

type Type description of
  • feat: Add new features
  • fix: Repair bug
  • docs: Just modified the document
  • style: Just change the space 、 Format indent 、 All right, wait , Don't change the code logic
  • refactor: Code refactoring , No new features or fixes bug
  • perf: Add code for performance testing
  • test: Add test cases
  • chore: Change the build process 、 Or add a dependency library 、 Tools etc.

utilize Gitlab Platform capabilities

Merge Request && Code Review
  1. When merging remote branch code , Use gitlab On the platform New merge request

image.png

  1. choice Source branch and Target branch

image.png

  1. Fill in the merge information and select Assignee

image.png

  1. Merge Operation and Code Review

image.png
If for Changes The code in has a better solution , You can add comments and don't click Merge Operation merge code , Wait until the code is optimized next time push Code will automatically continue to go Merge Request The process of .
Code Review It's not just about seeing the code written by the other party is not standardized 、 Is there a small problem with the details , Is more of a :

  1. Forget the other party's code for a while , If you're allowed to fulfill this requirement , How would you design it , Is it consistent with the other party's design ideas ? What's the difference ? Whose is better ?
  2. Forget the specific needs for a while ( Or you don't know the need ), Look at each other's code , Can you understand what he wants to accomplish ? Does he understand the need ? Did he do well ?

Actually CR It's a reaffirmation of design and implementation , In the course of repeated contests , Learn and grow from each other . If there is a negative answer to the above two questions , Then it is necessary to write well CR Comment on .

PipeLines
Continuous integration is a software development practice , That is, team development members often integrate their work , Typically each member integrates at least once a day , This means that multiple integrations may occur each day . Each integration is through an automated build ( Including the compilation , Release , automated testing ) To verify , To find integration errors as quickly as possible . Many teams have found that this process can greatly reduce integration problems , Enable teams to develop cohesive software faster .

stay PineLines in , Can be integrated Gitlab-CI and Gilab-Runner.GitLab-Runner It's cooperation GitLab-CI For use . In a general way ,GitLab Each project in it will define a software integration script belonging to the project , Used to automate some software integration work . When the warehouse code of this project changes , For example, someone push Code ,GitLab You will be informed of this change GitLab-CI. At this time GitLab-CI We'll find out what's associated with this project Runner, And inform these Runner Update the code locally and execute the predefined execution script .
Detailed introduction and use can read this article Gitlab-CI and Gitlab-Runner
https://www.cnblogs.com/cnundefined/p/7095368.html

Issues

image.png
Issues It can do two things

  1. After the team needs review , Split each function module , Each module can create a issue, And fill in the issue Information about , Last specified Assignee The development of this module can cooperate with git Of commit Information related operations , When the module is developed , stay commit You can specify the relevant issue Shut down ;
  2. When the requirements are developed and tested , The test will test out some bug, If bug More and more people , The management of the development team can put every bug Record as a issue, To complete a bug You can repair it by yourself close Corresponding issue.

All in all , Issues Mount each requirement directly under the name of the corresponding person , You can directly see the person responsible for the requirement . And by looking at all the Issues, You can intuitively see the current development progress ,

版权声明
本文为[LHH]所创,转载请带上原文链接,感谢