Branching projects

Branching turns part of a project into a project of its own, without copying anything. The tasks you branch are shared: they appear in both projects, and a change made in one shows in the other.

When to branch

• Red tasks pile up. Each red task documents a route that went nowhere in this context. When many accumulate, the context itself may be the problem: branch the ideas worth pursuing into a project whose context suits them, and keep the red tasks where they are, as the record of why they stopped here.
• A workstream outgrows its project. The data migration inside a larger platform project deserves its own project, its own colors and its own list, but it remains part of the platform.
• One piece of work serves two projects. A shared component or a common supplier negotiation belongs to both, and both should see its state.
• You want a focused view. A few tasks get a project of their own, without losing their place in the original one.

Branching is not a sandbox. Branched tasks are shared, not copied, so whatever you do to them happens in both projects. To try an alternative approach, add a new task instead and keep the old one, red if you abandon it (chapter 3).

Branch tasks into a new project

1. In the Tasks tab, right-click a task. To branch several tasks at once, select them first with Ctrl+click or Shift+click.
2. Choose Branch into new project….
3. In the Branch into a new project window, pick an emoji (🌿 by default), check the name (the task's name by default) and add a description if you like.
4. Click Branch. Andon creates the project and opens it on its task list.

In the new project, each branched task sits at the top level, with all its child tasks. In the original project nothing moves: the tasks stay exactly where they were.

Any row of the Tasks tab can be branched: a child task (top-level in the branch, still in its place in the original project), a todo list, a Kanban board, or a task of a project that is itself a branch. A task of an archived project can't be branched: restore the project first.

What is shared

A branched task is one and the same task in both projects. Its name, color, child tasks, notes, note history and files are shared: edit the note in the branch and the original project shows the change; add a child task in either project and it appears in both.

Each project keeps two things for itself: the order of its top-level tasks, and its folders. A shared task can sit in a folder in one project and at the top of the list in the other.

Plugin data belongs to the task too: a shared task's draw.io diagram and Yi Jing readings are the same in both projects.

Dragging a shared task under another task moves it in the project you are in only; the other project keeps it where it was. Changes inside a shared task, such as reordering or moving its child tasks, show in both projects.

Colors in both projects

A shared task's color counts in every project that holds it, by the usual rules (chapter 6). Set a shared task to orange and both projects turn orange: a blocked dependency shows at every level that depends on it.

Remember that the rule about the last task applies in each project separately. In the branch, a branched task is a top-level task; in the original project, it counts from wherever it sits in the list.

The ⑂ marker

A shared task shows the ⑂ marker on its row in every project containing it, followed by dots in the current colors of the other projects it is shared with.

• Hover over the marker to see the list: "Shared with:" followed by the projects.
• Click it to jump to the other project, or to choose one when there are several.

The marker only shows information; it never changes a color.

Where a branch came from

In search results, a branch project shows a line such as "⑂ Branched from Platform 2027 › Data migration", naming its origin project and task. An archived branch shows the same line; click it to open the origin task. If the origin task has since been deleted, the line keeps its name and adds "origin deleted".

Deleting and archiving with shared tasks

Andon never lets one project destroy work another project still holds.

Ending a share

There is no merge or un-branch command, and none is needed: the work already lives in both projects. To stop sharing a task, delete it from the project that no longer needs it; it leaves that project only, as the table above shows. Branching always creates a new project: a task can't yet be added to a project that already exists.

A worked example

1. The project Platform 2027 has a task "Data migration" with six child tasks, and it keeps growing.
2. You right-click "Data migration", choose Branch into new project…, keep the name and click Branch. A new project, 🌿 Data migration, opens with the task and its six child tasks.
3. You work on the migration in the new project: notes, files, Kanban board, folders. Every change also shows in Platform 2027, where the task stays in its place with a ⑂ marker.
4. A child task blocks on a vendor and turns orange. Both projects turn orange: Platform 2027 shows the blocked dependency without your opening the branch, and the ⑂ dots show the branch's color at a glance.
5. When the migration is finished, you archive the branch. Platform 2027 keeps the "Data migration" task, with its whole history.

Tips

• Name the branch after the outcome it delivers, so it reads well in the project list and in search.
• Branch the smallest piece that makes sense. A whole subtree comes along with each task you branch.
• Write in the branch's description why it was branched; the ⑂ line in search shows where it came from, not why.