4 ms·
Ask HN: Why do we have to comment each commit?
Hi,
I've been thinking of ways to improve developers workflow and it appears that we, software developers, are the only one who still have to manually save (commit) our work every x minutes. All other industries have systems with live collaboration and saves (Google docs...)
Furthermore we can empirically see that commenting each commit is not easy / carefully respected.
The important thing is that for me, merge requests are a better concept to describe a single, atomic, conceptual change rather than commits, which are often used as a mean to save work, because we, as developers don't have other ways to save work!
Do you see limitations to a New Generation Version Control with live updates and the only comments you have to make are to create a merge (pull) request ?
The workflow would be:
You connect to server (repo), then each file modification is automatically sent to server (and broadcasted to other users who have the file open).
We keep the branches systems and then atomic merges (and comments) are only made on a merge (pull) request.
- Memosyne 8y agoI think what your suggesting is similar to Memo[1] which is being developed at Github. 1 - https://github.com/atom/xray/tree/master/memo_core https://github.com/atom/xray/tree/master/memo_core
- z0mbie42 8y agoThanks, I wasn't aware, I'll explore this project!
- towaway1138 8y agoThere's nothing wrong with producing a series of personal commits with little or no comment, and then squashing them into fewer or a single commit before merging. But it's very important that the final product have a good comment. What was changed and why? We need to know.
- z0mbie42 8y agoIn my proposition, the flow: 1. commit 2. squash commits to a meaningful commit 3. merge would become: 1. code 2. merge with a meaningful commit
- brucedawson 8y agoThat is basically how Chromium's development workflow goes. Instead of 'merge' we have 'git cl upload' (and subsequent code review and eventual committing/merging). All of your local commits and revisions are landed as a single squished commit in the main repo.
- towaway1138 8y agoInteresting. In general this seems good, but sometimes I really do want my final submission not to be squished, e.g., because it consists of several distinct stages and is easier to understand that way.
- z0mbie42 8y agoVery interesting, I'll explore this workflow
- rcfox 8y agoYou could pretty much get that workflow by putting your repo in a Dropbox folder, just no live collaboration. Good luck compiling at any given moment when 10 other people are changing files under you though!
- z0mbie42 8y agoUsing dropbox looks like a dirty workaround (why designers would use sketch + dropbox instead of Figma ?) But you raise a very interesting point concerning compilation
- Artemix 8y agoBut what if you need to find a specific change that happened during an entire development day?
- fulafel 8y agoYour merge centric workflow is perfectly good and valid. But i think a commit message is still good to capture what's going on in your mind when you checkpoint. Don't listen to people telling you to squash, either. Git will bite you in the ass when you inevitably mix rewritten branches with non-rewritten ones, it's error prone. And rewriting loses history.