Developers working in fast-moving teams often deal with overlapping work, long-running features, and reviews that depend on clear and reliable history.

This guide focuses on common Git problems developers face when working in teams and highlights the techniques that keep workflows stable, predictable, and easy to maintain.

Handling Merge Conflicts the Right Way

You created a Pull Request (PR) and when it’s time to merge it to main you are hit with a Merge Conflict on the UI. Here’s how to handle the conflict efficiently and seamlessly.

Note: Resolving the actual conflict will always be a manual task at the code level.

1. Check your status when on your feature branch

git status

2. Checkout to the main branch — the one your PR needs to be merged to

git checkout main

3. Then git pull to get latest main in your local

git pull

4. Switch back to the feature branch the PR is based on

git checkout feature-branch

5. Execute the Merge Command:

git merge main    # (this tries to merge the main branch to the feature branch)

After running the merge command you will get conflicts in certain files, these conflicts should replicate the original merge conflicts being faced in the Pull Request.

Now the conflicts need to be merged manually and can incur code loss, which is fine if both the main and feature branches are pushed in origin.

git status               
git add resolve files    # add all the files with resolved code
git commit               # just git commit; without the -m flag
git push -u origin HEAD  

Running git commit will auto create a Merge Commit so you don’t need to provide any custom message.

After pushing to origin, the PR should not show any conflicts and the commit history in the feature branch should have a commit with an auto-merge message like this: Merged PR 123: Updated the UI with new design.

Reverting a Pushed Commit

Often at times we push and merge a commit to the main branch but then things go wrong and we end up introducing unexpected bugs into production code.

This is where you can safely revert the bad commit until the issue is identified. Here is how to do it safely:

1. Update your local repository

git checkout main
git pull

2. View the recent commits

git log

Here find the bad commit and copy the commit hash, which should look something like this: c41975d1dae1cc69b16ad8892b8c77164e84ca39.

3. Revert the individual commit

git revert c41975d1dae1cc69b16ad8892b8c77164e84ca39

git revert <commit-hash> automatically creates a commit message with a revert message:

Revert “Updated the UI with new design” This reverts commit c41975d1dae1cc69b16ad8892b8c77164e84ca39.

4. Verify and Push to main

git status
git push -u origin HEAD

Verify using git status that you are on the main branch and your local is a commit ahead of origin. git push to push the reverted code changes to origin.

Using stash the Right Way

Imagine you are working on a feature and have some useful changes on local but you have to pull the latest code from main to work on top of, so you do a git pull but end up getting the following message:

error: Your local changes to the following files would be overwritten by merge:
    <file names>
Please commit your changes or stash them before you merge.
Aborting

Here git already gives you a hint of what you need to do.

Using git stash the right way:

git stash
git pull
git stash apply    # this reapplies the latest stashed changes in your local

Note: this might give you merge conflicts.

This can be unsafe if you forget to reapply the changes immediately and lose track of the stashed code, so it is recommended for only small changes.

A safer approach for larger changes would be to ensure you checkout to a new branch and push your changes to origin. Which allows you to freely pull the latest code and merge it to your working branch without losing your code.

Note: this might also give you merge conflicts.

Resetting to a Previous Commit

What if you are working locally and have a few bad commits which you want to get rid of.

When can this happen:

• You were resolving a merge conflict but end up with bad commits.
• You have some unwanted commits in your local which you do not want or even remember — can happen if you restart work on an old feature after a long time.
• Or you get the following message and git pull raises merge conflicts.

Your branch and 'origin/<branch>' have diverged,
and have 4 and 2 different commits each, respectively.
 (use "git pull" to merge the remote branch into yours)

If you are sure your local commits are unwanted or backed up, you can get rid of them by resetting your commit history by running the following command:

git reset --hard HEAD~

CAUTION: This command destroys your local commits permanently!

This resets the local HEAD to one previous commit.

If you have multiple local unwanted commits, you can run the command multiple times and sync cleanly using a git pull:

git reset --hard HEAD~
git reset --hard HEAD~
git reset --hard HEAD~
...
git pull

This will reset the HEAD multiple times to a stable commit and then you can sync with the origin with no issues.

Cherry Picking

Cherry-picking lets you take a specific commit from any branch and apply it onto another branch.

It is a useful command which lets you pick up all changes in a commit from one branch to another, given that the 2 parent branches have similar history.

Possible useful scenarios:

• You fixed a bug on one branch e.g. “the dev branch”, and need the same fix to be applied on another branch e.g. “the release branch”.
• You accidentally committed changes to a wrong branch and want to move the commit to the correct branch.

Here is how to cherry-pick a commit safely from branch A to branch B:

1. View the recent commits on branch A

git checkout branch-a
git log

Here find the commit to copy and copy its hash.

2. Switch to branch B

git checkout branch-b

3. Apply the individual commit

git cherry-pick c41975d1dae1cc69b16ad8892b8c77164e84ca39

On a successful cherry pick you will get the following message:

[main abc123] Fix login bug
 Date: Tue Dec 1 12:00:00 2020 +0200
 2 files changed, 10 insertions(+), 3 deletions(-)

After which it should be safe to push to origin.

Hope this guide helps.

Also, check out the guide Best Git Practices for Beginners if you haven’t already.