Không, điều đó không hoàn toàn chính xác. Nó phụ thuộc phần nào vào phần mềm điều khiển phiên bản bạn đang sử dụng, nhưng tôi thích Git vì vậy tôi sẽ nói về điều đó.
Giả sử chúng ta có một Foo.java file:
class Foo {
public void printAWittyMessage() {
// TODO: Be witty
}
}
Alice và Bob cả sửa đổi các tập tin. Alice thực hiện điều này:
class Foo {
public void printAWittyMessage() {
System.out.println("Alice is the coolest");
}
}
và Bob thực hiện điều này:
class Foo {
public void printAWittyMessage() {
System.out.println("Alice is teh suk");
}
}
Alice kiểm tra phiên bản của cô trong lần đầu tiên. Khi Bob cố gắng kiểm tra anh ta, Git sẽ cảnh báo anh ta rằng có xung đột và sẽ không cho phép cam kết được đẩy vào kho lưu trữ chính. Bob phải cập nhật kho lưu trữ cục bộ của mình và khắc phục xung đột. Ông sẽ nhận được một cái gì đó như thế này:
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>
}
}
Các <<<<<
, =====
và >>>>>
dấu hiển thị mà dòng đã được thay đổi cùng một lúc. Bob phải giải quyết xung đột theo một số cách hợp lý, loại bỏ các điểm đánh dấu và cam kết kết quả.
Vì vậy, những gì cuối cùng tồn tại trong kho lưu trữ là:
Phiên bản gốc -> Phiên bản của Alice -> Phiên bản xung đột cố định của Bob.
Để tóm tắt: người đầu tiên cam kết tham gia mà không gặp bất kỳ vấn đề gì, người thứ hai cam kết phải giải quyết xung đột trước khi vào kho lưu trữ. Bạn không bao giờ nên kết thúc với những thay đổi của ai đó đang bị tự động ghi lại. Rõ ràng Bob có thể giải quyết cuộc xung đột không chính xác nhưng vẻ đẹp của kiểm soát phiên bản là bạn có thể khôi phục lại sửa chữa và sửa lỗi không chính xác.
Nguồn
2010-10-26 23:29:00
Bạn nói nó độc đáo! Claps :-) –