3

私は現在、会議のポスドクと共同で論文を書いています。バージョン管理ソフトウェアを使用して調査したところ、git が有力な候補であると思われました。今、私たちはそれを実際に体験する必要があり、いくつかの問題に直面しています. 具体的には、プッシュする前に同じファイルを編集することがあり、2番目にプッシュしたい人にエラーが発生する.

この同時編集を防ぐために使用できるヒント/ツール/などは何ですか? これらの問題に直面していない多くの共同作業者がいる大きなプロジェクトにgitが使用されていることは知っていますが、何が間違っているのでしょうか?

何か案は？

4

3 に答える 3

1

Gitには、TFSのようにファイルを「ロック」するメカニズムがありません。2人がファイルの同じ部分をアクティブに編集している場合は、競合が発生する可能性があります。

主なもの：

あなたがしていることについて同僚と話してください。可能であれば調整し、必要に応じて警告します。これは一種の歩行者のようですが、通常は本来よりも遅く発生します。 スクラムはあなたのルーチンの一部になるので素晴らしいです。

最大の要因は、変更を自分自身にどれだけ長く保持するかです。未解決の変更が長ければ長いほど、変更セットが重複する可能性が高くなります。

一緒に作業している機能に統合ブランチを作成するのは良いことです。チェックポイントを作成し、プッシュし、リベースを頻繁に行うと、修正が難しい大きな変更を加える可能性が低くなります。ただし、小さな競合は非常に簡単に処理できます。マスターにプッシュする前に、戻ってコミットの一部をクリーンアップする必要があるかもしれませんが、それは通常、調整するのに十分簡単です。

ささいなこと：

差分を調べることは、コードの一部がどのように変更されたかを理解するための素晴らしいツールです。異なるフォーマット設定間を移動する人々は、このツールを壊します。

一貫性のある形式を持つことは、これらの取るに足らない競合に役立ちます。一貫したフォーマットを選択するプロセスは別の問題です。;）

関数で作業していて、空白が正しくないことに気付いた場合は、それを修正します。同じ機能に取り組んでいる他の誰かが同じことをします。

たとえば、左インデント：

namespace foo {
namespace bar {

    class Foo {
    public:
        void something();
    };

    class Foo {
        public:
            void something();
    };

}}

namespace foo {
    namespace bar {
    }
}

私は個人的に、最初のセットのようにすべての名前空間を左揃えにすることを好みます。これにより、空白のノイズが最小限に抑えられます。ただし、一貫性は重要です。

タブとスペースは別のものです。理論的には、どちらを選択するかは問題ではありませんが、どちらかを選択してください。

コードの移動は避けてください（明らかに正当な理由がない場合）。これを行うのは難しいですが、各ファイルに含まれるものが少ないファイルが多い場合、これはそれほど問題にはなりません。

小さな「ハウスキーピング」の変更は、機能/バグ修正のコミットとは別にしてください。これにより、これらのコミットの変更をマージするのが非常に簡単になります。1つが機能の変更で、もう1つが空白の変更である場合、機能の変更を盲目的に行うことができます。

于 2012-10-11T22:05:42.287 に答える
1

実際、コードではなく論文を書いているので、git は完璧なツールではないかもしれません。Google ドキュメントなどを使用すると、パートナーが行った変更をほぼリアルタイムで確認できます。また、コミット/プッシュ/マージを行う必要はありません。

于 2013-11-20T16:10:57.603 に答える
0

「ロック」はある意味自動です。あなたはあなた自身のコピーを持っており、彼らはあなたからそれを奪うことはできません! 彼らがコピーを持っているのと同じように、それを奪うことはできません。これは、git DVCS の分散型の性質を使用していることを前提としています(ファイル共有にアクセスするのではなく :-( それぞれが独自のクローンを持ち、ブランチを交換するか、共通のベア リポジトリにプッシュします。

次のステップは、使用するドキュメント プロセッサが git マージに適していることを確認することです。理想的には、Latex やマークダウンなどのプレーン テキスト ソースです。Git は喜んであなたの別々の貢献をマージし、競合をハイライトします。ただし、非常に長い行は使用しないでください。

共同作業をしている場合は、マージの競合が発生する共通領域について話し合い、最適な文言に同意することができます。

両方を並行して作業する自由をお楽しみください。

于 2012-10-11T23:08:00.627 に答える