```yaml
---
slug: nodejs-memory-leak-heroku
published: 2022-07-19
description: You can connect to your production Heroku instance, debug it live, and even trace down memory leaks.
keywords: heroku, r14, r15, memory leak
changelog: ~
---
```

There's nothing more frustrating that your node.js app leaking memory. If you're coming here because of Heroku R14 / R15 errors, take some deep breaths, it'll be okay. Heroku's smart enough to swap to disk when this happens, and will kill and restart your app if things get absolutely wild.

## Background

![Heroku Dashboard with a lovely orange band of R14 errors](https://user-images.githubusercontent.com/1795/163650457-2371246f-bc80-4482-b42e-8bfdbf664a1a.png)

It started with my email box getting pelted with warnings that the memory quota on a project I advise for was getting hit with R14 errors. Going to the Heroku metrics page confirmed that yes, something was clearly wrong. In the above picture, you can see again and again the memory usage surge and then Heroku responding with an R15 and force rebooting the server. Moments later, the memory usage was growing again.

It's a Memory Leak, Ruin of Productivity and afternoons. 😭 

However, since the last time I dealt with a memory leak (2011) the tools have come a long way. So here's how you triage a production memory issue, run analysis against your currently leaking production boxes, and stamp out the issue.

## Modern Tools

The tools for dealing with a memory leak have gotten much better, especially if you're on Heroku. You only need two:

* A current version of Chrome (which comes with the amazing v8 debugger)
* The Heroku CLI (if on Heroku)

The first does 90% of the heavy lifting, while the second now has all the commands we need to turn on a debugger in production and forward debug data to our local machine. Make sure you've logged in to the Heroku CLI if you're triaging Heroku.

## Opening Chrome's Inspector

The Chrome Developer Tools are always available on `chrome://inspect`, which can be put in your browser's address bar. The DevTools are useful for debugging everything from node.js processes to Service workers. For now, we want to stay on the `Devices` tab, make sure `Discover network targets` is checked, and leave that window open while we set other things up. You may even see a few device targets show up that Chrome's discovered. In my case, apparently my TV can be seen. Odd, but neat.

![The Chrome developer tools](https://user-images.githubusercontent.com/1795/163651415-d75abf95-e781-45fb-ab2c-3e9adcb6ba1d.png)

## Enabling the Debugger With a Signal

The most common way to start debugging node is to add the `--inspect` CLI arg, either directly (via `node --inspect <your file>`), or in the appropriate env values ( `NODE_OPTIONS="--inspect" node <your file>`). In production environments, it may not be desirable to enable the debugger on every start; in the case of Heroku which randomly assigns ports, you can't even guarantee the debug port of `9229` is available. But, you can enable the debugger a different way.

From the [node.js debugging page](https://nodejs.org/en/docs/guides/debugging-getting-started/)

> Node.js will also start listening for debugging messages if it receives a SIGUSR1 signal. (SIGUSR1 is not available on Windows.) In Node.js 7 and earlier, this activates the legacy Debugger API. In Node.js 8 and later, it will activate the Inspector API.

Sending a signal is as easy as using the unix `kill` command, where `<PID>` is your node.js process ID:

```sh
$ kill -usr1 <PID>
```

You can try this locally by running `ps aux | grep node` to find your node.js process, and then using the `PID` for the above `kill` command. Personally, I find that the `usr1` signal is not only more reliable (works everywhere) but also means you don't have to completely restart the server. When you send `usr1`, node just sees the signal and starts up its debugger. It'll pop up moments later in the Chrome DevTools.

![local development showing the inspector starting](https://user-images.githubusercontent.com/1795/163651616-5d423ec2-bdd9-4bcd-828c-29e4bbf5335e.png)

![the development tools showing the new remote target](https://user-images.githubusercontent.com/1795/163651579-b7181e72-86d9-47e9-9d46-eb4c3cf76bc4.png)

Hit the `inspect` link and you'll be taken to a very familiar DevTools interface, but optimized for node.js debugging. In addition to the Console and Sources, you'll also have "Profiler" for CPU profiling, and "Memory" for memory usage profiling,

![connected development tools, ready to go](https://user-images.githubusercontent.com/1795/163651715-22c7a39a-81cb-43da-bc97-4e17523ffb56.png)

## Connecting to Heroku in Production

Once that's all working, it's time to connect to our production instance in Heroku and take some live samples. Close the inspector and local development server if needed, and make sure your `heroku` command works. If you're using a different environment such as Digital Ocean, look up SSH instructions to get to your host. They'll be different on every provider.

For heroku, there's the `ps:exec` command which gives you a shell on your default process for dyno 1. Be sure to specify your `<APP_NAME>` so that you're ssh-ing into the correct box, and if you need to connect to a dyno process that's not `web`, add the `-d <dyno>` flag.

```sh
$ heroku ps:exec -a <APP_NAME>
```

![connecting to a remote box over SSH](https://user-images.githubusercontent.com/1795/163652037-8309d4c9-452a-4bf5-848a-98f466346471.png)

From here, we can search our node process with `ps aux | grep node` and start the debugger with `kill -usr1 <PID>`. Our debugger will start, but obviously we can't see it yet. Heroku (and other providers) don't expose port `9229` to the internet for security reasons. Open another terminal window and use heroku's forwarding command to create a local tunnel for your debugger (and add the optional `-d` flag if needed).

```sh
$ heroku ps:forward -a <APP_NAME>
```

And just like that, your production instance shows up in the Chrome DevTools.

## Sampling

Taking samples is straightforward. Wait for the VM instance size to grow, click the trash can icon (force GC) to ensure it's actually grown by a reasonable amount, and then hit the **Take Snapshot** button to capture a memory heap. Chrome DevTools will be busy for a bit, but it'll create a Heap, which it adds to the left-hand side of the Memory profiler. Every heap is a detailed analysis of what was in JavaScript at that exact moment. Every string, object, key, event, closure, callback; you name it, it's here.

Collect several samples (5-6 is ideal) since you'll be looking for identifiable trends. I also recommend waiting about 2-3 MB between each sample. We want our growth in memory to be noticeable, and whatever's leaking to stick out.

Here, I've got 6 production samples of a leaking app. In the time I sampled, we added about 15MB to the footprint. 😱 

![chrome devtools with several heaps loaded](https://user-images.githubusercontent.com/1795/163652520-5df538be-aa9a-4ae7-bf41-17617abe030f.png)

What matters is we can see the memory growing, we have several samples of the Heaps in question (which contain our growing memory), and those Heaps are readable by the Chrome DevTools. We can save the Heaps, disconnect from our production machine (which also closes the debugger), and get to our analysis.

## Using Heap Compare

Select the newest (largest) Heap, and above the list of objects in the heap, change from `Summary` to `Comparison`. This changes the Heap view from telling you what's in the Heap to what changed **between** Heaps.

![how to change from summary to comparison view](https://user-images.githubusercontent.com/1795/163652680-cd5f2530-6b12-4c00-8014-326df53c8a80.png)

Sort the table by `# Delta`, and the problem suddenly becomes very obvious.

![a sorted by delta comparison](https://user-images.githubusercontent.com/1795/163652782-5832abe0-c4c3-4e79-b804-100f1916fa47.png)

We can compare against a few other Heaps (that's why we captured them) to isolate the source of the memory leak. Here, I'm comparing Heap 5 to Heap 4, where the number of `(concatenated string)` is much smaller and easier to manage. There's a lot of weird date strings like "-137 days, 21" being created and retained. Clicking on one gives us the full Retainer log. It's part of a larger string, that's part of a larger string, that's in `discountTimeLeft` in the update cycle of a React component called `DiscountBanner`, inside of a... `Timeout`.

![The memory leak source](https://user-images.githubusercontent.com/1795/163653410-35a401c4-0b85-4eb6-9c14-4eec51878a0d.png)

Opening up the `DiscountBanner` culprit, there's a `setInterval` in the `constructor`. Fixing this and redeploying closed the memory leak. It turned out that when next.js was running in Heroku, the `setInterval` would just keep on running and building its string about how many days were left on the discount. Since that string was locked in the `setInterval` callback, it could never be garbage collected by v8. Add in a few thousand requests per second, and those discount strings would ultimately take up all of the available memory and cause Heroku to restart the server with an R15 error.

## More than Heaps

I only needed the Heap compare, but the CPU profiler and the Memory timeline (Allocation instrumentation on timeline) can help narrow the issue even further in a larger application. The hardest part is getting a reproducible issue. Looking at production not only makes it easier, but ensures you're solving the right problem. And when you're done, you'll never put a `setInterval` in a React component constructor again. 😆 

Solving a Node.js Memory Leak on Heroku

```yaml
---
slug: developing-react-native-with-expo-and-flipper
published: 2021-12-07T01:00:00.000Z
description: Goodbye Chrome Debugger, hello Flipper
repost:
  url: https://blog.expo.dev/developing-react-native-with-expo-and-flipper-8c426bdf995a
  text: This article was written for the Expo Blog and appeared with the title _Developing React Native with Expo and Flipper_. It's been reproduced here with permission.
changelog:
  2021-12-03: There’s now an Expo community plugin for setting up Flipper in your Expo projects. The section on Flipper integration was updated to reflect this change.
---
```

There’s a lot of great React Native modules out there, but most of them require a custom iOS or Android build, leaving “ejecting” as the only option for Expo users. That changed in SDK >42, when Expo added the ability for Expo Application Services to create custom development builds of your app.

What’s a custom development build? It’s not just any Expo Go app, it’s your Expo Go app; complete with any React Native module you ever wanted, all without ever having to hit the eject button.

And now that Expo 43 includes React Native 0.63, [Flipper by Facebook](https://fbflipper.com/) is available by default; there’s no better time to ditch the old “Chrome Developer Tools” way of debugging your React Native app. Not only will you gain access to device information and crash logs, you’ll also have Flipper’s amazing plugin library. Everything from Apollo to Redux debuggers are in there.

If you’d like to skip to the end result, check out the [jakobo/expo-cdc-example](https://github.com/jakobo/expo-cdc-example) repo as that’s what we’ll be building towards.

## Overview
- Configuring your code for EAS
- Creating a development build of your app
- Connecting to your app via Flipper
- Final considerations

## Create an EAS-Friendly Expo App
We’re going to start our journey by making a run-of-the-mill Expo application (install Expo CLI if needed with `npm install -g expo-cli`). When we run `expo init -t expo-cdc-example`, we’ll be given a standard Expo application, configured for Typescript. If you would prefer vanilla JavaScript, just omit the `-t` option. The result (minus our hidden folders and our lockfile) looks like this:

```
/
|- assets
|- app.json
|- App.tsx
|- babel.config.js
|- package.json
|- tsconfig.json
```

From here, we can run `expo start` and view our Expo app. We could also build locally, but what we’re really looking for is to let someone else do all the work for us. This is doubly true if we’re developing on Windows, as XCode isn’t even an option for making an iOS app. Enter Expo Application Services (EAS).

EAS lets you use Expo’s hardware to build your iOS/Android application, and has its own CLI. You can use EAS for building non-expo applications as well, so the EAS cli isn’t bundled with Expo. We’ll need to install it globally like we did with our `expo-cli`.

    npm install -g eas-cli

Let that run, and you’ll have a new `eas` command available. The EAS CLI doesn’t have an `init` command, and while running the `eas` build command will generate the configuration file for us, we’ll have greater control if we create the file ourselves. Create a file named `eas.json` in your application root and copy/paste the following configuration in:

```json
{
  "cli": {
    "version": ">= 0.34.0"
  },
  "build": {
    "base": {
      "env": {}
    },
    "development": {
      "extends": "base",
      "developmentClient": true,
      "distribution": "internal",
      "releaseChannel": "default",
      "android": {
        "buildType": "apk"
      }
    },
    "production": {
      "extends": "base",
      "distribution": "store",
      "releaseChannel": "stable",
      "android": {
        "buildType": "app-bundle"
      }
    }
  }
}
```

This sets up EAS to build something we’ll call a “preview” build. It will behave just like our production app, but it’s claimed ownership of the default release channel. By utilizing `releaseChannel: "default"` in our development build, and not our production builds, we can make sure that an accidental `expo publish` doesn’t push code to our live application. There’s [a lot more to `eas.json`](https://docs.expo.dev/build/eas-json/) than we’re covering in this article, but the above is enough for us to launch our builds. If you’re already using the default channel for your app store releases, you can change value of the `releaseChannel` property.

We can now tell EAS to build our app. We’ll want to specify our build profile preview as part of the command.

If this is your first time running EAS, you’ll want to associate any iOS devices with your ad hoc provisioning profile. You can [follow the steps in the Expo documentation](https://docs.expo.dev/build/internal-distribution/), or just run `eas device:create` and follow the prompts. To generate our build, we just need to run `eas build --profile=preview`.

EAS will be off building things, and you can go get a cup of coffee. ☕

After a while, you’ll have a shiny build that you can install on your iOS/Android device! EAS runs in the background too, so no need to wait for a build to finish, you can get back to coding.

## Configuring EAS For a Development Build

So far, we’ve created an Expo app, we’ve configured EAS, and we’ve kicked off a custom build. But EAS doesn’t just let you make custom production builds, it **lets you make development builds too!** That’s right, it is your own Expo Go, with your own modules. And we’ll be using EAS to build it.

Enabling a development builds means creating a new profile in our `eas.json`. These additions should go alongside your preview build.

```json5
{
  "build": {
    // ...
    "devclient": {
      "extends": "base",
      "releaseChannel": "default",
      "distribution": "internal",
      "developmentClient": true,
      "android": {
        "buildType": "apk"
      },
      "ios": {
        "simulator": true
      }
    }
  }
}
```

Our new profile, `devclient` adds a few EAS options. The `developmentClient` flag tells EAS that we want a custom build of the Expo development app, and the `ios.simulator` field tells EAS not to create an iOS app, but a bundle that’s designed for the iOS Simulator.

Now, kick off your new build and go get more coffee. ☕

    eas build --profile=devclient

When that finishes up, you’ll have a custom simulator build. When you install that on your simulator and launch it, it will look different than your usual Expo Go app.

![The Expo Custom Development Client launch screen](https://user-images.githubusercontent.com/1795/146845551-1bd86cb8-8236-4805-ba10-2bf24ab0cb82.png)
_The Expo Custom Development Client launch screen_

Instead of the usual expo start command, it tells us our app needs to be started with the `--dev-client` flag, so let’s do that. Stop your expo start if it’s running, and restart it with `expo start --dev-client`.

The project will show up in your development build with a URL structure of `exp+<project>://expo-development-client/…`. The `exp+<project>` protocol helps the native OS tell the difference between your custom Expo app and any others you might have on the simulator or device.

So long, Expo Go, hello Development Builds. 💅

## Hello Native Modules, Hello Flipper

All of the above setup needs to be done exactly once, and the payoff is huge. We’re going to get a better debugger for React Native, called [Flipper](https://fbflipper.com/), by Facebook. Go download the app, and we’ll set up our development build to use this native module.

First, we’ll need to install Flipper and its dependencies, which is a straightforward pair of command: `expo install react-native-flipper react-devtools-core` for our expo related code and `yarn install expo-community-flipper` for our build plugin we'll be using later.
Then, we’ll need to tell our App to connect to Flipper in our `App.tsx` file:

```tsx
// App.tsx
import { connectToDevTools } from "react-devtools-core";
if (__DEV__) {
  connectToDevTools({
    host: "localhost",
    port: 8097,
  });
}
```

Since we’ve added a new native module, we’ll need to create a new development build that has our native iOS and Android code bundled in. Because Flipper also requires changes to our app’s `Podfile`, we’re also going to make use of Expo’s [Config Plugin](https://docs.expo.dev/guides/config-plugins/) system. Because we already installed the [community Flipper plugin](https://www.npmjs.com/package/expo-community-flipper), it's as easy as adding the plugin to our `app.json`.

```json5
{
  "expo": {
    // ...
    "plugins": ["expo-community-flipper"]
}
```

One last time (and one last ☕): `eas build --profile=devclient`

Install the new build on your simulator, open up the Flipper App and it just works 🤯

You can repeat this for any Native Module you want, though Flipper is an excellent starting point since it lets you use `react-native-reanimated` v2 with TurboModule support, frees you from the built-in Chrome debugging tools, gives you crash logs, and more. Just remember that you’ll need to create a new development build when you add a new module, or make judicious use of try/catch blocks to ensure you don’t throw an error.

## Keep Building From Here

This is just the start of what you can do with Expo’s development builds and Native Module support. Most Native Modules will work out of the box in a development build thanks to React Native’s autolinking, but if you do need custom changes to your `Info.plist` or `Manifest.xml` files (or even editing a `Podfile` like we did today), Expo can take care of that too as part of the build process. These [config plugins](https://docs.expo.dev/guides/config-plugins/) let you modify the plist and manifest without ejecting your app and are configured from within your `app.json`.

If you still run into issues, there’s an #EAS channel on the [Expo discord](https://discord.gg/4gtbPAdpaE) and the [Expo Forums](https://forums.expo.dev/) have an entire section dedicated to EAS.

Developing React Native with Expo and Flipper

```yaml
---
slug: running-expo-in-windows-subsystem-for-linux-wsl2
published: 2021-11-10T18:00:00.000Z
description: Windows, meet Expo in Linux
repost:
  url: https://blog.expo.dev/running-expo-in-windows-subsystem-for-linux-wsl2-425f6fd7838e
  text: This article was written for the Expo Blog and appeared with the title _Running Expo in Windows Subsystem for Linux (WSL2)_. It's been reproduced here with permission.
changelog: ~
---
```

If it runs in Node.js, it can run Expo. Even better, if it runs in Linux, you can take advantage of all the excellent React Native tools that may not be utilizing cross-platform utilities like `cross-env`. Since Windows 10 has support for Linux through a virtualized Windows Subsystem for Linux (WSL2), we can use that to run our Expo applications, build tooling, and more.

Getting everything working on WSL2 **does** have a few gotchas, which is why this guide can help you get up and running quickly and avoid some of the most common pitfalls (spoiler: it’s networking related).

# Overview

- Setting up WSL2
- Configuring `WSLHostPatcher`
- Alternative: Using Windows Firewall Rules
- Final considerations

# Setting up WSL2 for Expo Development

WSL2 gives you access to a fully featured Linux command line inside of Windows. While great cross-platform tools like `env-cmd` exist, not every tool we use in React Native development is Powershell-aware. Using WSL2 eliminates those problems entirely; it’s just Linux. Unless specified, all our commands will be in WSL2’s Linux environment.

****What You’ll Need for This Step****

1. Windows 10 or 11 (with or without the Windows Insider Program)
2. Windows Subsystem for Linux ([Instructions here](https://docs.microsoft.com/en-us/windows/wsl/install))

The first thing we’re going to need is both Expo CLI and EAS CLI in our WSL environment. From there, we can initialize our standard Expo app, just like a managed app. We’re using the Typescript template, but you can also opt for a vanilla JS experience.

    $ npm install -g eas-cli
    $ npm install -g expo-cli
    $ expo init expo-cdc-example
    $ cd expo-cdc-example
    $ yarn start

We’ll get our Expo QR code, but when we try to visit our developer page, we’ll end up at a 404. This happens because to our **browser**, `localhost `is referring to Windows, and Windows doesn’t know that those Expo requests need to be forwarded along to the WSL.

# Configuring `WSLHostPatcher`

Unless you have specific security concerns (such as exposing your Windows machine to the Internet), the fastest way to fix the port forwarding problems is with a utility called `[WSLHostPatcher](https://github.com/CzBiX/WSLHostPatcher)`. Built on the Windows Detours framework, it dynamically updates the bind & listen addresses for your WSL instances. We’re going to download the utility and run it every time our WSL instances starts. (Adjust appropriately for a non-BASH environment)

    $ cd
    $ mkdir wsl; cd wsl
    $ wget https://github.com/CzBiX/WSLHostPatcher/releases/download/v0.1.0/release.zip
    $ unzip release.zip
    # run WSLHostPatcher on every login
    $ echo "./wsl/WSLHostPatcher.exe" >> ~/.bashrc

Let’s close our dev console, along with any running `yarn` instances, and reload WSL. We’ll be greeted with `WSLHostPatcher` confirming it found and updated our WSL instance.

    Dll path: \\wsl$\Ubuntu\home\<yourname>\wsl\WSLHostPatch.dll
    Found 1 WSL host
    Patched 1

Give `expo start` a try now, and watch how your `localhost` request automatically finds its way to your Expo instance.

# Alternative: Windows Firewall Setup

One of the downsides to `WSLHostPatcher` is that it will bind your WSL instance to `0.0.0.0`. For most development scenarios, this is perfectly ok. If you have security concerns though, you can also use a Powershell script to forward specific ports to your WSL instance. This is a much longer setup, but uses the built-in Windows Firewall.

First, you’ll want to download the following script based on the excellent work of [@edwindijas on github](https://github.com/microsoft/WSL/issues/4150#issuecomment-504209723), and save it to `c:\scripts\wslbridge.ps1`. This script does a couple things.

1. Removes all existing WSL2 based routing rules
2. Creates new Outbound & Inbound rules on the Windows machine for your specified ports
3. Removes any existing proxies between Windows and your WSL instance
4. Creates a proxy from Windows to your WSL instance for all specified ports

```ps1
# [Configuration]
# All the ports you want to forward separated by coma
$ports=@(7700,8088,8089,19000);

# You can change the addr to your ip
# config to listen to a specific address
$addr='0.0.0.0';

# [Init]
$remoteport = bash.exe -c "ifconfig eth0 | grep 'inet '"
$found = $remoteport -match '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}';
if( $found ){
  $remoteport = $matches[0];
} else{
  echo "The Script Exited, the ip address of WSL 2 cannot be found";
  exit;
}

$ports_a = $ports -join ",";

# Remove Firewall Exception Rules
iex "Remove-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' ";

# adding Exception Rules for inbound and outbound Rules
iex "New-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' -Direction Outbound -LocalPort $ports_a -Action Allow -Protocol TCP";

iex "New-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' -Direction Inbound -LocalPort $ports_a -Action Allow -Protocol TCP";

for( $i = 0; $i -lt $ports.length; $i++ ){
  $port = $ports[$i];
  iex "netsh interface portproxy delete v4tov4 listenport=$port listenaddress=$addr";
  iex "netsh interface portproxy add v4tov4 listenport=$port listenaddress=$addr connectport=$port connectaddress=$remoteport";
}
```

Open up ****Task Scheduler**** and set up a task that will run the script on login, after a small delay. For reference, your task should look like the following:

![Create Task dialog box](https://user-images.githubusercontent.com/1795/146844508-fbd9cb3e-57e5-41b2-8cfc-d38873d9662e.png)
_Creating a task in the Task Scheduler_

![Task Triggers tab](https://user-images.githubusercontent.com/1795/146844535-fa52152a-575e-440f-826b-c8e8bfd18662.png)
_Setting a Trigger condition for our task_

![The Actions tab](https://user-images.githubusercontent.com/1795/146844565-cd926b31-0d6a-4cd3-a010-976a16e3c8e8.png)
_Task Action set to start the `wslbridge.ps1` script with the `-ExecutionPolicy Bypass` flag, allowing it to run with the necessary permissions_

Once configured, either on login or by running the script manually, Windows will automatically forward ports to WSL for you. From here, you can now run `expo start` from within WSL, and `localhost` will resolve as expected.

# Other Things You Can Do With WSL And Expo

The fun doesn’t stop at just accessing Expo’s developer tools. Because you can forward any port to WSL, that means you can access the Chrome Debugger, use `adb`, integrate Flipper, monitor with Wireshark, the list goes on! You’ll also be running your Expo builds from within Linux, meaning any build tooling will work just as it would on a Linux or Mac workstation.

It’s a great time to build React Native apps, and now it’s easier than ever on Windows.


Running Expo in Windows Subsystem for Linux (WSL2)

```yaml
---
# This frontmatter will be used by codedrift
slug: useful-git
published: 2015-03-18T00:00:00.000Z
description: There are some good git commands, and there are great git commands
changelog:
  2020-02-23: This was rescued from the archives of the old [felocity.org](https://web.archive.org/web/20050507121849/http://www.felocity.org/journal). As a result, many links in this piece were left pointing to archive.org destinations.
---
```

I love git. It and its other distributed version control systems have changed the way we think and write about code. Not too long ago, we used to commit giant monoliths of code to SVN locations. Complex environments often had to dedicate at least one person to managing branches. It was the complete opposite of good. I've been using git now for over 8 years, and I'm still learning tips and tricks that make my day to day development easier and better. These are some of my favorite commands.

## git bisect: When did the code go wrong?

Eventually something will break, and if you're unlucky, it will only happen after a long stream of commits. The git bisect command allows you to begin searching for that commit where things went south. The command looks like:

    git bisect start
    git bisect bad HEAD
    git bisect good aecdb123
    # and so on...

You'll need to specify a "bad" revision (often `HEAD`), a "good" revision (perhaps from a tag or git log), and then you're off to the races. Git will select a commit exactly halfway between "good" and "bad". So you'll test your code. If it worked, type `git bisect good`, and if it didn't type `git bisect bad`.

Every time you tell git if things are good/bad, it will cut the remaining revisions down by half. Before you know it, you'll have zeroed in on the commit that is causing everything to fail. Check the commit log, see what happened, and you'll usually be 99% of the way towards fixing your broken build. All of the bells and whistles that make bisect even cooler are available on the [git-bisect docs page](http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html).

## pull + rebase: 2 for 1

You can pull. You can rebase. Or you can do both in a single line

    git pull --rebase origin main

## git config: Type less with aliases

Maybe you don't like reaching up for the hyphen key `-` and want a simple command to pull and rebase at the same time. `git config` lets you set any of the config options. There are a lot, but for now we'll just show off an alias.

    git config --global alias.pr 'pull --rebase'

From this point forward, you can type `git pr` to pull & rebase. Your hyphen key will thank you!

## git-reflog: Undo nearly anything

`git reset` (with the hard flag) is probably one of the scariest operations you can do. Just like that, it could appear your entire repository was catapulted back in time. This can be pretty great… as long as you didn't need any of those changes. It only took me accidentally blowing away my changes once before I did `git reset` in new branches only. This was before I learned about the "reflog".

The `git reflog` command spits out a sequence of operations.

    1907832 HEAD@{0}: checkout: moving from master to sample
    1907832 HEAD@{1}: commit: working on git article
    809189a HEAD@{2}: commit: final title change
    1887f64 HEAD@{3}: commit: minor amendment to iframe article
    6c8e64c HEAD@{4}: commit: launch iframe blog, added to git blog
    b47369b HEAD@{5}: pull origin master: Fast-forward
    7f66541 HEAD@{6}: commit: changed to hashes for markdown, new post
    b9e19d0 HEAD@{7}: commit: converting to pygment happy land
    432a308 HEAD@{8}: rebase finished: returning to refs/heads/master
    432a308 HEAD@{9}: rebase: more drafting of the creed post

It turns out that it's damn-near impossible to lose something in git. As you commit, rewind, replay, and revert, git keeps a record of every single thing you've done. Now, let's reset to some arbitrary distance ago, destroying all my hard work.

    git reset --hard b9e19d0
    # HEAD is now at b9e19d0 converting to pygment happy land

Sure, I'm back in "pygment happy land", but I just lost 7 commits worth of work. `git reflog` knows you better than you think; it has your history of changes, including your foolish reset:

    b9e19d0 HEAD@{0}: reset: moving to b9e19d0
    1907832 HEAD@{1}: checkout: moving from master to sample
    1907832 HEAD@{2}: commit: working on git article

A quick reset back to `1907832`, and everything is back as if **nothing was ever destroyed**. There's a line added to your reflog for the reset you made too! This makes `git-reflog` incredibly powerful. It's also comforting to sometimes just look at the reflog and know git's got your back.

---

Most of these tips were pulled from notes I took while learning git. I then learned there is an entire website dedicated to improving your git-fu. [http://gitready.com/](http://gitready.com/) has examples, tricks, tips, and even more amazing things that go beyond this.


2022

Solving a Node.js Memory Leak on Heroku

2021

Developing React Native with Expo and Flipper

Running Expo in Windows Subsystem for Linux (WSL2)

2015

Useful git