I work in a way similar to the author, treating my micro commits like a videogame quick save. But many videogames separate "quick save" and "real save" in the UI and so do I.
I have a local branch, usually just called "wip" for work-in-progress and commit to it frequently. Then when I want to push to origin I pull all the contents from that branch into my "real branch" and commit it as one commit. Then delete the wip branch and repeat.
If I'm working on multiple tasks at once as my distracted brain loves to do, I'll have several wip branches. wip-new-hook-events, wip-update-sdk-version, wip-refactor-button-state. Sometimes the branches conflict with eachother, but dealing with that is worth being able to drop a task for a few days while I'm stumped or blocked. I also don't tend to micro commit when tests pass, just whenever I feel a smaller idea is either done, or I don't know how to progress yet.
Rebase works if you're comfortable with it, but it would make working on multiple tasks at the same time a bit harder wouldn't it? I'll be honest I'm not great with rebase.
If you do 'git checkout wip .' it pulls in all the changes committed to your wip branch into the staging area of your current branch. Then you can just 'git commit -m "My meaningful commit message."'
That's the cool thing about git though, it has a lot of compatible workflows so you can do what's most comfortable personally.
I consider myself a git noob, but I do find myself using rebase several times weekly. It seems to get easier the more I use it, along with all other git tactics.
Why bundle all changes into a single commit? How can the commit message be meaningful at that point? Why not just submit multiple atomic commits?
Sometimes I do that if it makes sense, but usually in that case those would be new wip branches with my workflow. If I'm at the point where my changes make for a good single atomic commit, they're ready to be committed to the main branch and the existing wip branch deleted.
If I'm working on really small tasks where I know I'll be done quickly and won't need to look back at my earlier changes, I don't bother making a wip branch.
Any chance you still have the link to the micro-commits post you mentioned below? Even better, do you have a post on your blog describing your workflow? I'd love to read a concrete example and apply it in my daily work.
I picked up the process when I first read a blog post about micro commits and wanted to try it but my company standards didn't allow tons of commits to clog the history like that. It feels like the best of both worlds to me.
I'll also add that sometimes I do break them into a few commits on "real branch" if it makes more sense to do so, and I use a GUI tool for merging if I need to solve conflicts. I also don't really worry about commit messages being useful in the wip branches. Oftentimes the commit message is just "wip".
Luckily my company doesn't have much prescription about commit process, so its up to each team to determine what works for them and we've been pushing for small atomic commits (probably what you'd term micro-commits).
The idea is that each commit should be small enough to fit in one "page" of PR review, with source lines and test line diffs <150 each, and everything should be one integrated and independent change with unit tests all passing and deployable to prod, etc. Honestly, I can't see a downside to this, other than maybe taking a while to internalize this process and to properly decompose commits.
Have you considered advocating for a change of company standards? Sometimes thats a sisyphean task, but if the only argument against it is "that's how it's always been done" it might be a worthwhile endeavor.
I think the difference in my case is an atomic commit works in isolation and pass tests. The micro commits don't always do that. That's where I differ from the article author in my workflow.
I have a "micro commit" sitting in a branch right now that's just a single line change, for example. That's not super common, but I don't have any strict rules for myself about when to or not to quicksave.
> Have you considered advocating for a change of company standards?
Oh trust me I did. I'm at a better job now :p My current company's git policy sounds identical to yours. But I still like this workflow for myself.
I've always disliked when code review tools are prescriptive about my commit history (i.e. prefer that each successive patch to a given CR needs to still just be a single commit rather than a separate commit per patch), and I ended up writing a shell function that just wraps whatever command I need to use to submit a CR that first swaps to a branch called `xxx-temp-xxx`, then does an interactive rebase (in which I squash all the commits I've made into one), then invokes the CR command, and finally swaps back and deletes the `xxx-temp-xxx` branch. This was made easier when I found out about `git checkout -`, which switches back to whatever you just swapped from last (like `cd -`).
I have a local branch, usually just called "wip" for work-in-progress and commit to it frequently. Then when I want to push to origin I pull all the contents from that branch into my "real branch" and commit it as one commit. Then delete the wip branch and repeat.
If I'm working on multiple tasks at once as my distracted brain loves to do, I'll have several wip branches. wip-new-hook-events, wip-update-sdk-version, wip-refactor-button-state. Sometimes the branches conflict with eachother, but dealing with that is worth being able to drop a task for a few days while I'm stumped or blocked. I also don't tend to micro commit when tests pass, just whenever I feel a smaller idea is either done, or I don't know how to progress yet.