Tôi đã sử dụng git được khoảng một năm và muốn sử dụng tính năng gắn thẻ để gắn thẻ cam kết ở các phiên bản khác nhau. Tôi đã tìm thấy rất nhiều thông tin về các lệnh để sử dụng để làm việc với các thẻ, nhưng điều tôi muốn biết là tại sao lại sử dụng tính năng gắn thẻ nếu tôi có thể tạo một nhánh mới được gọi 1.1.0và không phải làm rối trí toàn bộ. bộ lệnh git mới?
Có rất nhiều lý do chính đáng để gắn thẻ hơn là phân nhánh nhưng tôi muốn biết những lợi thế đó là gì.
Câu trả lời:
Các thẻ chủ yếu được sử dụng để tham chiếu trong tương lai đến phiên bản cụ thể của dự án, bằng cách gắn thẻ cam kết. Tất nhiên, bạn luôn có thể sử dụng các nhánh, nhưng nếu bạn thay đổi phiên bản nhiều, bạn sẽ có rất nhiều nhánh không sử dụng hoặc hiếm khi được sử dụng.
Thực tế, các thẻ dù sao cũng là các nhánh không có nhánh, chỉ thêm một cách để tham chiếu đến một phiên bản cụ thể của dự án để giảm độ phức tạp.
Chỉnh sửa: Đây là một cách hay để sử dụng git mà tôi sử dụng cho tất cả các dự án của mình.
Trong khi bạn có thể tạo một nhánh có tên là "1.0.0" - bạn hoặc bất kỳ ai có quyền cam kết, sau đó cũng có thể chỉ cần đẩy đến nhánh đó (có chủ ý hoặc không) và thay đổi ý nghĩa của 1.0.0.
Bạn không thể làm điều đó với một thẻ, một khi bạn tạo một thẻ - vậy là xong; Thẻ 1.0.0 có nghĩa là chính xác và không thể thay đổi * .
Đó là sự khác biệt thực tế chính giữa thẻ và nhánh
* Bạn có thể xóa và tạo lại thẻ do đó thay đổi thẻ, nhưng chắc chắn không phải ngẫu nhiên.
Tôi có xu hướng sử dụng quy trình làm việc kết hợp cả thẻ và nhánh. Thẻ rất tốt để đánh dấu mã đã phát hành hoặc các bản dựng phát triển đáng chú ý. Các nhánh rất tốt để theo dõi tất cả các thay đổi liên quan đến một phiên bản cụ thể.
Đây là một bản viết tốt về loại quy trình công việc này: http://nvie.com/posts/a-successful-git-branching-model/
Nhánh và thẻ giống nhau (con trỏ đến một cam kết, hay còn gọi là. "Ref" ), ngoại trừ nhánh tự động chuyển sang cam kết tiếp theo trong khi thẻ vẫn mãi mãi là 1 trên cùng một cam kết.
Khi tạo bản phát hành, bạn thường muốn đánh dấu "ảnh chụp nhanh" của mã mà từ đó bản phát hành đó được tạo và bạn muốn nó luôn được đánh dấu theo cách đó ngay cả khi bạn tiếp tục phát triển mã, vì vậy bạn sẽ sử dụng thẻ.
Nếu bạn đã thử sử dụng một nhánh cho điều đó, nó có thể vô tình chuyển sang một cam kết khác, từ đó bản phát hành không được xây dựng.
1 Tất nhiên trừ khi bạn xóa thẻ.
LƯU Ý: Tôi nhận ra đây là một câu hỏi cũ, nhưng tôi cảm thấy rằng sự giống nhau (và một điểm khác biệt quan trọng) giữa các nhánh và thẻ đã không được thể hiện trong các câu trả lời khác rõ ràng như nó có thể.
git commitcập nhật phần đầu của nhánh đã kiểm tra để tham chiếu đến cam kết mới, có, nhưng không có nhánh nào khác “tự động” chuyển sang cam kết tiếp theo. Bạn nên làm rõ đoạn đầu tiên của câu trả lời của bạn.
.git\refs\heads, chứa băm của cam kết. Bản thân họ không "nhớ" nhánh nào đã tạo ra chúng. Điều này khác với Mercurial, ví dụ, ở đó thông tin chi nhánh có thể được ghi vào siêu dữ liệu của cam kết.
Bạn sử dụng thẻ để ghi chú các cam kết quan trọng trong lịch sử. "Đây là cam kết chính xác mà chúng tôi đã sử dụng cho phiên bản này vào ngày mưa thứ năm khi máy chủ bản dựng bị hỏng". Nếu bạn sử dụng một nhánh thay vì một thẻ, bạn không bao giờ có thể biết chính xác bạn đã sử dụng cam kết nào. Bạn chỉ biết "Chúng tôi đã phát hành phiên bản 1.1.0 ở đâu đó trên chi nhánh này", trừ khi bạn viết thủ công mã băm chính xác cho cam kết đó, đó là lý do tại sao bạn sử dụng thẻ ngay từ đầu :)
Ngoài các câu trả lời khác, đây là 2 xu của tôi.
Câu trả lời ngắn gọn: Sử dụng thẻ cho các phiên bản phát hành
Câu trả lời dài: Tôi tin rằng việc sử dụng các thẻ để lập phiên bản phát hành cụ thể sẽ tốt hơn so với việc sử dụng các nhánh. Nếu bạn cần cập nhật relase, chỉ cần tách nhánh của cam kết được gắn thẻ và khi bạn hoàn thành công việc trên nhánh đó (rất có thể là nhánh hotfix), hãy tạo một thẻ mới ở đầu nhánh mới đó với phiên bản mới. Sau đó, hợp nhất nhánh đó lại thành master / development vì bạn thực sự không nên thay đổi phiên bản phát hành trừ khi đó là một hotfix có khả năng được hợp nhất lại vào mã nguồn của bạn. Sau đó xóa nhánh đó vì nó không còn cần thiết nữa. Nếu bạn cần áp dụng một hotfix khác cho phiên bản mới đó, hãy lặp lại các bước tương tự.
Tham khảo phần của bài viết sau hướng dẫn cách hợp nhất một hotfix với quy trình làm việc Git của tác giả - https://hackernoon.com/a-branching-and-releasing-strategy-that-fits-github-flow-be1b6c48eca2