Necessary introductory notes:
- Read, repeat and understand the article about git . This will help ensure that everything is already set up and ready to go.
- Install Intellij IDEA.
- Set aside an hour of personal time for complete absorption.
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 to yourself and clone your copy. How to make a fork - I described in this article in the chapter an example of the forking workflow .
- Clone from my repository and do everything locally without the ability to push the whole thing onto the server. After all, this will be my repository))
-
Copy the project address:
-
Open Intellij IDEA and select Get from Version Control:
-
Copy and paste the address to the project:
-
You will be prompted to create an Intellij IDEA project. We accept the offer:
-
Since there is no build system, and this is not the scope of the article, select Create project from existing sources :
-
Next there will be an oil painting like this: We've sorted out cloning, now we can look around.
First look at Intellij IDEA as a Git UI
Take another close look at the cloned project: already there you can get a lot of information about the version control system. The first is the Version Control panel in the lower left corner. In it you can find all local changes and get a list of commits (analogous to git log). Let's move on to the Log lecture . There is a certain visual component that helps to understand exactly how the development process went. For example, you can see that a new branch was created with a commit added header to txt , which was then merged into the master branch. If you click on a commit, in the right corner you can see all the information about the commit: all the changes and its metadata. Moreover, you can see what changes have been made. Moreover, the conflict was resolved there. IDEA also shows this perfectly. If you double-click on the file that was changed during this commit, we will see how the conflict was resolved: It is noticeable that on the right and left there were two versions of the same file that needed to be merged into one. And in the middle is the final result. When a project has many branches, commits and users who work in the project, you need to search separately by branch (branch), user (user) and date (date): And the last thing I want to explain before starting is how understand which branch we are in. I'll give you a minute to search... did you find it? Are you giving up? :D In the lower right corner there is a button Git: master , where after Git: it shows which branch the project is currently on. If you click on the button, you can do a lot of useful things: move to another branch, create a new one, rename an existing one, and so on.Working with the repository
Useful hotkeys
To continue working, you need to remember a few very useful hotkeys:- ctrl + t - get the latest changes from a remote repository (git pull).
- ctrl + k - commit/view all changes that are currently available. This includes both untracked and modified files (see my article about git, this is described there) (git commit).
- ctrl + shift + k is a command for pushing changes to a remote repository. All commits that were created locally and are not yet on the remote one will be offered for push (git push).
- alt + ctrl + z - roll back changes in a specific file to the state of the last created commit in the local repository. If you select the entire project in the upper left corner, you can roll back changes to all files.
What do we want?
To work, we need to master the basic script, which is used everywhere. The task is to implement new functionality in a separate branch and push it to a remote repository (then you need to create another pull request for the main branch, but this is beyond the scope of our article). What do I need to do?-
Get all changes currently in the main branch (master, for example).
-
Based on this main one, create a separate one for your work.
-
Implement new functionality.
-
Go to the main branch and check if there were any new changes while you were working. If it wasn’t, then everything is fine, and if it was, then we do the following: we go to the working branch and rebase the changes from the main branch to ours. If everything went well, then great. But there may well be conflicts. And they can be solved in advance without wasting time on a remote repository.
It would seem, why do this? This is a rule of good form, which prevents conflicts from arising after pushing your branch to the local repository (there is, of course, a chance that they will still exist, but it becomes much smaller).
- Push your changes to a remote repository.
Receive changes from a remote server?
I added a description to the README with a new commit and want to receive these changes. A choice is offered between merge and rebase if changes were made in both the local and remote repositories. Select a merge. Enter ctrl + t : As a result, you can see how the README has changed, i.e. changes from the remote repository have been pulled up, 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.-
Go to the lower right corner and click on Git: master , select + New Branch .
Leave the Checkout branch checkbox and write the name of the new branch. For me it would be readme-improver .
After this, Git: master will change to Git: readme-improver .
Simulating parallel work
For conflicts to appear, someone must create them :D I will edit the README with a new commit through the browser and thus simulate parallel work. They say someone, during my work, made changes to the same file as me, which will lead to a conflict. I will remove the word “entirely” from line 10.Implement your functionality
The task is to change the README and add a description to the new article, that is, the work in the git is done through Intellij IDEA. Add this: The changes are complete, now you can create a commit. Press the hotkey ctrl + k , we get: Before creating a commit, you need to carefully look at what is offered in this window. I specifically added an arrow to show you where to look. There are a lot of interesting things there. In the Commit Message section we write the text of the commit, and for it to be created, you need to click the Commit button . I still haven’t found how to do this with a hotkey, so if someone finds it, write, I will be very happy. We write that the README has changed and create a commit. As a result, an alert will pop up in the lower left corner with the name of the commit:Check if the master branch has changed
We completed the task, it works, we wrote the tests, everything is fine. But before pushing to the server, you need to check whether there have been any changes in the main branch during this time. How could this happen? It’s very simple: someone was given a task after you, and this someone did it faster than you. Therefore, we move to the master branch. To do this, you need to do in the lower right corner what is shown in the figure below: In the master branch, press ctrl + t to get its latest changes from the remote server. If you look at what changes were made, you can easily notice what happened: As you can see, the word “completely” was removed. Perhaps it was someone from marketing who decided that it couldn’t be written like that and gave the developers the task of updating it. We now have the latest version of the master branch locally. Let's go back to readme-improver . Now we need to rebase the changes from the master branch to ours. We do: If you followed everything correctly with me, the result should be a conflict in the README file: There is also a lot of information here that needs to be understood and absorbed. This shows a list (in our case of one element) of files that have conflicts. We can choose three options:- accept yours - accept only changes from readme-improver.
- accept theirs - accept only changes from master.
- merge - choose for yourself what to keep and what to remove.
- These are changes from readme-improver.
- Result. For now it is the same as it was before the changes.
- Changes from the master branch.
Push changes to a remote server
The next step is to push the changes to the remote server and create a pull request. To do this, just press ctrl + shift + k , after which we get: On the left there will be a list of commits that have not been pushed to the remote repository, and on the right there will be all the files that have been changed. That's all: click Push , and you will be happy :) If the push is successful, there will be a notification like this in the lower right corner:Bonus part
I didn’t initially want to add the creation of a pull request to the article, but it turns out not very complete because of this. Therefore, we go to the GitHub repository (if it is yours, of course)))) and see that GitHub already knows what to offer us: Click on Compare & pull request , and then click Create pull request . Due to the fact that we resolved conflicts in advance, now when creating a pull request, you can immediately merge it: That’s all I wanted to tell you this time. Of course, I just opened the door and showed you a small part. You will find the rest yourself as needed. As usual, I invite you to subscribe to my GitHub account , where I post projects based on various technologies that I use at work. I recently had a personal achievement - my project has already been rated by more than a hundred developers. It's an incredible feeling of joy that someone uses what you made. And uses it for good.useful links
- JavaRush: Getting started with Git: a detailed guide for beginners
- GitHub: Demo project to work with
- JavaRush: Analyzing branching strategies in Git
- JetBrains: Set up a Git Repository
- Habr: Git rebase
- GitHub: My Account