Git version control system branches and tags (version)

Table of Contents

1. Git branch (Branch)

1.1 Branch function

1.2 Four branch management strategies

1.3 Use cases

1.3.1 Instructions

1.3.2 Use in combination with application scenarios

2. Git tag (Tag)

2.1 Label function

2.2 Label specifications

2.3 Use cases

2.3.1 Instructions

2.3.2 Usage examples

1. Git Branch (Branch)

Branching is a key concept when we talk about version control systems. In Git, branches are a mechanism for handling different lines of code, allowing you to work between different parts of a project without affecting the main line of code.

1.1 Branch Function

Branches are a tool in Git for working on separate lines of functionality or features in a project. It allows you to develop, test, and experiment without affecting the main project. Each branch is independent, and modifications to one branch will not affect other branches.

Application scenarios:

  • New feature development: Create a new branch to focus on the development of new features without affecting the main branch (usually master).
  • Bug Fixing: If a bug is discovered on the master branch, it can be fixed on a new branch without interrupting ongoing development.
  • Experimental development: To try out some experimental ideas, you can create a branch, experiment on it, and then decide whether to merge it into the main branch.

1.2 Four Branch Management Strategies

In Git, there are four main environments for branches, often referred to as thefour basic branch management strategies:

1. Master/Main

  • Role: The master branch is usually the main branch of the project and contains the current most stable and deployable code.
  • Application scenario: When developing new features or fixing bugs, it is common to create a new branch from the main branch to work on.

2. Development branch (Develop):

  • Role: The development branch is the main branch used to integrate various functions. When a development cycle ends, the development branch is usually merged into the master branch to form a stable version.
  • Application scenario: When developing new features, create a new development branch from the main branch, and then merge it back into the development branch after completing the development.

3. Feature branch (Feature):

  • Use: Feature branches are used to develop a single feature or feature. Each feature has a corresponding feature branch, allowing feature development to be independent of the main branch and other features.
  • Application scenario: When new features need to be added, create a new feature branch from the development branch, and merge it back into the development branch after completing development.

4. Release branch (Release):

  • Use: The release branch is used to prepare for the release of a new version. Perform final testing, documentation updates, and version number increments on the release branch.
  • Application scenario: When the development cycle ends, create a new release branch from the development branch and prepare for release. After publishing, merge the release branch back into the master and development branches.

These environments provide an efficient way to organize the team’s workflow and ensure code stability and maintainability. Using these environments provides a clear understanding of the purpose and status of each branch, making it easier to collaborate and integrate code. This branch management strategy is often called Git Flow and is a workflow widely used in software development.

1.3 Use Case

1.3.1 directive 

# View local branches
git branch

#Create new branch
git branch feature-branch

# Switch to new branch
git checkout feature-branch

# Or one step (create + switch)
git checkout -b feature-branch

# Merge branch to main branch
git checkout master
git merge feature-branch

# Delete merged branches
git branch -d

# Delete remote branch
git push origin --delete dev

# Submit branch If the remote does not have this branch, it will automatically create this branch.
git push origin feature-branch

1.3.2 Use in conjunction with application scenarios

Master/Main: The master branch is the default branch of the project and usually contains the latest stable version. In many projects, the name of the master branch is master or main.

1. Create and switch branches: You can create a new branch. This branch is created from the state of the current working directory and contains all files and folders in the current working directory.

2. Working on a branch: When working on a specific branch, you can make modifications, add new files, etc. These operations will not affect other branches because each branch has its own working directory.

Test: After adding the two newly created files to the staging area and submitting them to the local warehouse, what will be the effect of switching branches?

After switching to master, the files originally added disappeared.

3. Submit branch

You can view it in the gitee remote repository

The code developed in this branch has nothing to do with others. Once the development is completed, it can be merged with the main branch.

2. Git tag (Tag)

2.1 Tag function

A tag is a reference to a specific commit, typically used to mark releases. Tags allow you to easily switch between versions without having to remember the hashes of individual commits.

Application scenarios:

  • Release Release: When you release a stable version, you can tag the commit so that it can be easily found and checked out in the future.
  • History Tags: Tag key points in your project to make it easier to review the project’s history.

2.2 Label Specification

In Git, the naming rules for tags are relatively flexible, but there are some recommended conventions and best practices:

  1. Version number: The most common tag is used to indicate the software version. It is a common practice to use semantic version numbers, where the version number includes a major version number, a minor version number, and a revision number, in the form of MAJOR.MINOR.PATCH. For example: v1.0.0.

  2. Prefix: It is common practice to prefix the version with the letter ‘v’ before the tag. For example: v2.1.3.

  3. Release Candidate: Sometimes there may be some pre-release versions before the software is released, you can use -rc or other similar tags. For example: v1.0.0-rc.

  4. Revision or fix version: Sometimes it may be necessary to fix a version. This can be done by appending the fix version number after the version number, such as v1.0.1.

  5. Timestamp: In some cases, you can use a timestamp as a label, especially if uniqueness is required. For example: v20220101.

  6. Semantic tags: Use semantic tags that clearly express the purpose of the tag. For example: release-2.0, feature-new-login, etc.

Note:

  • Avoid using special characters, spaces, or weak quote characters to avoid causing unnecessary problems.
  • Tag names are case-sensitive, so v1.0 and V1.0 are two different tags.
  • Be consistent when using tags and follow conventions within the project.

In general, label naming conventions are defined by the project team. Choosing a clear, meaningful, and easy-to-understand naming convention is very helpful for long-term maintenance and collaboration of the project.

2.3 Use Case

2.3.1 command

# List all tags
git tag

# add tag
git tag v1.0.0

# Note label: Contains the label's name, email address, date and label message. It is a more detailed tag type.
git tag -a v1.0.0 -m "Version 1.0.0"

# Delete tag
git tag -d v1.0.0

# Delete remote tags (pushed tags)
git push origin --delete v1.0.0

# Push tags
git push origin v1.0.0

# If you have multiple tags, you can use the --tags option to push them all at once.
git push origin --tags

2.3.2 Usage Example

Here’s a simple tag push of the current version of the code:

After pushing a tag, other team members can get the specific version in the project by pulling the latest tag. For example:

git pull origin v1.0.0.20231112_dev

This will get the v1.0 tag in the remote repository and switch your local repository to this version.