You finish the changes you’ve been working on, and commit them to your local repository (the third and fourth commits in the following screenshot).īut when you go to push your new commits to your team’s central repository, Tortoise stops you with message saying you shouldn’t create “multiple heads” in the remote repository. You’re working in your local repository, and there have already been a few commits that you’ve pulled in from the central repository (two, in the screenshot below). How We End Up in This Situation (or, “It’s All Bob’s Fault”) If you’re not 100% confident that a rebase will succeed, choose to “Keep original changesets”.If a commit is in the central repository, it’s off limits. Never, ever rewrite history that’s been shared with others.It’s possible to seriously harm yourself or others if you’re not careful while driving. This shouldn’t scare you away, but it should make you pay attention to what you’re doing. If you don’t know what you’re doing, it’s possible to unrecoverably lose your changes or otherwise seriously screw-up your team’s repository. You’re re-writing history in your repository. My hope is that this post will make it easier for teams with varying levels of technical savvy to collaborate while keeping their repository history easy to read.īefore going down this path, let me emphasize that performing a rebase is not risk-free. However, the command line can be a scary place for the uninitiated. Of course, it’s possible to rebase from the command line. This tutorial will show you how to perform a rebase in a Mercurial repository using TortoiseHg. Rebasing lets you take a repository that looks like this… The goal of this post is to show you how to resolve the same situation by performing a rebase, which will help keep your repository history neat and tidy. It’s very common to resolve this problem by performing a merge. This creates a fork in your repository path (called an “anonymous branch”, for reasons I’ll explain later) that needs to be resolved before you can push your changes. (Let’s sidestep the debates about whether or not that’s a good idea, and just recognize that it’s a common practice.)įor teams working this way, it’s common that you try and push your recent changes to the central repository, only to find that someone else has beaten you to the punch. When working with a distributed verion control system like Mercurial or Git, some teams choose to have multiple developers work on the same branch. I assume you have TortoiseHg installed, and have a basic working knowledge of Mercurial including pushing, pulling, and merging. Rebasing your commits, instead of merging, can help keep your Mercurial history much easier to follow, with fewer “merge polygons” in your commit graph. This post demonstrates performing a “rebase” on your Mercurial repository using TortoiseHg.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |