Skip to main content

Squashing commits in Git

If you're like me, then you tend to follow the ultra-conservative practice of "commit early, commit often" when using git. If so, I applaud you. It's important to be sure you are keeping track of your work, and if you push your commits back to GitHub, Bitbucket, or GitLab that's even better. No one wants to do a day's worth of software development work, only to wake up the next morning to a local hard drive failure.



However, if you work on a collaborative software project, some people may not care for all of those small, intermediate commits to clutter up the commit history on the main project repo. In these situations, git provides a great command rebase. rebase will allow you to squash your commits into something more easily reviewed by the code team when you issue your pull request.

First off, I would recommend that teams always work in local repos forked from the main project repo. My reasoning is that this allows developers to mess up their local fork without affecting the main project, which users may still be cloning or pulling from in order to use the software. You can use a devel branch for this, but I like to be safe.

Okay, say you are working in your own forked repo, and you have committed 47 times while trying to fix a particular bug (we'll call it issue #100). If you want to squash all of these intermediate commits into 1 commit, then you can use rebase in the following way:

[sourcecode language="bash"]
$ git rebase -i HEAD~47
$ git commit --ammend -m "Fixing Issue #100"
$ git push origin master
[/sourcecode]

Once you have committed your squashed issue fix to your forked repo, you can issue a pull request to the main repo so that your software team can evaluate your issue fix.

Using rebase to squash commits is quick and easy, and it makes the task of evaluating your work easier when the team gets together to discuss your pull request. It's a win-win and a great way to show your expertise and professionalism!
Labels:

Popular posts from this blog

Neural Network Dense Layers

Neural network dense layers (or fully connected layers) are the foundation of nearly all neural networks. If you look closely at almost any topology, somewhere there is a dense layer lurking. This post will cover the history behind dense layers, what they are used for, and how to use them by walking through the "Hello, World!" of neural networks: digit classification.
Read more

Arrays of Structures or Structures of Arrays: Performance vs. Readability

It's one of those things that might have an obvious answer if you have ever written scientific software for a vector machine. For everyone else, it's something you probably never even thought about: Should I write my code with arrays of structures (or classes), or structures (or classes) of arrays. Read on to see how both approaches perform, and what kind of readability you can expect from each approach.
Read more

Neural Network Pooling Layers

Neural networks need to map inputs to outputs. It seems simple enough, but in most useful cases this means building a network with millions of parameters, which look at millions or billions of relationships hidden in the input data. Do we need all of these relationships? Is all of this information necessary? Probably not. That's where neural network pooling layers can help. In this post, we're going to dive into the deep end and learn how pooling layers can reduce the size of your network while producing highly accurate models.
Read more