- 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 locallyThere 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 UITake 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 hotkeysFor 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: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 masterEverything 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 workFor 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 functionalityOur 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 changedWe 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:
- 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.