Quản lý phiên bản là thứ cho phép nhiều người cùng sửa một dự án mà không đè lên nhau. Nhánh là một bản làm việc riêng của bạn, gộp là đưa thay đổi từ nhánh về chỗ chung, còn xung đột xảy ra khi hai người sửa cùng một chỗ theo hai cách khác nhau. Giữ nhánh ngắn ngày, gộp thường xuyên và làm thay đổi nhỏ là cách giảm xung đột hiệu quả nhất.
Chào bạn, đây là Nhà Lập Trình. Nhiều bạn mới đi làm sợ nhất không phải viết mã, mà là khoảnh khắc gộp mã và màn hình báo xung đột. Tập này mình kể quản lý phiên bản bằng hình ảnh con đường, không đọc lệnh nào, để bạn hiểu chuyện gì đang xảy ra và bớt sợ.
Vì sao cần quản lý phiên bản?
Hãy nhớ lại thời làm bài tập nhóm bằng một tệp văn bản gửi qua thư. Bản cuối, bản cuối thật, bản cuối thật sự đã sửa. Người này sửa bản này, người kia sửa bản kia, rồi không ai biết bản nào đúng, và thay đổi của ai đó bị mất.
Quản lý phiên bản giải quyết đúng vấn đề đó cho mã nguồn. Nó lưu lại mọi lần thay đổi, ai sửa, sửa gì, lúc nào. Bạn có thể quay lại bất kỳ phiên bản nào trong quá khứ. Và quan trọng nhất, nhiều người có thể làm việc song song rồi ghép lại.
Ngay cả khi làm một mình, quản lý phiên bản vẫn đáng dùng. Nó là nút hoàn tác khổng lồ cho cả dự án. Thử một hướng mới, không được, quay về. Không còn nỗi sợ sửa hỏng mà không quay lại được.
Gần như mọi đội phần mềm hiện nay đều dùng. Biết dùng nó là kỹ năng cơ bản như biết gõ bàn phím.
Nhánh: con đường riêng của bạn
Hãy hình dung dự án là một con đường chính. Mọi người đều đi trên đó. Khi bạn muốn làm một tính năng mới, bạn rẽ ra một nhánh đường riêng. Trên nhánh này, bạn sửa thoải mái mà không ảnh hưởng ai. Con đường chính vẫn chạy ổn định.
Trong lúc đó, đồng nghiệp của bạn cũng rẽ ra những nhánh riêng cho việc của họ. Mỗi người một nhánh, song song.
Khi xong việc, bạn đưa nhánh của mình nhập trở lại con đường chính. Đó là gộp. Những thay đổi trên nhánh của bạn giờ trở thành một phần của con đường chính, và mọi người đều thấy.
Phần lớn thời gian, việc gộp diễn ra tự động và êm ả. Hệ thống quản lý phiên bản rất giỏi ghép những thay đổi ở những chỗ khác nhau. Bạn sửa tệp này, đồng nghiệp sửa tệp kia, hoặc cùng tệp nhưng khác đoạn, gộp lại không có vấn đề gì.
Xung đột: khi hai người sửa cùng một chỗ
Xung đột xảy ra khi bạn và đồng nghiệp sửa đúng cùng một đoạn mã theo hai cách khác nhau. Bạn đổi giá trị mặc định thành mười, đồng nghiệp đổi thành hai mươi. Hệ thống không biết ai đúng, nên nó dừng lại và hỏi bạn.
Màn hình xung đột trông đáng sợ, với những dấu đánh dấu lạ chen giữa mã. Nhưng thực ra nó chỉ đang nói: ở đoạn này, bản của bạn là thế này, bản kia là thế kia, bạn chọn đi. Bạn có thể giữ bản của mình, giữ bản kia, hoặc kết hợp cả hai.
Điều quan trọng nhất khi giải quyết xung đột là hiểu ý định của cả hai phía. Đừng chỉ chọn bản của mình cho nhanh. Thay đổi của đồng nghiệp có lý do. Nếu không chắc, hỏi họ. Chọn sai có thể xoá mất một bản sửa lỗi quan trọng mà không ai biết.
Sau khi giải quyết, chạy thử lại. Hai thay đổi đúng riêng lẻ có thể sai khi đặt cạnh nhau.
Nhánh ngắn ngày ít xung đột
Nguyên nhân lớn nhất của xung đột khó chịu là nhánh sống quá lâu. Bạn rẽ nhánh, làm ba tuần, trong ba tuần đó con đường chính đã thay đổi rất nhiều. Khi gộp, có hàng chục xung đột, và mỗi cái đều khó hiểu vì bạn không theo kịp những gì đã xảy ra.
Cách giảm là giữ nhánh ngắn. Chia việc lớn thành phần nhỏ, mỗi phần vài ngày là gộp được. Nếu tính năng chưa xong mà cần gộp, có thể ẩn nó sau một công tắc cấu hình, mã đã vào con đường chính nhưng người dùng chưa thấy.
Nếu buộc phải làm nhánh dài, hãy thường xuyên kéo thay đổi từ con đường chính về nhánh của mình, mỗi ngày một lần chẳng hạn. Xung đột nhỏ giải quyết mỗi ngày dễ hơn nhiều so với một núi xung đột dồn vào cuối.
Lưu thay đổi thường xuyên, mỗi lần một ý nhỏ, kèm lời nhắn rõ ràng. Khi có xung đột, những lần lưu nhỏ giúp bạn hiểu từng bước đã thay đổi gì.
Vài thói quen giúp đội đi êm
Thống nhất một cách làm việc với nhánh cho cả đội. Nhánh đặt tên thế nào, gộp vào đâu, ai được gộp vào con đường chính, có cần xem lại mã trước khi gộp không. Không cần phức tạp, chỉ cần mọi người cùng hiểu.
Không sửa lại lịch sử của những nhánh đã chia sẻ với người khác. Hệ thống cho phép viết lại lịch sử, nhưng nếu đồng nghiệp đã dựa trên lịch sử cũ, bạn sẽ gây ra rắc rối lớn cho họ. Viết lại lịch sử chỉ nên làm trên nhánh riêng chưa ai dùng.
Không đưa lên kho mã những tệp không nên có: tệp cấu hình chứa mật khẩu, tệp tạm của trình soạn thảo, thư mục thư viện cài tự động. Dùng danh sách bỏ qua ngay từ đầu.
Và khi không chắc một lệnh sẽ làm gì, đặc biệt những lệnh có chữ ép buộc hay xoá, hãy dừng lại hỏi. Quản lý phiên bản gần như luôn cứu được mọi thứ, nhưng có vài lệnh có thể làm mất việc của người khác.
Câu hỏi thường gặp
Nhánh trong quản lý phiên bản là gì?
Là một bản làm việc riêng tách ra từ dự án chung, nơi bạn có thể sửa mà không ảnh hưởng người khác. Khi xong, bạn gộp thay đổi từ nhánh về dự án chung.
Xung đột khi gộp mã là gì?
Là khi hai người sửa cùng một đoạn mã theo hai cách khác nhau, hệ thống không tự quyết được nên dừng lại để bạn chọn giữ bản nào hoặc kết hợp.
Làm sao giảm xung đột khi làm việc nhóm?
Giữ nhánh ngắn ngày, chia việc nhỏ, gộp thường xuyên và kéo thay đổi từ nhánh chính về nhánh của mình mỗi ngày nếu nhánh phải sống lâu.
Giải quyết xung đột sai có sao không?
Có thể xoá mất thay đổi quan trọng của đồng nghiệp mà không ai biết. Hãy hiểu ý định của cả hai phía, hỏi khi không chắc và chạy thử lại sau khi giải quyết.
Làm một mình có cần quản lý phiên bản không?
Rất nên. Nó giúp bạn quay lại bất kỳ phiên bản nào, thử hướng mới mà không sợ hỏng, và có lịch sử để hiểu vì sao mã thay đổi.
