When it comes to developer tools, especially IDEs, JetBrains is one of the top contenders of the industry. Their IntelliJ-based IDEs offer a flexible, ergonomic, though sometimes performance heavy solution for the everyday developer. In this blog post series I’ll focus on the version control system capabilities (especially Git and GitHub) of their latest IntelliJ IDEA (current release is 2020.1.2) which is one of our most common tools here at the Wanari Backend team.
Excellent question! One of my favorite features about IntelliJ is how comfortable it makes the development workflow. In the first half of this series, I’d like to show you how easy it is to perform the common Git and GitHub tricks once you’ve got the feel of it. Working with a well organized GUI is much less painful than a cumbersome CLI, which will become clearer as we’ll delve into more and more advanced Git witchcraft in later episodes.
This initial episode of the series will include the most basic necessities such as:
For our purposes, let’s assume we’ve just created a new project in IntelliJ and we’re eager to start putting our app together piece by piece. It would probably be a good idea to set up a GitHub repo, which will make team collaboration simpler by a great deal, not to mention the obvious advantages of having a backup of our cherished codebase.
First, we should provide our GitHub credentials to IntelliJ. Open File → Settings… and in the newly appeared window find Version Control → GitHub. Add a new account and in the popup provide your login details.
Then we need to click on VCS → Import into Version Control → Share Project On GitHub and hit the Share button on the popup. If you prefer keeping your codebase hidden from the world check the Private option on the popup.
Let’s take a look at our Github page to see if we’ve had success!
Our new repository seems intact, even though it’s a bit bare. We’re almost ready to start publishing our progress!
Before we begin typing away, it’s important to talk about what we actually don’t want to publish. If we take a look at the Project view (View → Tool Windows → Project), we can see that the .gitignore file was automatically created with the repository.
For my own purposes I’ve added these exclusions:
Let’s talk about creating our initial commit! In the Project view, we can see that the excluded folders and files are marked with a yellowish color so it’s easy to recognize which resources won’t be committed. By default, our folders and files take on white color but when we apply some changes to a resource, it turns red. By right-clicking on a file and selecting Git → Add, we add it to the Default changelist, so it turns to green to indicate that it’s tracked and ready to be committed. These color codings can be customized under Files → Settings → Version Control → File Status Colors if you see fit.
At the simplest form, we don’t really need to add the files to be able to commit them, but it will be a tremendously helpful feature when we’ll get to know changelists in a later episode. For now, let’s just open the Commit Changes dialog! There are several ways of doing this. We can make it happen by:
We should see a similar Commit Changes dialog:
Remember when I said we don’t need to add all the files to be tracked? We have the option to add any files we’d like to commit here, so let’s add the Unversioned Files as well. We have a bunch of other options we won’t need now so I’ll just set a commit message and the author field and then we’ll be ready to commit!
On the bottom, use the blue Commit button! A Code Analysis warning might appear to inform us about any errors and warnings that might occur. We’re given the options to Review these concerns, ignore them and Commit anyway or Cancel the action. We shouldn’t be worried (for now) so let’s just ignore the warning and Commit.
We only have one problem now which is that our commit only exists in our local repository. We should keep the remote repository in sync with our latest changes by pushing the commits. Open the Push Commits to remote dialog under VCS → Git → Push.
Everything seems to be in order so let’s hit the Push button then check the results on GitHub.
You may have noticed that in the former chapter we didn’t take advantage of branches and only operated on the master branch. However, projects are all about collaborating with your teammates which may raise some difficulties. We’d like to avoid getting tangled up in each other’s changes as well as keeping track of individual progress. Luckily, this is what branches are made for.
Let’s say we’ve been put in charge of implementing some feature of the app. Naturally, we’d like to start by creating a new branch. Open the branches dialog by clicking on
By clicking on New Branch, the new branch will be based on the branch you’re currently on, so make sure it’s the right one!
Alternately you can click on the remote branch you’d like your new branch to be based on (origin/master in this case) and then select New Branch from Selected…
Name the branch, check the Checkout branch option and hit Create.
In the bottom right corner we can see that the newly created branch was indeed checked out.
After implementing the requested feature we should commit and push the changes. In the Commit Changes dialog select the Commit and Push… action then in the next window choose Push.
If we go to our Github page we can see that the operation was successful.
To make these changes final, let’s create a pull request from IntelliJ. We can achieve this by opening the Create Pull Request window under VCS → Git → Create Pull Request.
Click OK on the popup. Let’s open the PR under VCS → Git → View Pull Requests which will make the Pull Requests view visible in the Git tool window.
There’s a number of options that we can apply here but we’ll take a look at the View Timeline and the Show Diff actions. On the right side right-click on any file and choose Show Diff.
Here we can see all the changes since the last commit and even leave comments just like on Github!
By right-clicking on the PR and then selecting View Timeline we can see the latest updates of the Pull Request.
If the Pull Request suffices, click on Merge then check on Github if we were successful.
Let’s switch back to the master branch before we start working on a new feature (***VCS → Git → Branches…***, then click on master and then Checkout). If we take a look at the Git Branches window the blue arrow indicates that the remote branch has changed and the local branch is behind it.
Let’s pull the changes by clicking on VCS → Git → Pull:
The default settings seem fine so hit Pull and the changes should be applied.
Alternatively you can do this even quicker by clicking on the blue arrow in the top right corner and then choosing between merging or rebasing changes.
Thank you for reading this short post about the basics of using Git and GitHub in IntelliJ IDEA!
I hope you found these simple tricks useful and got motivated to abandon the boring command line in favor of convenience. We only scratched the tip of the iceberg so stay tuned for future posts!