March 11, 2015

Branches, Branches, Branches: Developer Workflow in Helix

Streams & Branches
Version Control

branches image

In a previous article I went through how easy it is to get started with a fresh local repository using the new DVCS features of Helix. But the life of a developer is a study in non-stop interruptions, so today I thought I’d talk about juggling multiple tasks.

One of the things I like most about Git is its ability to do lightweight, in-place branches with a minimum of fuss, so it isn’t surprising it also happens to be one of my favorite weapons in our new DVCS arsenal. Getting started with a new branch takes only a single command. To illustrate a couple of points, I’m going to return to my previously created repo, to which I’ve already submitted a single, hello-world script file. To refresh my own memory, the directory contents are as follow at the outset:

[email protected]:~/newProject$ ls  p4config.txt

So let’s say I create another file, a simple readme to describe my project, and while I’m working on that I get interrupted by the need to change my existing hello-world script. This is a ridiculously trivial example, of course, but it represents what happens in the real world all the time. Creating a new development branch is as simple as a single command:

[email protected]:~/newProject$ p4 switch -c dev
[email protected]:~/newProject$ ls  p4config.txt

Executing that command created a new branch named “dev”, and switched me to it. But wait a minute, where is the readme file on which I was working? Did I just lose that work? Let’s use the list argument to the switch command to see all our branches:

[email protected]:~/newProject$ p4 switch –l
dev * 

That shows I’m working in my new dev branch instead of the main branch where I created the readme file. One of the nice aspects of our DVCS technology is that it saves your work in progress when creating branches, so you won’t lose any progress on any task. Let me switch back to the main branch to prove that point:

[email protected]:~/newProject$ p4 switch main
[email protected]:~/newProject$ ls  p4config.txt  readme

Sure enough, my readme file is right there where I left it. So now let me go back to the development branch I started and do the actual work:

[email protected]:~/newProject$ p4 switch dev
[email protected]:~/newProject$ vim
[email protected]:~/newProject$ p4 reconcile
//stream/dev/ - opened for edit
[email protected]:~/newProject$ p4 submit -d "Updated the hello world script."
Submitting change 4.
Locking 1 files ...
edit //stream/dev/
Change 4 submitted.

Again the example is pretty contrived, but it will help answer an important question: How do I merge my work from the development branch back into main? It’s simple:

[email protected]:~/newProject$ p4 switch main
[email protected]:~/newProject$ p4 merge --from dev 
//stream/main/ - integrate from //stream/dev/ 
... must resolve content from //stream/dev/ 
[email protected]:~/newProject$ p4 resolve –as 
/Users/perforce/newProject/ - merging //stream/dev/ 
Diff chunks: 0 yours + 1 theirs + 0 both + 0 conflicting 
//sysop-dvcs-1425919429/ - copy from //stream/dev/ 

All I had to do was issue three commands: One to switch back to main, another to merge all the work from my development branch, and a third to let the system auto-resolve my changes. This works great, even when editing the same file in different branches. The only time I have to do anything is if I’ve made changes to the very same lines in the file, and even then it’s pretty simple to pick and choose which bits I want back into main.

So there you have it. Helix clearly provides the kind of classic, lightweight, in-place branching that DVCS aficionados know and love. It makes it trivially simple to switch gears, handle interruptions safely, and that’s a big win for developers.

All Perforce Version Management & Collaboration Products Are Free for 20 Users.