Professional tools and troubleshooting

So far, we’ve looked at an ideal scenario: you write code, make commits, and create a pull request. But in real life, things often don’t go as planned: you might make a mistake in the code, create a commit with an incorrect message, or simply realize you went in the wrong direction. In this lecture, we’ll go over how to solve the most common problems.

1. Rollback — undoing changes before a commit

Scenario: you changed a file but realized all your edits are wrong and you want to quickly return the file to the state it was in after the last commit.

Use the Rollback function:

1. Open the Commit tab.
2. Find the changed file you want to “roll back.”
3. Right-click it and choose Rollback.

The IDE will warn you that the changes will be lost. Confirm, and the file will instantly return to its last version saved in Git. This is the simplest and safest way to undo local changes.

2. Reset — removing local commits

Scenario: you made one or more commits but haven’t done a push yet. You realized those commits are wrong and want to remove them completely, as if they never existed.

Use the Reset function:

1. Open Git -> Log to see the commit history.
2. Find the last “good” commit you want to end up on (the one before the bad ones).
3. Right-click it and choose Reset Current Branch to Here....

In the dialog that opens, you’ll be asked to choose a reset mode. The most radical is Hard.

Warning! The Hard mode permanently deletes all commits after the selected one, as well as all code changes that were in those commits. Use it with great caution and only for commits that no one has seen yet (those that were not pushed to GitHub).

3. What to do after a push?

Scenario: you did a push and only then noticed an error in it.

Once a commit reaches the remote server, it becomes part of the shared project history. Trying to rewrite that history can create huge problems for your colleagues. Imagine they’ve already pulled your changes and started their own work based on them.

The correct and safe solution:

Simply make a new commit that fixes the error and push it. This is absolutely normal practice. This way, the history remains honest and clear to everyone.

4. Looking into the past: advanced log usage

We’re already familiar with the Git -> Log tab, but it’s not just a list of commits — it’s a powerful investigation tool.

• Commit hash (Commit Hash): you’ve probably noticed a string of letters and digits in the log, for example a1b2c3d. This hash is unique; it lets you reference any point in the project’s history precisely. You will rarely need to use it manually, but it’s important to know that this is the unique identifier of each “snapshot” of your code.
• You can filter history by branch, author, date, or even by a word in the commit message. This helps quickly find who worked on a particular piece of functionality and when.
• Want to find the commit where a specific line of code was added or removed? In the Log window there’s a search field that searches not only commit messages, but also the contents of the changes themselves.
• Right-click in the code editor gutter and choose Annotate with Git Blame. The IDE will show next to each line who last changed it and in which commit. This is incredibly useful for understanding why the code is written the way it is.

5. Danger zone: Force push

So, we’ve established that rewriting pushed commits is a bad idea. But what if you did change your local history (for example, with Reset) and now it diverges from the server’s history? When you try a normal push, Git will throw an error to protect the shared history from being overwritten.

For such cases there’s an option — force push. This command tells the server: “Forget everything you had. My local version of history is the only correct one. Replace your history with mine.”

WARNING! In 99% of cases, using force push in team projects is a catastrophe. It can permanently delete commits that your colleagues have already pulled and are working from. It’s tantamount to tearing pages out of a shared library book and gluing in your own.

When you must never use force push:

• On any shared branches: main, develop, master. Never.
• On any branch that anyone other than you is working on.

The only acceptable scenario:

You’re working in your personal feature branch that no one else has seen or used yet. You made a few “messy” commits, pushed them to the server, and then decided to “clean them up” using Reset. In this case, you can do a force push to update your branch on the server before creating a pull request.

In the IDE, this option is usually hidden behind the Push button. IDE developers did this deliberately so you don’t click it by accident.

If you’re not 100% sure what you’re doing, never use force push. It’s safer to create a new commit with the fixes.

6. Updating the project

Always click Update Project on the main branch before starting a new task. This will save you from many future merge conflicts and ensure you start with the most up-to-date version of the code.