Once you’ve decided to use branching, one thing to consider is naming your branches to clearly communicate what they contain or address. A common practice in development where branching is used with code repositories is to prefix the branch name with something to easily identify it. This could be a ticket number, priority flag, type of work, emoji status, or similar:
Talk with your development teams and see what type of naming conventions they use! If there’s an opportunity to use the same convention, it can help follow work across the entire process as the same information can be referenced in conversation and documentation.
When you want to apply your changes to the main file, you can merge the branch. If you're an editor on the main file, you can initiate the merge to review any changes from main in the branch and resolve any conflicts that may appear.
If you're an editor in the organization but a viewer on the main file, you will need to reach out to an editor of the file in order to have a branch merged. This is somewhat similar to how a PR request is made in the engineering process. One way we recommend doing this is to use a comment and @mention the editor(s) with a summary of the proposed addition or updates, where the editor(s) will then receive a notification and can switch to your branch to view the changes or leave additional comments for follow-up.
After a branch has been merged into the main file, it's automatically archived along with all comments made within the branch. In the event that you need to undo a merge, you can restore a previous version of the file from version history.
Even if you archive branches with unused designs, they'll still be associated with the main file. Archived branches can be viewed or restored at any time, making it easy to recover them if you need to revisit an idea. This saves you from having multiple pages in a file that are outdated, potentially causing confusion for others accessing the file.