

When we use rebase, we can think of it as resetting our base branch. Git checkout feature/potion-for-posterity As a reminder, our base branch is develop for this example, but it can be any other arbitrary branch as well. Once the changes are safe and out of the way, we can checkout our base branch and pull the latest changes. We can push these changes up to Github just to be extra safe. To do this, we can commit or stash the changes on our current branch.

It is a good idea to periodically reset our base branch. To avoid potential conflicts later on, we’ll want to make sure we’re keeping up-to-date with the latest changes when we can. It is normal to have teammates merging their work into the base branch throughout the course of a work day, especially if the base branch is develop. Image: Long commit messages change colour Handling changes coming into the base branch There is no rule that requires us to adhere to this character limit, it’s just a personal preference. In the screenshot below, we can see that the commit message text has changed colour to let us know we’re exceeded the recommended character limit. However, writing our commit message in the editor lets us see when our message has gotten too long. Git allows us to write our commit messages inline by using the -m flag. We can checkout develop and once we’re on develop, we can pull the latest changes: Regardless of the base branch we choose, we’ll want to make sure it’s up-to-date before creating our new branch.įor this example, we have decided to base our work off of develop. Occasionally, we may choose another feature branch as our base. By default, our base branch would either be the main branch or the develop branch. At this point, we can pick our base branch. Image: A pull request is like a potion recipe Creating a new branchīeginning a new task means we’ll need to create a new branch. It helps me decide the sequence and composition of my commits. Having this mental model helps me organise my commits to tell a coherent story. I find it helpful to think about a pull request as if I were documenting a potion recipe that I’d like to eventually pass on to my future self. Thoughts about pull requestsīefore we dive into the meat of this walkthrough, let’s take a moment to talk about pull requests. If you’re unfamiliar with vim commands, you can check out the little table of commands at the end of this article to get a small crash course.
Git rebase reword download#
You can head to their website and download the version that suits your environment. To follow along, you will need to have git installed. In this tutorial, we will learn a practical beginner’s workflow that utilises interactive rebasing. Another related challenge is trying to get your head around rebasing. Incorporating git into your workflow for the first time can be quite daunting. It may be a fair to assume that almost every development team uses git for version control and to collaborate on code.
