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

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 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

The Only Neural Network Layer You Will EVER Need

Neural networks can seem daunting, complicated, and impossible to explain. But in reality they are remarkably simple. In fact, they only ever require a single layer of neurons. In my previous post about the basics of neural networks , I talked about how neurons compute values. They take a set of inputs, multiply each input value by a weight, and sum the terms. An activation function is then applied to the sum of products, to yield the output value. That output value could be zero (i.e., did not activate), negative, or positive. In this post, we will go deeper down the rabbit hole. We will look at neuron layers, which layers are actually necessary for a network to function, and come to the stunning realization that all neural networks have only a single output. Organizing Neurons into Layers In most neural networks, we tend to organize neurons into layers. The reason for this comes from graph theory (as neural networks are little more than computational graphs). Each layer con...
Read more