Rebasing

Thus far, we’ve only dealt with one way of moving code from one branch of a GitHub repo to another: by merging the branches. This is by far the most common way that code moves from one branch to another, but it is not the only way. In particular, merging is generally used to move code from feature branches back into the main. Let’s now look at rebasing, a way of moving code from the main branch into a feature branch.

Rebasing a Branch

Rebasing allows you to update your feature branch to reflect changes that have been made to the main branch since the feature branch was created. If, for example, another developer commits changes onto the main branch that affect the same functionality you’re changing in your feature branch, you can rebase your feature branch so that the feature branch includes that other developer’s changes. This lets you ensure that your changes will work correctly with the code on the most up-to-date version of the main branch, not just with the state of the main branch at the time you started work on your feature branch.

Let’s walk through an example of performing a rebase. Open GitHub Desktop and use the keyboard shortcut Ctrl-N to create a new local repository. Enter a name for the repo and select the checkbox labeled “Initalize this repository with a README.”

Sidebar: The .gitignore File

You’ll notice in the dialog box above that one of the options is a dropdown marked “Git ignore.” Most programming languages have at least some files associated with them that can be generated automatically from the source-code files; for example, Java .class files are generated automatically by the compiler, with a one-to-one correspondence between the contents of the source-code file and the contents of the corresponding class file. To reduce the size of our repo, we can commit just the source files: anyone with a Java compiler can generated the .class files themselves. Git accomplishes this by creating a special file in the repo called .gitignore that uses wildcards to describe the filenames that should not be committed to the Git history even if they appear in the repository folder. For our example, let’s work with a small Python program. Select “Python” from the “Git ignore” dropdown and click “Create repository.”

Back to Rebasing

Let’s create a simple Python program to work on. Click the “Open in Visual Studio Code” button in the main part of the window or use the keyboard shortcut Ctrl-Shift-A. Click “New file” in the main part of the VS Code window, enter the code below, and save the file as helloWorldGUI.py.

Close VS Code and switch back to GitHub Desktop. Select “Repository → Open in Command Prompt” from the menu or use the keyboard shortcut Ctrl-` to open a terminal window. Run the code using the command python helloWorldGUI.py.

Switch back to GitHub Desktop and commit the new file with the default commit message. Click the “Publish repository” button at the top of the screen to upload the contents of the repo thus far to GitHub.com. Leave all of the default options in the dialog box and click “Publish repository.” Create a new branch called add-counter, then open up the source file in VS Code and make the following changes:

Close VS Code, commit the changes with the message “Partial counter implementation,” and then switch back to the main branch. Now let’s simulate a change made by another developer to add keyboard bindings. Open VS Code and update the code again to the following:

Close VS Code, commit the changes with the message “Add keybindings,” and then switch back to the add-counter branch. We now want our add-counter branch to reflect the change that was made to the main branch since we created our branch. Select “Branch → Rebase current branch…” from the menu or use the keyboard shortcut Ctrl-Shift-E. Click on main in the list of branches (since this is the branch we want to rebase from) and then click “Rebase.”

Now, if we switch the left-hand sidebar to the “History” tab, we can see that the commit from the branch is now part of our feature branch’s commit history.

Note: it is generally considered poor practice to rebase a branch after you’ve already pushed it to the remote repository. This is because doing so will cause the commit history of the remote repository to be overwritten, which can cause problems for other developers working on the branch that was rebased.

That’s rebasing in a nutshell. Next post, we’ll look at another way of moving code from one branch to another: cherry-picking. As a challenge for next time: the resulting program code after rebasing is below (click on the image to see a larger version). Can anyone spot the bug in how I’ve assigned the keybindings?