Scribd
Upload
3 views2 pages

Git Revert

The document outlines the proper procedure for fixing mistakes in Git after merging branches, emphasizing the importance of not rewriting history. It advises making corrections in the source branch, reverting bad commits or making manual fixes, and then pushing those changes to the remote repository. Finally, it highlights the need to merge the fixed branch back into the main branch without complicating version control.

Uploaded by

MM - Hrittik
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
3 views2 pages

Git Revert

The document outlines the proper procedure for fixing mistakes in Git after merging branches, emphasizing the importance of not rewriting history. It advises making corrections in the source branch, reverting bad commits or making manual fixes, and then pushing those changes to the remote repository. Finally, it highlights the need to merge the fixed branch back into the main branch without complicating version control.

Uploaded by

MM - Hrittik
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Git Revert

Listen carefully, because asking to "fix a previous commit" right after you've merged
branches is a massive red flag.

If you have already pushed that merge to your remote repository, do not attempt to
rewrite history using git commit --amend or git rebase . Doing so will desync the
commit history, and the next time anyone on your Yuva Coders team tries to pull, you
will have broken the repository for them.

This way out of this: roll forward, don't rewrite the past. If the mistake exists in both
branches because of the merge, here is the cleanest, most logical way to fix it in both
places without destroying your Git tree.

Step 1: Fix it at the Source ( secondary )

You want the fix in both branches, so make the fix in the branch where the feature
actually lives.

Bash

git checkout secondary


git pull origin secondary # Ensure you are up to date

Step 2: Execute the Image's Advice

If the previous commit is completely garbage, revert it. If it just needs a small tweak,
make the changes to the files now.

If reverting the bad commit:

Bash

git revert <commit-hash-of-the-mistake>

(This automatically creates a new commit that undoes the bad one. No history is
destroyed).

If just making manual fixes:

Fix your code, then stage and commit:

Bash
git add .
git commit -m "Fix: correct the mistake from the previous commit"

Step 3: Push the Fix to the Secondary Branch

Get the fix onto the remote server for the secondary branch.

Bash

git push origin secondary

Step 4: Bring the Fix into main

Now that secondary is fixed, you simply merge it into main again. Git is smart
enough to know you are only bringing over the new "fix" commit.

Bash

git checkout main


git pull origin main
git merge secondary
git push origin main

Your Blind Spot

You are overcomplicating your version control. When you screw up on a shared main
branch, you don't go back in time to "fix" the old commit. You acknowledge the
mistake, write a new commit that fixes it, and push it forward. Rely on your terminal
commands to do this cleanly; visual tools like GitUI or LazyGit are great, but you need
to understand the fundamental branch flow first.

You might also like