Git is a very powerful revision control system used in software development, and at this point, is effectively the industry standard. One of the things that makes Git so powerful is that there are all sorts of low-level operations that developers can do in it. This includes everything from tagging releases, to having an insane number of branches, to painless merging of said branches, to rewriting history.
If you’re new to Git, your brain probably threw an exception when reaching the end of the paragraph as you thought to yourself, “Wait WHAT? Why would you want to REWRITE HISTORY?” Good question! Normally, you don’t want to mess history in a revision control system. But sometimes you may want to or even need to. A few possible reasons for rewriting history include:
Feature Branch “B” is a branch of Feature Branch “A” and you want to merge B’s changes to master, but not A’s.
Squashing all the commits in a feature branch to a single commit, after having previously pushed those commits.
A developer made a commit with something that doesn’t belong in Git, such as PII or credentials.
You want to “clean up” the commit history a little.
Whether any of the above are fully valid reasons or not is something up to you and your dev team.
That said, rebasing is not something you want to experiment with for the first time on your production repo. It’s just a bad idea. So I built a playground/lab where anyone can experiment with git rebasing in an isolated and local environment, which can be stood up in seconds. Here’s how to get started:
git clone email@example.com:dmuth/git-rebase-i-playground.git
In this post, I’m going to discuss how to create a GitHub repo and upload (or “push”) it to GitHub, a popular service for hosting Git repositories.
What is revision control and why do I need it?
The concept of revision control is a system which tracks changes to files. In programming, that is usually program code, but documents and text files can also be tracked. Using revision control will give the following benefits:
You will know what was changed, when it was changed, and who changed it
Multiple people can collaborate on a project without fear of overwriting each others’ changes.
Protection against accidentally deleting a critical file. (revision history is usually read-only)
In GitHub, we store revisions in “repositories” or “repos” for short. As of this writing, the #1 service for storing Git repositories is GitHub. They offer free hosting for Git repositories.