So far we've looked at the ideal scenario: you write code, make commits, create a Pull Request. But in real life things often go wrong: you might make a mistake in code, commit with a wrong message, or just realize you're heading in the wrong direction. In this lecture we'll go over how to solve the most common problems.
1. Rollback — undoing changes before commit
Scenario: you changed a file but realized all your edits are wrong and want to quickly return the file to the state it was in after the last commit.
Use the Rollback feature:
- Open the
Committab. - Find the changed file you want to "rollback" in the list.
- Right-click it and choose
Rollback.
The IDE will warn you that changes will be lost. Agree, and the file will instantly return to its last version saved in Git. This is the simplest and safest way to discard local changes.
2. Reset — removing local commits
Scenario: you made one or more commits but haven't pushed yet. You realized those commits are wrong and want to remove them completely, like they never happened.
Use the Reset function:
- Open
Git -> Logto see the commit history. - Find the last "good" commit you want to be on (the one before the bad ones).
- Right-click it and choose
Reset Current Branch to Here....
In the popup you'll be asked to choose the reset mode. The most radical is Hard.
Warning! The Hard mode irreversibly 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 haven't been pushed to GitHub).
3. What to do after Push?
Scenario: you pushed, and only after that noticed an error in the push.
Once a commit is on the remote server it becomes part of the shared project history. Trying to rewrite that history can cause huge problems for your teammates. Imagine they've already pulled your changes and started working based on them.
The correct and safe approach:
Just make a new commit that fixes the mistake and push it. That's totally normal. This way the history stays honest and clear for everyone.
4. Look back: advanced work with the log
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: you've probably noticed a string of letters and numbers in the log, e.g.
a1b2c3d. That hash is unique and lets you reference any point in the project's history precisely. You rarely need to use it manually, but it's important to know it's 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 and when worked on a certain part of functionality.
- Want to find the commit that added or removed a specific line of code? The
Logwindow has a search field that looks not only at messages but also at 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 and in which commit last changed it. That's incredibly useful for understanding why the code is written that way.
5. Danger zone: Force Push
So we've established that changing pushed commits is a bad idea. But what if you did rewrite your local history (for example, with Reset) and now it diverges from the server history? When you try a normal push, Git will error out, protecting the shared history from being overwritten.
For such cases there's the option — force push. This command tells the server: "Forget what you had. My local version of the history is the one true version. Replace your history with mine."
WARNING! In 99% of cases using force push in team projects is a disaster. It can irreversibly delete commits your colleagues have already pulled and built work on. It's like 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 more than just you are working on.
The only acceptable scenario:
You're working in your personal feature branch that no one has seen or used. You made several "messy" commits, pushed them to the server, and then decided to "clean them up" with Reset. In that case you may do a force push to update your branch on the server before creating a Pull Request.
In IDEs this option is usually hidden behind the Push button. IDE authors did this on purpose so you don't press 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 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 working from the most up-to-date code.
GO TO FULL VERSION