ソロ開発者に最適なバージョン管理習慣ですか？

私は自分の仕事で唯一の開発者であり、VCSの利点を理解しています。良い習慣に固執するのは難しいと思います。現時点では、主にWebアプリを開発するためにgitを使用しています（私の仕事のためにオープンソース化されることはありません）。

私の現在のワークフローは、開発サイトに多くの変更を加え、テストし、修正し、テストし、満足して変更をコミットしてから、コミットをライブサイトにプッシュします（したがって、大きな新しい変更に取り組んでいる場合、週に1回コミットしますが、私のIDEにはコミットされていないものの良い取り消し履歴があります）。

基本的に、マシンを切り替えるときにだけgitを使用します（たとえば、devコンピューターを自宅のdevコンピューターに移動するか、ライブコンピューターに移動します）が、日中は実際には利点がありません。これにより、変更の長いランドリーリストが作成されます（また、コミットごとに適切なメッセージを見つけるのに苦労しています。急いでいるときはいつでも、「管理者とテンプレートのその他の変更」などのくだらないメッセージを残す傾向があります）。

どのくらいの頻度でコミットする必要がありますか？1行の変更ごとにコミットを取得する必要がありますか？テストの前にコミットする必要があります（たとえば、少なくとも構文/コンパイルエラーのためにコミットしてから、完全に元に戻す必要があります。アイデアが機能しなかった、またはメッセージが嘘であるため）。

まだ新鮮なうちに夕食の仕事をやめる前に、毎朝/午後に必ずコミットする必要がありますか？悪いVCS習慣を持つことで私が見逃しているものは何ですか？

あなたはたくさん不足しています。

ある意味、私もソロです。重大な変更を行うたびに、または重大な変更を開始する前にコミットします。本当に毎日ではなく、近い。時々1日に数回。

私が得たのは、いつでも戻ることができるということです。それはたくさんです。また、ブランチを順序付けることは役立ちます。

私はそれが私に多くの秩序を与えると思います。

私はsvnを使用していますが、うんざりしています。しかし、他のことを学ぶことにもっと時間を費やすことはできません。

がんばろう。

頻繁にコミットする必要があります。論理的なマイルストーンに到達したら、必ずコミットする必要があります。1日以上かかる場合は、少なくとも作業日の終わりにコミットするか、さらに良いことに、作業を小さなチャンクに分割する必要があります。

それには多くの理由があります。たとえば、コンピューターがクラッシュした場合はどうなりますか？1週間または1か月よりも、1日分の仕事だけを失う方がはるかに優れています。もう1つの理由は、頻繁にコミットすることで、バグの特定が容易になることです。バイナリ検索を実行して、バグの原因となった小さな変更を把握できます。

もう1つ：コミットする前に、diffを実行し、行ったすべての変更を確認する必要があります。これにより、すべての変更が意味をなし、何も忘れていないことを確認できます。これは、より良いコミットメッセージを思い付くのにも役立ちます。そしてもちろん、これは頻繁にコミットするもう1つの理由です。1か月分の変更よりも1日分の変更を行う方がはるかに簡単です。

CVSを最大限に活用するには、一度に1つの機能/バグ修正に取り組み、その機能/バグ修正が完了したらコミットする必要があります。これにより、次のことが得られます。

• コミットメッセージは作成しやすく、より意味があります。
• 将来のバグを、それらを導入した変更に簡単に追跡し直します。
• 簡単に以前の状態に戻すことができます（それは失敗した機能を失うことを意味しますが、その後に発生したバグ修正を保持することを意味します）。

また、PCを切り替えるため、少なくとも2つのブランチが必要です。

• 常に機能する「準備完了」ブランチ（もちろん、開発ブランチで作業しているバグを除く）
• 時々実行できない状態になる可能性のある開発ブランチ（職場から家に帰るときなど）。

1行の変更ごとにコミットを取得する必要がありますか？

それがバグを修正するものである場合、確かに。

悪いVCS習慣を持つことで私が見逃しているものは何ですか？

「悪いVCS習慣」を持っていた人と仕事をしました。彼は一人で仕事をするのが大好きで、年間1,000,000ドルのような製品をもたらす製品ラインを担当していました。彼は上司が彼にうなずいたときにのみコミットします。それからある日、彼のハードドライブがクラッシュしました。彼に代わって交換品を準備してから、彼の最後のチェックインは6か月前であることがわかりました。VCSはソースセーフであったため、他に何が間違っていたかを推測できます。最後のコミットが破損していました。彼の製品ラインの破損していないバージョンを入手するには、1年以上前に戻る必要がありました。彼は解雇されるべきだったにもかかわらず、解雇されなかった。

別の逸話は自分自身に関係しています。以前は、趣味や研究プロジェクトのコードをリムーバブルハードドライブに保存していました。ある日、私のアパートは壊れました。ラップトップ（壊れていた）とすべてのリムーバブルハードドライブが盗まれました。すべてのDVD（Red Dawnを除く）が盗まれました。デスクトップコンピューターは盗まれませんでした。オフサイトのソース管理があれば、特に一部のプロジェクトは学術プロジェクトに基づいていたため、15年分のプロジェクトを失うことはありませんでした。回復できないコードを失った。

どのくらいの頻度でコミットする必要がありますか？

私はそれをいくつかの測定基準に分けます：

• コンピューターが死んだ場合、どれだけの労力を失いますか？または盗まれますか？

• これでBug_1234が修正される場合は、「fixes Bug_1234」というコメントを付けてコードをチェックインします。

• これが論理的な配信/マイルストーンである場合は、「Bug_1234、form_xyz」（または必要に応じてTask_1234）などのコメントを付けてチェックインします。

• 金曜日の夜、家に帰る前に必ずコードをチェックインしてください。また、休暇を離れる前に、すべてのチェックイン（またはチェックアウトの取り消し）を行います。

• 会社のポリシーが指示するときはいつでも。

行の変更数に関しては考えないでください。機能のチャンクで考える。VCSを使用すると、各機能チャンクの中央に見出しを付けることができるため、gitログなどで「ここで何が起こったのか」を簡単に確認できます。

また、EclipseのようなIDEを使用すると、特定の行をポイントして、それを表示された形にしたコミットに移動できます。つまり、ソース行から直接コミットに行くことができます。コミットが小さく、良いメッセージがある場合、「修正された大量のバグ」よりもはるかに役立ちます。

このように変更をグループ化することで見逃している最大のことは、バグがいつどこで導入されたかを追跡できることです。

私の経験では、バグが導入されてから2〜3週間後にいくつかのバグに気付くことが何度かありましたが、事実から1週間分のコミットをふるいにかけることは困難です。これらのケースでは、コミットを単純にバイナリ検索して、どの個々の変更が問題を引き起こしたかを追跡することが役に立ちました。これらのバグは主にC ++コードのメモリ使用量のバグであったため、プロジェクトではそれほど頻繁には発生しない可能性があります。

チームで開発する場合、その他の利点があります-単純なコミットコメント、簡単なマージ、バグ修正へのコミットの関連付けなど。

毎日または半日ごとにコミットを開始する場合は、タグまたはブックマークを使用して、ライブサイトで使用されているコードのバージョンを追跡する必要があると思います。それが最も重要なことだと思います。

私もソロ開発者です。SVNを使用していますが、大好きです。データベースの構造とデータベース内のテストデータをxmlに変換して、ソース管理に含めることができるツールを作成しました。

私は通常、自律的な作業単位を完了するたびにコミットします。時々、些細で無関係な単一行の修正をあちこちで実行すると、それらすべてを一緒にコミットしますが、2つの無関係な大きな自律的な作業単位間で単一行の修正が発生した場合、それはそれ自体を取得しますコミット、それは何も悪いことはありません。

また、私は常にコンパイルするコードをコミットし、ほとんどの場合、すべての基本的なテストにも合格するコードをコミットします。そうでない場合は、コミットメッセージに「機能しない」を含めるようにします。これが発生する唯一のケースは、まだ十分に機能していなくても失いたくない重要な変更を行ったときであり、これに加えて、私は確信していない素晴らしいリファクタリングの冒険に着手しようとしています成功します。そこで、リポジトリを台無しにして捨てなければならない前に、これまでに行った作業のバックアップとしてリポジトリを使用します。

これは、ソースコードをコミットする必要がある場合は常にコミットすることを意味します。朝のコミットまたは夕方のコミットルールを持つことはまったく意味がありません。コミットするかどうかを決定するのはコードの状態です。

リポジトリに入れるメッセージは重要ではありません。何か意味のあるものを思い付かない場合は、必要なときにコミットしないよりも、空白のメッセージでコミットすることをお勧めします。

あなたが思い付くすべてのものが馬鹿げているので良いコミットメッセージを考えることができないなら、これは大丈夫であることを心に留めておいてください。コミットメッセージは明白なことを述べることが期待されるので、あなたがそれらを書いているとき、それらはあなたに愚かに聞こえるに違いない。しかし、私を信じてください。もしあなたが一ヶ月後に古いリビジョンを調べる必要があるなら、あなたはメッセージがない以上に愚かなメッセージでさえ感謝するでしょう。

「論理」変更を行うたびにコミットします。たとえば、新しい機能を実装する場合は、段階的に実行します。通常、これらの各ステップは互いに依存しています。したがって、これらのステップを個別にコミットし、コミットメッセージで各ステップが必要な理由を説明できます。

コミットメッセージは本当に重要です。あなたは言って避けなければならないものを教えて、あなたがやっているなぜあなたはそれをやっています。コードにはすでに変更が文書化されていますが、6か月後にはなぜ変更を行ったのかがわかります。

これは、偶然誰かが飛び込んで、もう一人ではない場合にも便利です。あなただけの場合でも、クリーンな履歴を使用すると、a git blameを使用して、バグのある行がいつ、なぜ変更されたかを簡単に知ることができます。

大きな泥の変化の代わりに小さなコミットを行うことで、中間状態をテストすることもできます。緊急に何かをリリースする必要がある場合は、変更を隠しておくことができます。以前に機能していたバグを導入した場合、バグを導入するのはコミットされていない変更であるか、古いコミットであったかを隠して確認できます。

またgit bissect、その厄介なバグというコミットを伝えることの力を解き放つことができます。コミットの長さが2,000行の場合、それでも役立ちますが、それほどではありません...

もう1つは、継続的インテグレーション（CI）、そして継続的デプロイメント（CD）の最初のステップであることです。CIとテストは新しいコミットでトリガーされるため、変更が何かを壊すかどうかをプッシュするたびに通知されます。これにより、展開するのが安全かどうかを知ることができ、急いでいるリリースの直前ではなく、問題が導入された瞬間に通知を受けることができます。

他の質問について：

• （を使用してgit rebase --interactive）履歴を書き直そうとしない限り、コンパイルさえしなかったものをコミットしないでください。
• 1行の変更は、別の目的がある場合（バグを修正するか、現在コミットされていない変更とは無関係）、コミットに値します。git add --patchそれらをステージングするために使用します。
• 失う余裕のない重要なものがない限り、夕食前に自分でコミットする必要はありません。その場合、進行中の作業を別のブランチでコミットすることができます。
• リモートリポジトリへのコミットとプッシュはバックアップです。コミットしてプッシュするのが週に1回だけの場合、最悪の場合、1週間の仕事を失う可能性があります。

どのくらいの頻度でコミットする必要がありますか？

ソロ開発者として、基本的なテストの後、そして夜の終わりにプロジェクトを離れるときに、大きな変更を加えたと感じるたびにコミットします。

1行の変更ごとにコミットを取得する必要がありますか？

いいえ、1行の変更で機能またはバグが大幅に変更される場合を除きます。

テストの前にコミットする必要があります（たとえば、少なくとも構文/コンパイルエラーのためにコミットしてから、完全に元に戻す必要があります。アイデアが機能しなかった、またはメッセージが嘘であるため）。

おそらくない。少なくとも私にとっては、テストとコーディングのほとんどを「作業コピー」で行い、変更に満足したらコミットします。多くのIDEでは、実際にコミットする前に何が変わったかを示し、コミットにメモを添付する機会を与えてくれます

まだ新鮮なうちに夕食の仕事をやめる前に、毎朝/午後に必ずコミットする必要がありますか？悪いVCS習慣を持つことで私が見逃しているものは何ですか？

VCSやそれが引き起こす悪い習慣についてはあまり詳しくありません。私は、最初の質問に対する答えとして、これに関する私の意見をほとんど共有したと思います。

想定されている一般的な質問への回答として、あなたは主に別のレスポンダーの投稿で対処されているブランチとしてコミットを使用しているようです。取り消し履歴などの良いIDEを使用しているかどうかはわかりませんが、IDEを再起動してマシン間を移動する以外に良いと思うものは見つかりませんでした。

私は常習的なコミッターであり、それが私に合っていることを発見しましたが、確かに私のコミットメッセージはほとんどいつものように、

Age:  9 mins [*] Working on implementing and testing PaintSystem.
Age: 17 mins [*] Working on implementing and testing PaintSystem.
Age: 37 mins [*] Working on implementing and testing PaintSystem.
Age: 52 mins [*] Working on implementing and testing PaintSystem.

したがって、私のブランチ（mercurial）にこのような頻繁で習慣的なコミットを行ったことで、最も詳細なコミットログが正確に推奨されたとは言えません。たとえば、妻が夕食に出かけるように頼んだら、途中でコードをコミットすることもあります。その時点で、前の「Working on [...]」コミットメッセージを急いでコピーして使用します。

私のコミットログパターンは通常、次のようなものです。 "Working on [...] Working on [...] Working [...] Completed [...] Started working on [...] Working on [...] Completed [...] Started working on [...]"

逆に言えば、それは私の尻を救った。予期せずにテストしなかったエッジケースに遭遇することもありますが、この時点で頻繁にコミットすることで、間違いをどこで引き起こしたかを正確に把握できます。

そのため、私は最良の習慣については知りませんし、理想的なコミットロギングの習慣については耳を傾ける人ではありませんが、より頻繁にコミットすることは、回帰を実行する必要がある場合に確実に役立つと言うことができます。

1行の変更ごとにコミットを取得する必要がありますか？

私は以前に1行の変更をコミットしましたが、通常は注意が必要な変更であり、時間が足りなかったのかもしれません。私のコミットは、常に完全で完全な作業単位や変更に似ているとは限りません。言ったように、時々彼らは私の妻が予期せず夕食に出かけるように頼んだ結果です。

TBHその"Working on [...]"ログパターンに従う私のコミットの多くは、一貫した変化の単位をモデリングしていません（なぜ私はしばしばより良いメッセージを思い付かないことができます"Working on [...]"）が、私が一杯のコーヒーを作るような息抜きをしただけの結果です。この"Completed [...]"メッセージは、その作業単位の終了を示しています。そこで"Started working on [...]"、何か作業を始めたばかりのときに、最初のタイプのメッセージとともに、より詳細なメッセージを書くことがよくあります。15分ごとに1回のようにコミットを平均すると、「Working on [...]」メッセージは、誰かがより詳細なメッセージを含む1つのより大きなコミットでコミットする可能性のある中間者に似ています。

テストの前にコミットする必要があります（たとえば、少なくとも構文/コンパイルエラーのためにコミットしてから、完全に元に戻す必要があります。アイデアが機能しなかった、またはメッセージが嘘であるため）。

時々テストを実行する前に、先に進んでコミットします（予期しないイベントがあった場合）。また、私は一人ですが、CIを実行するサーバー（ここではLAN上で自宅で実行されているサーバーのみ）にプッシュします。それはやり過ぎのように思えるかもしれませんが、私は以前の職場でそれに頼るのに慣れました。さらに、毎回、すべてのユニットテストと統合テストを手作業で実行する必要はありません。私はそれをすべて押すだけに結びつけているのが好きです。テストが失敗した場合、リグレッションを行い、最新のリビジョンの間違いを修正し、先へ進むことで前進する方法で作業するのは十分簡単です。ただし、コミットする前に、少なくともデバッグビルドに対してコードをビルドします。

まだ新鮮なうちに夕食の仕事をやめる前に、毎朝/午後に必ずコミットする必要がありますか？

私は外出する前にコミットし、プログラミングを中断するのが好きです。この質問に出くわすまで、私は実際にその理由をあまり考えませんでした。コミットログなしで中断した場所をピックアップするのを防ぐために、中断した場所の代わりに、diffなどを実行できるようにします。うーん、コミットする頻度を考えると理論的には必要ないかもしれないので、それについてお話しする必要があります。なんらかの理由でコンピュータを離れる前に、私はまだコミットとプッシュをより快適に感じています。その一部は、たとえば、SVNを使用していた数週間、SVNを使用していたときにプロジェクトマネージャーが戻ってきた後、コンピューターが火事になりました。私たちのコードは会社の財産です。また、特にプッシュを使用すると、CIプロセスがすべてのテストの実行を開始できるようになり、離れたときに戻って結果を確認できるようになります。

ああ、時々私は去った後少し酔ってしまいますが、通常は酔っている間に複雑なコードを書くのは悪い考えです（いつもではありませんが、酔っている間にユーレカの瞬間を過ごした後、本当に素晴らしいコンテキストメニューシステムを思いついたとき、しかし、ビールは6本しかなく、コーディングはそれほど複雑ではありませんでした）。それをしようとすると、酔っ払ったコードと落ち着いたコードを混ぜるのではなく、戻る前に落ち着いて書かれたコードをコミットしました。その時点でコミットログは次のようになりますが、"Reverting back to code written before Jagermeister shots."私はこれをしません酔っ払ったコードのインスピレーションを得ない限り、非常に頻繁に、しかしそれらのまれなケースでは、私が出かけて酔っ払う前に何かをコミットすることは本当に助けになりました。