Main branches

Each repository should contain at least two main branches, Master and Develop; Master for official release, develop for daily development.

The master branch

  • Master The master branch is also used to deploy the production environment. The master branch must be stable
  • The Master branch is usually combined with the Develop and Hotfix branches, so you can’t change the code directly at any time

Development Branch Develop

  • Develop is a branch of development that keeps code up to date and bug-fixed
  • When developing new features, the Feature branch is created under the Develop branch

Temporary branch

Feature Branch

  • The name of a branch of functionality that is separated from the Develop branch in order to develop a specific feature
  • Functional branches typically exist only in developer repositories, not in Origin.
  • You can name it as feature-* (branch feature/branch name).

Pre-release branch

  • We may need to have a pre-release version to test before releasing the official version (i.e. before merging into the Master branch).
  • The release branch is separated from the Develop branch and must be merged into the Develop and Master branches after pre-release
  • You can name it release-*

Bug Fix branch

  • After the software is released, it is inevitable that there will be bugs. This is where you need to create a branch to fix the bug. The branch is separated from the master branch. After the patch is complete, merge into the Master and Develop branches
  • It can be named in the form fixbug-*.

Use Git for daily development

When we get a Git address, we clone it first

Git clone 'XXXXX' git remote -vCopy the code

In fact, Git automatically matches the local master branch with the remote master branch and the default name of the remote repository is Origin

Branch functionality from Develop

Git checkout -b feature-* developCopy the code

Continuous improvement on this branch

  • When people work together, people gomasteranddevBranches push their own changes, so you need to synchronize your code online
  • git pull origin developDescription To get the commits on the Develop branch in the remote repository, andorigin/developThe contents of themergeTo your current branch
Git pull origin developCopy the code

Constantly improve the function

  • throughgit add git commit -mConstantly improve the function of this branch
Git add git commit -m"Copy the code

Function development completed

  • After the feature is developed, merge it into DevelopFully developedandThe test passDo not commit an error
Git merge --no--ff feature-* git branch -d feature-*Copy the code

The –no-ff flag causes the merge to always create a new commit object, even if the merge can be performed by caching. This avoids losing information about the history of the element branch and groups all commits with added elements together.

The usual default Git merge has no way of seeing from the Git history which commit objects are working together — you’ll have to read all the log messages manually. Restoring the entire functionality (that is, a set of commits) in this mode is a real headache.

Pre-release branch release

Create a publishing branch from the Develop branch. For example, say version 1.1.5 is the current production release, we’re about to release a big release, Develop is ready for the “next release”, and we’ve decided that this will be version 1.2 (not 1.1.6 or 2.0). Therefore, we branch and give the distribution branch a name that reflects the new version number

Git checkout -b release-x develop Git checkout master git merge --no-ff release-xCopy the code

To preserve the changes we made in the Release branch, we need to remerge those changes into Develop

Git checkout develop git merge --no-ff release-1.2Copy the code

Now that we’re really done, we can remove the publish branch because we no longer need it

Git branch - d release 1.2Copy the code

Fix branch hotfix-*

The patch branch is created from the Master branch. For example, say that version 1.2 is the current production release, is running, and is causing trouble due to serious errors. But change DEVELOP is still volatile. Then, we might branch off a patch branch and start fixing the problem

Git checkout -b hotfix-1.2.1 master git checkout -b hotfix-1.2.1 master git checkout -b hotfix-1.2.1 master Git commit -a -m "add version to 1.2.1"Copy the code

When the fix is complete, commit the fix

Git commit -m "Fixed a serious production problem"Copy the code

Once the patch branch is complete, the bugfix needs to be merged back to Master, but also back to Develop to ensure that the bugfix is also included in the next release

  • Incorporated into themaster
$git tag - $git tag - $git tag - $git tag - $git tag - $git tagCopy the code
  • Merged to develop
$git merge --no-ff hotfix-1.2.1Copy the code
  • Delete this branch
Git branch - d hotfix - 1.2.1Copy the code

Git Stash application scenario

  • When you are developing a project on the dev branch and there is a bug in the project that needs to be fixed urgently, but the content you are developing is only half finished and you don’t want to commit. You can use the git stash command to save your changes to the stack and then switch to the Hotfix branch to fix the bugs. When the fix is done, you can switch back to the Dev branch and restore the contents from the stack.
  • Because of the negligence, the content that should have been developed in the dev branch was developed in the master branch. Therefore, the development needs to be switched back to the dev branch. You can use git Stash to save the content to the stack.
// Save all uncommitted changes (workspace and staging) to the stack git stash // View the contents of the current stash git stash list // Restore the code in staging git stash popCopy the code

reference

  • GIT- Team collaboration flow
  • Liao Xuefeng’s official website – multi-person collaboration
  • Gits usage specification