Forem: Project Page

How to go back to a previous commit in git

Kenny Grant — Mon, 23 Sep 2019 07:16:19 +0000

Have you ever accidentally committed the wrong files to git, but you hadn't pushed your commit up to origin yet and just want to tidy up?

All is not lost, it's quite easy to recover from this, though the commands to do so are not very intuitive. Unfortunately git doesn't have an undo command, however you can undo this quite easily using git reset.

If you want to add some files or edit the commit message, you can use git commit with the amend option:

git commit --amend

This will add whatever changes you have queued up to the previous commit (for example you may have seen a typo in your comments for the commit), and it will also let you edit the commit message for the previous commit.

If you want to get rid of the commit, while keeping the changes to your files, use git reset with HEAD~ to indicate the previous commit or a commit hash to go back to a specific commit:

git reset HEAD~

This will perform a reset of the git index (but not the changes themselves). So your files will still be as you had them, but the git index will be reset, and you can start your commit again (making modifications, not adding all the files etc). It's as if your previous commit just didn't happen.

If you committed changes that you just want to throw away, and you don't want to keep at all, you can also do a hard reset:

git reset --hard HEAD~

Or if you want to get rid of a few commits, the last commit hash you want to keep:

git reset --hard a1b2c3

But beware, this could delete or change files, and will reset the state of all the files to the previous commit, so use it with care. Usually you're better doing a soft reset.

Only ever do this if you haven't pushed the commits to origin.

If you have published the commit, you should instead publish another reverting commit, instead of rewriting history (which can cause other people lots of problems).

How to move a commit to another branch in git

Kenny Grant — Fri, 20 Sep 2019 16:07:47 +0000

Here's a little git problem that happened to me today, which used to be quite scary when I was first learning git but is actually easy to remedy as long as you are working locally.

We've all done it - sometimes you forget you haven't created a branch yet, or worse yet you're on the wrong feature branch, and you start adding some code and make a commit. Then you realise you've committed code to the wrong feature branch or straight to master, and now it's in the wrong place.

As long as you haven't pushed your changes up to origin, this is very easy to undo. Let's say we have made a commit a1b2c3d on the branch feature-a, and we haven't yet made a feature-b branch.

So first of all we want to get our commit onto the right branch, so let's take a note of the hash want to move, and start at master:

git checkout master

Optionally (if we don't have the branch yet) we make a new branch feature-b to put it on and check it out:

git checkout -b feature-b

Then make sure you are on the right branch feature-b (may not be necessary if you just created it), and cherry pick this commit into that branch to add just that commit to feature-b:

git checkout feature-b
git cherry-pick a1b2c3d

And finally let's reset feature-a branch back to the previous commit hash (say z1b2c3d). Using git reset --hard will remove all the commit referencing the changes, and all the changes themselves, from feature-a branch, while leaving that commit on feature-b:

git checkout feature-a
git reset --hard z1b2c3d

You can do this with multiple commits too, just cherry pick several, then reset back to the last commit you want to keep. The process is the same if you have committed to local master by mistake - just cherry-pick to a branch, then reset master.

Only ever do this if you haven't pushed the commits to origin.

Just for func

Kenny Grant — Thu, 19 Sep 2019 20:42:40 +0000

If you missed the first episode of this series about Learning Go, you should start at the beginning (see the link above).

Today we're going to have fun with functions. First though, I must apologise for stealing the title of today's lesson from renowned gopher Francesc Campoy, who made a a really fun series of podcasts called Just for Func - once you're a little further along with Go, you should watch them all for another perspective on the language.

As well as looking at go functions today, we'll learn three new keywords:

const - a value that doesn't change
var - a value that may change
return - leave a function and give the caller some output

If you've used another language in the C family you'll probably be familiar with all of these. Let's start where we left off, with function main, but we'll try adding another function which we can call from main. We declare functions with the func keyword which we saw last time, and declare constants with const and variables with var (though often in Go this isn't necessary, as you'll see later).

We're going to define a function to find the position of a number in pi:

// piPosition finds the first location of a given number in pi
func piPosition(number int) int {
    ...
    return index
}

This uses func to declare a function called piPosition (note the camel case, that's what we use in Go), which takes a number of type int (integer), and returns an integer representing the index of this number in pi.

The full code is below or here - we declare a constant for pi (note there is no type assigned, this is implied) - you can read more about the reasons for allowing this on the go blog about constants.

We then declare an integer number, add one to it, skip past some commented out code (which is there to show you what you can't do - try uncommenting it and see what happens), and call the function piPosition. piPosition is an odd and rather useless little function which finds the index, but it'll show us how functions work in Go and how to use return. Inside piPosition, we convert both pi and number (53 in this case) to strings, and find the index of the number within pi (you can find most numbers within pi if you look long enough).

There's one interesting problem here though - if you choose to use the specifier %f within printf (to convert pi to a float), you'll get no result for 53, because pi will be truncated to the size of number that would fit into a float type. This tells us something interesting - the pi constant declaration turns it into something other than float.

// Package main compares strings
package main

// These are the packages imported by this program
import (
    "fmt"
    "strings"
)

// A constant cannot be changed during program execution
const pi = 3.141592653589793238462643383279502884

// the entry point for the program
func main() {

    // A variable stores a value that may change
    var number int = 52

    // We can change number, but not pi
    number = number + 1

    // This is a compile error, try uncommenting to see
    // go is a compiled language and will not allow you to
    // compile a program which does a Bad Thing like this
    // pi = 52

    // We also can't assign a string to a number, try this to see 
    // number = "string"

    // Let's call the function piPosition 
    // and assign its return value to index
    index := piPosition(number)

    // Print something with a format - see Printf for more details.
    fmt.Printf("The number %d is at position %d in pi", number, index)

}

// piPosition finds the index in pi 
// (as a string) of a given number
func piPosition(number int) int {
    // We're going to cheat and use strings
    p := fmt.Sprintf("%v", pi)
    n := fmt.Sprintf("%d", number)

    // A quick search in the standard library docs 
    // turns up this function to find the index in a string
    // let's return this as an answer from the function, 
    // using the return keyword
    return strings.Index(p, n)
}

Note when we call piPosition, we assign the result to a variable without using var, or even a type. This is how you can implicitly create new variables in Go, and it's handy so you'll see this a lot. The variable type is set by the return type of the function.

    // Let's call the function piPosition 
    // and assign its return value to index
    index := piPosition(number)

You can try out today's code here https://play.golang.org/p/h82XuiWFaJL - note the clever URL created as a hash (a unique string which maps to only this content). This is the sort of clever thing you'll learn to do later in the course, in order to impress your friends and confound your enemies.

Yes, I'm using fmt to convert numbers to strings, and comparing numbers as strings, experienced go programmers don't @ me :) You can also use the strconv package in the standard library for this, but I would like to keep things simple. If you work out why the %f specifier won't work, and what type pi ends up being, post it in the comments below - floating point numbers are notoriously tricky.

So to recap, we've covered these 6 keywords so far:

package - a folder containing go files
import - a way of importing go packages including the standard library
func - this stands for function, a set of instructions for transforming data
const - a value that doesn't change
var - a value that may change
return - leave a function and give the caller some output

Only 19 to go before you're an expert! In the next lesson we'll learn how to set up a web server in a few lines of code using the excellent Go standard library, and a few more keywords too, and we'll be on the way to making ~~the next twitter~~ something at 53words.com.

If you haven't already, you should download go and get set up locally with your editor - you can use this hello world exercise to test it out on your computer. I recommend VS Code as an editor on a Mac, but there are many other editors and most have go support. There are lots of instructions on the web for installation, I won't go into it here.

Let's build something and learn go at the same time

Kenny Grant — Wed, 18 Sep 2019 21:41:31 +0000

Hi, I'm Kenny, and I write Go code for a living and run golangnews.com, a news website for Go programmers, as a hobby. I've been using Go for a while and thought I'd write some tutorials to show other people how awesome it is.

Follow along to learn go and build something awesome while you do it.

This course is an introduction to the Go programming language from Google. I'll try not to assume too much knowledge - even if you haven't done much programming before, it should be approachable with a little effort, so please ask questions in the comments below if you're unsure on any points, or think things haven't been explained well. I'm going to try a post every few days over the next few months, and by the end you should be proficient in Go and have a server up for yourself, so follow along if you'd like to learn the language in bite-size chunks.

Why would you want to learn Go? Go is ideal for writing internet servers - it powers many internet services we take for granted; it's used by companies as varied as Youtube, Monzo, Ironio, SendGrid, GitLab and Digital Ocean.

To keep us motivated, we're going to build something real - let's build a better twitter while we learn go (ignoring scaling concerns for now, we'll just keep it simple - one program, one server). I'm going to put it here: 53words.com. We'll get that server up and running in just a few lessons.

There is nothing at this domain at present, at the end of the course we'll have a better twitter (with fewer adverts, nazis and dank memes), it may also involve the number 53 somehow. So let's go!

First, we need to learn Go. It has just 25 keywords, which are a good place to start. Here are our first three keywords:

package - this is the basic unit of code in go, you can think of it as synonymous with folder - a folder on your computer is a package in go
import - this lets you import packages/folders of code from elsewhere, including the standard library of code provided by the Go authors.
func - this stands for function, a set of instructions for transforming data

So packages/folders contain files which contain functions which transform data.

You don't have to install anything yet, to get started, we'll use play.golang.org - this is an interactive go website that lets you execute go programs from your browser. If you open that link, you'll find this code:

// Package main is the entry point of your program
// the first and only function in your program called by the operating system
package main

// import lets you import lots of packages
import (
    // fmt is a package for reading and writing stuff (mostly text)
    // you can use it to print things out (as below)
    "fmt"
)

// func then a name defines a function
// main is the first and only function called from outside
// after that, you're on your own
func main() {

    // fmt.Println writes the things you give it to standard output
    fmt.Println("Hello", "World")

}

The quote marks above define strings (human words), we'll go into types and the different built in types in Go in the next tutorial. Let's try making a change here - add your name in quotes and print it out instead of "World", then press Run at the top to see the result below.

Back yet? Great. If you printed your name, let's try something else, add the number 53 and the text "words" at the end of the Println function and see what you get, so something like:

fmt.Println("Hello", "World", "Kenny", 53, "Words")

You'll find that Println prints most things you throw at it (even numbers or other types of thing), because it does some tricks to format every thing in the right way.

Any questions? Let me know in the comments below. You can run the final code for this lesson at play.golang.org without leaving your browser.

A short history of the Stripe Status Page

Kenny Grant — Tue, 17 Sep 2019 07:31:07 +0000

When Stripe was founded in 2018, stripe.com featured just one sentence – Payment processing for developers, and a single link. Stripe have grown from this simple page to a valuation of billions and a reputation for cutting edge design – using radically simple design and software to help customers navigate complex payment flows.

The stripe status page is a great example of design in the service of clear communication, which delivers exactly what the reader needs and nothing more. Today we're going to look at the elements they chose to include on their status page, and why it works so well.

The first status page at Stripe

The first stripe status page at status.stripe.com was created in 2012 by Amber Feng, then an engineer in her first few weeks at Stripe – she now heads Financial Infrastructure at the billion dollar company.

The first page was not responsive (responsive web design not being a mainstream idea at the time), but otherwise was very similar in content and style to the page we see today. It has a global indicator at top, and then a list of services with historical uptime below, and at the bottom a feed from the twitter account which was used to tweet out status updates in the event of an outage. From the post:

"We built color-coded charts that show 90-day availability in Stripe’s three core services: the site, the API, and Stripe.js. We also show the raw uptime figures, calculated over the same three-month period. To calculate the figures, we use Pingdom to monitor each service, effectively performing a complete API request in the case of the API."

The original page:

Pingdom for status checks

This first page was updated via checks from pingdom – an interesting case of avoiding building out a separate checker service when an external one was available which was good enough – this let them build the first status page quickly and see if it was something they wanted to invest more time in later. It was a small company of around 10 people and this was her first task:

"When I first joined Stripe, we were tiny – I interviewed with everyone at the company! Without the lure or credibility of Stripe’s reputation or brand, what really attracted me to the company was the team." – Amber Feng

Contrast with AWS

The Amazon AWS status page provides a good counterpoint to the stripe status page. It is manually updated, non-responsive (so hard to read on phones), and hugely complex. There is no overall status and no grouping of services in a logical order, just an interminable list of services and regions. It's so long that I couldn't even take a representative screenshot, and at the top of the page is a wall of text that nobody visiting it wants to read.

The new status page

Stripe started with the smallest thing that could possibly work, and a very simple page, and it has served them well to this day. Their latest status page looks very like the original, what is most remarkable is how little has changed since the original design, which is a testament to its thoughtful simplicity:

The design is so good that competing services have been heavily inspired by it. Statuspage.io, founded in 2012, offers a very similar view, clearly inspired by the stripe design to break down status by service and show the historical uptime as green or red bars summarising status per day.

You can read a longer article with more detail and images in the full case study over at Project Page, or read more on twitter.

How to use git branches

Kenny Grant — Mon, 16 Sep 2019 21:06:57 +0000

There are lots of possible workflows for git, but the simplest one is in my experience also the most effective, and works from small teams to very large ones at Google and Facebook. This is sometimes known as trunk based development and I'll explain how it works below.

Trunk based development

There is one main branch - usually called master.
This is always green on tests and never broken.
All new changes are based off master
There are no separate merge commits

Master/Head can be used as the base for all new changes, and is regularly updated as changes are released by developers. All developers have commit access, and the social contract is such that master is never broken. It can be used as a working release and for internal testing or development, and all new work is based off master. There may be release branches (used for back-porting bug fixes for example), and locally devs use feature branches for changes.

All new changes are based off master, and are usually done in a feature branch, though if small they may be worked on directly. When the change has been tested locally and is ready to go, it is rebased off master (optionally with some commits squashed and tidied up), it is then merged into master, resulting in a simple linear history on master of all work done, with tags to denote different releases. As a result, the master branch looks like this (example taken from the go language project at Google):

There are no merge commits, and no long-lived branches (apart from optional release branches, which exist to back-port bug fixes).

So the process for developing and committing code is:

Pull latest origin/master
Rebase feature branch off master
Make changes to feature branch
Run tests on feature
When ready, share for code review

The developer may go through several cycles of this process as the code goes through code review. The process for final merging is:

Pull latest origin/master
Rebase feature off master, squashing if required
Run tests
Merge into origin/master

Release Branches

Release branches on the go project for example, look like this:

A branch off master at the time of the original release, which holds any new commits specific to that release. These can then be used for bug fix releases to that older code if required (typically on larger projects). Most smaller projects won't have to bother with this and can just get away with tagging releases.

Alternatives

Feature Branches

Feature branches can actually be used with trunk based development as well, and often are locally while working on changes, but this style of using git has one important difference - it requires merge commits for merging feature branches in.

Some people like this because it gives a clear indication of when a branch has been checked in, and can make it easier to revert all changes from a branch.

I prefer to drop the historical artefacts which are branches and branch names and instead let commit comments speak for themselves in the history.

It means the repository can end up looking like a particularly kafkaesque subway map:

Gitflow

Another alternative is sometimes known as git flow - this suits a style of development where work continues on development versions of software over weeks or months, which are then after a long time merged onto master as releases. It is not very well suited if you want to practice continuous delivery and release small features frequently. It can be summarised by the following graphic:

Which tells you everything you need to know about gitflow. Image from nvie.com.

Github workflow

Github has introduced an interesting take on using git which requires users to clone (fork) repos, make all their changes, and then submit a pull request back to the original repo.

This does allow developers who have no access to the original repo to work on the code, and submit suggested changes, hence its popularity with open source projects and on github. The downsides are that it may mean changes are worked on in isolation without discussion with the original maintainer, then submitted as a large dump all at once.

Conclusion

I think if you have full control over your development process, it is simpler and more productive to use the trunk based development model, as it lets you release frequently and keep master up to date at all times, and results in a clean git history which is easy to read, and is free of artefacts from the development process. This system works well at the scale of Google as well as for small teams.

You can find out more about how Google use git in this article, or by contributing to one of their open source projects like the Go Language.