Testing working state on different machine
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!
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.
Yes that is a good summary of my problem. In git I would have 3 ways of testing:
- Maintain my commits on fully separate branches, and test one by one on the test machine.
- If I was combining branches, I might squash multiple branches and create an integration branch by cherry-picking those commits
- 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.
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)?
Everything would be in git commits in my current workflow - lots of commits where the commit message is "wip" :)
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.
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.
Hi! Finally got back to this (to be honest I had some problems with GitButler so I stopped using for a while, but it seems like a recent update might have fixed my other problems, we shall see).
I actually don't think the worktree does what I need in this case - mainly, I don't think there's a way to push and pull changes to a worktree via github.
Just pulling the most recent gitbutler integration commit does seem to work though, but I could imagine this getting complex if multiple people on my team use GitButler, since if anyone else pushed to gitbutler/integration, it would overwrite my commit history on the origin. Please let me know if I'm mistaken in any of those assumptions. For now, checking out those integration commits will be my solution until there's a more native solution!
I think your assessment is correct: while gitbutler/integration is a requirement, worktrees aren't feasible as each of them naturally wants their own branch. From what I could gather, this is something that's being worked on, so I'd hope that soon any branch can be used with GitButler.
In such a world, each worktree could be added as its own project, but… worktrees aren't supported yet, which would certainly be a next step. Assuming worktrees are supported, you'd then probably be able to see, share and apply virtual branches in various worktrees, even though I am not sure about the details at all just yet.
I find this problem very valuable to think about as I have a feeling it could lead to improved handling of GitButler's data structures.