Trong Git, các chi nhánh địa phương có thể theo dõi nhau - điều này hữu ích như thế nào?

Question

Tôi nghe nói rằng trong Git, bạn có thể để một theo dõi một số local branch B khác.

Tại sao một người nào đó muốn làm điều đó?

Answer 1

Một ví dụ tôi có thể nghĩ là nếu bạn có nhánh 'ổn định'. Sau đó, nó sẽ được tốt đẹp nếu bạn có thể làm cho một chi nhánh mới, 'thí nghiệm' ví dụ, và để cho nó theo dõi các chi nhánh ổn định.

git checkout --track -b experiment stable 
* do some experiments with some commits * 
git push 

Khác với khả năng nhất quán (đó chỉ là phỏng đoán).

Answer 2

Những điều chính cần lưu ý khi có chi nhánh địa phương theo dõi một chi nhánh địa phương khác là (1) thông báo đầy đủ hơn từ Git về chi nhánh phía trước/phía sau nhánh được theo dõi và (2) móc kích hoạt.

Một khu vực Git hiển thị thêm thông tin là khi tạo chi nhánh. Tạo một basic branch trông giống như sau:

$ git co -b A master 
Switched to a new branch 'A' 

Trong khi tạo một tracking branch trông giống như:

$ git co --track -b B master 
Branch B set up to track local branch master. 
Switched to a new branch 'B' 

này sẽ thêm vào sau .git/config:

[branch "B"] 
    remote = . 
    merge = refs/heads/master 

Sau khi cam kết một số thay đổi về chi nhánh A và B, thực hiện git status -s -b trên chi nhánh A hiển thị ## A khi chi nhánh B hiển thị ## B...master [ahead 1, behind 1], cung cấp một số thông tin nhanh về mối quan hệ giữa các chi nhánh B và master.

Khu vực khác nơi bạn có thể muốn chi nhánh địa phương theo dõi một chi nhánh địa phương khác là kích hoạt hooks; cụ thể là pre-receive, update, post-receive và post-update trong một git push. Ví dụ: bạn có thể có móc để kích hoạt bản dựng trên máy chủ tích hợp liên tục, thực hiện kiểm tra tiêu đề giấy phép, kiểm tra lỗi định dạng không gian trắng, v.v.

Answer 3

Lưu ý rằng thông tin trước/sau mà bạn có giữa một chi nhánh 'B' và một 'A' được theo dõi bởi lần đầu tiên chỉ hoạt động nếu cấu hình branch.B.merge được xác định đúng: refs/heads/master.
Nó sẽ không hoạt động nếu nó được định nghĩa lỏng lẻo: 'master'.

Nhưng với commit 05e7368, được thực hiện bởi Junio C Hamano (gitster) cho Git 2.3.0 (Q1 2015), điều này cũng sẽ hoạt động.

Khi kiểm tra ra một chi nhánh được thiết lập để xây dựng trên đầu trang của một chi nhánh (thường, một chi nhánh từ xa theo dõi), "git checkout" báo cáo như thế nào công việc của bạn liên quan đến các chi nhánh khác, ví dụ

Your branch is behind 'origin/master', and can be fast-forwarded. 

Quay lại khi tính năng này đã được giới thiệu, điều này chỉ được thực hiện đối với các chi nhánh đó xây dựng dựa trên các chi nhánh từ xa theo dõi, nhưng 5e6e2b4 (Hãy chi nhánh địa phương hành xử giống như các chi nhánh từ xa khi --tracked, 2009/04/01 , git 1.6.3) thêm hỗ trợ để cung cấp cho cùng một báo cáo cho các chi nhánh xây dựng trên các chi nhánh địa phương khác (tức là các chi nhánh có các biến số branch.*.remote được đặt thành '.').
Không giống như sự hỗ trợ cho các chi nhánh xây dựng trên các nhánh theo dõi từ xa, tuy nhiên, này không tính đến thực tế rằng cấu hình branch.*.merge được phép ghi lại tên chi nhánh rút gọn.

Khi branch.*.merge được thiết lập để 'master' (không phải là 'refs/heads/master'), nghĩa là "chi nhánh của tôi được xây dựng trên các chi nhánh 'thầy' địa phương", điều này gây ra "git checkout" báo cáo:

Your branch is based on 'master', but the upstream is gone. 

Thượng nguồn là kho lưu trữ của chúng tôi và chắc chắn không bị mất, vì vậy đầu ra này là vô nghĩa.

Answer 4

Có nhiều trường hợp khi theo dõi chi nhánh địa phương khác hữu ích. Ví dụ, trong một số luồng công việc git, có một cái gì đó tại chỗ bảo vệ chủ từ trực tiếp nhận được yêu cầu đẩy. Một ví dụ là đánh giá mã hoặc hệ thống tích hợp liên tục, mà phải vượt qua trước khi cam kết hạ cánh trên nhánh từ xa. Một ví dụ khác là khi một dự án được quản lý bởi một bộ các ủy ban chỉ chấp nhận các yêu cầu kéo (các dự án GitHub thường làm điều này). Là một nhà phát triển, tôi có thể muốn tạo một chi nhánh tính năng, và sau đó gửi chi nhánh đó để xem xét (hoặc gửi một yêu cầu kéo đến một người giao dịch repo). Sau đó tôi có thể muốn tiếp tục phát triển địa phương trong khi đồng đội của tôi xem xét không đồng bộ mã của tôi và CI xây dựng hoàn chỉnh. Để tiếp tục phát triển trên đầu trang của cam kết trước đó của tôi, tôi có thể tạo một chi nhánh địa phương thứ hai theo dõi từ chi nhánh địa phương đầu tiên của tôi. Điều này cho phép tôi để xây dựng từ cam kết đầu tiên của tôi, mặc dù cam kết đó đã không được thực hiện theo cách của mình để các chi nhánh từ xa thượng nguồn. Ngoài ra, nếu ai đó đề xuất thay đổi mã xem xét cho chi nhánh đầu tiên của tôi, hoặc xây dựng CI không thành công, tôi có thể cập nhật nhánh đó, và sau đó rebase những thay đổi đó thành các nhánh nội bộ xuống. Dưới đây là cách thiết lập chi nhánh để theo dõi một chi nhánh địa phương khác.

Cho một chi nhánh tính năng địa phương:

$ git co -b branch-1 
$ git branch -u origin/master 
Switched to a new branch 'branch-1' 
$ git branch -vv 
* branch-1    9f0c361 [origin/master] Some commit message 
    master     85ede1a [origin/master] Some commit message 

Điều này cho thấy, ngành theo dõi cục bộ master và branch-1 cả theo dõi master chi nhánh trên origin từ xa. Bây giờ tôi có thể tạo một chi nhánh khác và thiết lập nó để theo dõi chi nhánh theo dõi địa phương branch-1.

$ git co -b branch-2 
Switched to a new branch 'branch-2' 
$ git branch -u branch-1 branch-2 
Branch branch-2 set up to track local branch branch-1 by rebasing. 
$ git branch -vv 
    branch-1    85ede1a [origin/master] Some commit message 
* branch-2    85ede1a [branch-1] Some commit message 
    master     85ede1a [origin/master] Some commit message