TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: How to commit properly when starting out a project?

4 点作者 m712超过 5 年前
When I am just starting out a new project, usually I work on multiple things at once, like (in a web project) the routes, authentication, database models, etc. etc. So usually during the first few days of a project I don't commit at all and just keep adding new code. The result is that when I do commit 5 days down the line it's just a single "Bring the project up-to-date" commit that just pushes everything at once. What is the best practice for committing when just starting out a project? What do you recommend?

5 条评论

caspg超过 5 年前
A few times, I did what you described. I was working and experimenting for couple of days and after I was satisfied I &quot;brought project up-to-date&quot;. But this caused me headaches a few times. It&#x27;s hard to revert certain changes, hard to understand what was going on a couple of days ago.<p>Right now, I wouldn&#x27;t work for 5 days without a single commit. Those &quot;best practices&quot; were invented to address concrete problems.<p>My advice is not to worry about commit history when you are starting. But definitely try to commit as often as possible. Group changes in logical chunks. Try to use meaningful commit titles and messages.
seanwilson超过 5 年前
When starting from nothing, usually I commit broken code with blank messages to a develop branch, then squash all the commits into master with a better description latter.<p>Not committing anything and losing it all by accident because you&#x27;re obsessing about micro-commits and a clean history that nobody is ever going to read is a much worse alternative.<p>Small commits and good descriptions become useful once you have some foundation that&#x27;s not in a high state of flux and you need to track what change broke something. You don&#x27;t need this at the draft stage.
adamzapasnik超过 5 年前
Imo focus on code instead of commit history. I almost run into the same trap myself couple of times. Code history and quality! at the beginning hardly matters. At the beginning you don&#x27;t need to follow any process, because there is nothing to base that process on (no code).<p>Just ship the code, your time matters more than a few fancy commit messages.
fasouto超过 5 年前
I like to commit small parts of code separately, but to be honest when you are starting a project and you are working alone I don&#x27;t think is that important.
forgotmypw1超过 5 年前
start with readme. one commit per logical set of changes. just like later.