Shulou(Shulou.com)06/02 Report--

This article focuses on "what are the ways to prevent loss of Git code?" interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Now let the editor to take you to learn "what are the ways to prevent loss of Git code?"

1. Common workflow

Usually when you come to the office in the morning to turn on the computer, first perform the update operation (click IDEA menu VCS-Update Project...), and then start coding happily. After the coding is completed, you usually perform the following actions:

Update operation

Create this submission

Push remote branch

1.1 Update operation

To ensure that Git has a concise submission history, you need to perform an update operation before submitting, that is, click menu VCS-Update Project..., or press Ctrl+T in IDEA, and the following window pops up:

Select the update type (Update Type) on the left side of the window:

Merge: perform a merge operation when updating. It is equivalent to executing git fetch & & git merge or git pull-- no-rebase.

Rebase: performs a rebase operation when updating. It is equivalent to executing git fetch & & git rebase or git pull-- rebase.

Branch Default: specify update types for different branches in the .git / config file.

On the right side of the window, select how to clean up the working directory (Working Directory) before the update:

Using Stash: use git stash to store local changes.

Using Shelve: use IDEA's built-in Shelve feature to store local changes.

Usually, you can select Merge and Using Stash. After clicking OK, IDEA performs the following steps:

Step 1: use git stash to store local changes

Step 2: execute git fetch & & git merge to pull remote branches and merge

Step 3: perform git stash pop to restore storage

Some students may be more accustomed to creating a local submission first and then performing an update operation, which will cause Git to automatically generate a merge submission, resulting in a lack of concise submission history.

1.2 create this submission

When the update is complete, click the menu VCS-Commit... in IDEA Create this submission.

1.3 push remote branch

Then click VCS-Git-Push... Push to the remote branch.

2. Analysis of common problems

Among the three steps above, steps 2 and 3 have the highest risk of accidents, and the two most common accidents are conflict and file occupation, which we discuss below.

2.1 merge remote branch conflicts

If your local branch has already created a commit before performing the update operation and has not yet been pushed to the remote branch, there is likely to be a conflict when performing git merge in step 2.

At this point, close the conflict window above, and the Version Control tool window displays as follows:

The location where the branch name was originally displayed in the lower right corner of the window becomes Merging master, indicating that the local branch master is currently in the merging state. Click the Resolve button in the red box on the left to bring up the conflict handling window again. After the conflict is resolved manually by the IDEA-based graphical interface, IDEA automatically adds the file to the temporary storage area (adding the temporary storage area means the conflict resolution is complete), and the final commit can complete the conflict resolution.

2.2 recovery of storage conflicts

When git stash pop restore storage is performed in step 3 of the update operation, the stored content may conflict with the content that has just been updated.

The conflict that occurs when restoring storage is slightly different from the above merge conflict, first of all, the name of the branch in the lower right corner does not have the word Merging, and an extra small window will pop up in the lower right corner to indicate the failure to restore storage, and tell you not to worry, all the changes are in the stash list and are not lost. You can view the stash list by clicking the menu VCS-Git-UnStash Changes...:

Select the entry at the top of the list, then click Apply Stash, and the previous changes will return to the working directory.

Let's go back to the conflict and manually resolve the conflict and perform a submission. If a misoperation occurs during conflict resolution, you can right-click Default Changelist-Revert... Clear the contents of the current working directory, re-execute Apply Stash, and then repeat the conflict resolution process.

2.3 File occupancy error

When performing step 2 git merge, execution may fail because the file is occupied. For example, the project may introduce some jar files, these jar files have been dynamically loaded by JVM locally, if someone else updated the jar file and pushed to the remote branch, you will encounter the above problem when you update. Follow the Wechat official account "web_resourc" and reply to Java to get the 2019 latest resources.

The solution to this error is simple: first unoccupy the file, such as terminating the local JVM process, and then click VCS-Update again.

When you execute step 3 git stash pop, the execution will also fail because the file is occupied. For example, if you update a jar file, the recovery may fail because the jar file is occupied when restoring storage.

For this kind of error, you need to release the file occupancy first, and then perform the unstash operation manually.

3. Submit or update first? Is a problem!

3.1 problems caused by submission and update

3.1.1 it is difficult to deal with conflicts

If you submit first, but there is a conflict during the update, it means that the submission you just created is actually problematic, usually due to team communication or division of labor, but in any case, someone else has already taken the lead in push, and your submission will be rejected. Even if the conflict is resolved manually, the retention of this submission will become a hidden danger in history. If someone else reset returns to this submission to continue to work, the probability of conflict when merging other branch content will be greatly increased, so it is best to cancel the submission (reset-soft HEAD~), then update and resolve the conflict, and finally create a new submission.

3.1.2 incorrect handling of conflicts

After a conflict, some students may think of the following ways to deal with it:

Clear the current workspace

Adjust the code for the conflict part

Then perform the update operation again

The above approach is obviously not feasible, because the code you adjust will first be stored (stash) by IDEA, and then conflicts will still occur in step 2 of the update, and when conflicts occur, your changes have not been restored to storage (unstash), making it seem that the code you adjusted is missing and puzzling.

3.1.3 Rebase will rewrite the submission history

If you select update type Rebase in the update window of IDEA, it is equivalent to manually executing the git fetch & & git rebase or git pull-- rebase command. The advantage is that an automatic merge submission is not generated and a concise submission history is maintained. However, it should be noted that after Rebase, your local submission will be rewritten. Although the submission information is the same, the commit hash has changed, as shown in the following figure:

After executing the following Rebase command

The execution result is:

Please note that the v4 and v5 submissions in the results have been rewritten.

3.2 it is recommended to update before submitting

If you know in advance that there will be conflicts, I believe you will not choose to submit the code first, but conflicts are inevitable, which requires us to develop good development habits. Instead of resolving post-submission conflicts, it is better to resolve conflicts and then commit as soon as possible, which can not only reduce a meaningless automatic merge submission, but also simplify the processing process when conflicts occur.

3.3 develop good habits

To avoid conflicts as much as possible, it is recommended to develop the following development habits:

Update before coding

Update before submission

Check for compilation errors before submission

The granularity of submission is as small as possible and the description is as accurate as possible.

Modify the public file and inform other members of the update as soon as possible

Last but not least, the division of labor in the team should be clear.

At this point, I believe you have a deeper understanding of "Git code loss prevention methods", might as well come to the actual operation of it! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.