ソース管理への最初のコミットはいつ行うべきですか？
プロジェクトがいつソース管理に最初にコミットするのに十分であるかは、私には決してわかりません。私はプロジェクトが「フレームワーク完成」になるまでコミットを延期する傾向があり、その後は主に機能をコミットします。 （これにはコアフレームワークが大きすぎるほど大きな個人プロジェクトは行っていません。）これがベストプラクティスではないと感じていますが、何が問題になるのかはわかりません。
たとえば、1つのコードファイルで構成されるプロジェクトがあるとします。非常に基本的な機能（1つまたは2つの機能）でプロジェクトを機能させるには、約10行のボイラープレートコードと100行が必要です。最初にチェックインする必要があります：
- 空のファイル？
- ボイラープレートコード？
- 最初の機能は？
- 他の時点で？
また、特定の時点でチェックインする理由は何ですか？
実用的な「ユニット」が完成したらすぐにコミットする必要があります。
ユニットとは？それはあなたが何をしているかに依存します。たとえば、Visual Studioプロジェクトを作成している場合は、何も含まれていない場合でも、作成直後にソリューションをコミットします。
それ以降は、できるだけ頻繁にコミットし続けますが、それでも完了した「ユニット」（クラス、構成など）のみをコミットします。そうすることで、何か問題が発生した場合にあなたの人生を楽にし（小さな変更のセットを元に戻すことができます）、競合の可能性を減らします。
私に関する限り、ソース管理リポジトリは基本的なプロジェクトセットアップの一部なので、空のプロジェクトを生成した直後にコミットします。
昨日
...代わりに、タイムトラベルできない場合...
（たぶんあなたの車は88mphに到達できないか、フラックスコンデンサーがちょうどスナップした）
今
新しいプロジェクトは流血の場所でコミットされるべきであり、それはクレイジーではありません現在のDVCSシステムは、コミットを回避するためにすべての可能な言い訳を削除しただけです：git init . ; git add * ; git commit -m initial-commit今、手遅れになる前に、すでにそうかもしれません。
さらに賢明で議論の余地のある質問である可能性があります。「いつmergeコミットをsharedソース管理team managedリポジトリに確立されたプロジェクト？」 （形容詞、形容詞が重要であることに注意してください）そして、私は他のほとんどの答えが実際にそれに答えようとしていると感じています。
あなたの個人的なブランチはcrazyのように、少なくとも毎日1回に就寝前にコミットする必要があります。あなたは翌朝起きるだけで、前の夜に何をしていたのか見当がつかないかもしれません。 VCSはそれに対してあなたをカバーするべきであり、うまくコンパイルされ、スムーズに実行され、そして/またはテストに合格する非常に最新のサブバージョンのサブバージョンにロールバックする機会を持つことが最善のオプションかもしれません。
私はできるだけ早くコミットすると言います。ソース管理の主な目的は、何か問題が発生した場合に戻ることができるようにすることであり、これは「早い段階で頻繁にコミットする」慣行と共鳴します。
個人的に、私の最初のコミットには通常、。gitignoreファイル（または同等のもの）だけが含まれ、*。py [co]Pythonコード用。基本的なプロジェクトのセットアップおよび/または最初の最も単純なプロトタイプは、通常以下のとおりです。
最初のコミットは、READMEファイルで、プロジェクトの概要が1行だけの場合もあれば、プロジェクトの最初のマイルストーンに関する十分な情報が含まれる場合もあります。広範なトピックには、次のものも含まれます。
- 前書き
- プロジェクトの説明
- プロジェクトの構造
- コーディング規約
- 方法の説明：
- 建てる
- テスト
- 展開する
- 既知の問題と回避策
- tODOリスト
- 利用規約
プロジェクトに変更を加える前にREADMEを更新することは Readme Driven Development とも呼ばれ、作成に時間を費やす前に変更を検討することができますそれらの変更。
このソフトウェアに貢献または使用したい人は、READMEから始めます。
失いたくない作業を行った場合は、ソース管理システムにあるはずです。
これは確かにGitのような分散システムに当てはまります。集中型システムを使用していて、何かをチェックインする唯一の方法は、それをeveryoneから見えるようにすることです、あなたはmight保留したい-または独自のローカルgitリポジトリを設定し、準備ができたら中央システムに送信することを検討してください。
私の経験則では、空のファイルがいくつか含まれている場合でも、ソリューションファイル（または他のビルドスクリプト）が完了したらチェックインします。これは、複数の人がプロジェクトで作業している場合に適しています。人々がプロジェクトに何かを追加しているので、そのファイルは最初に最悪のマージ問題を抱える傾向があり、そのためニーズは早期にそして頻繁にコミットされます。
プロジェクトで作業しているのがあなただけで、ファイルが1つしかない場合でも、同じワークフローをたどって問題の考えを保存する方が簡単です。
言及されていても確かではありません。
しかし確認コミットしたものが実行/コンパイルされることを確認してください！したがって、構文エラーなどはありません。
壊れたコードをチェックアウトすることほど苛立たしいことはありません。
あなたが何かばかげたことをする直前。
魔法の力を持たない私たちにとって、それはほとんど意味がありません。
自分で作業している場合は、飲み物などを手に入れるたびに行ってください。
チームで作業している場合は、コンパイルが完了していることを確認する必要があります。そうすれば、誰かが最新になっても、エラーが発生することはありません。しかし、それ以外はできる限り。
ソフトウェアテスト（TDDアプローチ）にさらに関連する別の視点は、新しいテストケースが緑色になったらすぐにコミットされます。これは、新しい「ユニット」のコードが完成したことを意味します。
プロジェクト開始から約2〜3時間。
冗談ですよ。すべての状況に当てはまる良い答えは1つではありません。まず、分散バージョン管理システム（gitやMercurialなど）を使用している場合、ローカルリポジトリにコミットしても、致命的な障害が発生した場合にデータが保持されません。ただし、プライベートリモートリポジトリでは、費用がかかる場合があります。 githubで。あなたはコミット履歴を保存しますが、私の経験では、プロジェクトが少し進歩するまでそれを必要としないでしょう。
また、ファイルを移動する場合は特に、最初はあまりチャーンしたくないでしょう。変更をコミットすることは、小さな変更である場合には負担になります。物を捨てることもできます。しかし、複製するのが簡単ではない変更を失うと、バックアップコピーを作成し損なうことになり、バージョン管理システムは非常に貴重なバックアップシステムになります。
最近、DropBoxなどを使用してコードを保存している人もいます。設定に労力がかからないので、プロジェクトの最初は良い妥協かもしれません。ただし、特に複数の人が同時にコードに触れている場合は、深刻なソフトウェア開発では野蛮な習慣になります。
そのため、価値のあるもの、つまり複製するのが簡単ではない場合はいつでも、バージョン管理を設定する傾向があります。価値は主観的であり（自分の能力に依存します）、自分で判断する必要があります。その時点で、2番目のリポジトリを外部ディスクに保存します。パブリックプロジェクトの場合はgithubに保存するか、支払いアカウントに保存します。
多くの人がすでに「すぐに」と答えており、私は100％同意します。また、Xionの suggestion がVCSの無視パターン（つまり、.gitignoreまたは同等のもの）。
早い段階でコミットすることのマイナス面がないことは、ほぼ合意されていると思います。利点を追加したいと思います。
- 破棄することを選択したものをコミットする可能性は低くなりますが、それでもまだ残っています。新たな開発を始めるときは、コードを書いて、物事をひっくり返します。後でコミットしたとき、すでにたくさんのファイルがあるとき、次のコミットで削除するためだけに誤ってコミットしたことがあります。これは、小さい、または空のコミットとは対照的に、歴史の真のノイズです。
- あなたが体系的なタイプであり、プロジェクトに典型的な最初のステップがある場合、それらをコミットポイントとして持つことは、あなたや他の人に指示になる可能性があり、特定のポイントで分岐して再利用可能なプロジェクトスタブを作成する機会さえ提供するかもしれません。私はこれが便利なMavenベースのプロジェクトに取り組んできました（Mavenプロジェクトの設定では、いくつかの小さな最初のステップですでにかなりの基本を定義できますが、これらのステップはそれほど重要ではありません do、再利用性を保証するために十分な思考が必要になる場合があります。
新しいプロジェクトを始めるとき、私は通常、コードが追加される前にそれをコミットすることから始めます。私が常に従った経験則は次のとおりです。PCがクラッシュしてすべてのデータを消去した場合、メモリから書き込む必要のないコードはどれですか。 10年前、TDDとより良いプログラミングの実践の前に、私は覚えることについて非常に楽観的でした。今、私はより慎重になる傾向があります。他の多くのポスターが早期にコミットし、頻繁にコミットすると述べたように。あなたはそれをすることによって何も失うことはありません。
私はほとんどの時間自分で作業しているので、たるんでいることを告白しなければなりませんが、通常は家に帰る前にコミットします。そうすれば、明日に間に合わなければ、同僚が中断したところから再開できます。
現在、仕事でTortoise/SVNを使用しています。
コミットすぐに空のプロジェクト。プロジェクトの作業に費やす時間ごとに数回コミットし続けます。コードがコンパイルされない場合でもコミットします。コミットメッセージでそのようなコミットに「WIP」のマークを付けて、それらを追跡します。
また、手動でコミットするのを忘れた場合に備えて、すべてのプロジェクトを10分ごとにバックアップリポジトリに自動的にコミットするスクリプトもあります。それを私のクラウド対応の取り消しバッファーと呼びましょう。
チェックイン（別名。Push）チームにコードを表示させる必要がある場合は、プロジェクトをチームリポジトリに送信します。私のような人なら、おそらくあなたのコードがあなたのチームによって見られる準備ができる前です。
あなたのチームにとっていい人になりたいのであれば、squashあなたのコミットをチームリポジトリにプッシュする前にコミットしてください。
使用しているVCSによって異なる場合があります。
Gitを使用して、空のディレクトリ（またはほぼ空のREADMEファイル）をコミットします。ポイントは、完全に最初からやり直したい場合は、戻ってブランチをその空の状態にリセットできることです私はまだ開発プロセスの初期段階（上流にプッシュする前）です。次に、「生成された」ファイル（たとえば、ビジュアルスタジオソリューション）をコミットします。次に、実際にコーディングしているときに、通常どおりに各ユニットのコミットを開始します。
SVNを使用すると、コミットごとに上流にプッシュするため、Gitの場合のように最初からやり直すという贅沢を本当に得ることはありません。この場合、プロセスの早い段階で大幅な刷新を行うと考えている場合は、早期にコミットしてもメリットがない場合があります。それは、コーディングする人次第です。
私はすべての記事を読み終えましたが、良い解決策はすでにたくさんあると思いますが、私の方法論をあなたと共有したいと思います。
フレームワークの作成に取り組んでいる間（最初から）、モジュールが完成または完了するまで、モジュールごとに多くの変更が行われます。したがって、私は常に2つの場所を持ち、1つはDYNAMICとして、もう1つは静的です。変更が行われ、フレームワークがまだ確定されていない場合、それは動的な場所でコミットされ、完了して確定されたら、静的な場所に移動します。だから私は完全なソース管理を持っています。
ありがとう
通常、新しいものを追加するたびにチェックインしますが、個別のコミットでデータを分離しようとします。
つまり、新しい依存関係を追加する場合は、コンパイルするか、最初から再度実行する時間が失われるほど大きくなるまで、変更を加えます。より大きなタスクがある場合は、それが理にかなっているときに複数回コミットしようとします（関数ごとに1回、コンパイルして正常に実行させるたびなど）。
バックアップポイントが必要な場合もコミットします（つまり、「今行った作業がうまくいかなかったり、複雑になりすぎた場合は、現在のコードに戻りたい」、または誰かが私に削除を依頼した場合もコミットします。実行して、いくつかの緊急の問題を修正します）。
集中化されたソース管理システムを使用する場合、コンパイル/動作しないコミットはチームの全員に影響を与えるため、バックアップポイントに対して任意にコミットすることはできません。
通常、ボイラープレートコードの追加を開始すると（たとえば、Django Webサイトに新しいWebアプリケーションを追加））、実行するすべての操作をコミットします。
チュートリアルに従ってコードを生成/作成する場合、チュートリアルのコミットメッセージにはステップ名を使用します。このようにして、後でリビジョンを比較し、チュートリアルのステップが何をしたかを確認できます。
たとえば、1つのコードファイルで構成されるプロジェクトがあるとします。非常に基本的な機能（1つまたは2つの機能）でプロジェクトを機能させるには、約10行のボイラープレートコードと100行が必要です。
ものを追加するのがどれほど難しいかによって異なります。
ボイラープレートコードを追加するのが簡単であれば、他のコードを開始する直前に追加してコミットします（このようにして、後でミスをしたり、奇妙なバグを導入したりした場合は、ボイラープレートコードに戻って開始することができます再び）。
コードが重要なものである場合、新しいものを追加するたびに（コードの2行ごとのどこかが変更され、100行程度に）コミットします。
どのようなアプリケーションでも、コンポーネントの設計にある程度の時間を費やすことになります。大まかにまたは詳細に、名前空間、プロジェクト、外部参照、サードパーティライブラリなどを知っている必要があります。
チームに所属している場合は、ベースプロジェクトを作成し、依存関係セットを取得し、そのスケルトン（プロジェクトの基盤となるもの）を確認するために、リーダーまたは選ばれた人に提案することをお勧めします。
また、チェックインする前に、タスク、リリース、トランクなどのブランチが仕様に含まれていることを確認して、プロセスが確実になるようにします。
すでに進行中のプロジェクトの新しい「タスク」で作業していて、自分のタスクブランチにいる場合は、毎晩チェックインして作業を保持します。