- There are different types of rolling back: one is common, the other less so
- Git’s best features (for me) are branches and documenting commits
- Tips on how/when to start a repository at the end
That is not its main purpose, but I think the power of Git is most easily recognized when collaborating with others and hosting the codebase on a website such as GitHub or GitLab. This is where it becomes crucial to allow each contributor to work on discrete issues on separate branches without affecting the main codebase until the changes are ready to merge.
That said, Git is a very powerful and useful tool for personal projects as well. I think the idea of “rolling back” to a previous commit has been brought up a fair bit here, but there might be a few different interpretations of what that means. One interpretation might be if you add new (uncommitted) changes to your code and decide to toss them all out and go back to your last commit. I do this all the time. Another interpretation is “rolling back” from your current commit to a previous commit. I find that in practice I rarely do this.
Let me explain.
Say you are working on a project and you have four commits: A - B - C - D.
These commits are like checkpoints in a game. They are completely unrelated to saving the file with Ctrl + S. You will likely save your code many times before you commit it.
In roll-back scenario #1, it would be as though you start trying to add a feature to your project after commit D (e.g., new formatting/styling on your website). You save your code, test it out, and decide you don’t like it and want to scrap all the code you wrote in the last 3 hours. So you just discard all the changes that came after commit D. I do this all the time and I think it’s a very common use of Git.
In scenario #2, you decide that you liked commit C better than the code added in commit D. Even though all those changes have been saved and committed, you can still revert your code back to the state it was in at commit C. Although this is very powerful, in my experience it’s less common.
It is more common to make the changes you want and commit them in commit E. Why? Because quite often you’ll like part of what commit D does, but you’ll want to improve it by adding/removing/changing some code. Going all the way back to commit C is probably not what you want (you did make commit D for a reason after all).
All of that was just a long-winded way to say that I think rolling back is a critical and powerful part of Git, but depending on which type of rolling back you’re talking about, it might not be what you use Git for on a daily basis.
For me personally, I find the most important aspects of Git to be:
- The ability to work on separate branches of the code; and
- Documenting the “what” and the “why” of my changes.
As for the first, it is so much easier to make changes to your code when you don’t have to worry about messing anything up (especially if your code is live). You just make a new branch and add whatever changes you want – break as many features as you want – and your main codebase stays safe and intact. If your changes go well, you can merge them in to the main branch. If not, you can delete the branch with no repercussions.
The second, documentation, hasn’t really been discussed much here but it is one of the most important parts of Git BY FAR. Each time you commit, you should be making a commit message. This message should explain what the change was and why it was made. The “how” is usually evident by reading the code itself. The audience you are writing these commit messages for is either: other people; or your future self.
Everyone has moments when they come back to a project after a few weeks and can’t remember why a piece of code is there. This is what commit messages are for: to tell anyone reading the code at a later date about the changes and the reasoning behind them. See this excellent article on how to properly write Git commit messages: How to Write a Git Commit Message
There are many ways to go about this, and you can run
git init later on in a project, but ideally you want to create your git repository at the beginning of your project so you can track changes from the beginning.
Two common ways are as follows:
Create a local git repository, add code, upload to GitHub later:
- Make a new directory
- Navigate to that dir on the command line
- Open that repository in VS Code with the command
- Later on, if you want it on GitHub follow these instructions
Create a repository on GitHub and clone it to your machine: