Rebase on master git how to#

Save and close the file, and a moment later a new file should pop up in your editor, showing you the current wording of the commit message. With this: reword 1fc6c95 nblargh testing new thing Pick 6b2481b Awesome New Feature: FED and Jasmine tests For example you might perform an interactive rebase and replace this: pick 1fc6c95 nblargh testing new thing This time, instead of using the squash command, use the command reword. To reword commits, perform an interactive rebase as described in the above section.

Once you've saved and closed that file, your commits have been squashed together, and you're done with this step! Rewording commits This commit message will be the commit message for the one, big commit that you are squashing all of your larger commits into. Reword this commit message as you want, and then save and close that file as well. Save and close the file, and a moment later a new file should pop up in your editor, combining all the commit messages of all the commits. It should end up looking like this: pick 1fc6c95 do something It looks something like this: pick 1fc6c95 do somethingįor every line except the first, you want to replace the word 'pick' with the word 'squash'. Once you've run a git rebase -i command, your text editor will open with a file that lists all the commits in your branch, and in front of each commit is the word 'pick'. (Your hash will be a lot longer than 6 characters.

For example, if your merge base is abc123, you would run $ git rebase -i abc123. Note that you should replace $ with the actual commit hash from the previous command. Let's say you have a fork of edx-platform, and you've created a branch, like so:

Rebase on master git how to#

So, now that you understand what a rebase is, the next step is learning how to do it. Unlike most version control systems, Git allows you to change the history of your project - but it is very cautious about letting you do so. In effect, c and d have been injected into my-branch's history, as if they had been there the entire time. You'll notice that there is not a direct path from f to f′: from the point of view of anyone else watching my-branch, history has suddenly changed. Going back to the way things used to be just consists of changing that branch label so that it points back at f. When you rebase a branch, Git moves the branch label to point at the newly-created commits: my-branch is no longer pointing at f, it's now pointing at f′. The master branch is whatever commit the master label is pointing to, as well as all of that commit's parents. Git doesn't erase your previous commits: e and f are left untouched, and if something goes wrong with the rebase, you can go right back to the way things used to be.Īnother thing to notice, however, is that Git treats branches as merely labels. Git actually creates new commits that represent what your changes look like on top of master: in the diagram, these commits are called e′ and f′. When you rebase, Git finds the base of your branch (in this case, b), finds all the commits between that base and HEAD (in this case, e and f), and re-plays those commits on the HEAD of the branch you're rebasing onto (in this case, master). You'll notice that d is currently the latest commit (or HEAD) of the master branch. Here's an example of a very simple repository: it has four commits on the master branch, and each commit has an ID (in this case, a, b, c, and d). A Git repository is a tree structure, where the nodes of the tree are commits. To understand this, we need to understand a bit about how Git works. Regardless of the reason, if your pull request has gone stale, you will need to rebase your branch onto the latest version of the master branch before it can be merged. Sometimes, a pull request can go stale without conflicts: perhaps changes in a different file in the codebase require corresponding changes in your pull request to conform to the new architecture, or perhaps the branch was created when someone had accidentally merged failing unit tests to the master branch. The most common reason why pull requests go stale is due to conflicts: if two pull requests both modify similar lines in the same file, and one pull request gets merged, the unmerged pull request will now have a conflict. A 'stale' pull request is one that is no longer up to date with the main line of development, and it needs to be updated before it can be merged into the project. When many different people are working on a project simultaneously, pull requests can go stale quickly.