Branches or tasks?

Git is awesome and incredibly powerful. Describing and implementing the concepts that Git relies on for its full power requires a pretty robust vocabulary. Fetch. Pull. Push. Merge. Branch. Commit. Rebase. Stash. Revert. Blame. Cherry-pick. These commands enable all sorts of flexibility for teams to use Git in the way that works best for them, but it also puts a lot of additional burden on developers. 

Conveyor relies on this flexibility under the hood, but it takes a more natural language approach to translate the functionality into words and phrases that fit better with your development work.

The biggest fundamental difference is that in Conveyor, instead of referring to “branches,” it uses the concept of “tasks.” That is, everywhere in Conveyor that you see the word “task” you can mentally substitute “branch”to get an idea of what’s happening behind the scenes. At first glance, this may seem trivial, but it enables much more natural vocabulary throughout.

When you sit down to do some work, you’re not “creating a new branch.” You’re “starting a task.” You’re not “checking out a different branch.” You’re “switching tasks.” When you’re done, you’re not “merging a branch.” You’re “finishing a task.” Sure, behind the scenes, Conveyor is branching and merging, but you don’t have to worry about the details.(Although, you could hop into a terminal and run `git log` to see what’s going on if you’re curious.)

A screenshot of a task header showing the 'Switch to task' button
Switching tasks is a more accurate description of what is happening when changing branches.
A screenshot of a task header showing the 'Finish task' button
Sure, you’re merging a branch, but you’re really “finishing a task”

That way, when you finish a task, you’re not only merging, but you’re also cleaning up the branch. However, instead of thinking about these as discrete tasks that you have to remember to do, you simply click “Finish Task” and Conveyor handles it so you can move on to the next task.

In addition to the ongoing work on tasks, the task model enables thinking about branches as work to be done. While it feels unnatural to move a branch to a backlog, saying that a task is‘ In Progress’ or ‘Up Next’ is incredibly natural. And you can even move a task to the backlog if it doesn’t need to be on anybody’s radar at the moment.

A screenshot of a task header in the web application that shows a drop down including 'Start', 'Move to Backlog', 'Finish', and 'Reject'
Tasks are more naturally suited to organize and re-classification.

Let’s look at the backlog now. By classifying tasks with categories such as bug fix, feature, or improvement, you can then organize and filter your backlog. Instead of a library of branches with limited meta data, you’re now looking at a curated list of actionable tasks with assignees, names, and contributors.

A screenshot of the Backlog tab of a project tin the web application with filtering options for the task type and the assignee.
Thinking in terms of tasks instead of branches means they can be filtered, picked up, etc.

While branches can be stale, a stale “task” feels more accurate. When a task hasn’t seen any activity, it feels more natural to surface it and nudge it to the backlog. Stale branches can linger indefinitely with no clear action. This gives a clear path forward when progress halts. Stale tasks/branches don’t linger and clutter up or distract from other work. They can comfortable be tucked into the backlog to revisit later. And since the activity is recorded, you’ll easily be able to see what happened and why when you revisit the backlog in the future.

A screenshot of a stale task with a prominent mess encouraging moving it to the backlog.
Nudging stale branches to the backlog feels natural and welcome.

Get updates and early access