Testing working state on different machine

[dchaniel]

Apologies if this is in the instructions somewhere, I did not find it offhand.

I work on hardware (robots) and a frequent workflow I do is to checkout my branch on a shared robot machine to test on the robot. At the moment, I don't see a way to test my entire working state (it's often more efficient for me to test a few different changes at once) and was wondering if there is a feature or workflow that would support this. If not, consider this a feature request. Thank you!

[Byron]

Thanks for sharing! Let me repeat the feature back to you so you can make corrections, just in case.

There is two machines, one machine to write code on, and the other to test it on. In GitButler, Virtual Branches are used to turn on and off different parts of the code, which affects the working tree on the dev machine. There should be some mechanism to mirror that working tree ono the test-machine.

If the above is close, could you share how you did that previously by means of Git commands? Thanks for helping me to understand this better.

[dchaniel]

Yes that is a good summary of my problem. In git I would have 3 ways of testing:

1. Maintain my commits on fully separate branches, and test one by one on the test machine.
2. If I was combining branches, I might squash multiple branches and create an integration branch by cherry-picking those commits
3. I could also rebase one branch onto the other and use the branch with both changes as the test branch. This got unwieldy because of rebase conflicts ect.

Gitbutler is a huge win for local development because it makes it way easier to separate my PRs into more granular and reviewable chunks, but it makes it more laborious to do the testing because there's not an easy way for me to test a set of changes together. Thanks for taking the time to better understand the workflow. And let me know if you have any ideas for doing this with existing gitbutler tools.

[Byron]

Thanks for elaborating! I can visualize the workflow (even) better now :).

How are you sharing what's in your worktree with the test machines? And are you leaving some changes uncommitted (I am trying to gauge if everything is in Git commits, or if there are changed files in the worktree)?

[dchaniel]

Everything would be in git commits in my current workflow - lots of commits where the commit message is "wip" :)

[Byron]

Thanks :)!

To recap:

Gitbutler is a huge win for local development because it makes it way easier to separate my PRs into more granular and reviewable chunks, but it makes it more laborious to do the testing because there's not an easy way for me to test a set of changes together. Thanks for taking the time to better understand the workflow. And let me know if you have any ideas for doing this with existing gitbutler tools.

Would Git worktrees be an option for you? Given a local state that was created with GitButler, the main working tree should be at a particular state and without any uncommitted modifications. From there, you can create a worktree whose branch points to the current commit, with the worktree checked out in another location, one that could be accessible on the remote machine.

This can be repeated, i.e. change the configuration of virtual-branches, and create a git worktree checkout at that commit.

This works based on the knowledge that the GitButler integration branch reflects whatever is configured in a particular instant, and even though it changes a lot, one will be able to create 'snapshots' using worktrees without problems.

At least, that's the theory.

[dchaniel]

Interesting idea, I'll try that, thanks! I hadn't worked with worktrees before, seems promising for this use case. Will let you know if there's any nuances this doesn't cover.