19

タイトルがそれを言っていると思います。私はソース管理に不慣れです。

たとえば、2人の開発者が同じプロジェクトで作業していて、同じファイルの編集を同時に開始した場合、全員がわずかに異なる時間に新しいバージョンを送信するとします。私が理解していることから、変更を最後に送信した人は変更を保持し、他の人のコードはアーカイブにのみ存在します!!!

あれは正しいですか？

どうか明らかにしてください。ありがとう。

4

2 に答える 2

40

いいえ、それは完全には正しくありません。使用しているバージョン管理ソフトウェアによって多少異なりますが、Gitが好きなので、それについて説明します。

ファイルFoo.javaがあるとします。

class Foo {
    public void printAWittyMessage() {
        // TODO: Be witty
    }
}

アリスとボブは両方ともファイルを変更します。アリスはこれを行います：

class Foo {
    public void printAWittyMessage() {
        System.out.println("Alice is the coolest");
    }
}

ボブはこれを行います：

class Foo {
    public void printAWittyMessage() {
        System.out.println("Alice is teh suk");
    }
}

アリスは最初に自分のバージョンをチェックします。ボブがチェックインしようとすると、Gitは競合があることを警告し、コミットをメインリポジトリにプッシュすることを許可しません。ボブはローカルリポジトリを更新し、競合を修正する必要があります。彼は次のようなものを手に入れます：

class Foo {
    public void printAWittyMessage() {
<<<<< HEAD:<some git nonsense>
        System.out.println("Alice is the coolest");
=====
        System.out.println("Alice is teh suk");
>>>>> blahdeblahdeblah:<some more git nonsense>
    }
}

<<<<<、=====および>>>>>マーカーは、どの行が同時に変更されたかを示します。ボブは、賢明な方法で競合を解決し、マーカーを削除して、結果をコミットする必要があります。

したがって、最終的にリポジトリに存在するのは次のとおりです。

元のバージョン->アリスのバージョン->ボブの競合修正バージョン。

要約すると、最初にコミットしたものは問題なく入り、2番目にコミットしたものはリポジトリに入る前に競合を解決する必要があります。誰かの変更が自動的に破壊されることは決してありません。明らかに、ボブは競合を誤って解決できますが、バージョン管理の利点は、誤った修正をロールバックして修復できることです。

于 2010-10-26T23:29:00.630 に答える
4

使用しているシステムによって大きく異なります。

ただし、一般的なケースは次のとおりです。2番目に変更をコミットする人は、「マージ」操作を実行する必要があります。つまり、2つのファイルを比較して、マージされたバージョンを考え出す必要があります。ただし、（！）多くの一般的なシステム（IDEを含む）には、それを支援するスマートツールが付属しています。

比較したそのようなツールは次のとおりです。http： //en.wikipedia.org/wiki/Comparison_of_file_comparison_tools

于 2010-10-26T23:29:20.507 に答える