New ask Hacker News story: Group changes into commits and rebase to build a better Git history
Group changes into commits and rebase to build a better Git history
3 by your_challenger | 0 comments on Hacker News.
You can read the markdown version [here](https://ift.tt/3fbLPFH) ## Problem statement We all have worked on a feature intensively and had to refractor a lot of the code base (in early projects). But can't spend the mental expense to context switch from `writing code` to `make meaningful commit messages`. A good commit history is at the expense of the developer, which results in breaking the "flow". As pg mentioned in his blog post [Holding a program in one's head][1], it be better to work in long stretches to have better developer productivity. And it is very common for devs to have to make code cleanups which are unrelated to the feature they are working on ([example tweet][2]) * Commit small and commit often * Writing good git commit messages goes a long way * get gud at git ## Scenario Lets say you are building a feature and mid way you came across a variable name that could be fixed. Or a piece of code that is no longer needed. But you don't want to include this unrelated changes in your working commit. So for good practice you need to create a new commit for those changes. ## Current solution 1. git-worktree We can currently use [git-worktree](https://ift.tt/1MTM1X7) to create a parellel repo in your local directory and make the changes in that, push a commit, pull the changes in the feature working tree and continue. *This is long and hard* 2. stash and make changes Make a stash of the current feature changes and then make the required changes, commit and pop the stash. *So bad my eyes are bleeding* 3. Make the changes in the current working tree and use `git add -p` to make patches when creating a commit This is what works the best. But the flaw of this approach is that it looses the essense of story-telling, You may make changes that don't show a history, instead shows a bunch of unrelated changes on top of each other. ## The solution If we could `patch` changes into `commit groups` and then finally commit those changes when all the related changes are ready, it will let the developer write code in a long stretch [1] and also build a story for the commit history. ### Why commit groups? We can currently create patches. But using this new feature we can add patches into groups as we read the code to make patches. We will have *more than one stages files* "area". [1]: https://ift.tt/10iIPeF [2]: https://twitter.com/awesomekling/status/1390950309669781505?s=20
3 by your_challenger | 0 comments on Hacker News.
You can read the markdown version [here](https://ift.tt/3fbLPFH) ## Problem statement We all have worked on a feature intensively and had to refractor a lot of the code base (in early projects). But can't spend the mental expense to context switch from `writing code` to `make meaningful commit messages`. A good commit history is at the expense of the developer, which results in breaking the "flow". As pg mentioned in his blog post [Holding a program in one's head][1], it be better to work in long stretches to have better developer productivity. And it is very common for devs to have to make code cleanups which are unrelated to the feature they are working on ([example tweet][2]) * Commit small and commit often * Writing good git commit messages goes a long way * get gud at git ## Scenario Lets say you are building a feature and mid way you came across a variable name that could be fixed. Or a piece of code that is no longer needed. But you don't want to include this unrelated changes in your working commit. So for good practice you need to create a new commit for those changes. ## Current solution 1. git-worktree We can currently use [git-worktree](https://ift.tt/1MTM1X7) to create a parellel repo in your local directory and make the changes in that, push a commit, pull the changes in the feature working tree and continue. *This is long and hard* 2. stash and make changes Make a stash of the current feature changes and then make the required changes, commit and pop the stash. *So bad my eyes are bleeding* 3. Make the changes in the current working tree and use `git add -p` to make patches when creating a commit This is what works the best. But the flaw of this approach is that it looses the essense of story-telling, You may make changes that don't show a history, instead shows a bunch of unrelated changes on top of each other. ## The solution If we could `patch` changes into `commit groups` and then finally commit those changes when all the related changes are ready, it will let the developer write code in a long stretch [1] and also build a story for the commit history. ### Why commit groups? We can currently create patches. But using this new feature we can add patches into groups as we read the code to make patches. We will have *more than one stages files* "area". [1]: https://ift.tt/10iIPeF [2]: https://twitter.com/awesomekling/status/1390950309669781505?s=20
Comments
Post a Comment