How are people using branching in practice?

Branching Questions
1

Hi all. I excitedly upgraded to an Organization even though our team only has two members specifically because I assumed branching would solve our file organization problems. Upon playing with it, I’m realizing the paradigm doesn’t (at least at first glance) leave room for iteration/experimentation.

Example: Say I want to branch an existing page in the app to add some functionality. Ideally, I’d like to create a branch, come up with a few different concepts (including prototypes), arrive at the best one, then merge it specifically back into the main file. At that point, I’d like the original file to represent only the chosen changes, but I’d also like all of my iterations to exist somewhere where I can go back and pull from them for future work.

I naively assumed this was how branching would work, but it appears you can only merge back in your entire branch, leaving you with a few options:

  1. Keep all iterations/concepts/experiments of all time in a single file, which may get bloated and hard to find.
  2. Create a new file for iteration and experimentation, then go back to the main file and only create a branch once you know exactly what changes you want to make. This maintains the current problem of significant overhead if you want to maintain a main/master spec.
  3. Delete all of your non-chosen work before merging a branch back to main.

I’m hoping I can understand how this feature was designed to be used so we can adjust accordingly. Has anybody found a model that works well?

1 Like
2

We use number three. We are working with feature branches and once they are approved they are merged to main. if we need to revisit we can inspect the branch version history and copy from there to a new branch.

with that said, we are also waiting eagerly for the possibility to do partial merges and keeping branches open post-merge to allow more flexible workflows.

3 Likes