Why use Git

Why use Git? I feel don’t want me to say much more, because everybody is in use ah, use up is cool!! So here’s how to learn Git materials to make you love learning. It is called git Bible by everyone, let the monkey teach you to study, and at the same time, play the thrill of clearance by learning Git Shoot. Git related materials we will find their own time to learn, next we mainly look at the following about our git work some relevant provisions, please read carefully, keep in mind, to avoid work on the pit.

Branch agreed

The main branch

  • Master branching principle
  • The Master branch holds stable version code ready for deployment in production
  • A project can have only one Master branch
  • Update code on the Master branch only when new code is released for deployment
  • Git tag -a v0.0.1 -m git tag -a v0.0.1 -m git tag -a v0.0.1 -m
  • Master branch code can only be merged by release/* or hotfix or development feature/* branches, meaning that code cannot be modified directly on the master branch
  • The release branch
  • Can only be derived from the master branch naming rule: release/*, “*” is identified by the release number of this release, such as our monthly release/2020.2.27, but in general project stability, use release as the branch name.
  • Release is mainly to prepare for the release of the official new version. The merge of code comes from the official development branch feature/* that we have verified and confirmed.
  • Once the launch is successful, it will revert back to the Master branch (the release partner does this), and also back to the Dev branch if there are fixes during the release (such as minor bugs before launch)
  • dev
  • The dev branch is the branch that holds the latest development results of the test environment
  • A project can have only one dev branch
  • The dev branch is mainly for the release of the test version, the initial development of the project is allowed in this branch, once the release of the cable, subsequent development must be cut from the master or release branch to develop (feature/*).
  • Dev is used as a validation branch for the test environment, primarily for scenarios where multiple people are developing multiple requirements at the same time. Switch from the master branch, but there is no regression to the master branch, nor can you change code on this branch, which is only used for the release of the test environment.

Development branch (Feature branch)

  • This branch branches off the Master branch for the development of new functionality (new requirements or version iterations)
  • Naming rules feature/* Example: Feature /install Installation requirements
  • This branch usually does not need to be committed to a remote location, but if the project has many local locations, it is recommended to commit to a remote location because of the risk of losing.git files (which happened to me).
  • The granularity of each feature/* branch should be as low as possible, for example, only one requirement or one function at a time. However, if you are quite clear that the two requirements can be verified and on-line at the same time, then the granularity can be appropriately relaxed.
  • Once the development is complete, if the project has only one requirement waiting to be verified, it can be directly verified by the branch release test. If there are multiple requirements, and different people are working on them, please merge them into the dev branch release verification. When the requirements are verified, the branch can be merged into the Release or Master branch (if there is no release branch).
  • The feature branch only interacts with the Release branch, not directly with the Dev and Master branches
  • When features cannot be developed for various reasons; Or abandoned; Or if it is already online, delete the branch directly, or if it is committed to a remote location, delete it altogether

Hotfix branch

  • Naming rules: hotfix/* For short, fast branches, you can also use hotfix as the name
  • The Hotfix branch is used to quickly fix bugs or fine-tune features for released products
  • Derived from the Master or release/* branch
  • Once fixed, merge into the dev branch for validation. After the validation passes, we need to return to the master
  • Once the Hotfix branch is established, it is independent and cannot pull code from other branches

Bugfix branch

  • Naming rules: bugfix/* For short, fast branches, you can also use bugfix as the name
  • The Bugfix branch is used to quickly fix bugs or fine-tune functionality for products that are not live or for iteration requirements
  • Derived from the Master or release branch or the corresponding development branch feature/*
  • Once fixed, merge into the dev branch for validation. After validation, you need to return release and master

The following figure shows a model of branch management

Development scenarios

Development situation of actual development, we have encountered more, may be only one project development, or development, or there is a project to develop multiple demand at the same time, these requirements and project between independent, actually branch management with the development of the actual number of no direct relationship, with the development of the demand nodes is directly related to, The branch management of multi-person development of a requirement is the same as that of one person development of a requirement, but we need to follow the submission specifications of the code, and then one person development of multiple requirements and multiple people development of multiple requirements are actually the same development scenarios, let’s analyze these scenarios one by one.

Develop a new project or the project has only one requirement

One-man development

  • Many of our small projects are developed by one person, so there may be many problems in branch management according to personal reasons, but the basic norms should be followed in place so as not to leave a hole for future generations.

  • If you are working on a new project, it doesn’t matter if you are working on it in the master or dev branch. Once the project is live, you need to pull all the latest code into the master branch of the remote repository

  • If it is an iterative requirement, cut a feature from master /* (

    Please refer to the convention on feature branches above for separate naming

    ) out of the development, prohibited in the master branch development, development online, please timely return to the master branch

Many people develop

  • When multiple people are working on a requirement, they are usually working on the same branch. If there is a conflict, communicate with each other to see whose code to use

  • Similarly, if you are working on a new project, it doesn’t matter if you are working on it in the Master or dev branch. Once the project is live, you need to push all the latest code to the master branch of the remote repository

  • Similarly, if it is an iterative requirement, then cut a feature from master /* (

    Please refer to the convention on feature branches above for separate naming

    ) out of the development, and then we communicate unified good, prohibit the development of the master branch, development online, please timely return to the master branch

tips

  • Everybody development iteration requirements, should be like in the dev development directly, when you finish development and in the test, all of a sudden the product added a demand, and the demand than the preceding demand in advance online, this time you can only cut into two branches, one is to develop new demand suddenly, an environment that is need to test version of the branch. Therefore, in order to avoid such a situation, we suggest that all development requirement branches should be named feature/* according to the convention of the above branches

Multiple requirements are being developed simultaneously in a project

One person develops many requirements

  • One person develops multiple requirements in one project at the same time. Generally, it is more common to meet projects that undertake multiple business systems. Fortunately, I have met such projects, and one person develops 6 or 7 small requirements at the same time
  • Because some of these branches are under development or already need testing, a test branch (dev) is required to merge all development branches and use this test branch (dev) for the release of the test environment
  • Keep in mind that code changes for each requirement can only be made in the corresponding development branch (feature/*), never in the test branch (dev)

Multiple people develop different needs

  • In fact, the operation of multiple people developing different requirements in a project is the same as that of one person developing multiple requirements, but there are not so many branches managed by each person, and it is not easy to write wrong branches of code
  • Multiple development, there will inevitably be conflicts, especially remember that if you are not sure you modified the code, merge the conflict, must communicate with the team to resolve the conflict
  • Similarly, everyone’s development branch code needs to be merged into the test branch (dev), while routinely committing it to remote locations to avoid someone else packing it without pulling it

tips

  • Local branch code is best delivered remotely to avoid the risk of code loss. Also remember to delete the local and remote development branches as soon as the development branch completes its mission.

Git related command scripts

Configure an alias

  • The following command reduces the status checkout commit Branch word to ST CO CI BR and is global. For details, see Configuring an Alias

    git config –global alias.st status git config –global alias.co checkout git config –global alias.ci commit git config –global alias.br branch

    Git st git status git co git checkout git ci git commit git br git branch

Git command development process

1. Gitlab Project creation (see GITLAB Project Creation Specification for details)

2. Clone Project

git clone [email protected]:xxxxxxx
// HTTP
git clone http://git.midea.com/XXXXXXXX
Copy the code

3. Create branches

Git br -b dev // go to the dev branch git co dev // go to the dev branch git co dev // go to the dev branch git co dev // Git co-b dev master git co-b feature/test master Git co-b feature/test master git co-b feature/testCopy the code

4. Submit code to the staging area

// All commits must have comments that briefly describe what is covered by the commit. ** Comments are strictly prohibited if the content is too simple or cannot clearly express the submitted content! ** // Properly control the granularity of the commit content, each commit contains a single function point. It is forbidden to submit multiple function items at one time. Git ci -a -m "update file" git ci -a -m "update file" git ci -a -m "update file" // This merge command is only used for files that have already been traced. For files that are not traced, use git add first.Copy the code

5. Pull and submit the remote code

Git pull // Pull the remote repository code and all the names of the remote branches from the current branch, but if the current branch is not traced remotely, Git pull origin dev git pull origin dev git pull origin dev git push devCopy the code

6. Merge feature/test code into dev branch

Git co dev // Merge code uses --no-off merge mode // By default, git executes a "fast-farward merge", which directly points the Master branch to the dev branch. With the --no-ff parameter, a normal merge is performed to create a new node on the Master branch. So in order to keep the evolution of the release clear, we want to do this. Git merge --no-off feature/test // delete git push origin Git push origin --delete feature/testCopy the code

7. The master branch is tagged after the version is online

Git show v0.0.1 git show v0.0.1 git show v0.0.1Copy the code

Common command statements

  • View the version that has been committed

    Git log –oneline git log –oneline

  • The fallback version

    Git reset –hard *** git reset –hard *** git reset –hard *** git reset –hard *** git reset –hard **

Brief Description of version number (TAG)

  • Version number (TAG) Naming rules: Major version number. Second version number. Revision number, as shown below (following GitHub semantic version naming convention)

    v1.2.3

    1. Major version number: When an incompatible API is added or modified

    2. Minor version number: when a downward function is added or modified

    3. Revision number: fixed as a problem with backward compatibility

Reprint address: renwei.vip/? p=496