A match made in heaven: Git and IntelliJ IDEA

Sticking to the established tradition, I greet you as future senior software engineers. Today's article is the logical extension of my article on Git. In the article about Git, I described how to work with Git on the command line. Today I will show you how to do it all in IntelliJ IDEA. At the beginning of my journey as a developer, I used the command line and thought that I didn't need a GUI for this. After all, everything was clear as it was... But that was right up to the moment when I started using Git in IntelliJ IDEA... From the outset, I want to say that I am describing my personal experience. There are several ways to solve any given problem in IntelliJ IDEA. If you know a better way than what I will describe in the article, write it in the comments and we'll discuss it.

Required inputs:

1. Read, follow along, and understand my article about Git. This will help ensure that everything is set up and ready to go.
2. Install IntelliJ IDEA.
3. Allocate an hour of personal time to achieve complete mastery.

Let's work with the demo project that I used for the article about Git. UPDATE: At the time of publication, the new GitHub UI will be available, and some icons will not be where they are shown in the article. Don't be alarmed: you just need to either not switch to the new UI, or look for them.

Clone the project locally

There are two options here:

1. If you already have a GitHub account and want to push something later, it is better to fork the project and clone your own copy.
2. Clone my repository and do everything locally without the ability to push the whole thing to the server. After all, this is my repository :)

To clone a project from GitHub, you need to copy the project link and pass it to IntelliJ IDEA:

1. Copy the project address:

2. Open IntelliJ IDEA and select "Get from Version Control":

3. Copy and paste the project address:

4. You will be prompted to create an IntelliJ IDEA project. Accept the offer:

5. Since there is no build system and that's beyond the scope of this article, we select Create project from existing sources :

6. Next you'll see this beautiful screen: Now that we figured out cloning, you can take a look around.

First glance at IntelliJ IDEA as a Git UI

Take a closer look at the cloned project: you can already get a lot of information about the version control system. First, we have the Version Control pane in the lower left corner. Here you can find all local changes and get a list of commits (analogous to "git log"). Let's move on to a discussion of Log. There is a certain visualization that helps us understand exactly how development has proceeded. For example, you can see that a new branch was created with a added header to txt commit, which was then merged into the master branch. If you click on a commit, you can see in the right corner all the information about the commit: all its changes and metadata.Moreover, you can see the actual changes. We also see that a conflict was resolved there. IDEA also presents this very well. If you double-click on the file that was changed during this commit, we will see how the conflict was resolved:We note that on the left and the right we have the two versions of the same file that needed to be merged into one. And in the middle, we have the final merged result. When a project has many branches, commits, and users, you need to search separately by branch, user, and date:The last thing I want to explain before we start is how to understand which branch we are in. I'll give you a minute to figure it out... Did you find it? Give up? :D In the lower right corner, there is a button labeled Git: master. Whatever follows "Git:" is the current branch. If you click the button, you can do a lot of useful things: switch to another branch, create a new one, rename an existing one, and so on.

Working with a repository

Useful hotkeys

For future work, you need to remember a few very useful hotkeys:

0. CTRL+T — Get the latest changes from the remote repository (git pull).
1. CTRL+K — Create a commit / see all the current changes. This includes both untracked and modified files (see my article about git, which explains this) (git commit).
2. CTRL+SHIFT+K — This is the command for pushing changes to the remote repository. All commits created locally and not yet in the remote repository will be pushed (git push).
3. ALT+CTRL+Z — Rollback changes in a specific file to the state of the last commit created in the local repository. If you select the entire project in the upper left corner, you can roll back changes in all files.

What do we want?

To get work done, we need to master a basic scenario that is used everywhere. The objective is to implement new functionality in a separate branch and then push it to a remote repository (then you also need to create a pull request to the main branch, but that's beyond the scope of this article). What is required to do this?

1. Get all the current changes in the main branch (for example, "master").

2. From this main branch, create a separate branch for your work.

3. Implement the new functionality.

4. Go to the main branch and check if there have been any new changes while we were working. If not, then everything is fine. But if there were changes, then we do the following: go to the working branch and rebase the changes from the main branch to ours. If everything goes well, then great. But it's entirely possible that there will be conflicts. As it happens, they just can be resolved in advance, without wasting time in the remote repository.

   Are you wondering why you should do this? It's good manners and prevents conflicts from occurring after pushing your branch to the local repository (there is, of course, a possibility that conflicts will still occur, but it becomes much smaller).

5. Push your changes to the remote repository.

What comes next depends on your tasks and your imagination.

Get changes from the remote server?

I added a description to the README with a new commit and want to get these changes. If changes were made both in the local repository and in the remote one, then we are invited to choose between a merge and a rebase. We choose to merge. Enter CTRL+T:You can now see how the README has changed, i.e. the changes from the remote repository were pulled in, and in the lower right corner you can see all the details of the changes that came from the server.

Create a new branch based on master

Everything is simple here.

1. Go to the bottom right corner and click Git: master. Select + New Branch.

Leave the Checkout branch checkbox selected and enter the name of the new branch. For me, it will be readme-improver.

Git: master will then change to Git: readme-improver.

Let's simulate parallel work

For conflicts to appear, someone has to create them :D I will edit the README with a new commit through the browser, thus simulating parallel work. It's as if someone made changes in the same file while I was working on it. The result will be a conflict. I will remove the word "полностью" from line 10.

Implement our functionality

Our task is to change the README and add a description to the new article. That is, the work in Git goes through IntelliJ IDEA. Add this:The changes are done. Now we can create a commit. Press CTRL+K, which gives us:Before creating a commit, we need to take a close look at what this window offers. I added red arrows to show you where to look. There's a lot of interesting stuff here. In the Commit Message section, we write text associated with the commit. Then to create it, we need to click Commit. I still haven't found out how to do this with a hotkey. If someone finds out how, please write me — that would make me very happy. We write that the README has changed and create the commit. An alert pops up in the lower left corner with the name of the commit:

Check if the main branch has changed

We completed our task. It works. We wrote tests. Everything is fine. But before pushing to the server, we still need to check if there were any changes in the main branch in the meantime. How could that happen? Quite easily: someone receives a task after you, and that someone finishes it faster than you finish your task. So we need to go to the master branch. To do this, we need to do what is shown in the lower right corner in the screenshot below:In the master branch, press CTRL+T to get its latest changes from the remote server. Looking at what the changes, you can easily see what happened:The word "полностью" was removed. Maybe someone from marketing decided that it should not be written like that and gave the developers a task to update it. We now have a local copy of the latest version of the master branch. Go back to readme-improver. Now we need to rebase the changes from the master branch to ours. We do this:If you did everything correctly and followed along with me, the result should show a conflict in the README file:Here we also have a lot of information to understand and soak up. Shown here is a list of files (in our case, one file) that have conflicts. We can choose from three options:

1. accept yours — accept only changes from readme-improver.
2. accept theirs — accept only changes from master.
3. merge — choose yourself what you want to keep and what to discard.

It is not clear what changed. If there are changes are the master branch, they must be needed there, so we cannot simply accept our changes. Accordingly, we select merge: Here we can see that there are three parts:

1. These are the changes from readme-improver.
2. The merged result. For now, it is what existed before the changes.
3. The changes from the master branch.

We need to produce a merged result that will satisfy everyone. Reviewing what was changed BEFORE our changes, we realize that they simply removed the word "полностью". Okay, no problem! That means that we will also remove it in the merged result and then add our changes. Once we correct the merged result, we can click Apply. Then a notification will pop up, telling us that the rebase was successful:There! We resolved our first conflict through IntelliJ IDEA :D

Push changes to the remote server

The next step is to push the changes to the remote server and create a pull request. To do this, simply press CTRL+SHIFT+K. Then we get:On the left, there will be a list of commits that have not been pushed to the remote repository. On the right will be all the files that have changed. And that's it! Press Push and you will experience happiness :) If the push is successful, you will see a notification like this in the lower right corner:

Bonus part

At first, I didn't want to add the creation of a pull request to this article, but it's not quite complete without it. So, let's go to a GitHub repository (one that's yours, of course :)) and we see that GitHub already knows what we want:Click Compare & pull request. Then click Create pull request. Because we resolved the conflicts in advance, now when creating a pull request, we can immediately merge it:And that's all I wanted to say this time. Of course, I've only opened the door a little for you and showed you a small part. You will learn about the rest as you need it. I have a habit of inviting you to follow me on GitHub, where I post my projects involving various technologies that I use at work. I recently made a personal achievement: one of my projects was given stars by more than a hundred developers. There is an incredible feeling of joy when you know that what you have done is being used by someone else. And using it for good.

Useful links

1. CodeGym: Getting started with Git: a comprehensive guide for newbies
2. GitHub: Demo project for practice
3. JetBrains: Set up a Git Repository
4. GitHub: My account