Hello everyone. In the previous episode, we learned how to use PUSH to push new versions of code to the remote repository. In this episode, we will introduce how to PULL (synchronize) the code that our colleagues have pushed to the remote repository back to our local repository. Additionally, after explaining the operation, we will also mention the typical scenarios when we would use this action.

For this operation, I am using IntelliJ IDEA version 2022.3.2 (Community Edition). If you find that you have the same version but a different UI, please enable the new UI in the settings.

Edit and commit new code versions directly on GitHub.

Firstly, for better understanding of the process, we need to simulate our colleague’s code submission. To save time, let’s directly edit the code on GitHub and commit it, so that the version of the code in our remote repository is slightly ahead of the version in our local repository.

1.Firstly, on the GitHub repository, we directly click on the code file that we want to edit.

2.Click on the “Edit this file” button. The screen will now enter the editing mode.

3.In the editing mode, enter some random text. Here, on the second line, I have entered “[Text from colleague’s second line]” for identification purposes.

4.Below, there is a “Commit changes” box. After entering the main purpose and detailed description of this update, directly click the green “Commit changes” button below to submit the update.

5.After the update, we can now see the text we just entered on the code file page.

At the same time, in the project page’s file list, we can also see the commit message we entered during the submission. With this, we have completed the process of our colleague’s code submission.

Performing Pull (code synchronization) operation in IntelliJ IDEA.

Go back to the IntelliJ IDEA interface. First, let’s take a look at the difference between the code versions in the remote repository and the local repository.

1.In the editor interface, right-click the mouse and choose “Git -> Fetch” to update the snapshot of the project repository.

2.After the update is completed, if the remote version is newer than our local version, we will see a blue arrow pointing from the top right to the bottom left (↙) in the Git branch quick switch button at the top. This indicates that our local version can be updated.

3.Next, click the Git button in the bottom left corner or press “Alt+9” to open the Git tool window.

4.Now, let’s check the branch status from the “Log” in the Git tool window. From the logs, we can see that the version of the remote branch “origin/main” is newer than the version of the local branch “main”.

5.Go back to the code editing area, right-click the mouse, and choose “Git -> Pull…”

6.Now we can see that the code has been updated with the line of text that our colleague entered. Also, in the branch history, we can see that the version in our local repository is now synchronized with the version in the remote repository.

With this, we have completed the Pull operation.

Why do we need to perform a Commit operation before executing the Pull action?

In this section, let’s discuss a good practice, which is to wrap up our current development work and perform a commit operation before executing the Pull action.

Because in a collaborative development environment where multiple people are working on the same project, it is quite common to have two or more individuals developing the same file simultaneously. This can lead to different developers making changes to the same location, resulting in what we call code version conflicts.

In order to efficiently track and resolve conflicts that may arise in such situations, it is a good practice to wrap up our current work and perform a commit before executing a Pull. This way, we can easily understand the reasons behind the changes we made and those made by our colleagues. Knowing the reasons allows us to handle the code conflicts effectively.

Furthermore, it’s worth mentioning that currently in IntelliJ IDEA, if code modifications have been made but a commit has not been performed before the Pull action, the Pull operation cannot be executed. Instead, we will encounter a “Git Pull Failed” error message.

Once we have performed a Commit, if there are conflicts between the remote version and our current version, IntelliJ IDEA will automatically display a conflict resolution window, providing a user-friendly and convenient approach. (We will explain the operation of the code conflict window together in the “Conflict Handling” section.)

In daily work, when do we use the PULL operation?

In the last section of this chapter, let’s discuss when we perform the Pull operation in our daily work.

The first timing: The first thing we do when we sit down to work is to perform the Pull operation in IntelliJ IDEA.

Due to company culture and remote work arrangements, it is highly possible that while we are away from work, other colleagues might have made code modifications. If we perform a Pull before starting to write code, we can quickly identify if there are potential conflicts in the current code. This allows us to address conflicting code sections in advance, preventing the conflicts from escalating during the development process and causing various troubles during resolution (including code complexity or difficulties in communication between team members).

The second timing: When the current feature development reaches a milestone, first commit the changes, and then immediately perform the Pull operation.

When reaching a milestone in feature development, it is highly likely that there have been code changes during the development of that feature. At this point, after committing the changes, performing a Pull can help identify code conflicts early and handle them promptly. This ensures that we resolve all issues before pushing the changes to the remote repository, avoiding delays and difficulties for other developers caused by unresolved problems.

The third timing: Before leaving work, commit the current work, and then immediately perform the Pull operation.

Before leaving work, even if the current feature development has not reached a milestone, we still perform a Pull operation. The reason is the same as before – there might have been code changes during the development of that feature. Detecting conflicts early allows us to address them promptly, so we can start the feature development work faster and with a better mood the next day. Also, don’t forget that if conflicts are detected and resolved during the pull before leaving work, make sure to do an additional Commit before leaving.

Video Demonstration (using 2023.1.2 Community Edition)