Introduction
As I continue my journey into programming, I realize more every day how little I really know. As much as I may have learned casually over the decades, and most recently, somewhat intensely, these past months, there really is an endless supply of knowledge.
At first, Git made complete sense. “Oh, it's just like unlimited undos.” A way to keep track of all the changes you made. However, the more I read about it, I find that it's much more complicated than that. It has to do with working with other people. And the more I watch videos like those by The Modern Coder I realize there is more to Git than just ‘git clone’, ‘git add .’ and ‘git push’.
Git Merge
One of the first things I learned was how to create a branch. If me and my project partner wanted to work on different parts of the same project, we would separate into different branches. This command will create a new branch in your repository:
$ git branch <branch-name>To switch to the branch, you would use:
$ git checkout <branch-name>To list all branches:
$ git branch -lTo create a new branch and switch to it:
$ git checkout -b <branch-name>Reference: There are other switches (flags) you can use with the ‘branch’ and ‘checkout’ commands: git-branch manual page and git-checkout manual page.
Once you’ve created a branch (in the below example, named ‘feature branch’), you can make changes without affecting your partners code base. After you have added the code to implement the features you are responsible for, you will want to combine it together with your partner’s code and bring everything back into the ‘master’ branch.
To do this, you can:
// get back on the master branch
$ git checkout master // merge the feature_branch into the master branch
$ git merge feature_branch// delete the feature_branch
$ git branch -d feature_branch
You might be wondering why you would delete the branch after merging it into the master. I know I did, I mean why not just leave it?
An example of master branch and a feature branch being merged looks like this:
I used to stress out a lot and try to learn everything at once, or beat myself up mentally because I didn’t know everything there was to know about whatever I was studying. I don’t do that anymore. I learned enough of the basics of Git to do my studies and work. Then, I wait for moments when I’m challenged with the, but wait “why can’t I do this?” or “somebody must have had to do this before” moments. And, almost on cue, a search result shows up that opens up a new path of learning.
One such issue I had was “What do I do with these multiple commits that are all kind of meaningless and could probably be grouped together, instead of being 6 different commits…?” The answer:
Git Squash
This simple, useful command consolidates multiple commits. This is especially useful for when you make multiple commits that don’t really add-value as separate commits. Instead you can collect them and put them under one commit hash. You can update the commit messages and rewrite history to be more succinct and clear.
Here’s a great video on git Squash by The Modern Coder that explains it beautifully.
Git Rebase
After ‘squash’ing and consolidating your commits so that they make sense in the way they are collected, you can use a Git Rebase to clean up your branches by putting your commits at the tip of the master branch.
Another great video by The Modern Coder, this time on Git Rebase.
Clémentine Pirlot does a good job of discussing rebasing using the interactive mode.
Finally, I can’t say enough good things about the clarity and directness of Modern Coder’s videos explaining git…here is his overview of rewriting git history.
