>I usually work on problems that requires a lot of thought, a lot of back and forth between solutions, a lot of a reach this state where stuff kinda work but it is not what I need yet and I am not sure it is gonna be in the final version.
How do you manage this without source control? The back and forth? Trying an experiment and then throw it away? Sounds like the perfect use case for private branches.
>I must say that in smaller and simpler codebase than the one I usually work with it might be possible.
On the other hand, if I'm working a large and complicated changeset I don't know how I'd keep the WIP organized if I couldn't use source control privately in the process of iterating on that changeset.
Doing the work in a private branch means I can frequently rebase on master so merging at the end is a cakewalk, I can also switch back to master to start a new branch to work on something else.
>reach the final version and I commit all together
>Do you guys come back and fix everything after?
I make incremental commits on a private branch as I'm working. As I go it might not look like much more than an "undo" history, maybe a few abandoned branches. When I want to merge I'll do an interactive rebase. Reorder the commits to group similar work, in their implementation dependency order, then squash them into a set of logical commits and write some decent commit messages. It doesn't take too long, I do it as part of reviewing my code changes before sending them to the whole team. For example, my backburner task right now has 78 commits made over ~2 weeks, and will be squashed to about ~4 commits when I'm ready to merge.
How do you manage this without source control? The back and forth? Trying an experiment and then throw it away? Sounds like the perfect use case for private branches.
>I must say that in smaller and simpler codebase than the one I usually work with it might be possible.
On the other hand, if I'm working a large and complicated changeset I don't know how I'd keep the WIP organized if I couldn't use source control privately in the process of iterating on that changeset.
Doing the work in a private branch means I can frequently rebase on master so merging at the end is a cakewalk, I can also switch back to master to start a new branch to work on something else.
>reach the final version and I commit all together >Do you guys come back and fix everything after?
I make incremental commits on a private branch as I'm working. As I go it might not look like much more than an "undo" history, maybe a few abandoned branches. When I want to merge I'll do an interactive rebase. Reorder the commits to group similar work, in their implementation dependency order, then squash them into a set of logical commits and write some decent commit messages. It doesn't take too long, I do it as part of reviewing my code changes before sending them to the whole team. For example, my backburner task right now has 78 commits made over ~2 weeks, and will be squashed to about ~4 commits when I'm ready to merge.
My style is loosely based on the kernel patch series guidelines, https://www.kernel.org/doc/html/v4.17/process/submitting-pat...