DEV Community: Bianca Power

How to Combine Git Commits - Squash 'em with a rebase!

Bianca Power — Mon, 13 Apr 2020 22:26:01 +0000

Here's the situation. Everything seems to be working well with your current code, so you do a git commit. Then you notice a small bug, or maybe you forgot to comment an important line of code, or to remove all of your console.logs. So you make your minor changes... and git commit again. Then you push to production - and let's face it, nothing 'just works' when you push to production - and now you need to make a few more minor changes, you add them, git commit again. Maybe this happens a few times, before you're actually done with that bit of code. So now when you look at the commit history, there's the original, nicely named commit, maybe something like "implement new navbar", then there are a litter of commits following it, things like "bugfix", "please work now", "working navbar", "navbar fix AGAIN". Or maybe your commit messages are better than that, but either way, ideally, all of that code should have been part of the "implement new navbar" commit. Read on for how to do just that.

Here's how we can combine multiple commits into one, to neaten up our git history and make it easier to see what went on.

Below is an asciinema cast of me doing just that.

Let's talk it through. First, doing git log shows us the most recent commits. In this case, it's the most recent 4 commits that we want to combine. Those are shown here:

Next, quit out of git log, so we're back to the terminal.

Quick side note: After running the command in the next step, git launches us into our default text editor so that we can make some changes and specify what we want. Most systems will default to something like vi or vim, but if you're not comfortable in those environments, go and check out my article on how to change your default text editor before doing the next step.

How to change your default text editor for git (and avoid vim)

Bianca Power ・ Apr 11 '20

#git #tutorial #beginners

Now the part we've been waiting for! We're going to run the following command:

$ git rebase -i HEAD~4

This is a git command named rebase, which we're going to do in interactive mode (-i for short), and we're doing it on the most recent 4 commits, which we specify with HEAD~4 (HEAD is how we refer to our most recent commit). When we run that command we see:

At the top we have a list of the most recent 4 commits - the ones we want to combine. Below that, git helpfully tells us about the options we have. The option we want to use is squash, which will 'use commit, but meld into previous commit'. To do that, we edit the file we're in, changing 'pick' to 'squash' for just the commits we want to squash - we leave the original commit unchanged, because that's the one we want to squash the others into (in vim, hit i to enter insert mode). At this point we see:

Now we save and close the file (:wq in vim). As soon as we've done that, we get launched into another file:

Here, git wants us to specify the commit message for the combined commit. In this case, we just want the original commit message, so we need to remove (or comment out) any other text, leaving us with:

Now we save and close that file, and we're back in terminal. Doing git log shows us that our commit history has changed:

We see our combined commit, as well as some older commits that weren't changed.

Did you find this helpful? I'd love to hear your feedback!

Found a typo?

If you've found a typo, a sentence that could be improved or anything else that should be updated on this blog post, you can access it through a git repository and make a pull request. Instead of posting a comment, please go directly to https://github.com/biancapower/my-dev.to and open a new pull request with your changes.

Writing a Bash function to automate Exercism.io exercise setup

Bianca Power — Mon, 13 Apr 2020 06:34:20 +0000

Lately I've been working my way through the JavaScript track on Exercism.io. It's an excellent website and I highly recommend checking it out if you either want to work on your skills in a particular language (there are 50 to choose from), or are comfortable in a particular programming language and interested in mentoring others.

Something I found a little repetitive was the process of setting things up to work on an exercise. The process went something like this:

open the exercise in the browser
copy the download command (e.g. exercism download --exercise=collatz-conjecture --track=javascript) from the browser window, and paste it into terminal
cd into the correct folder (e.g. cd Exercism/javascript/collatz-conjecture)
run npm install so that the tests are ready to be run

Pretty straightforward, but also a predictable and repeatable pattern... perfect for a bash function! Here's the command I want to be able to run in order to make all of the above execute (where the name of the exercise is 'collatz-conjecture'):

$ devil collatz-conjecture

To make this possible, here's the bash function that I added to my .zshrc (I use zsh so added it to my .zshrc, but if you're using bash, add it to your .bashrc):

devil() {
    exercism download --exercise=$1 --track=javascript && cd ~/Exercism/javascript/$1 && npm install;
}

Let's break it down. On line 1 is the name I've given to the function (devil), followed by parentheses and an open curly brace (standard function syntax). I named my function 'devil' because it's easy to type, and something I associate easily with 'exercism' (making it easy to remember).

Line 2 is where the awesomeness happens. These are all the steps I was previously doing 'manually', run for me by executing only one command. The && between each command means that each command must succeed in order for the next one to execute. This makes sense in this context, because each command relies on the previous commands's success. For example, we can't cd into the folder in step 2 if it wasn't created in step 1. But what about the $1? That's the bash way of saying "grab the first argument passed in when the function is run, and use it here". So in our example above, $1 would hold the value collatz-conjecture.

Line 3 is the closing brace to end the function.

So now all I need to know is the name of the next exercise I want to attempt on Exercism.io, and I can simply run devil exercise-name to have my bash function do all the setup work for me!

Here's what it looks like in action:

Found a typo?

How to add ASCII Art around code comment blocks in vim

Bianca Power — Sun, 12 Apr 2020 06:54:18 +0000

While browsing Twitter this morning I came across this awesome gem

// Detect dark theme var iframe = document.getElementById('tweet-1249081168072282113-467'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1249081168072282113&theme=dark" }

and started experimenting! The full article is here, but here's my quick guide on how to get started.

Installation

What we're going to use is a text filter program called boxes. Step 1 is installation.

Debian-based systems:

$ sudo apt-get install boxes

Mac (OSX):

$ brew install boxes

Here's what that process looks like on OSX:

We can check that boxes has installed successfully by running boxes -v. If we get something like boxes version 1.3, that means boxes is installed (it's ok if your version number is different).

Command line use

Now we have boxes. Great! What next? Before we go using it in vim, let's play around with it a bit on the command line. The asciinema video below captures the main commands and a demo (you can copy the text out of the video - try it!), or scroll down for a list of the commands to try.

To use boxes on the command line, we pipe some text into it. For example:

$ echo "Here's some text I want to put a box around!" | boxes

To list all available box designs in the config file (my install came with 65!), we run:

$ boxes -l | less

The less isn't strictly necessary, but it allows us to more easily navigate through the lengthy output.

To use a particular design, append -d [designname] to the command. For example:

$ echo "Here's some text I want to put a box around!" | boxes -d cat

Use in vim

Now comes the super fun part! We can use vim to add any of these boxes around some lines in a file. Think multi-line code comments we really want to stand out, or making documentation files more interesting!

Here's how (written steps below video):

write some lines of plain text (we'll wrap comments around them in the next steps)
place the cursor in the first of the lines to be commented
specify the number of lines to comment, followed by !!, then the boxes command you want to use. E.g.: to comment 4 lines, and use the cat design, do the following:

4!!boxes -d cat

and you'll have something like...

            /\             /\
           |`\\_,--="=--,_//`|
           \ ."  :'. .':  ". /
          ==)  _ :  '  : _  (==
            |>/O\   _   /O\<|
            | \-"~` _ `~"-/ |
           >|`===. \_/ .===`|<
     .-"-.   \==='  |  '===/   .-"-.
.---{'. '`}---\,  .-'-.  ,/---{.'. '}---.
 )  `"---"`     `~-===-~`     `"---"`  (
(  I'm a cat                            )
 ) I'm a kitty cat                     (
(  And I dance dance dance              )
 ) And I dance dance dance             (
'---------------------------------------'

There are several configuration options, including alignment of the text within the box. It's also possible to create your own designs and add them to the config. For all this and more, check out the man page by running

$ man boxes

Happy commenting!

Found a typo?

How to change your default text editor for git (and avoid vim)

Bianca Power — Sat, 11 Apr 2020 08:36:24 +0000

We've all done it. git add . then... git commit. Big mistake. We forgot to add a -m with a message! Now we're in the dreaded vim text editor...

But what if there was another way? By changing the git config, we can specify a different editor for git to launch us into if it needs to do so. Below is how to do this on a unix (OSX or Linux) system.

First, check what your current system default is (you can pause the video below and copy the text command out of it - try it now!):

In the example above, as on many systems, the default editor is vim. Personally, I love vim, but if you're not familiar with it it can make things a bit difficult and really mess up your flow. First let's look at how to change git's default text editor to nano, and what nano looks like in practice:

As you can see, nano is much more straight forward than vim (not least because it gives you the commands you need at the bottom of the screen!), but it still exists completely in the terminal (which has pros and cons).

What if you want to change the editor used by git to something external to the terminal, like VS Code? Here's how:

Note that changing the editor to code didn't work quite as we wanted it to - because we're leaving the terminal environment in order to go and edit the file in VS Code, we need to tell git to wait for us. We do that by specifying code --wait, which basically says "Hey git, I'm gonna go over to VS Code to edit that file now, just hang about, and once I've closed that file you can read it and finish processing the command".

The process for changing the default to other text editor is basically the same, it's just a matter of finding the correct key word(s) for launching the editor.

What do you use as your default text editor? Comment below!