Branching Designs in Abstract — Part 2

1: Before you branch
2: Working in a branch — you’re here 📍
3: Ready to merge

Once you get your branch created and named, working in a branch should feel pretty normal: You open your design files from Abstract by clicking `Edit` in your branch, then Sketch or Adobe XD will open. You design like you always do (though you may notice the Abstract plugin as you work).

While you’re working you may come up with a new idea you want to pursue or come across something you need to fix. Follow our recommendations below on how to use branches to organize your work.

Planned exploratory work

If you know from the get-go that you have some exploratory design work you’d like to do, here are our recommendations for setting yourself up early for success:

• Create a branch off master for your exploratory work.
• Use an emoji or the word “explore” in your branch name to indicate to your team that its purpose is exploration.
• Create a new file for explorations. Alternatively, create an exploration page in an existing file if the idea is related to updating or splitting off of a feature that’s already in your product.
• If the idea doesn’t end up getting approved for development or production, you can archive the branch. That way, you can unarchive it later if the idea comes back up.
• If the work does get approved for development, you can change the branch name to match its new status, intent, stage, etc.
• You can create a new child branch for any explorations that aren’t going into development and then delete those items in the parent branch.
• OR you can create a “stash” commit in your branch to save all your explorations in Abstract; then, you can delete all of the artboards, pages, or files that won’t be going into development.
• Finally, your cleaned up branch is ready to be merged to master!
• If you need to revisit your previous explorations after you merge, you can find your stash commit in the archived branches area.

Unexpected new ideas

On the other hand, if you unexpectedly come up with a new idea in the middle of working, we recommend this route:

• If you are starting a large-scope branch, make a playground file.
• Now you can work on your task, and if any exploratory ideas come up while you are working, you can expand upon them in your playground file.
• Rename your branch when you are ready to ship the first version of the designs (example: Design System v1).
• Then create a new child branch, and give it a subsequent name (example: Design System v2)
• Now, go back to the parent branch and delete the things that weren’t going to make it into the first version. (For example, if you had 10 explorations in the playground file but only one was approved for development, delete the other nine things. This is okay because they’re still in the child branch that you called “Design System v2”).
• Once you’ve merged the parent branch into master, the child branch now becomes a primary level branch that has all the explorations you had been doing before and is ready for continued work.

Tip: Merge or archive a parent branch to force a child branch to become a new parent branch.

When you open a file and see something that needs to be fixed, we recommend you:

1. Stop working on your current file.
2. Create a new branch from master to make the needed fix.
3. Request a review.
4. Merge the branch to master so everyone else also can use the correct design.

Branches in Abstract belong to a single person, and only the branch owner can work in their branch. However, that doesn’t mean you can’t collaborate in Abstract! Read below about different ways of collaborating and how to use branches to your advantage in each situation.

When working with other designers on the same task:

Working on parallel branches for related design efforts.

• Break down the large workload into separate areas.
• Start by creating a parent branch.
• Then have each team member make child branches for the smaller tasks assigned to them.
• Each member then merges their branch back to the parent when they have finished their task. Over time the large workload becomes completed through the collaboration of the team, which is similar to the way feature branching works in engineering.

When brainstorming with another designer:

Explorations as child branches of another designer’s work.

• Have one person create a branch and start exploring some designs.
• When another person sees something that inspires them to take the design in a new direction, have that second person create a child branch.
• Each person can keep working separately, and merge the child branch when they’ve agreed on which ideas should move forward.
• ⏸️Be considerate. Do the parent and child branches compete (e.g., does the child branch explore an alternative idea than the parent)? Make sure to have a conversation with your colleague about which designs overlap before you merge up to the parent branch and overwrite their work.

When working with a non-design stakeholder (e.g. copywriter, UX engineer, graphic designer, etc.):

Collaborating on branches with non-designers.

• It can help to view the collaboration as a temporary “hand-off.”
• Try not to work on your parent branch while the stakeholder is working on their child branch.
• When the stakeholder has finished, have them add you as a reviewer and go through their branch together.
• When approved, you or the stakeholder can merge their child branch up into your parent branch.

When working on the same artboard in parent and child branches:

Regardless of which workflow you’re using from above, if you’re using parent and child branches and multiple people are working on the same artboards, you may be concerned about work being overwritten. One resolution is to duplicate artboards in the child branches.

• Create the parent and child branches.
• In the child branch, duplicate any artboards that you are going to work on if you know that those artboards will also be changed in the parent branch.
• Work on your copy of the artboards as usual. When updates are made to the parent branch, make sure to click “update from parent” to bring in those changes.
• Now you’ll see the original artboard and your copy side by side. You can use this comparison to update your version, incorporating the parent updates without your artboard being overridden.
• When you are done with your child branch, move your designs to the original artboards and remove the duplicated artboards. You’re ready to merge!

Caution: If your files are large or you are using high resolution images embedded in your files, this is not a recommended workflow.

Part 3: Ready to merge →

Originally published at https://www.abstract.com.