
Required inputs:
- Read, follow along, and understand my article about Git. This will help ensure that everything is set up and ready to go.
- Install IntelliJ IDEA.
- Allocate an hour of personal time to achieve complete mastery.
Clone the project locally
There are two options here:- 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.
- Clone my repository and do everything locally without the ability to push the whole thing to the server. After all, this is my repository :)
Copy the project address:
Open IntelliJ IDEA and select "Get from Version Control":
Copy and paste the project address:
You will be prompted to create an IntelliJ IDEA project. Accept the offer:
Since there is no build system and that's beyond the scope of this article, we select Create project from existing sources :
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.



Working with a repository
Useful hotkeys
For future work, you need to remember a few very useful hotkeys:- CTRL+T — Get the latest changes from the remote repository (git pull).
- 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).
- 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).
- 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?Get all the current changes in the main branch (for example, "master").
From this main branch, create a separate branch for your work.
Implement the new functionality.
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).
- Push your changes to the remote repository.
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:

Create a new branch based on master
Everything is simple here.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:


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:



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

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

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:

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:

GO TO FULL VERSION