Why do I need to clean up my branch?
Have you had an indoor or outdoor tree that grew and ended up with little branches here and there with dead leaves or none at all? How could you help it be healthy and strong?
It's a good practice to prune branches that are not being used. It helps the plant or tree grow healthier and pushes the nutrients to other areas.
Um...I'm here to learn GitHub, not plant maintenance! 🙄
Well, GitHub isn't so different from pruning trees. Remember those branches? You need to clean them up to keep your project healthy! 😄 To do that, follow this game plan:
git rebaseto combine branches.
git pruneto remove orphaned branches.
interactive git rebaseto squash commits and logically order your commits and branches, as well as give your commits descriptive names.
Manually delete outdated pointers in the ref folder in your local repository file.
Debug your repo with
Let's git to it!
Use git merge or git rebase to combine branches
Go through your branches to see what branches need to be a part of the master branch. Use git merge and git rebase to make sure you have all of the commits and branches you need on the master branch. You know the basics of using these, but let's take a look at a few concrete examples, so you're confident in your branch management. Did you know that you can use rebase when pulling from your remote repository?
Imagine your local repository has the master branch that you cloned from GitHub. It also has a new wwbranch that you created on the tip of the master branch. This creation of wwbranch is also Commit 2 on the master branch:
Say there are a few extra commits on that master branch in the repository. How will you update the master branch with the new commits but also make sure that your branch comes off of the new commit?
First, you need to update your local repository with the new commits on the master branch in the remote repository with
git pull --rebase.
Now your tree should look like this:
You want your branch to work off of the latest commit on the master branch: 3. To do that, first make sure that the wwbranch is in your working directory with
git checkout ww. Now run the rebase command to point the wwbranch to the tip of the master branch:
git rebase master ww.
Perfect! Now its ready to send over to GitHub!
But wait! Let's say you are the repository owner and want to merge your branch with the master branch before pushing it back remotely. What would you use?
Yes! First, go to your master branch working directory with
git checkout master. Now you can merge the master branch with your wwbranch on your local repository using
git merge ww.
Now your tree should look like this:
Do you remember what command to use to send it to the remote?
Git push! 🤘
Alright! Now you've got all of these branches in your local repository. It's a good idea to check and see if you can clean out some of the branches you don't need anymore.
Use git prune to remove orphaned/unused branches
You can use the
git prune command to remove orphaned branches. Orphaned branches are branches that are not connected to any others and have been left unused.
To find out what branches you currently have in your repository, use the command
git branch -a.
If you see any branches in there that you don't want, you can use the command
git branch -d <branch name>. If you want to delete the branch called badbranch, use the
-D switch to force the deletion if it doesn't work:
git branch -d badbranch.
You can connect to the remote repository to see what orphaned branches can be deleted or pruned from your local repository:
git remote prune origin --dry-run.
This command will not delete those branches, just list them. You can delete them using the command
git remote prune origin.
Use interactive rebase to clean your branch
Why do I need to clean up? All I've been doing is adding new commits to my branch. What is the big deal?
Let's say that you like to save a new commit every 5 minutes just to be on the safe side. On top of that, it takes way too much time to type in anything but
asdf for the commit message...for all of them! You may find yourself with 110 commits and only four of them are actually meaningful.
Now's the time to use the new techniques you learned with interactive git rebase to organize this mess. You may find that:
There are too many commits; you only need four.
The commit messages do not provide a description.
You want to squash your 110 commits down to four. What feature do you use for that?
Squash ! 💫 Type in your command to start interactive git rebase on the text editor:
git rebase -i master
You've located four commits that need to be combined to create one of the meaningful commits for a project. Place all you the ones you would like to combine together using the
pick fda59df commit 1pick x536897 commit 2pick c01a668 commit 3pick 8a9fbd7 commit 4
Put the keyword
pick in front of the commit that you want the others to squash into. Type in
squash for the ones that you want to move into the above commit:
pick fda59df commit 1squash x536897 commit 2squash c01a668 commit 3squash 8a9fbd7 commit 4
After the rebase, the resulting commit 1 will be combined with 2,3,4.
But wait. How about our second problem? We squashed four commits together, but how will we know what this commit for?
To be honest, all of those commits are there because I wanted to demonstrate the squash feature. I will go ahead and add a description for it in the text editor:
pick fda59df commit 1 to demo squash for advanced github!squash x536897 commit 2squash c01a668 commit 3squash 8a9fbd7 commit 4
Fantastic! 😇 In the last edit to the text above, we successfully squashed the commits into one, and changed the commit message to make it descriptive. Very cool! 😎
So what other cool things can you do to make your branches cleaner? After all, you want your projects to stay easy to handle as they grow bigger.
Remove untracked branches
Sometimes there are large, open source projects on GitHub that have been running actively for years! As you can imagine, there are many contributors, commits, and branches! Do you think every branch is in use? Probably not! Do you think all the files that have been staged are in use? Probably not!
To solve this, the git file structure comes in handy. You have folders called
ref under the main
.git directory in your local repository folder. The ref folder holds pointers (references) to certain commits, branches, and objects. Getting rid of those unused pointers will help with the cleanup. All you have to do is just find them and delete them.
Debug your source code in Git with bisect!
Let's talk about debugging source code. It can happen to anyone: you have a bug in your code! 😰
If you know where the bug came from...
If you have a couple of files, you want to track them going backward to see the origin of the bug. This can be done with a command that you should be familiar with from the advanced logging chapter...git blame.
You can use it to look at who changed what line on different files. To look further into a specific file like
helloworld.c, use a switch
-C with git blame to analyze and annotate code snippets origination:
git blame -C helloworld.c.
Looking at the annotations in the code may help if you are tracking a specific bug, but what if you have no idea where the bug came from?
If you don't know where the bug came from...
Git bisect will help you do a binary search through the code. It will then inspect areas the developer annotates using commands.
For example, you know that your last good commit was the 12th one on the master branch. But somewhere closer to the 20th commit, you start to see some bugs. Luckily, you can use git bisect to inspect the code between those commits.
In Git Bash, you will type in the following command:
git bisect start.
Git bisect will do a binary search through your commit history. As it runs, you can type the
git bisect bad command to track any bugs you see.
Wait until you see the commit that marks the last time the source code was free of bugs:
git bisect good.
Parsing and testing the commits to see which are good and bad, annotating them, and continuing with the search, may help you narrow down the exact one in which the bug started. Neat, right? 🙌
Clean up your branches by:
git pruneto remove orphaned branches.
Removing orphaned object references in the ref folder.
Cleaning up all messy commits using
interactive git rebaseto combine commits, reorder them, and change messages.
Updating your local repository by using
git pullwith rebase.
Debugging your source code using