[Git] Git branches and tags to master these skills let you become a qualified coder

I. Practical scenarios of branching and labeling in the development process

1.1. What is Branching and Labeling

1. Branches：
   • Function Development: When a team member needs to develop a new feature, a new feature branch can be created. This branch can be independent of the main development line and does not interfere with other development work, while allowing team members to work without interfering with the main development line.
   • Bug Fixes: If a bug is found on the main development line, the team can create a dedicated fix branch to resolve the issue without having to wait for the current ongoing development to complete.
   • Version Release: When preparing for a new release, you can create a dedicated branch for the release. This allows the team to continue working on new features on the main development line while finalizing stability tests and bug fixes on the release branch.
2. Tags：
   • Version Release: When a software reaches a milestone version, such as a major release or a milestone version, the team can create a tag for that version. This tag can be used to identify the status of the corresponding version of the code, making it easier to track back and manage later.
   • important event: Some teams tag their code to identify important events, such as major feature launches, important architectural tweaks, etc., so that they can track the evolution of the project later.

1.2. Development environment layering

1. Development：
   • Represents the phase in which a programmer or development team writes, debugs, and tests new functionality or modifies existing functionality.
   • In a development environment, developers are free to edit, build and debug code to implement new features or solve existing problems.
   • This phase is usually the one with the most frequent code changes and the highest flexibility requirements.
2. Testing：
   • It stands for various kinds of tests, including unit tests, integration tests, acceptance tests, etc., on the completed developed functions, modules or the overall system.
   • In a test environment, testers or automated testing tools rigorously test the software to ensure correct functionality, stability of performance, and so on.
   • This phase focuses on verifying the quality of the software and finding and fixing potential defects.
3. Staging：
   • Represents the deployment of functionality that has been developed and tested into a production-like environment for final integration testing and validation.
   • In demo environments, real production environment configurations are usually simulated, including databases, caches, message queues, and so on, to ensure that the software can function properly and collaborate with other systems.
   • The goal of this phase is to ensure system stability and consistency prior to deployment to a production environment.
4. Production：
   • Represents the actual runtime environment that end users will come into contact with, where the software provides services and handles real data and user requests.
   • In production environments, software needs to maintain high availability, performance, and security, and often needs to be integrated with monitoring systems as well as be ready to respond to failures.
   • The concern in this phase is to ensure that the system reliably delivers services to end users and responds to and handles all kinds of anomalies in a timely manner.

1.3. Branching vs. labeling

• The “dev” stage corresponds to the “alpha” state, which indicates the version of the software that is under development.
• The “test” stage corresponds to the “beta” state, which indicates the version of the software that is in the testing stage.
• The “pre” stage corresponds to the “rc” state, which indicates the software version in the pre-release or gray test stage.
• The “pro” stage corresponds to the “r” state, which indicates an official release or version of the software in the production environment.

There are several advantages to indicating the status in the label suffixes

1. Clear identification of version status: By indicating the status in the tag suffix, it is possible to clearly identify which stage the current version is in, including development, testing, pre-release, and production. This helps team members and other stakeholders to quickly understand where the current version is and in what environment it is suitable for use.
2. Convenient Versioning: Labels with status suffixes facilitate version management. The development team can quickly locate the corresponding stage of the version according to the different status tags, and can deploy and test the corresponding version in different environments, thus improving the efficiency of version management.
3. Harmonized naming convention: By indicating the status in the label suffix, a uniform naming convention can be established, making the naming uniform within the team for each stage of the release, reducing communication costs and the possibility of misunderstanding.
4. Easy to trace historical records: In the project history, tags with status suffixes can help developers trace back versions to different stages more easily. This can be very helpful in finding the status of code at a particular stage or going back in time to a historical version.
5. Support for parallel development and release: By labeling states with a tag suffix, versions of different states can exist in parallel and be clearly distinguished. This helps support teams to develop and release in parallel at different stages, increasing their flexibility and efficiency.

Git Branching Explained

2.1.GitBashHere Manipulating Branches

View Branches

git branch //view local branches
git branch -a //View remote branches

As you can see we have no branches other than the default master Create a branch git branch name // only save locally, remotes need to be push

Git branch naming convention dev/test/pre/pro (i.e. master)

Switch the branch git checkout name Create a + toggle branch git checkout -b name Merge a branch into the current branch git merge name I commit five files to dev before merging them to test. Branch commit remote git push originname Delete branch (Delete local before deleting remote, deleting local requires cutting other branches first）

git branch -d name //delete local branch
git push origin --delete dev // to delete the remote branch

2.2. Manipulating Branches in IDEA

Right click on the git project, go to git and select Branches

Select the branch you want to switch to The current branch is master, I create a new dev2 and switch to Select the branch you want to switch to.checkoutrecognize We’re currently on the dev2 branch. But there’s still only one master branch under “Remote Branches”, which means there’s still only one master branch in our remote repository, so we’ll need to push the branch we created in our local repository to our remote repository so we can see the new branch in the remote repository. Click dev2, and then click “Push” on the left to bring up the push dialog. Click “Push” to push to the remote repository, so the branch new operation is completely finished, you can see in the “Remote Branches” branch under the “dev2”, we can code in the branch and pull and push operations. If you want to delete a branch, it is recommended to checkout to another branch, e.g., checkout to the master branch, but this is not mandatory, it is just a convenient way of deleting a branch

Third, the Git tag to explain

3.1. The GitBashHere Operations tab

When we release a version, we usually tag it in the repository first, so that the version at the moment of tagging is uniquely identified. In the future, whenever we take a tagged version, we take out the history of that tagged moment. So the tag is also a snapshot of the repository. See all tags git tag Tags are not listed in chronological order, but alphabetically. You can view the tag information with git show <tagname Create tag First, switch to the branch that needs to be labeled, e.g., test, and then create the label

Tag format: major version number. Secondary version number. Revision number – Type tag, where the type tag can be: alpha, beta, rc, r. Tag examples: 1.0.0-alpha, 1.0.0-beta, 1.0.0-rc, 1.0.0-r

Push tags to remotes git push origin Delete tag

If the tag has been pushed to a remote, it's a little trickier to remove the remote tag, first from the local
         git tag -d 1.0.0-alpha
Then, it is deleted from the remote. The delete command is also push, but in the following format:
         git push origin :refs/tags/1.0.0-alpha

3.2. Manipulating labels in IDEA

Idea create tag

You can create a tag by right clicking on the project and following Git -> Repository -> Tag... Create a tag.

or top menu bar Follow VCS -> Git-> Tag... to create a tag.

Push Remote Branch

Just take special care to check the box when you push To see the version of a tag you just need to toggle the version. That’s when IDEA switches the code

Tagging of previous code commit versions

IV. Expansion – practical branching and labeling

Here’s the whole process demonstrated in code (you’ll also need to make careful distinctions) 1. Clone remote library test1 git clone [email protected]:yanppp999/test1.git 2. Create the dev/qas/pre branch (pro is master, there is no need to create it again), and then switch to the dev branch. git branch dev git branch test git branch pre #add(int a, int b){a+b+b}   v1.0.0 #add(int a, int b, int c)   v1.1.0 #add(int… arr)            v1.2.0 3. Create and edit the Cal.java class to add an add(int a,int b) method in three steps: add->commit->push(*****) git add Cal.java git commit -m ‘Project Phase 1 complete’ git push origin dev Note 1: In the case of a branch, the push command requires two parameters: the remote repository name and the branch name. git push origin dev Note 2: doc window switch to master, enter ls command, Cal.java can not be found, the same in the github site, also have to select the dev branch in order to see the Cal.java file git branch master ls At this point, the first phase of the project is complete, followed by the testing phase (which will constantly switch between dev-test branches). ## Tag related content and re-add it in after the branch has finished talking about it ## Skip this step for the following command ## Create and push tag “dev-1.0.0” to remote git checkout dev git tag 1.0.0-alpha git push origin 1.0.0-alpha 4. Merge dev to test and commit git checkout test git merge dev git push origin qas 5. After the test, create the label: qas-1.0.0 git tag qas-1.0.0 6. Merge qas into pre git checkout pre git merge qas git tag pre-1.0.0 7. Merge pre into master git checkout master git merge pre git tag prd-1.0.0 Note 1: The actual production of the APP or software software version naming specification in detail, details can be referred to: information / 12, information / 13 v1.0.0.191202_be.d v1.0.0.191210.t v1.0.0.191221.rc v1.0.0.191225.r 8. git clone specifies branch or tag 1. Take complete git clone https://github.com/arvidn/libtorrent.git 2. Use the specified branch git checkout origin/dev 3. Use the specified tag git checkout 1.0.0-alpha 4. You can also specify the tag or branch at the time of clone: git clone -b RC_1_1 https://github.com/arvidn/libtorrent.git git clone -b libtorrent-1_1_9 https://github.com/arvidn/libtorrent.git