|
|
|
|
|
by mhh__
813 days ago
|
|
Github and gitlab are both deeply, fundamentally, flawed because the unit of contribution is the branch rather than the commit. Other than the UI not being very good, the code review experience is fundamentally hampered unless you enable squashing but that's a bit shit for different reasons. On a purely UX level too the velocity of getting patches in is terrible. They're designed for ad-hoc open source contribution, not tight-loops of consistent work. People put up with the slowness because they know no difference but I promise its slow. You shouldn't need to go and get a coffee to wait for something to get merged and start coding again. |
|
That's git main insight, branching is everywhere, so it is designed with branching and merging as fundamental, explicit, and regular operations. Seeing how successful git is, it looks like it was a good choice.
GitHub and GitLab are built on top of git, and follow its principles, so that making the branch the unit of contribution is simply natural.
Of course, you can make single commit branches, in fact, that's what squashing is for. There is, of course, no obligation to wait before you have your change merged before you start working again, you can start from an earlier version and rebase later, merge back some changes, or do whatever you want really. You can tight-loop as much as you want, especially on your local machine.