4 ms·

I am struggling to appreciate how this is _not_ a completely flawed workflow. Are many teams doing this? What is the workflow like that benefits from this? What

by Jenk 3y ago

I am struggling to appreciate how this is _not_ a completely flawed workflow. Are many teams doing this? What is the workflow like that benefits from this? What's the "shit not _that_ branch":commit ratio?

corytheboyd 3y ago
Personally this sounds completely reasonable to me (especially with lazygit) > You can stash everything, create a new branch, switch to it, fix the bug, commit and push it, then switch back to what you were working on. Also comfortable with fixing the bug on my current branch, leaving it there to validate as I complete the other stuff, then later pull commits out to new branches to create atomic PRs. Assuming the bug can wait that is, otherwise yep off to a new branch, and no amount of git magic prevents an interruption from being disruptive. I know worktrees are a thing but I feel like the branching model is enough complexity to both be useful and remember. No problem if people want to use a more complex workflow with a GUI, this is for them, not for me.
dogleash 3y ago
What part exactly? The worktrees? If you're just talking worktrees, the benefit is what it says on the tin, multiple parallel working directories. They're a nice to have, not world-changing or anything. The example in the article is contrived to sell a separate kind of workflow tool in the product he's building. I don't use worktrees like that. My use case is heretical software development, but sometimes I work with projects that take a long time to build. And even longer to test. Worktrees let me minimize the amount of rebuilding when switching branches, or kick off a full test run and go work in another branch.
neandrake 3y ago
We’re not yet using git, but we have one repository with multiple branches, one for each released version (on-prem software, not a service run). We are in regular active development of ~3 branches at a time. Most developers dealing with this will have multiple clones checked out rather than switch branches in the same clone. The reason for doing so is we often make significant project structural changes in each release, and the act of switching branches updating thousands of files and lots of structural changes often causes most IDEs to combust. Pointing the IDE to a different cloned workspace works much more smoothly. After switching to git I anticipate it will include our own guides for using worktrees for such a purpose.
numbsafari 3y ago
Another way to look at this, is that a working copy is a projection of the state of a repository at a particular commit. If you are working on or with a tool that utilizes the repository contents to drive it, then you can expose multiple instances or versions of the tool from those projections, while leveraging a shared content cache and upstream configuration. For example, let's say you are working on a static site (this is just an example). You can have a web server running that is serving the main worktree from https://mysite.local/ https://mysite.local/, and any worktrees from https://mysite.local/~[worktree]/ https://mysite.local/~[worktree]/. Then, if you want to make a particular branch available for someone to review in their browser to provide feedback, you can direct them to the worktree URL while you continue doing other work either in your main branch, or on other branches altogether.

by Jenk 3y ago

corytheboyd 3y ago

Personally this sounds completely reasonable to me (especially with lazygit) > You can stash everything, create a new branch, switch to it, fix the bug, commit and push it, then switch back to what you were working on. Also comfortable with fixing the bug on my current branch, leaving it there to validate as I complete the other stuff, then later pull commits out to new branches to create atomic PRs. Assuming the bug can wait that is, otherwise yep off to a new branch, and no amount of git magic prevents an interruption from being disruptive. I know worktrees are a thing but I feel like the branching model is enough complexity to both be useful and remember. No problem if people want to use a more complex workflow with a GUI, this is for them, not for me.

dogleash 3y ago

What part exactly? The worktrees? If you're just talking worktrees, the benefit is what it says on the tin, multiple parallel working directories. They're a nice to have, not world-changing or anything. The example in the article is contrived to sell a separate kind of workflow tool in the product he's building. I don't use worktrees like that. My use case is heretical software development, but sometimes I work with projects that take a long time to build. And even longer to test. Worktrees let me minimize the amount of rebuilding when switching branches, or kick off a full test run and go work in another branch.

neandrake 3y ago

We’re not yet using git, but we have one repository with multiple branches, one for each released version (on-prem software, not a service run). We are in regular active development of ~3 branches at a time. Most developers dealing with this will have multiple clones checked out rather than switch branches in the same clone. The reason for doing so is we often make significant project structural changes in each release, and the act of switching branches updating thousands of files and lots of structural changes often causes most IDEs to combust. Pointing the IDE to a different cloned workspace works much more smoothly. After switching to git I anticipate it will include our own guides for using worktrees for such a purpose.

numbsafari 3y ago

Another way to look at this, is that a working copy is a projection of the state of a repository at a particular commit. If you are working on or with a tool that utilizes the repository contents to drive it, then you can expose multiple instances or versions of the tool from those projections, while leveraging a shared content cache and upstream configuration. For example, let's say you are working on a static site (this is just an example). You can have a web server running that is serving the main worktree from https://mysite.local/ https://mysite.local/, and any worktrees from https://mysite.local/~[worktree]/ https://mysite.local/~[worktree]/. Then, if you want to make a particular branch available for someone to review in their browser to provide feedback, you can direct them to the worktree URL while you continue doing other work either in your main branch, or on other branches altogether.