Write in front

For a long time, I have been using the git command line to manage code. When there is only one person, this is completely okay. However, when participating in teamwork, the command line seems incomprehensible. This does not mean that you cannot do it after the command, but Commands need to remember too many commands, the learning cost is too high, and if you only rely on commands to resolve conflicts, you will never want to experience the feeling that you have experienced it once. After spending a day or two studying the idea's git tool, I decided to give up the command line and embrace the gui completely, so I will record the research results of these two days for your reference.

Create warehouse

Create a remote warehouse

The first step is to github or gitee code management platform. Here we take github as an example

  • Enter the warehouse name
  • Select the warehouse type, public means everyone is visible, private means only authorized

After the warehouse is created, it is an empty warehouse by default. At this time, the interface will prompt how to push code to the warehouse

Notice that there is a warehouse address on the interface, the address is ssh and https, what is the difference between the two?

  • https: Code management through http protocol, user name and password are required
  • ssh: code management through the ssh protocol, using a key (you can understand it as a credential)

The operation of pushing the warehouse will be explained in detail later, so I won't introduce it here.

Associate local warehouse

If it is a local existing project that needs to be associated with the newly created remote warehouse, the specific steps are as follows

  • Initialize the project

VCS -> Import into Version Control -> Create Git Repository in the menu bar, and a folder selection window will pop up after selection. Just select the current folder

After selecting the folder, idea will create a .git in the current directory, indicating that the project is already a project that uses git version control. If your terminal is a friendly terminal (such as Oh My ), this time Will display the current branch, the default is the master branch

➜  git-learning git:(master) ✗
  • Associate remote warehouse

The remote warehouse is called Remote in git. A project can be associated with multiple reomtes, that is, your project can be pushed to multiple remote warehouses at the same time. This is very useful. For example, our code needs to be pushed to the customer warehouse for integration. , And you need to push to the company’s warehouse for code review. At this time, you can use multiple VCS -> Git -> Remotes add a remote warehouse. If it is the first warehouse, the name defaults to origin. It is recommended not to modify the name

In this way, we have completed the association between the local warehouse and the remote warehouse, and then we can submit the code and create the branch.

Clone warehouse

If it is a warehouse that someone else has created and submitted the code, you need to synchronize to the local, then you need to clone the warehouse, select File -> New -> Project from Version Control , and enter the remote warehouse code address.

gitignore

In the project, there are some project files or program runtime files that we don’t want to submit to the warehouse, so we need to prepare a file named .gitignore the files that we don’t want to submit to this file, and git will not deal with them. File submission and management.

example

/out/
/classes/
.mvn
/node_modules/
.idea
*.iws
*.iml
*.ipr
.DS_Store
/target/

You can right-click on the file or folder to add it to gitignore

Submit code

After the code is modified, it needs to be submitted to the local warehouse. This process is called Commit . After the code is submitted to the local warehouse, the commit can be submitted to the remote warehouse. This process is called push . The process of updating the code from a remote warehouse is called pull . A git operation is the three most commonly used operations, and there are buttons corresponding to these three operations in the upper right corner of the idea

  • ① Update code, pull operation
  • ② Submit to the local warehouse, commit operation
  • ③ Submit to remote warehouse, push operation

Click the commit icon to submit the code, the submit code interface is as follows

Note that there is a check box in front of the file. If it is a newly added file, it will not be automatically checked without special configuration. The newly added file needs to be manually checked before submission. You can directly select all the top-level folders Yes, you need to push after commit to synchronize to the remote warehouse, click the push button

After the push is successful, you can log in to the remote warehouse to view the latest code

Note that the system prompts us to add a README file, README is a file named README.md , located in the root directory of the project, a good README file helps others to quickly understand the project situation, about how to write a README file, you can refer to the following Documentation

After modifying the code, the submission interface will also compare the local submission with the previous submission, so that we can view the modified content

Rollback code

There are two ways to roll back the code in git

  • reset
  • revert

What is the difference between the two, suppose we submit three commits

commit1 -> commit2 -> commit3

If I want to roll to commit2, if I use reset, then all the changes after commit2 will be discarded, that is, all the commits after commit2 will be cut off. Revert is a bit like undo, and will reverse the operations done by commit2. That is undo, and a new commit is generated, which becomes

commit1 -> commit2 -> commit3 ->4

What specific application scenarios? For example, when debugging, we may need to add some debugging statements, such as system.out. When the debugging is completed, we hope to remove these debugging statements and submit a commit before debugging. After debugging, you can reset to this commit. Of course, you can also implement it through branches. Just delete the branch after debugging.

Our system is constantly iterating. Suddenly one day, the product manager said that a function that was already online was no longer needed, then the commit corresponding to the function can be found and reverted, so that the corresponding function can be removed and the subsequent new functions can be retained. .

reset

On the toolbar of the idea, click on the Git toolbar to switch to the Log tab. You can see the local commit log and the remote commit log. Right-click on the designated commit and select Reset Current Branch to Hear to roll back to the commit by reset

There are four rollback modes

<img src="http://zhengjianfeng.cn/images/R2byAplCbygdWlcNS98tcHuYiflKF4FC.jpg" style="zoom:60%;" />

Choosing the Hard mode will clear the local version and force a rollback to the specified commit state, but the push operation cannot be performed through reset, because the local version is lower than the remote version, and you can force push to the remote branch at this time

By default, the idea is to prohibit forced push on the master branch. If the master branch requires forced push, you can use the command line git push --force

Force push is a very bad habit, unless you are clearly aware of the consequences of force push, otherwise do not perform force push

revert

Revert can undo all the modifications made by the specified commit without affecting the modifications of other commits. Suppose we have three files, file1.txt, file2.txt, and file3.txt. Now submit three commits, three commit respectively

  • Commit1: add content to file1.txt
  • Commit2: add content to file2.txt
  • Commit3: add content to file3.txt

Now we are in Commit2: File 2 modify this commit, right-click and select Revert Commit , then the commit window will pop up, and idea will automatically submit a new commit. After committing, we find that the content of file 2 is gone, that is, the modification of commit2 has been cancelled. The content can be pushed to the remote warehouse by executing the push operation after commit, because a new commit is generated, so it can be submitted to the remote warehouse without force push

The revert operation will often encounter code conflicts. At this time, you need to manually resolve the conflicts. The solution will be explained in detail below

Branch management

Branch is a very important concept in git. Assuming that without git, our system is online and runs stably online. At this time, you need to develop subsequent functions but want to keep the current online version of the code, because there may be online Urgent bugs need to be fixed and you need to use the current version to modify, so you may copy a copy of the code for backup. When the new function is developed, you also need to integrate the code modified on the backup code during this period of time. This process is carried out manually and is very error-prone, so git provides branches to solve this problem. The code running online can be on the master branch, such as the master branch, and new functions can be developed from the master branch, such as the dev branch. To fix bugs, you can also cut a branch from the master branch, such as the fix branch. When the bug is fixed, merge the fix branch to the master branch. When the new function is developed, integrate the dev branch to the master branch. All the above operations are completed.

New branch

Display the current branch in the lower right corner of the idea

Click Open to create a new branch under the current branch

You can also cut out a branch from a commit. For details, right-click New Branch

Switch branch

If you want to switch to another branch, click on the branch you want to switch and select Checkout

Before switching branches, you need to submit or temporarily save the changes of the current branch. The temporary storage will also be mentioned later

Branch merge

For example, if I want to merge the fix branch to the dev branch, then switch the current branch to dev and select the fix branch Merge into Current

The merging process may cause conflicts, you need to resolve the conflicts to complete the merge, the conflict resolution will also be mentioned below

After merging the branches, it is recommended to delete the fix branch to avoid committing the branch to the remote warehouse by mistake, causing branch confusion.

rebase

Rebase Current onto Selected option on Merge in the above menu. There are two ways to merge, one is merge and the other is rebase. What is the difference between the two, such as rebase at 1:00 in the afternoon, 2 and 3 is the merge method to merge

  • merge will retain branch commit information
  • Merge will create a commit message for Merge branch
  • Compared with merge, rebase integrates the commit on the branch into the current branch, making the entire code cycle clearer
  • Compared to merge, rebase does not generate redundant commit information

The specific use of rebase and merge has its own advantages, depending on the specification requirements of the project.

Conflict resolution

Regardless of whether it is rebase or merge, conflicts will inevitably occur when merging. The so-called conflict means that the code on the two branches is modified to the same place. The system cannot determine which code to keep, and manual intervention is required to resolve the conflict. process. If there are conflicts, all conflicting codes will be listed when merging

There are three options to choose at this time

  • Accept Yours: Keep the current branch code and discard the merged branch code
  • Accept Theirs: Keep the merged branch code, lose the current branch code
  • Merge: Manually merge

After selecting Merge, enter the manual merge code interface

  • ① Current branch code
  • ② The merged code
  • ③ The merged branch code

Idea will highlight the different on both sides, you can merge according to the actual situation

After merging, a confirmation box will pop up. If all conflicts are resolved, you can click Apply Change and Mark Resolved to indicate that the conflicts have been resolved

Label management

Create label

Generally, when we release a new version, we will tag the project to show its importance. On gihub, we often see that the project will be tagged when a new version is released.

Right-click on the commit log to create a label for the commit. The label name is generally the version number, such as v1.0 v1.1 etc.

When pushing the code, you can choose to submit the tags to the remote warehouse together

In this way, we can see the tag in the remote warehouse, and the system will automatically package and archive the code corresponding to the commit at the time of the tag

Pull the code according to the label

For example, if you need to fix the v1.0 code, we need to pull the v1.0 code, and after the repair is completed, it needs to be merged into the current branch

  • Pull code according to tag

The code can be pulled by entering the tag name, but the branch name at this time is the commit number corresponding to the branch. To put it bluntly, it is a commit. We need to create another branch on the branch to modify the code. The method of creation and the above The same, just click on the branch name, New Branch , then submit after modification and merge as normal branch.

patch

patch

You can create a patch for one or more commits, idea will create a .patch file, which records the changes in the file

The patch can be imported on the branch, VCS -> Apply Patch

Patching is also a way of merging, and it also needs to resolve code conflicts

cherry-pick

Similar to patching, cherry-pick can directly apply one or more commits from other branches to the current branch without exporting the patch file


DQuery
300 声望93 粉丝

幸福是奋斗出来的