Basic use of SourceTree

1. What is SourceTree

  • Project version control software with a visual interface, suitable for git project management
  • windows, mac available

2. Get the project code

2.1. Clone/New 

Click Clone/New

 

2.2. Enter the address

Enter the project address in the pop-up box, either http or ssh address.

 

  If the type of repository pointed to by the arrow says "this is not a standard Git repository", it may be for the following reasons

    1) Project address acquisition error

    2) No project access

2.3. Complete the clone

Click "Clone" and wait for the project to clone to complete. After completion, there is only one branch master on the left

  After cloning is completed, the master source code after the release is obtained. If you want to obtain the latest source code under development, you need to initialize the project flow and click "Git Workflow"

  Click "OK" directly to get the source code of the develop branch

  Development tasks are all done on the develop branch

2.4. Branch Types

There are 5 types of branches

  1) master, the final release version, there is only one in the entire project

  2) develop, the development branch of the project, in principle, there is only one project in the project

  3) feature, feature branch, used to develop a new feature

  4) release, pre-release version, a version between develop and master, mainly used for testing

  5) hotfix, repair patch, used to fix bugs on the master, directly acting on the master

2.5. Branching Practice

Master and develop have been introduced above. When a new function needs to be added during development, a new feature branch can be created to add new functions without affecting the develop source code in development. When the new function is added, the feature branch is completed. , merge new features into develop, update the code on develop

    1) Create a new feature. First, the current development branch points to develop, click "Git workflow"

Select "Create new branch"

As you can see in the preview, the feature branch is branched from develop, enter the function name, click OK, the feature branch is added to the project structure, and the current development branch points to the newly created feature branch

  2) Carry out development tasks under the F_add_feature branch and submit

The above operations have added feature_1, feature_2, and feature_3 files respectively, and submitted three times in total. There are three files in the current project folder.

After switching to the develop branch, you will find that there are no three new files under the develop branch, indicating that the operation under the feature does not affect the source code of the develop branch

  3) After completing the feature development, merge the source code in the feature into the develop branch. Point the current branch to the F_add_feature branch, click "Git Workflow", and select "Complete Feature"

In the preview, it indicates that the feature branch will be merged into develop, click OK to commit the merge, after the merge is successful

  4) When you need to add new functions, repeat the above operations

  5) When multiple people collaborate in development, it may occur that different people operate on the same file, causing merge conflicts. To simulate this situation, create two new features at present, modify the feature_1 file respectively, and then merge them separately.

feature_1 performs the following operations under feature_1.txt

feature_2 performs the following operations under feature_1.txt

Merge F_feature_1 and F_feature_2 successively, there will be conflicts

Click close to view the uncommitted changes, indicating that there is a conflict in feature_1.txt,

Open feature_1.txt

 

 

 Appears <<<<<<< HEAD, =======, >>>>>>> feature/F_feature_2, between HEAD and = sign indicates the code under the current branch, = sign and >>>>> >>feature/F_feature_2 represents the code under the branch to be merged, >>>>>> feature/F_feature_2 represents the branch name of the branch to be merged,

According to the situation, distinguish the code to be kept, the code to be deleted, and finally delete <<<<<<< HEAD, =======, and >>>>>>> feature/F_feature_2

Submit the modified code again

Once a feature merge conflict occurs, the feature branch to be merged will not be deleted, such as F_feature_2. After ensuring that there is no problem with the merge, you can manually delete F_feature_2

2.6. Release test version

When the development reaches a certain stage and the test version can be released, you can branch from the develop branch, establish a release branch, and enter the pre-release testing stage. Click on "Git Workflow" and select "Build New Release"

  

As you can see in the preview, release is forked from develop, enter the release version name 'R_v1.0', and click OK

R_v1.0 is a phased release version, which is mainly used for testing before release. Subsequent development work is still carried out on develop. If problems are found during the testing process, they can be modified directly on the release, and submitted after the modification is completed.

2.7. Official Release

After making two changes to the release branch R_v1.0, the test is completed and the official release can be carried out. Under the current branch pointing to the R_v1.0 branch, click "Git Workflow" and select "Complete Release Version"

 

As you can see in the preview, R_v1.0 is merged into develop and master respectively, click OK to complete the official release.

After the merge is completed, the default point to develop is the current branch, the master adds multiple version updates, pushes the master branch to origin, and completes the online release

2.8. Create a new patch

After the official version is released, develop can continue to carry out follow-up development. When there is a problem with the official version, the problem needs to be corrected, and a hotfix can be created on the master branch. Switch the current branch to master, click "Git Workflow", and select "Create a new fix patch"

  

In the preview, the hotfix branch is pulled from the master, enter the name of the repair patch, and click OK

Modify the problem of master under this branch, and submit it after the modification is completed. When all patch issues are modified, click "Git Workflow" and select "Finish Patching"

  

In the preview, H_fix_1 is merged into master and develop respectively, click OK to complete the branch merge.

After the merge is completed, the default current branch is develop, the master branch has a version that needs to be updated, the current branch is switched to master, push is performed, and the patch repair is completed.

2.9. Merge conflicts

When completing the release version and completing the repair patch, if there is a conflict, you can modify the conflict according to the above 2.5., and then carry out the follow-up operations.

 

 

 Appears <<<<<<< HEAD, =======, >>>>>>> feature/F_feature_2, between HEAD and = sign indicates the code under the current branch, = sign and >>>>> >>feature/F_feature_2 represents the code under the branch to be merged, >>>>>> feature/F_feature_2 represents the branch name of the branch to be merged,

According to the situation, distinguish the code to be kept, the code to be deleted, and finally delete <<<<<<< HEAD, =======, and >>>>>>> feature/F_feature_2

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325254726&siteId=291194637