But since there aren’t any upstream changes, we want to now fold our SomeTopic branch back to master. We switch back to the master branch and synchronize with upstream. We first want to synchronize our local repository with upstream, but we want to do this on master. Scenario 1: One local branch, no upstream changesįirst, let’s create a local topic branch and make some changes:Īt this point, we decide we want to push our changes up. Now that we have our local repository set up, we can walk through making local changes. This indicates that “master” is the current bookmark being tracked. Our repository explorer, as seen in TortoiseHg, now looks like: It represents the mainline of the code we’re working on, and everything will be pulled into this line, both from upstream and from our local branches. Git will create a “master” branch by default when you clone, but we’ll need to do this manually. If everything’s good, we’ll create the “master” bookmark: This bookmark represents the last pushed commit, so you can execute the “outgoing” command to make sure that you have nothing to push: Now that we have our extensions enabled, we need to create our local marker for a master branch. Tools like TortoiseHg have features that light up when bookmarks are enabled, so you’ll have all sorts of things help you in those tools. I’ve enabled the Rebase and Bookmarks extension, and configured bookmarks to track the current commit. This ensures that our bookmark gets moved up with each commit, instead of getting just stuck on one. You’ll also want to enable tracking the current commit for bookmarks. To enable these extensions, just modify your hgrc file. The cornerstone of my local development workflow include the Rebase and Bookmarks extension. With local topic branches, I don’t use different commands for committing (as I would with patch queues), nor do my branches leak metadata into the public timeline, as it would with normal Hg branches.įirst, let’s get our local environment set up appropriately. I tried a few other options, such as real branches, patch queues, and so on, but none had the same flavor that I was looking for with local topic branches. Is light, quick, and does not leak into the public, mainline work.Works well in the face of unpredictable work.Allows me to keep lines of work separate from each other, until it’s ready to push back upstream.Gives me a clean, linear, understandable timeline.I will say that I like this workflow because it: There are plenty of good articles out there on why this is an interesting and valuable workflow to know and understand, so I won’t rehash all the arguments. My local workflow revolves around local branches and rebasing. Well, a teammate tried to follow those steps…and found that I missed a few important nuggets. A while back, I wrote what was basically a stream of consciousness post on getting my Git workflow working in Hg. The nice thing about distributed version control systems (DVCS) such as Git and Hg is that they both allow me to basically decide how my source control should fit with my short and long-term development workflows. Mercurial workflows: local development work 9 July, 2010.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |