4 ms·

OT: seconded. If anyone knows of a way to commit to a "staging" repository, then bundle my broken wip commits to the main repository, I'd love to know. I'd li

OT: seconded. If anyone knows of a way to commit to a "staging" repository, then bundle my broken wip commits to the main repository, I'd love to know. I'd like to keep the main repo clean with one commit per feature/bugfix, but still be able to commit regularly and walk back/bisect changes whilst working on the feature.

cheald 14y ago
You can do this with git and squashed commmits, but while it seems like a good idea, it's really not - when you're bug-hunting, smaller single-change commits make it far, far easier to track down and kill the bug. Having to crawl through a 3000-line squashed commit to find where a bug was introduced is awful. A better workflow is to use feature branches to work on a feature, when when you're done with it, rebase and merge it back to master and create a tag for the feature. This gives you an easy timeline of what features or fixes were introduced when, lets you commit often without breaking master, and doesn't destroy your valuable commit history.
- steeleduncan 14y ago
  Thank you. This looks like it will work well. The only problem is remembering not to push. It would be nice to be able to work with two repositories in parallel. One repository for my development and the other one the "official" repository with larger commits, better commit messages and the guarantee that all commits work.
  - cheald 14y ago
    You might be interested in git-flow[1] which is a formalization of this workflow. [1] http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flo...
- maw 14y ago
  when you're bug-hunting, smaller single-change commits make it far, far easier to track down and kill the bug. This is true, but with the caveat that each of those commits needs to basically work. If you have untestable commits, things work less well, and maybe it's worth having slightly larger commits so that they will be testable.

cheald 14y ago

You can do this with git and squashed commmits, but while it seems like a good idea, it's really not - when you're bug-hunting, smaller single-change commits make it far, far easier to track down and kill the bug. Having to crawl through a 3000-line squashed commit to find where a bug was introduced is awful. A better workflow is to use feature branches to work on a feature, when when you're done with it, rebase and merge it back to master and create a tag for the feature. This gives you an easy timeline of what features or fixes were introduced when, lets you commit often without breaking master, and doesn't destroy your valuable commit history.

steeleduncan 14y ago
Thank you. This looks like it will work well. The only problem is remembering not to push. It would be nice to be able to work with two repositories in parallel. One repository for my development and the other one the "official" repository with larger commits, better commit messages and the guarantee that all commits work.
- cheald 14y ago
  You might be interested in git-flow[1] which is a formalization of this workflow. [1] http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flo...
maw 14y ago
when you're bug-hunting, smaller single-change commits make it far, far easier to track down and kill the bug. This is true, but with the caveat that each of those commits needs to basically work. If you have untestable commits, things work less well, and maybe it's worth having slightly larger commits so that they will be testable.