Forem: Guroosh

Git: Best Practices for Professionals

Guroosh — Mon, 25 May 2026 14:16:10 +0000

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.

Git: Best Practices for Beginners

Guroosh — Mon, 25 May 2026 14:03:41 +0000

Git and GitHub are essential tools for software development, yet many beginners avoid using them properly due to concerns about making mistakes. They worry about accidentally deleting production code, pushing secrets, or exposing poorly written code. However, the real problems that emerge are less dramatic but far more damaging: messy commit histories, abandoned branches, and a lack of context.

This guide outlines simple, reliable practices that keep your workflow clean, predictable, and professional.

Essential Commands to Stay in Control

Git provides numerous commands to check your repository status, and running them causes no harm. In fact, you should develop a habit of using them frequently:

1. git status

The most important command, use it obsessively whenever you can.
Shows your current branch, what has changed, which files are added, and how your commits compare to the remote origin.

2. git pull

Generally safe to run at any time, especially before starting a new task.

3. git diff

Useful for reviewing your unstaged changes.

4. git log

Useful for reviewing the commit history in your local repository.

Starting with a new Feature

When beginning a new feature, first ensure everything is up to date:

git status     # Ensure you're on the main branch

If you’re not on the main branch, switch to it:

git checkout main

Then continue with:

git pull
# Output example:
# remote: Enumerating objects: 3, done.
# ...
# From github.com:repo/project
#    a3c912d..e71b4ac  main       -> origin/main
# Updating a3c912d..e71b4ac
# Fast-forward
#  README.md | 4 +++-
#  1 file changed, 3 insertions(+), 1 deletion(-)

git pull     # Run again to confirm
# Already up to date.

git log      # Optional, to check the latest commits in your local history

git checkout -b a-new-branch-with-a-unique-name  # -b to create a new branch

git status   # Confirm you're on the new branch

You’re now ready to start coding.

Name your Branches Clearly

Avoid generic names like refactoring, ui_update, or bug_fix.

Branch names should aim to be:

Informative: Clearly communicate the purpose
Unique: Prevent accidental conflicts with existing branches

A few good examples of branch names:

fixing-bug-payment-timeout-using-redis
feature/add-user-profile-with-updated-fields
task-123--fix-db-connection-issue

If available, include the ticket/task number in the branch to ensure uniqueness and improve traceability.

Commit and Push Frequently to Your Branch

New developers hesitate to push code for various reasons:

the code isn’t working yet
they’re hiding unfinished work, or
they fear accidental merges.

However, pushing frequently to a feature branch is exactly what it’s designed for.

Here’s how to do it:

git status                                 # Ensure you're on the correct branch
git add app/config api/src README.md       # Add only the files you want
git status                                 # Verify what's staged (colored display)
git commit -m "A Good Commit Message"
git push -u origin HEAD

Tip: If you are on the correct branch git push -u origin HEAD will always work, no need to copy and paste the specific branch name.

After pushing, create a Pull Request (PR) immediately:

New developers assume a PR should only be created when the work is finished. This is incorrect. Opening a PR early provides several benefits:

A clear, visual summary of all ongoing changes
An easy way to track progress as you develop

PRs are not a sign of completion.

In fact, most major Git platforms (GitHub, Azure Repos, etc.) offer Draft PRs to prevent accidental merges and to signal that the work is still in progress.

Option to convert a PR to a Draft PR in Github

Option to Create a Draft PR in Azure DevOps

Avoid adding all files to the staging area

Blindly adding everything with git add . risks pushing:

OS-specific hidden files like .DS_Store
Temporary artifacts
Editor swap files

Instead, intentionally add specific files to the staging area:

git add app/config app/utils api/src README.md

However, as a long term solution .gitignore should be used to avoid staging any unwanted files or folders.

Even with a well-maintained .gitignore, make it a habit to add specific files deliberately rather than relying on git add ..

Closing and Merging the PR

Write Clear, Informative Commit Messages

When it’s time to close the PR, the final commit message must be clean and informative. Individual commit messages on the branch won’t appear in the main history, so focus on the PR’s merge message.

A Good Commit Message explains what changed and why. For example:

Bad: “UI changes”
Better: “Update to hide unused sidebar buttons to simplify UI”

Tip: Git platforms like GitHub auto-generate merge commit messages and automatically reference PRs using #<number>, which helps maintain a searchable history of closed PRs.

Squash and Merge for Cleaner History

When merging a pull request, use Squash and Merge.

Benefits of Squashing and Merging:

Your main branch history remains readable, each feature appears as a single commit.
Individual features are easier to revert if needed by just reverting a single squashed commit.
Developers can commit frequently on their branch without worrying about cluttering the main branch’s commit history.

Delete the Feature Branch After Merging

After a PR is merged:

Delete the feature branch immediately.

Tools like GitHub and Azure Repos retain the PR history, so nothing is lost.

GitHub lets you know that a branch can be safely deleted

Azure Repos recommeds to delete the source branch when merging a PR

Ideally, only the main branch and active work-in-progress branches should remain in the repository. This keeps the repository clean and prevents confusion by having abandoned branches.

Hope this guide helps.

If you’d like to explore more advanced Git concepts, workflows, and best practices, you can read my Guide for Professional Developers.