Patrick Reagan

Git Worktrees as Swimlanes

2026-04-16T00:00:00+00:00

Git worktrees let you have multiple branches checked out at the same time, which is genuinely useful — but the advice you usually hear (“one worktree per feature branch”) leaves you juggling a pile of ephemeral directories, each one missing the .env file, the node_modules, or the install step that makes it runnable. That friction keeps most people on a single checkout.

Here’s a different way to use worktrees: as persistent roles, not per-feature containers.

The Mental Flip

A worktree is a directory with a role. The directory stays put; whichever branch I need rotates through it.

I open each one in its own VS Code window, so switching swimlanes is a window switch. Once I’m in a swimlane, I pick the branch with git checkout.

That’s it. The rest of this post is about how to make that comfortable in practice.

The Swimlanes I Use

I keep four worktrees around at all times for any repo I spend real time in:

Swimlane	Role
`development`	Stays on the `development` branch. Used to run the latest version of the app and as the base I branch off.
`work-queue`	Where I create new branches for each ticket I work on.
`review`	Where I check out whatever branch is currently under review.
`experiments`	Longer-running spikes that may or may not produce commits.

development and experiments are stable: the branch checked out in each one rarely changes. work-queue and review are different — the directory is stable, but the branch checked out inside it rotates constantly.

Set them up once. Clone your repo into a directory you’ll treat as the main checkout — I name mine after the default branch (development), but any name works. Then add the rest as siblings:

$ git clone <repo-url> ~/Projects/<project>/<main-checkout>
$ cd ~/Projects/<project>/<main-checkout>
$ git worktree add ../work-queue
$ git worktree add ../review
$ git worktree add ../experiments

Without a branch argument, git worktree add creates a new branch named after the directory (so ../work-queue gets a branch called work-queue) off HEAD. I never commit to these — they exist only so the worktree has some branch to initialize with. The real work happens on branches I check out into the directory later.

Rotating Branches Through a Directory

When a new task comes in, I switch to my work-queue window and check out a fresh branch off development:

$ git fetch origin
$ git checkout -b TICKET-1234-fix-login origin/development

That’s the whole ceremony. The directory doesn’t care what branch it hosts. When the work is done and the PR is opened, I leave the branch where it is and move on to the next one — git checkout -b TICKET-1235-... — and the previous branch keeps living on the remote.

review works the same way, but the branches it hosts already exist. When a PR lands in my review queue, I switch to the review window and pull it in:

$ git fetch origin
$ git checkout TICKET-1234-fix-login

I review in the directory, make any fixup commits directly, push, and when I’m done I rotate to the next PR. No new worktrees to create, no old ones to clean up.

In practice I let an agent run most of these commands for me — the mechanics are identical, just wrapped in a slash command. The next post in this series covers that layer.

Solving the Untracked-File Tax

The real reason worktrees feel painful is untracked files. A new worktree is a fresh checkout — no .env, no installed dependencies, no local config. Before you can run anything, you’re copying files by hand or re-running setup scripts.

I had Claude Code write a small git subcommand called git worktree-copy that handles this. It wraps git worktree add and, after the new worktree is created, reads a .worktree-copy file from the repo root to decide what to copy or run. The config is plain text:

# Files and directories to copy from the source checkout
.env
.env.local
config/master.key

# Lines prefixed with ! are shell commands, run inside the new worktree
! bundle install
! pnpm install

Each entry is either a path to copy over from the source checkout, a ! prefix that runs the rest of the line as a shell command in the new worktree, or a comment. I use it like this:

$ git worktree-copy ../work-queue

Everything after the path is passed straight through to git worktree add, so any flag that works there works here too. See the gist for the full script.

Shared Caches, Separate Databases

Two other gotchas, both about state that lives alongside the worktree rather than inside it.

Node dependencies. Copying node_modules across worktrees burns disk and install time quickly. If your project is on pnpm, this is a non-issue — packages land once in a global content-addressable store and get symlinked into each worktree’s node_modules, so a fresh worktree costs almost no disk. If you’re still on npm or yarn, multiplying node_modules across worktrees is a reasonable excuse to switch.

Rails + Postgres databases. If your worktrees share a database, they’ll step on each other’s schema migrations and data. I parameterize config/database.yml so the database name derives from the worktree’s directory, with an environment variable escape hatch when I want to override it:

<%
  database_base_name = ENV.fetch("DATABASE_BASE_NAME") do
    "myapp_#{Rails.root.basename.to_s.gsub(/\W+/, "_")}"
  end
%>

development:
  database: <%= database_base_name %>

Each worktree now gets its own database keyed to its directory name. The gsub scrubs dashes and other non-word characters so Postgres identifiers stay clean, and setting DATABASE_BASE_NAME (in .env or on the CLI) overrides the auto-inferred name when I want to point two worktrees at a shared database intentionally. SQLite doesn’t need any of this — the database file lives in the repo and gets its own copy per worktree naturally.

A Note on Branch Naming

Because the work-queue directory hosts many branches over its lifetime, the branch names need to be self-descriptive. I prefix every branch with the ticket ID from my tracker (for example, TICKET-1234-fix-login). That way git branch --list and gh pr list both tell me what I have in flight without me having to remember which branch was about what. It also makes the next post in this series — where I let Claude Code drive the pipeline — possible, because the agent can match branches back to tickets without guessing.

When Not to Use This

Worktrees-as-swimlanes earns its keep when:

You regularly have more than one branch in flight.
Your setup tax (install, migrate, configure) is non-trivial — enough that a blank checkout is painful.
You switch contexts often: feature work → review → hotfix → back to feature.

It is overkill when the repo is small enough that a single checkout and the occasional git stash is fine, or when branches are short-lived enough that they merge before the overhead of setting up a worktree pays off.

What’s Next

This setup is worth the effort on its own if you’ve ever lost ten minutes to rebuilding a checkout after a context switch. But the real reason I landed on it is that it lets me pipeline work with an AI agent — one swimlane executing on the next ticket while I’m reviewing the previous one in another. That’s the subject of the next post.

Serve Your Rails App Over SSL in Development Mode

2024-05-13T00:00:00+00:00

Serving your application over SSL in production is a minimum requirement in 2024, but testing your configuration locally can be a pain. Here’s how you can test SSL locally without using external dependencies or “doing it live”.

Generate Your Certificate Bundle

When first researching a solution, I found this answer on StackOverflow (archived) that went into great detail about how to create a Certificate Authority that can then be used to generate multiple SSL certificates. The general approach is:

Generate a private Certificate Authority (CA)
Generate a Certificate Signing Request (CSR) using the Common Name of the hostname you will be serving over SSL
Generate a certificate that is signed by the private CA along with an accompanying private key

Rather than copy/pasting these commands into a terminal session each time you want to generate a new SSL certificate, you can automate them with a parameterized Rake task. Invoke it with the desired CN (hostname) of your server:

rails "cert:generate[host.example]"

When first invoked it will create the CA certificate, but subsequent invocations will skip this step and just generate the necessary certificate files. Your config/certs directory will now look like:

$ tree config/certs
config/certs
├── host.example.crt <-- Server SSL certificate
├── host.example.csr <-- CSR file (ignore)
├── host.example.key <-- Private key for server certificate
├── root-ca.crt      <-- Root CA certificate (install in certificate store)
├── root-ca.key      <-- Root CA private key
└── root-ca.srl      <-- Certificate serial number store

1 directory, 6 files

Configure Hostname Resolution

Whichever hostname you pick, you’ll need to ensure it’s resolvable. The easiest way to do this is to add it to your local /etc/hosts file:

echo "127.0.0.1 host.example" | sudo tee -a /etc/hosts

Repeat this for each hostname you want to resolve, but keep in mind that if you shadow a publicly-resolvable hostname you’ll want to remove it from /etc/hosts later to prevent conflicts when you go to production.

Configure Your Rails Application

Before you can connect to your server, you’ll need to whitelist the hostname to prevent the host authorization middleware from blocking your requests. You can do this by adding the hostname to the approved list:

# config/environments/development.rb
Rails.application.configure do
  config.hosts << 'host.example'
end

Or just disable the check if you’re using multiple hostnames:

# config/environments/development.rb
Rails.application.configure do
  config.hosts = []
end

Scoping this configuration to the development environment ensures you won’t accidentally open your production environment to Host header attacks

A common reason for running HTTPS locally is to confirm that Rails’s force_ssl option is working as expected, so go ahead and configure that too:

# config/environments/development.rb
Rails.application.configure do
  config.force_ssl = ENV['FORCE_SSL'].present?
end

Start the Rails Server

When you ran the cert:generate task, it provided some helpful output:

Files needed for configuration:

             Root CA: /path/to/config/certs/root-ca.crt (add to your browser certs)
  Server Certificate: /path/to/config/certs/host.example.crt
          Server Key: /path/to/config/certs/host.example.key

Run your server in SSL mode:

  sudo rails server -b 'ssl://host.example:443?key=/path/to/config/certs/host.example.key&cert=/path/to/config/certs/host.example.crt'

The --binding option (aliased as -b) allows us to specify a custom binding other than the default of 127.0.0.1:3000. In this case we are binding to port 443 and providing the necessary certificate details. The use of sudo is required because we are binding to a privileged port.

Once the server is started in SSL mode, fire up another Rails server on port 80 to test the force_ssl redirect configuration:

FORCE_SSL=1 sudo -E rails server -b 'host.example' -p 80 -P tmp/pids/server-http.pid

The use of -E ensures the FORCE_SSL environment variable will be passed to the rails server command, and the the --pid option (aliased as -P) will permit two Rails processes to track their PIDs separately instead of using the default tmp/pids/server.pid

Now that we’ve simulated a common redirect scenario, we can use cURL to ensure everything works correctly.

Test the Connection

We’ll connect to the health check route that ships with modern versions of Rails, but since we’re using a private CA to sign our server certificate we’ll need to provide that PEM-encoded certificate to allow cURL to trust our server certificate:

curl \
  --include \
  --location \
  --cacert config/certs/root-ca.crt \
  http://host.example/up

Using this command, we should see a 301 redirect and the resulting status served over SSL:

HTTP/1.1 301 Moved Permanently
content-type: text/html; charset=utf-8
location: https://host.example/up
Content-Length: 0

HTTP/1.1 200 OK
x-frame-options: SAMEORIGIN
x-xss-protection: 0
x-content-type-options: nosniff
x-permitted-cross-domain-policies: none
referrer-policy: strict-origin-when-cross-origin
content-type: text/html; charset=utf-8
vary: Accept
etag: W/"7e6c9877b2dec7dfadc43e742246d94d"
cache-control: max-age=0, private, must-revalidate
x-request-id: ad037646-fe4f-44a0-9454-0461908e06e4
x-runtime: 0.010109
server-timing: start_processing.action_controller;dur=0.01, render_template.action_view;dur=0.01, process_action.action_controller;dur=0.87
Content-Length: 73

<!DOCTYPE html><html><body style="background-color: green"></body></html>

Success!

Trust Your CA Certificate

If you’re connecting to your server using cURL, it’s annoying to have to provide the --cacert option with every invocation, and if you’re connecting via a browser, your requests may get rejected due to the default security policy. If you’re on macOS, there are a couple of steps you need to take to ensure the private CA cert we created is trusted in Firefox, Safari, Chrome, and cURL:

Open Keychain Access and add the CA certificate to your “login” keychain by dragging and dropping it into the “Certificates” list:
Double-click the certificate in the list, expand the “Trust” section, and select “Always Trust” from the drop-down (the setting will be updated when you close the detail window):
For Firefox specifically, open “Preferences > Privacy & Security > View Certificates …”, click “Import …”, and import the root CA certificate:

See this post for a deeper dive on how to configure this for Firefox

Alternatively, if you’re just using cURL, you can add your root certificate to the local store and avoid having to use --capath all over the place. First, find out where the store is located:

curl -v https://host.example 2>&1 | grep CAfile
*  CAfile: /etc/ssl/cert.pem

Then append the certificate to the list, making sure to keep a backup:

sudo cp /etc/ssl/cert.pem{,.bak} && cat config/certs/root-ca.crt | sudo tee -a /etc/ssl/cert.pem

Conclusion

With this streamlined setup, you can more easily test your SSL configuration and test cases where external services require callbacks to be served over a secure connection.

Working with External Services in Nest.js

2021-09-30T00:00:00+00:00

At its core, Nest.js provides a robust dependency injection system for resolving dependencies within your application. While a typical use case might be to inject a database connection into any service classes that need it, where this can really shine is when your application relies on one or more external service(s).

A solution that we often employ in this situation looks like the following:

Create a TypeScript interface that provides an ergonomic surface area for how we want to interact with the external service
Create concrete classes that implement this interface that we can use in both a local development environment and a remote production environment
Create a referenceable service token that can be used to inject the right dependency as needed
Create a service fake that implements the above interface that can be injected for use in our end-to-end (e2e) tests

In Practice

A server-side application will typically need to send email, so let’s think about how that looks in its simplest form. As promised, we’ll tackle the interface first:

type Message = {
  from: string;
  to: string;
  subject: string;
  body: string;
};

interface Mailer {
  send(message: Message): Promise<void>;
}

Now we can introduce some concrete classes that implement this interface. First, we’ll start with a class that will actually send an email through an SMTP relay (using nodemailer):

type SMTPMailerOptions = {
  host: string;
  username: string;
  password: string;
};

class SMTPMailer implements Mailer {
  protected readonly transport: ReturnType<typeof createTransport>;

  constructor(options: SMTPMailerOptions) {
    this.transport = createTransport({
      host: options.host,
      auth: {
        user: options.username,
        pass: options.password,
      },
    });
  }

  async send(message: Message): Promise<void> {
    await this.transport.sendMail({
      from: message.from,
      to: message.to,
      subject: message.subject,
      text: message.body,
    });
  }
}

And a corresponding class that will satisfy this interface but will log the message rather than attempting delivery:

class LoggingMailer implements Mailer {
  send(message: Message): Promise<void> {
    return Promise.resolve(console.info(JSON.stringify(message)));
  }
}

Injecting Our Dependency

In order to use these mailer classes, we now need to make Nest’s dependency injection system aware of them. Because we’re not providing a concrete class (we’ll be using our Mailer interface), we need to specify a service token that can be resolved to an instance of a Mailer class.

The service token can be a string, but I like taking the extra step of creating a TypeScript enum to make things less error-prone:

enum ServiceTokens {
  Mailer = "SERVICE_TOKENS_MAILER",
}

Now, we can register our mailer as a provider – I like the useFactory approach for most cases:

// app.module.ts

@Module({
  providers: [
    {
      provide: ServiceTokens.Mailer,
      useFactory: (): Mailer => {
        const env = process.env.NODE_ENV || "development";

        if (["development", "test"].includes(env)) {
          return new LoggingMailer();
        }

        // Typically, this configuration would come
        // from external environment variables
        return new SMTPMailer({
          host: "smtp.relay",
          username: "admin",
          password: "d34db33f",
        });
      },
    },
  ],
})
export class AppModule {}

So … in our local environments we’ll simply log all email messages, otherwise we will try to send through the configured SMTP server.

The credentials in this example are hard-coded but you’ll definitely want to pull this configuration from your environment. The official Nest documentation is a good place to research approaches.

Putting it All Together

Now that we’ve registered our mailer as a provider, we can inject it anywhere we need to. Let’s put together a simple controller that will send a message to a target recipient:

class Recipient {
  email: string;
}

@Controller("notifications")
@Injectable()
export class NotificationsController {
  constructor(
    @Inject(ServiceTokens.Mailer) protected readonly mailer: Mailer
  ) {}

  @Post()
  @HttpCode(HttpStatus.OK)
  async notify(@Body() recipient: Recipient) {
    await this.mailer.send({
      from: "noreply@host.example",
      to: recipient.email,
      subject: "Notification",
      body: "You have been notified!",
    });

    return { status: "ok" };
  }
}

Make sure to add the controller to your AppModule:

// app.module.ts

@Module({
  controllers: [NotificationsController],
  // ...
})
export class AppModule {}

You should now be able to boot your app with yarn start:dev and use cURL to initiate a message send:

curl -s \
  -H "Content-Type: application/json" \
  -d '{"email":"user@host.example"}' \
  "http://localhost:3000/notifications" | python -m json.tool

You should see a response of {"status": "ok"} and see a message printed to the Nest.js console:

{"from":"noreply@host.example","to":"user@host.example","subject":"Notification","body":"You have been notified!"}

Bonus: Adding a Fake for E2E Testing

We’ve already guarded against accidentally sending emails in our test environment, but what about when we want to assert whether or not an email was sent from our application? An approach that I prefer over using a tool like jest.spyOn() is to introduce a lightweight fake.

We can again rely on the initial interface definition to help define our fake:

class MailerFake implements Mailer {
  lastMessage?: Message;

  send(message: Message): Promise<void> {
    this.lastMessage = message;
    return Promise.resolve();
  }

  clear(): void {
    this.lastMessage = undefined;
  }
}

Swapping out our mailer at test time is as easy as using overrideProvider() when creating our testing module:

// test/notifications.e2e-spec.ts

describe("Notifications (e2e)", () => {
  let app: INestApplication;
  let mailer: MailerFake;

  beforeAll(async () => {
    mailer = new MailerFake();

    const moduleFixture: TestingModule = await Test.createTestingModule({
      imports: [AppModule],
    })
      .overrideProvider(ServiceTokens.Mailer)
      .useValue(mailer)
      .compile();

    app = moduleFixture.createNestApplication();
    await app.init();
  });

  afterAll(async () => await app.close());

  // prevent pollution between tests
  afterEach(() => mailer.clear());

  it("sends an email to the specified recipient", async () => {
    const { body, status } = await request(app.getHttpServer())
      .post("/notifications")
      .send({ email: "user@host.example" });

    expect(body).toEqual({ status: "ok" });
    expect(status).toBe(HttpStatus.OK);

    expect(mailer.lastMessage).toEqual({
      from: "noreply@host.example",
      to: "user@host.example",
      subject: "Notification",
      body: "You have been notified!",
    });
  });
});

Now we have a robust solution that sends mail when we want, doesn’t send mail when we don’t want, and allows us to have confidence that our application was doing the right thing the whole time.

This article was originally posted on the KindHealth engineering blog.

Managing Connections in Express Apps

2021-06-02T00:00:00+00:00

Typically when building apps in Express you’ll be using some sort of persistence mechanism, whether that is a relational database, NoSQL database, or another object store. Certain circumstances require using two stores simultaneously, perhaps if you want to use an RDBMS as a source of truth but leverage something like Redis as a cache to boost overall performance. Whatever technology you’re using in your application, you’ll want to ensure that connections are established (or have failed fast) before you fully boot your app.

Introductory tutorials often take the approach of initializing the database connection independently from booting the Express app – this tutorial is a top result but there are many like it. The typical approach is as follows (we’re using Sequelize with sqlite here):

const app = express();
app.use(express.json());

sequelize
  .authenticate()
  .then(() => {
    console.log("Database connection established");
  })
  .catch((err) => {
    console.log(`Connection failed: ${err}`);
  });

app.get("/users", async (_, resp) => {
  const users = await User.findAll(); // User is a Sequelize model
  resp.status(200).json({ users });
});

app.listen(3000, () => {
  console.log("Listening on port 3000");
});

The problem may not be obvious, but we’ve created a situation where 2 unintended outcomes are possible:

Requests to the /users endpoint return no data because a request is made before the database connection is established
The connection to the database fails, but the application starts in a broken state (requests to /users hang since the database is unavailable)

We can handle the second scenario by exiting the process when the database connection fails, but there could be a period of time where the app starts handling requests waiting for the connection to finally time out.

Fortunately, there are a couple of solutions to ensure that the application starts in a valid state.

Wait for the Connection Promise to Resolve

What might be the quickest solution is to move the “listen” operation inside of the resolved promise after the connection is established:

app.get("/users", async (_, resp) => {
  const users = await User.findAll(); // User is a Sequelize model
  resp.status(200).json({ users });
});

sequelize
  .authenticate()
  .then(() => {
    console.log("Database connection established");

    app.listen(3000, () => {
      console.log("Listening on port 3000");
    });
  })
  .catch((err) => {
    console.error(`Connection failed: ${err}`);
    process.exit(1);
  });

This way, the application will only be available once the database connection is available, and the process.exit call will ensure that the process exits with an error status for anything monitoring it. This can also be accomplished using async / await:

(async () => {
  try {
    await sequelize.authenticate();
    console.log("Database connection established");
  } catch (e) {
    console.error(e);
    process.exit(1);
  }

  app.listen(3000, () => {
    console.log("Listening on port 3000");
  });
})();

Use Node’s Built-In Event Handling

Node supports an event-driven architecture at its core, and Express builds on these core capabilities. Inspired by this blog post, we can adopt an approach that listens for events before starting the server:

app.get("/users", async (_, resp) => {
  const users = await User.findAll(); // User is a Sequelize model
  resp.status(200).json({ users });
});

app.once("connected", () => {
  app.listen(3000, () => {
    console.log("Listening on port 3000");
  });
});

sequelize
  .authenticate()
  .then(() => {
    console.log("Database connection established");
    app.emit("connected");
  })
  .catch((e) => {
    console.error(e);
    process.exit(1);
  });

Similar to the previous example, the app will only boot once the event has been emitted. Though this could result in some disconnect between the strings used in the event handlers, that can be easily mitigated using a TypeScript enum:

enum Events {
  Connected = "connected",
}

app.once(Events.Connected, () => {
  app.listen(3000, () => {
    console.log("Listening on port 3000");
  });
});

sequelize
  .authenticate()
  .then(() => {
    console.log("Database connection established");
    app.emit(Events.Connected);
  })
  .catch((e) => {
    console.error(e);
    process.exit(1);
  });

Again, it’s possible to use async / await semantics:

(async () => {
  try {
    await sequelize.authenticate();
    console.log("Database connection established");
  } catch (e) {
    console.error(e);
    process.exit(1);
  }

  app.emit(Events.Connected);
})();

Both of these approaches provide a cleaner way to ensure that your Express applications boot successfully or fail fast.

This article was originally posted on the KindHealth engineering blog.

3 Uses of `git rebase` for Your Daily Workflow

2020-10-07T00:00:00+00:00

Rebasing is a way of rewriting your local history by applying commits to your working tree in a different order from how they were originally made.

There are 3 flavors that I find useful in my daily work:

git rebase <branch-name>
git rebase -i <commit>
git rebase --onto <new-base> <old-base>

Using `git rebase <branch-name>`

I use this to get my local branch history up-to-date with the mainline development branch. It allows for a linear history on my branch and optionally a linear history on the main branch.

For example, here I have branched off master to feature and the histories have diverged:

a--b--c--d   master
    \
     e--f--g feature

I now want to apply my changes from feature to master, but I want to include the current history of master into feature so that my main branch can have a linear history. I can use git rebase to make this happen:

$ git checkout master
$ git pull # get my local master in sync with remote
$ git checkout feature

At this point, I’m ready to modify my branch to have a new “base” – looking at the previous history, the first commit on feature (commit e) has a “base” (or parent commit) of b. Instead, I want to change my history to be based off of a different parent (d or master in this case):

$ git rebase master

This version of rebase will get feature up-to-date with the current master and then re-apply all the commits from feature on top of this new “base”. If there are any conflicts, I’ll have a chance to correct them and continue the process.

Once completed, my history will look like this:

a--b--c--d   master
          \
           e'--f'--g' feature

Each of these new commits performs the same changes, but the “prime” (') indicator designates that these have different SHAs and, due to our desired rebase operation, different parents.

Now, I can choose to merge this with master and maintain a linear history:

$ git checkout master
$ git merge feature --ff-only # Don't create a merge commit

Now my history looks like this:

a--b--c--d--e'--f'--g'  master

Using `git rebase -i <commit>`

Before rebasing master, I’ll typically use the --interactive variant to clean up my commit history by providing better comments and grouping related changes together into a single commit.

Let’s say that I branched off of master and made a few changes on my branch that I’m about ready to merge back in:

  * update .gitignore
  |
  * moar config
  |
* * wip
| |
* * config
|/
*

It’s useful to just be able to add commits as backstops as I’m figuring out how to actually get something working, but I don’t want these unhelpful comments showing up in the history. I can use an interactive rebase to reorder, change, and even delete the commits that I’ve made.

Now that I have a handle on what changes I actually need, I’ve decided that I want to:

Combine the 2 commits that changed the config file
Modify the commit message for the config file changes
Modify the commit message for our WIP commmit
Remove the commit that changes the .gitignore file

If I invoke git rebase with -i, it will drop me into my default editor:

$ git rebase -i HEAD~4 # can also take a commit SHA

My editor (in this case, vim) will be invoked and display the relevant commit history:

pick 0cb4a62 config
pick 1f7c8d7 wip
pick 2151280 moar config
pick bcc7808 update .gitignore

# Rebase 0b4f673..bcc7808 onto 0b4f673 (4 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

By default these are all marked as pick – exiting the editor without modifications won’t change the commit history. If I move the commits around and label each like the following:

reword 0cb4a62 config
fixup 2151280 moar config
reword 1f7c8d7 wip

Exiting the editor will start the rebase operation and drop us into the editor to update, or “reword” the commit messages we want to change. Once completed, we’ll be left with a history that might look like this:

* * Add helper script to decrypt secrets in dev
| |
* * Add secrets to main config file
|/
*

Now we’re ready to rebase and merge into our master branch.

Using `git rebase --onto <new-base> <old-base>`

At times, I may make a feature branch that, while I’m waiting to merge it, I would like to start another feature that requires changes made on that feature branch:

a--b--c--d     master
    \
     e--f      feature-1
         \
          g--h feature-2

After merging my first feature to master, my new feature branch feature-2 has diverged:

a--b--c--d--e'--f' master
    \
     e--f--g--h   feature-2

We can see that, although e and f are the same as what are on master, they have different SHAs, so if we merge these, we’ll be in for a bad time. The answer is to apply our commits from feature-2 on top of commit f' while dropping the duplicate commits on the floor. git rebase --onto to the rescue:

$ git rebase --onto f' f

This will apply our new commits from feature-2 (commits g and h) on top of f' – we now end up like this:

a--b--c--d--e'--f' master
                 \
                  g--h   feature-2

Now I can do any other needed work to get feature-2 ready to merge with master.

Two Ways to Share Git Hooks with Your Team

2017-05-05T00:00:00+00:00

Git hooks are a useful feature that can be used to manage the integrity of your source repository. On my current project, I wanted to ensure that all my Go source files were formatted correctly before allowing them to be committed.

Fortunately for me, there is a simple hook available that I can save as .git/hooks/pre-commit to make this happen.

This works well for my purposes, but I wanted to make it as simple as possible when sharing with the rest of the team. This Stack Overflow post gives a couple of possibilities that I’ll go into more depth about.

Create Your Managed Hooks Directory

Since the .git directory isn’t versioned, I created .githooks at the root where all these hooks live. You can choose whatever makes the most sense for your project. Remember that when adding hooks they must be executable, so make sure you chmod +x each of them to make that happen. Otherwise, you’ll tear your hair out when you think they should run but they don’t.

If you’re using Git version 2.9 or greater, this is as simple as setting the core.hooksPath configuration variable to your managed hooks directory:

$ git config core.hooksPath .githooks

If you’re using an earlier version, you need to ensure that your managed hooks make it into the .git/hooks directory. I think symlinking is a good way to go, just make sure to clear the old ones out first:

$ find .git/hooks -type l -exec rm {} \; && find .githooks -type f -exec ln -sf ../../{} .git/hooks/ \;

That takes care of your local configuration, but each team member will need to ensure the hooks are in the right place in their local repository each time they do a new checkout. I like to just put this into my Makefile and include it into my general project setup. Here are the two variations expressed as make targets:

init:
  git config core.hooksPath .githooks

init:
  find .git/hooks -type l -exec rm {} \;
  find .githooks -type f -exec ln -sf ../../{} .git/hooks/ \;

A version of this article first appeared on the Viget blog

OTP: The Fun and Frustration of C

2015-02-19T00:00:00+00:00

Collaborate with Google Slides, Deliver with Keynote

2015-01-28T00:00:00+00:00

Fun with Cellular Automata

2014-04-18T00:00:00+00:00

Teaching Kids Programming with Khan Academy

2014-04-07T00:00:00+00:00

Game Programming in C with the Ncurses Library

2014-03-25T00:00:00+00:00

Fixing Missing Assets With Rails 4 on Heroku

2013-09-27T00:00:00+00:00

Three Reasons I Hate Laptops in Meetings

2013-05-20T00:00:00+00:00

Why I Chose to Learn C

2013-03-29T00:00:00+00:00

Refactoring Patterns: The Rails Middleware Response Handler

2012-11-26T00:00:00+00:00

Protip: Passing Parameters to Your Rake Tasks

2009-12-14T00:00:00+00:00

Keep Your Friends Close, But Your Test Data Closer

2009-09-18T00:00:00+00:00

Conditionally Customize Your URLs in Rails

2009-03-31T00:00:00+00:00

Test Drive mod_rewrite Rules With Test::Unit

2009-02-24T00:00:00+00:00

Fast, Cheap, and Good: My Rails Rumble Experience

2008-10-24T00:00:00+00:00

I Have a Pull Request on GitHub, Now What?

2008-04-24T00:00:00+00:00

Maintaining Lookup Data in Your Rails Application

2008-04-22T00:00:00+00:00

No Query String? No Problem.

2008-03-19T00:00:00+00:00

Smart Application Messaging: The Email Reflector

2006-10-06T00:00:00+00:00

Quick Apache Rewrite Rule for MVC Apps

2006-06-14T00:00:00+00:00