Other commenters have mentioned interactive and patch staging. That is the standard way to ensure that only the lines you specify go into a commit. I want to add an alternative method that offers some extra advantages.
Patch stack management tools like stacked-git and topgit allow you to setup a number of patches (using git). You can then specify which patch each change goes into. This is sort of like having multiple staging area/indexes at your disposal. They also allow you to add commit messages to each patch at any stage of the development. You could also add, delete, split, squash or edit each patch at any time. And these patches are converted to regular commits at the end of development of the feature. You can also convert any commits into patches if you ever need it.
The attraction that I see in this workflow is that it allows you to combine the chaotic development workflow and final rebasing step into a single stage.
The ad is about a git tool (hiflux) that happens to be written in Rust. That is perfectly relevant in this context. Rust is also a good language to write such tools (as is Go). I understand why Rust evangelism can be a bit tiring. But the opposition to it shouldn't try to imitate the same quality.
The perfect commit is useful only when you're ready to publish. Development can be chaotic with all the half-done or possibly-wrong code. You don't need to worry about all those standards while you're still developing. The perfect commit is then crafted out of the chaotic development branch by editing the history. I keep the original development branch alive for reference, while the crafted commit is submitted to the maintainer.
Patch stack management tools like stacked-git and topgit allow you to setup a number of patches (using git). You can then specify which patch each change goes into. This is sort of like having multiple staging area/indexes at your disposal. They also allow you to add commit messages to each patch at any stage of the development. You could also add, delete, split, squash or edit each patch at any time. And these patches are converted to regular commits at the end of development of the feature. You can also convert any commits into patches if you ever need it.
The attraction that I see in this workflow is that it allows you to combine the chaotic development workflow and final rebasing step into a single stage.