[Git Basics] Branches and labels

Article directory

1. Standard workflow

1.1 Management branch

Git is a distributed version control system, and branch management is one of its core functions. Branches allow developers to work on different versions in parallel, which can later be merged into the master branch. Here we will detail how to use Git for branch management.

View Branches:
To view local branches, you can use the following command:
```
git branch
```
To view remote branches, you can use:
```
git branch -r
```
To view local and remote branches at the same time, you can use:
```
git branch -a
```
Create a branch:
To create a new branch, you can use the following command ( new_branchsubstitute the actual branch name):
```
git branch new_branch
```
Switch branch:
To switch to an existing branch, use the following command ( target_branchsubstitute the actual branch name):
```
git checkout target_branch
```
Or you can use the following command to switch to the new branch while creating the branch (will be new_branchreplaced by the actual branch name):
```
git checkout -b new_branch
```
Merge branch:
Before merging branches, switch to the target branch (will be target_branchreplaced with the actual branch name):
```
git checkout target_branch
```
Then use the following command to merge the specified branch into the current branch (will be source_branchreplaced with the actual branch name):
```
git merge source_branch
```
Delete branch:
To delete a local branch, you can use the following command ( target_branchsubstitute the actual branch name):
```
git branch -d target_branch
```
To delete a remote branch, use the following command (replace remote_nameand target_branchwith the actual remote name and branch name):
```
git push remote_name --delete target_branch
```
Pushing a branch:
To push a local branch to a remote repository, you can use the following command (replace remote_nameand branch_namewith the actual remote and branch name):
```
git push remote_name branch_name
```

A small example:

Assuming we have a feature_xnew feature called to be developed, we can create and manage a branch by following these steps:

Create and switch to feature_xbranch:
```
git checkout -b feature_x
```
Develop new features and commit changes to feature_xthe branch:
```
git add .
git commit -m "Add feature_x"
```
When development is complete, switch back to the master branch (usually or main) master:
```
git checkout main
```
Merge feature_xbranch into master branch:
```
git merge feature_x
```
Push the merged master branch to the remote repository:
```
git push origin main
```
If you no longer need feature_xa branch, you can delete it as follows:
- First make sure you've switched to another branch, such as master ( mainor master):
```
git checkout main
```
- Then delete the local feature_xbranch:
```
git branch -d feature_x
```
- If feature_xthe branch has been pushed to the remote warehouse, you also need to delete the remote branch. will be originreplaced by the name of the remote repository (usually origin):
```
git push origin --delete feature_x
```

1.2 Branch strategy

Master branch (Master) : Stability is critical. Merging code that has not been code reviewed and tested into this branch is prohibited. The code on the master branch should always be ready to be deployed to production.
Development branch (Develop) : The development branch is the basis for continuous integration. Modifications that have undergone code review can be merged into this branch. Subsequent bug fixes and feature development should be based on the development branch. After the developer completes the modification, the code is merged back into the development branch.
Feature Branch (Feature) : The branch for feature development and change requests. For each feature, a new feature branch can be created from the develop branch. After the feature development is complete, after code review and testing, the feature branch is merged back into the development branch.
Hot fix branch (Hotfix) : emergency repair branch. When a problem occurs after the code on the main branch is released to the production environment, a hotfix branch can be created from the main branch. After the fix is complete, merge the hotfix branch into the development branch and the master branch.
Pre-release branch (Release) : The pre-release branch is used to prepare for the release of the version, such as v0.1, v0.2, v1.12, etc. Typically, system testing is done based on these branches. If a bug is found on a pre-release branch, a temporary bug-fix branch can be created based on that pre-release branch.
Bugfix branch (Bugfix) : Bugfix branch is used to solve known problems. After the developers locate and solve the problem, they merge the bug fix branch into the development branch and the pre-release branch. Then, the tester performs regression testing. After the regression test is completed, close the corresponding Bug.

2. Create tags

2.1 create

The main reason for using tags in Git is to mark a specific commit point for easy tracking and referencing. Labels are often used to denote important milestones, such as version releases. Unlike branches, tags are fixed, they don't move with subsequent commits.

There are two types of tags: lightweight and annotated.

Lightweight Tags: A lightweight tag is a simple reference to a specific commit. The command to create a lightweight tag is as follows:
```
git tag tag_name
```
will be tag_namereplaced with the actual tag name.
Annotated tags: Annotated tags are full objects stored in the Git database, and they contain more information such as who created the tag, date created, additional descriptive information, etc. In general, we recommend using annotated tags, as they provide more contextual information. The command to create an annotated label is as follows:
```
git tag -a tag_name -m "tag message"
```
will tag_namebe replaced with the actual tag name, and will be tag messagereplaced with a descriptive message about the tag.

Once a tag is created, it can be pushed to a remote repository with the following command:

git push origin tag_name

will be tag_namereplaced with the actual tag name. To push all local tags to a remote repository at once, use:

git push origin --tags

2.2 Sign

Signing a label is to ensure the authenticity and integrity of the label. By signing a tag with GPG (GNU Privacy Guard), you can prove that the tag was created by you and has not been tampered with since it was created. Signed tags are often used in security-sensitive projects or during releases to ensure the origin and integrity of code.

Before signing tags, GPG needs to be set up. Here are the steps to sign a label:

Install GPG. Depending on your operating system, you may need to download and install GPG tools from the official GPG website: https://gnupg.org/
- Ubuntu：sudo apt install gnupg
- CentOS：sudo yun install gnupg
Generate a GPG key. Open a command line or terminal and run the following command to start generating keys:
```
gpg --gen-key
```
Follow the prompts, you may be required to enter a name, email address, and password to generate the key. Once generated, the key will be automatically added to the keyring.
Get the GPG key ID. Run the following command to get the key ID:
```
gpg --list-secret-keys --keyid-format LONG
```
Look for secthe line starting with , the key ID is /the following 16 characters.
Add the GPG key to the Git configuration. Use the key ID you just obtained (replace your_key_id):
```
git config --global user.signingkey your_key_id
```
Sign label. Create an annotated label with the -sor option and sign it with a GPG key:--sign
```
git tag -a -s tag_name -m "tag message"
```
will tag_namebe replaced with the actual tag name, and will be tag messagereplaced with a descriptive message about the tag.
Verify the signature. To verify the signature, the following command can be used:
```
git tag -v tag_name
```
will be tag_namereplaced with the actual tag name. If the signature is valid, you will see Good signature from <your_name>a message similar to this.

3. Action tab

After creating tags, you can do the following:

View a list of tags: Run the following command to see all created tags:
```
git tag
```
With -lor --listoption to filter tags like:
```
git tag -l "v1.*"
```
This will display v1.all tags starting with .
View details for a specific tag: To view details for an annotated tag (including creator, creation date, and tag information), you can run:
```
git show tag_name
```
will be tag_namereplaced with the actual tag name.
Checkout tags: To check out a specific tag, you can run:
```
git checkout tag_name
```
will be tag_namereplaced with the actual tag name. This will let you view and test the state of the code for a specific tab. Note that when you check out a tag, you're in a "detached head pointer" state, which means you're not on any branch. If you need to make changes based on this, please create a new branch.
Removing tags: To remove a local tag, you can run:
```
git tag -d tag_name
```
will be tag_namereplaced with the actual tag name. To delete a remote tag, you need to delete the local tag first, then run:
```
git push origin --delete tag_name
```
will be tag_namereplaced with the actual tag name.