0

私は複数のマシンで作業する傾向があるため、ある種のバージョン管理を維持し、複数のマシン間で作業を同期するために git を使用します。私は自分のコードに取り組んでいる唯一の人です。

基本的なことのほとんどは git で行うことができます。たとえば、ファイルを git チェックアウトして個々のファイルを以前の状態に戻し、git revert を使用して全体を返すことができます (その複雑さの一部をまだ完全には理解していないため、git revert を使用するのは怖いです)。以前の状態に投影します。また、特に方向がわからない場合は、git branch を使用してコードを別の方向にフォークすることもあります。

しかし、私の git に関する知識はやや乏しく、さらに作業を進めるにつれて、ソース ファイルを徐々に再保存し続ける傾向があります。たとえば、コードの作業中に 1...18 を経て、終了するまでに project18.c に取り組んでいる可能性があります。これは、ファイルの作業中に頻繁に git コミットを行うことに加えて、プロジェクトでの作業を「ダイヤルバック」する 2 つの方法があります。ただし、このインクリメンタル ファイル番号付けは、複数のファイルにまたがるコードではうまく機能しません。カプセル化して周囲の関数から内部実装を隠す自己完結型関数の作成に一生懸命取り組むことで、私の問題のいくつかに対するよりエレガントな解決策になると思います。

主要な新機能やコードの断片ごとに git コミットを実行するように勧められることがよくありますが、頻繁に git コミットを実行できなかった場合、バグのあるコードを手動で「取り消す」のに途方もない時間を費やしてしまうことがよくあります。コードを実装するその特定の方法を放棄しています。事前にコードをより適切に計画//設計することが役立つ場合があると思いますが、何が行き止まりのコードやバグのあるコードになるかを完全に予測するのは難しい場合がよくあります。

バージョン管理の実用的な戦略を探しています。これは、特にうまくいかないときに役立ち、問題のある部分のデバッグに役立ちます。

4

2 に答える 2

4

仕事の習慣に真剣に取り組んでいる場合 (たとえば、生活のためにコードを書きたい場合や、フリー ソフトウェア プロジェクトに貢献したい場合など)、頻繁にコミットすることに慣れるのが最善です。コミットにはまだいくつかのロジックが含まれている必要があります。記述したコードの 10 行ごとに個別のコミットを行うのは誤りです。小規模で論理的なコミットは、リグレッションが発生した場合にレビューまたはbisectするのに適しています。

多くのチェックポイントが必要な場合は、作業中の機能のテスト スイートに対して 1 つのコミットを作成し、テスト スイートの合格部分ごとに 1 つのコミットを作成することができます。またはそのようなもの、あなたの作業スタイルに応じて。(Git を使用すると、必要に応じて、変更を公開するときにいつでも履歴をクリーンアップできます。) それでも十分でない場合は、何か間違ったことをしています。

于 2012-10-15T08:20:37.463 に答える
2

問題の解決策は、次の 2 つの部分に分かれています。

コミットについて

コミットの背後にある考え方と、それが元々考えられていた方法をよりよく理解する必要があります。コミットは、理想的には、何かを行うコード (関数や一部のリファクタリングなど) と同じレベルである必要があります。したがって、頻繁にコミットする必要があり、そうしないと、コミットした場合に記録されていた進行状況に関する情報が失われます。git の仕組みをよりよく理解するには、 http: //git-scm.com/bookを読むことをお勧めします。

分岐の探索

同じプロジェクトで関連のないさまざまな機能に取り組んでいる場合、互いに関係のないコミットを連続して行うのは煩わしい場合があります。これは、さまざまなアイデアを互いに独立して (コード単位で) 同時に処理できる強力な機能です。分岐方法などの情報は、前のリンクにあります。また、複数の機能を備えた大規模なソフトウェアに特に役立つ git ブランチの操作モデルに関する記事もありますhttp://nvie.com/posts/a-successful-git-branching-model/

于 2012-10-15T08:26:15.450 に答える