IDEA git operation skills collection, continuously updated

About the Author

Table of contents

1. Create a new project

2. Push and pull code

3. Status identification

1. Create a new project

First, we create a new project on GitHub, then pull this empty project locally, build the skeleton of a maven project locally, and then push it up. We will walk through the whole process of how to host a project to git from scratch, which will be discussed later. The operation will also be demonstrated based on this project.

First we create a new repository on GitHub:

Pull the project locally on IDEA. When pulling the code, you need to authenticate. Just enter your username and password:

Manually build a maven project in the pulled down directory, and create a new project structure according to the structure of the maven project. The test folder and resource folder are omitted here. You can add them yourself if needed:

pom.xml example:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>org.example</groupId>
    <artifactId>IdeaGitDemo</artifactId>
    <version>1.0-SNAPSHOT</version>



</project>

Then turn the project into a maven project:

Then push the project to the remote warehouse.

2. Push and pull code

There is a git push and pull option in the upper right corner of IDEA.

3. Status identification

The green ones are new ones that have not yet been committed, and the blue ones represent changes that have not yet been committed.

Double-click a file of a commit you want to view, and a comparison panel between the current version and the previous version will pop up:

The comparison panel supports some shortcut operations: jump to the previous difference, jump to the next difference, and locate the source file of the file.

5.cherry pick

Cherry pick can be used when we want to merge certain commits instead of merging two branches.

Give an example of a usage scenario:

When we have a main branch main, and then pull out two development branches Dev_A and Dev_B based on main, the two development teams are developing different functions on these two branches. During the development process, Dev_A's development team discovered a bug on main, and then fixed the bug on its own development branch. At this time, since both development branches have not been completed, it is impossible to directly merge Dev_A into any branch. You can only merge the commit that fixes the bug into each branch. At this time, you can use cherry pick.

For example, at this time, there are bug fixes for the master content on Dev_A, but there are new development content submissions later. If you directly merge the Dev_A branch into the main branch, the unstable content that has not completed the test will be merged into the main branch, thereby disrupting the entire branch. main branch. If this bug fix is directly merged into other development branches, it will disrupt the normal development of other branches.

At this time, cut to the main branch, and then commit the bug fix and cherry pick to the main branch:

At this time, the commit to fix the bug has been uploaded to the main branch. Just push the main branch:

6.revert

In actual development, there may be situations like this:

A certain piece of code was rewritten by us at a certain moment, and then not long after the customer had a change in demand, we found that it was better to make new demands based on the original code. At this time, we are required to roll back this piece of code to the previous version.

Obviously, it is impossible to use the version number to roll back the entire code version to a certain version, because other files do not need to be rolled back, only the current piece of code needs to be rolled back. At this time you need to use revert. The revert command can roll back a file to a specified version:

The file rolled back after revert will definitely conflict with the current file. In this case, you need to manually merge the conflicts:

After merging conflicts, IDEA will automatically generate a standard revert commit message, commit and then push it to the server:

7.squash

In actual development, we may often encounter situations like this:

A file has just been modified, and it is found that it has not been modified correctly or has not been completed, so it continues to modify and submit, and then submits a large series of consecutive scattered submissions. At this time, in order to prevent the log from looking messy, you can consider merging multiple submissions. commit：

First, click on the earliest commit to be merged, and choose to start rebuilding the basics from here:

Select all nodes upward from this node and squash into, except for the first item, select all subsequent nodes as squash:

(The blogger forgot to take a screenshot when performing this step and stole a picture from elsewhere to give an example)

start rebasing：

Re-enter the commit message.

After continue rebasing, you can see that multiple submission records are combined into one:

8. Version rollback

There is a lot of content in this section, and it is not easy to understand as a chapter. The blogger will write a separate article about this section in the next few articles. After it is written, it will be continuously updated into this article and placed here as a hyperlink. Everyone is welcome to continue to pay attention~