プロジェクトがソース管理に最初にコミットするのに十分であるかどうかはわかりません。プロジェクトが「フレームワーク完了」になるまでコミットを延期する傾向があり、それ以降は主に機能をコミットします。（これには大きすぎるコアフレームワークを持つほどの個人的なプロジェクトは行っていません。）これがベストプラクティスではないと感じていますが、何が間違っているのかわかりません。

たとえば、1つのコードファイルで構成されるプロジェクトがあるとします。約10行のボイラープレートコードと、プロジェクトを非常に基本的な機能（1つまたは2つの機能）で動作させるために100行かかります。最初にチェックインする必要があります：

1. 空のファイル？
2. 定型コード？
3. 最初の機能は？
4. 他のポイントで？

また、特定の時点でチェックインする理由は何ですか？

賢明な「ユニット」が完成したらすぐにコミットする必要があります。

ユニットとは何ですか？それはあなたが何をしているかに依存します。たとえば、Visual Studioプロジェクトを作成している場合、ソリューションが何も含まれていなくても、作成直後にソリューションをコミットします。

それ以降は、できるだけ頻繁にコミットを続けますが、完了した「ユニット」（クラス、構成など）のみをコミットします。そうすることで、何か問題が発生した場合にあなたの生活が楽になり（小さな変更セットを元に戻すことができます）、競合の可能性が減ります。

私の知る限り、ソース管理レポジトリは基本的なプロジェクト設定の一部ですので、空のプロジェクトを生成した直後にコミットします。

昨日

...代わりに、タイムトラベルできない場合...
（車が時速88マイルに到達できないか、フラックスコンデンサーがスナップしただけかもしれません）

いま

新しいプロジェクトは血まみれの場所でコミットする必要がありますが、そうではありません。現代のDVCSシステムgit init . ; git add * ; git commit -m initial-commitは、コミットを回避するためにすべての可能性のある言い訳を削除しました：今、すでに手遅れになる前に

もう1つの理にかなっている、議論の余地のある質問は、「確立されたプロジェクトのチーム管理リポジトリの共有ソース管理にコミットをマージするのはいつですか？」（形容詞に注意してください、形容詞は重要です）そして、私は他のほとんどの答えが実際にそれに答えようとしていると感じています。

あなたの個人的なブランチは、就寝前に、少なくとも1日 1 回、狂ったようにコミットする必要があります。翌朝、目を覚ますだけで、前夜、何をしていたのかわからないことがあります。VCSはそれに対してあなたをカバーするべきであり、うまくコンパイルし、スムーズに実行し、そして/またはテストに合格する非常に最近のサブバージョンのサブバージョンにロールバックする機会を持つことはあなたの最良の選択肢かもしれません。

私はできるだけ早くコミットすると言います。ソース管理の主な目的は、何か問題が発生した場合に戻ることができるようにすることであり、これは「早期かつ頻繁にコミットする」プラクティスに共鳴します。

個人的には、最初のコミットには通常、.gitignoreファイル（または同等のもの）のみが含まれ、Pythonコードの* .py [co]のように、必要なフィルタはほとんどありません。基本的なプロジェクトのセットアップおよび/または最初の最も単純なプロトタイプが通常続くものです。

最初のコミットは、プロジェクトの1行程度の要約を含むREADMEファイルか、プロジェクトの最初のマイルストーンに関する十分な情報です。幅広いトピックには次のものも含まれます。

• 前書き
• プロジェクトの説明
• プロジェクト構造
• コーディング規約
• 方法に関する指示：
  • 建てる
  • テスト
  • 配備する
• 既知の問題と回避策
• ToDoリスト
• 利用規約

プロジェクトに変更を加える前にREADMEを更新する方法は、Readmeドリブン開発とも呼ばれ、変更を行う前に変更を検討することができます。

このソフトウェアに貢献したい、または使用したい人は誰でもREADMEから始めます。

失いたくない作業を行った場合、それはソース管理システムにあるはずです。

これは確かにGitのような分散システムに当てはまります。集中システムを使用していて、何かをチェックインする唯一の方法が全員に見えるようにすることである場合は、控える必要があるかもしれません-または、独自のローカルgitリポジトリを設定し、集中システムに送信することを検討するかもしれません準備ができたらシステム。

私の経験則では、空のファイルがいくつか含まれている場合でも、ソリューションファイル（またはその他のビルドスクリプトの一部）が完了したらチェックインします。複数の人がプロジェクトに取り組んでいる場合に適しています。このファイルは、人々がプロジェクトに物事を追加しているため、最初は最悪のマージの問題が発生する傾向があります。

プロジェクトで作業しているのがあなただけで、ファイルが1つしかない場合でも、同じワークフローをたどって、問題に対する考え方を保存する方が簡単です。

ていないことを確認、それが言及された場合。

ただし、コミットしたものが実行/コンパイルされるようにしてください！したがって、構文エラーなどはありません。

壊れたコードをチェックアウトすることほどイライラすることはありません。

ソフトウェアテスト（TDDアプローチ）に関連する他の観点は、新しいテストケースが緑色になったらすぐにコミットすることです。これは、コードの新しい「ユニット」が完成したことを意味します。

愚かなことをする直前。

魔法の力を持たない私たちにとって、それはほとんどそしてしばしば意味します。

自分で作業している場合は、飲み物などを飲むたびにそれを行います。

チームで作業している場合は、おそらく他の誰かが最新になってもエラーが発生しないように、コンパイルする必要があります。しかし、それ以外は可能な限り。

プロジェクトに約2〜3時間かかります。

ほんの冗談ですよ。すべての状況に当てはまる良い答えはありません。まず、分散バージョン管理システム（gitやMercurialなど）を使用している場合、壊滅的な障害が発生した場合にローカルリポジトリにコミットしてもデータは保持されません。ただし、プライベートリモートレポジトリには、GitHubなどで費用がかかる場合があります。あなたはコミット履歴を保存しますが、私の経験では、プロジェクトが少し進歩するまで、それを必要としません。

また、特にファイルを移動している場合は、おそらく最初はあまり解約したくないでしょう。ほんの小さな変更であれば、変更をコミットすることは負担になります。あなたは物を捨てることを決めるかもしれません。ただし、複製するのが簡単ではない変更を失った場合、バックアップコピーを作成し損なうことになり、バージョン管理システムは非常に貴重なバックアップシステムになります。

最近では、DropBoxなどを使用してコードを保存する人もいます。セットアップに労力がかからないため、プロジェクトの開始時に適切な妥協案となる場合があります。ただし、特に複数の人が同時にコードに触れている場合は、深刻なソフトウェア開発では野barな習慣です。

そのため、価値のあるもの、つまり複製するのが簡単ではないものがあるときは常に、バージョン管理を設定する傾向があります。価値は主観的なものであり（能力に依存します）、自分で判断する必要があります。その時点で、2番目のリポジトリを外部ディスクに保存します。パブリックプロジェクトの場合はgithubに保存するか、支払いアカウントが保持します。

多くの人がすでに「すぐに」と答えており、私は100％同意します。また、XionのVCSの無視パターン（または同等のパターン）から始める提案も気に入ってい.gitignoreます。

早期コミットにマイナス面はないということは、ほぼ同意されていると思います。私は利点を追加したい：

• 破棄することを選択したものをコミットする可能性は低くなりますが、それはまだ残っています。新たな開発を始めるとき、私はすぐにコードやディスクラッドなものをコーディングし、後でコミットしたとき、すでにたくさんのファイルがあるとき、次のコミットで削除するためだけに誤ってのものをコミットしました。これは、小さなコミットまたは空のコミットとは対照的に、歴史の真のノイズです。
• あなたが体系的なタイプであり、プロジェクトに典型的な最初のステップがある場合、それらをコミットポイントとして持つことは、あなたや他の人にとって有益であり、特定のポイントで分岐して再利用可能なプロジェクトスタブを作成する機会さえ提供するかもしれません。私はこれが便利なMavenベースのプロジェクトに取り組んでいます（Mavenプロジェクトを設定する際に、いくつかの小さな最初のステップはすでにかなり重要なベースを定義することができますが、それらのステップは大したことではありませんが、保証するのに十分な思考が必要な場合があります再利用可能性）。

使用しているVCSによって異なります。

Gitでは、空のディレクトリ（またはほぼ空のREADMEファイル）をコミットします。ポイントは、開発プロセスの初期段階（アップストリームをプッシュする前）で完全にやり直したい場合は、ブランチを空の状態に戻すことができるということです。次に、「生成された」ファイル（例：Visual Studioソリューション）をコミットします。その後、実際にコーディングするときに、通常どおり各ユニットのコミットを開始します。

SVNを使用すると、コミットごとにアップストリームをプッシュするため、Gitのように最初からやり直す贅沢を得ることができません。この場合、プロセスの早い段階で大幅な改良を行うと思われる場合、早期にコミットすることは有益ではない場合があります。しかし、それはコーディングする人次第です。

新しいプロジェクトを開始するときは、通常、コードを追加する前にそれをコミットすることから始めます。私が常に守ってきた一般的な経験則は、PCがクラッシュしてすべてのデータを消去した場合、メモリから書き込む必要のないコードを選択することです。10年前、TDDとより良いプログラミングの練習の前に、私は自分が覚えていることについて非常に楽観的でした。今、私はより慎重になる傾向があります。他の多くのポスターが早くコミットし、頻繁にコミットすると述べているように。あなたはそれをすることで何も失いません。

私はほとんどの時間を独りで働いているので、たるんでいることを告白しなければなりませんが、家に帰る前に通常コミットします。そうすれば、明日も間に合わなければ、同僚は私が中断したところから再開できます。

現在、職場でTortoise / SVNを使用しています。

空のプロジェクトをすぐにコミットします。プロジェクトでの作業に費やす時間ごとに数回コミットしてください。コードがコンパイルされない場合でもコミットします。そのようなコミットを追跡するために、コミットマッサージで「WIP」でそのようなコミットをマークします。

また、手動でコミットするのを忘れた場合に備えて、10分ごとにすべてのプロジェクトをバックアップリポジトリに自動的にコミットするスクリプトもあります。それをクラウドでバックアップされたアンドゥバッファーと呼びましょう。

チームにコードを表示する必要がある場合は、プロジェクトをチームリポジトリにチェックイン（別名、プッシュ）します。あなたが私のようなものであれば、おそらくあなたのチームがあなたのコードを見る準備ができる前です。

チームに優しくしたい場合は、コミットをチームリポジトリにプッシュする前につぶしてください。

すべての記事を読み終えましたが、すでに多くの優れたソリューションが得られていると思いますが、私の方法論を皆さんと共有したいと思います。

フレームワークの作成に取り組んでいる間（最初から）、モジュールが完了するか完成するまで、各モジュールに対して多くの変更が行われます。だから私は常に2つの場所があり、1つはDYNAMIC、もう1つは静的です。変更が進行していて、フレームワークがまだ確定していない場合、動的な場所でコミットされ、完了して確定したら、静的な場所に移動します。したがって、完全なソース管理ができました。

ありがとう

どのアプリケーションでも、コンポーネントの設計に時間を費やすことになります。名前空間、プロジェクト、外部参照、サードパーティのライブラリなどを大まかにまたは完全に知っている必要があります。

チームに所属している場合は、ベースプロジェクトを作成し、依存関係セットを取得し、そのスケルトン（プロジェクトの基盤となる基盤）をチェックするために、リードまたは選択された人をお勧めします。

また、チェックインする前に、タスク、リリース、トランクなどのブランチが仕様に従っていることを確認して、プロセスが安定するようにします。

すでに進行中のプロジェクトの新しい「タスク」に取り組んでいて、自分のタスクブランチにいる場合は、毎晩チェックインを行い、作業を保存します。

通常、私は何か新しいものを追加するたびにチェックインしますが、個別のコミットで内容を分離しようとします。

つまり、新しい依存関係を追加する場合、コンパイルするか、最初からやり直すのに時間がかかるほど大きくなるまで、変更を加えます。より大きなタスクがある場合、理にかなっているときに複数回コミットしようとします（関数ごとに1回、コンパイルして正常に実行するたびなど）。

また、バックアップポイントが必要な場合（つまり、「今試してみたことがうまくいかない、または複雑になりすぎた場合、現在のコードに戻りたい」、または誰かが私をドロップするように求めたとき）緊急の問題を解決します）。

集中化されたソース管理システムを使用する場合、バックアップポイントに対して任意にコミットすることはできません。コンパイル/動作しないコミットはチームの全員に影響するためです。

通常、定型コードの追加を開始するとき（たとえば、django Webサイトに新しいwebappを追加するとき）、すべての操作をコミットします。

チュートリアルに従ってコードを生成/作成する場合、コミットメッセージのチュートリアルでステップ名を使用します。この方法で、リビジョンを比較し、後の時点でチュートリアルのステップが何をしたかを確認できます。

たとえば、1つのコードファイルで構成されるプロジェクトがあるとします。約10行のボイラープレートコードと、プロジェクトを非常に基本的な機能（1つまたは2つの機能）で動作させるために100行かかります。

ものを追加するのがどれほど難しいかによって異なります。

• ボイラープレートコードを追加するのが簡単な場合、他のコードを開始する直前に追加してコミットします（この方法で、ミスをしたり、奇妙なバグを後で導入した場合、ボイラープレートコードに戻って開始できます再び）。

• コードが自明ではない場合、何か新しいものを追加するたびにコミットします（コードの2行ごとに100ほど変更されます）。