Git: How to replace the master branch

Why does it matter if we commit undesired content into a repository?

  • temporary files
  • the built software (binaries, executables, …)
  • personal information
  • credentials
  • proprietary information

Can’t I just undo the change or roll back to a previous commit?

Strategies on how to remove unwanted information

  1. Notify anyone that might be collaborating on this branch, that they should refrain from pushing/pulling
  2. Follow the L1 steps and create a new branch that contains only the commits before the erroneous commit.
  3. Push the new branch and delete the erroneous branch locally and on the shared repository
  4. Optional: rename the new branch to have the same name as the original branch
  5. Notify colleagues to resume work as usual
  1. Notify your the project lead and your coworkers that are actively working on the project to stop pulling and pushing to the main branch
  2. If you have a Continuous Integration and Continuous Deployment (CI/CD) pipeline running, check with your colleagues if it has to be paused or active jobs have to be aborted
  3. Follow the L1 steps and create a new branch that contains only the commits before the erroneous commit.
  4. Replace the main “master” branch with the “fixed “branch using:
    git push origin +fixed:master
    Depending on what your remote repository is named you might need to replace origin. However remote and origin are frequent default values
  5. Notify the project lead and coworkers to resume work and reactivate any suspended CI/CD pipelines
  1. Do you have a local copy or a very recent branch/fork of the main branch that could be used — even if it needed a few edits
  2. Most backup softwares usually do hourly backups and might have an older version of the branch in question that could be restored
  3. Coworkers might haven’t pulled the latest main branch yet or a branch that is only minimally diverged from the original main branch. Get a copy from them and re-apply — if needed — the latest commits
  4. If nothing works you could explore using the BFG Repo-Cleaner to scrub the project from sensitive information. However, using the tool is very tedious and the history might still not be completely clean. Furthermore, it will result in creating a new repository and having everyone switch over to that one
Humorous book cover about the joy of pushing to master, using irony implying pushing to master is always ok
Humorous: The joy of pushing to master

How can we prevent accidental merges from happening in the future?

  1. Do not push to main branches directly —
    This is the most obvious takeaway. Never push directly to a main branch. We’ve all done it and we’ve told others not to do it. It happens to me too and I had to fix main branches in the past
  2. Use a branching model like Git-Flow or GitLab Flow. These approaches are detailed and even using a customized variation that works for you and your team is possible and worthwhile
  3. Protect important branches — see GitLab protected branches and GitHub protected branches
  4. Have merge-request reviews (or pull requests for GitHub)
  5. Use secret detection — tools like GitLab support secret detection and security scanning

Conclusion

References

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store