Git: Không thể hiểu tại sao nhánh (chủ đề) cam kết/sáp nhập xảy ra trên nhánh chính

Question

Lưu ý: Tôi không chắc liệu điều này đã được yêu cầu chưa, tôi không thể tìm thấy câu hỏi nào phù hợp với ngữ cảnh của mình (hoặc tôi không thể hiểu bối cảnh của các câu hỏi hiện tại ')

Tôi yêu Git những ngày này. Đặc biệt, các nhánh chủ đề. Tôi đang làm việc trên một ứng dụng chia sẻ mã nhỏ. Và tôi có các nhánh địa phương như "master", "authentication", "bookmarks", "comments", "nose", v.v ...

Luồng công việc (dự định) của tôi giống như sau: Tạo một nhánh chủ đề ==> Làm việc trên nhánh chủ đề ==> Cam kết các tệp vào nhánh ==> Hợp nhất các nhánh chủ đề thay đổi thành nhánh "master". (Và sau đó xóa chi nhánh chủ đề)

Tôi đã thử làm tương tự cho một vài nhánh. Nó hoạt động tốt. Nhưng sau đó khi tôi kiểm tra biểu đồ git, ngay cả khi tôi theo cùng một quy trình làm việc, tất cả các cơ hội đã xảy ra trên "chủ". Không có dòng cây phân kỳ và hội tụ! Nó cho thấy một dòng singe với nhiều cam kết từ đó. Tôi không chắc tại sao? Tôi ấn tượng, tôi đã làm một cái gì đó với con trỏ HEAD?

Để cung cấp cho một cái nhìn thực tế, đây là đồ thị git của tôi: http://github.com/none-da/zeshare/network

Dưới đây là các lệnh tôi đã sử dụng:

>> git branch authentication_feature 
>> git checkout authentication_feature 
>> # I work with all the files here in "authentication_feature" branch 
>> git commit -m "Authentication_feature is up" # commiting to the branch 
>> git branch # just to confirm, which branch I am working on 
>> git checkout master # trying to shift to master branch 
>> git merge --no-commit authentication_feature # I merge in two steps. This is step 1 
>> git status;git add; git commit -m "Authentication_feature" merged to "master". # This is the step 2 
>> git log --graph --pretty=oneline # confirming the graph 
>> git push origin master # pushing to the remote server(github) 

Answer 1

Nhưng sau khi tôi kiểm tra đồ thị git, ngay cả khi tôi đi theo quy trình làm việc cùng, tất cả các cơ hội được diễn ra trên "bậc thầy".Không có dòng cây phân kỳ và hội tụ!

Vâng ... Tôi thấy một số nhánh và hợp nhất của bạn.

Bạn sẽ tìm thấy ở đây page all the possible merge scenarios
(biên soạn vào thời điểm đó - vào cuối năm 2007 - bây giờ SO đóng góp: Jakub Narębski)

Bạn có thể là trong một trường hợp nhanh về phía trước, trong đó sẽ giải thích tại sao hòa trộn của bạn sẽ làm cho tất cả các cam kết của bạn xuất hiện để làm chủ một khi chúng được thực hiện:

2/Trường hợp chuyển tiếp nhanh; Không có cam kết A, B, C, và chúng tôi bắt đầu từ tình huống sau đây:

1---2---3    <-- trunk <-- HEAD 
      \ 
      \-a---b---c <-- branch 

2,1/"git merge branch"

1---2---3   /----- trunk <-- HEAD 
      \   v 
      \-a---b---c <-- branch 

kết quả Nhanh chóng chuyển tiếp trong chỉ cần di chuyển đầu của thân cây.
Nó không tạo ra một cam kết, do đó:

2.2/"git merge --no-commit branch"

Giống như trong 2.1, vì nhanh chóng chuyển tiếp không tạo ra một cam kết.

Vì vậy, nếu bạn không cam kết về chủ kể từ khi bạn tách ra, và sau đó làm một hợp nhất trên tổng thể, tất cả các bạn cần làm là cài đặt lại ĐẦU bậc thầy ...

---

Một nguyên nhân cho các chi nhánh để không được hiển thị là "to-do list hiệu lực thi hành" được mô tả trên presentation page of the GitHub Network Graph visualizer (đó là "git graph" bạn đang đề cập đến ở đây)

Nhưng bạn đang nhìn thấy từng cam kết chỉ một lần. Để yên trong một giây.
Tôi thấy rằng nhiều lập trình viên được sử dụng cho một SCM tập trung mà họ bỏ lỡ một thực tế là Visual Visualizer của chúng tôi đang thực sự hiển thị và kết nối các kho khác nhau.

Nếu tôi tự vẽ đồ thị dưới dạng gốc, thì biểu đồ hiển thị một loại danh sách mã cần làm mà tôi chưa kéo vào repo của mình.
Khi tôi muốn bắt kịp những gì cộng đồng đang làm trong dĩa của họ về repo của tôi, tôi có thể nhấn lên biểu đồ và xem ngay lập tức những gì người khác đã làm. Nếu tôi kéo các thay đổi của Bertg, lần sau tôi thấy biểu đồ, Bertg sẽ không còn hiển thị nữa vì anh ấy sẽ không còn bất kỳ cam kết nào mà tôi không làm.
Tiếp tục suy nghĩ danh sách việc cần làm và bạn sẽ hiểu biểu đồ.

Vì vậy, nếu điều đó đúng với việc hợp nhất từ ​​các chi nhánh repos khác (tức làbạn không thấy các nhánh đó nữa khi chúng được hợp nhất), điều đó có thể đúng cho việc hợp nhất từ ​​các chi nhánh repo của riêng bạn: sau khi hợp nhất, bạn không còn thấy chúng trong biểu đồ của mình nữa.

Nhưng tôi, vì:

• Tôi không phải là chủ sở hữu của dự án.
• Tôi có thể muốn lấy các thay đổi của tôi từ bất kỳ chi nhánh nào của bạn.

Answer 2

Bạn đã không nói gì lệnh bạn thực sự sử dụng, nhưng tôi đoán là bạn đã tạo chi nhánh của mình với git branch nhưng không kiểm tra chi nhánh để chuyển đến chi nhánh. Bạn có thể làm điều này trong một bước như sau:

git checkout master -b topic22 

Điều này khiến bạn ít có khả năng sẽ vô tình làm chủ.

Bây giờ bạn đã thêm chuỗi lệnh bạn đã làm, tôi thấy bạn đã thanh toán chi nhánh.

Chuỗi lệnh có vẻ ổn. Tôi nghĩ lý do có vẻ như không có chi nhánh là vì không có cam kết can thiệp vào nhánh chủ. Sau khi hợp nhất, nó giống như một luồng phát triển tuần tự. Điều này được thảo luận tốt ở một trong những câu trả lời khác, do đó không cần phải xây dựng ở đây.

Answer 3

Bạn đang sử dụng một cái gì đó giống như

git show-branch 

để cho bạn thấy những chi nhánh và check-in, một khi bạn sáp nhập chi nhánh của bạn để làm chủ bạn không thể nhìn thấy nữa sửa đổi - không chắc chắn lý do tại sao.

Tôi không thể tìm thấy bất kỳ giải thích nào về hành vi nhưng dường như không có bất kỳ vấn đề nào với kho git kể từ git log hiển thị tất cả các cam kết cho từng chi nhánh.

Vì vậy, tôi đoán đó chỉ là cách công cụ hiển thị biểu đồ nhánh.

Answer 4

Tôi là thương hiệu mới với git và github bản thân mình (và liên kết vẫn còn xuống), nhưng sau khi nhìn vào các bước của bạn, có thể vì bạn không đẩy nhánh thực sự vào github? Điều này dường như được làm việc cho tôi cho đến nay (Tôi chèn lệnh push):

... 
>> git commit -m "Authentication_feature is up" # commiting to the branch 
>> git branch # just to confirm, which branch I am working on 
>> git push origin authentication_feature # push the branch to github 
>> git checkout master # trying to shift to master branch 
... 

Answer 5

Tôi đặt cược bạn đang tìm kiếm công tắc --no-ff trên git merge. Theo mặc định, merge sẽ chỉ cập nhật HEAD vào đầu nhánh mới, nếu không có cam kết can thiệp.

Nếu bạn muốn rời khỏi hợp nhất cam kết xung quanh để giúp nhóm các cam kết của bạn, hãy vượt qua --no-ff.

Answer 6

Là một thay thế cho việc sử dụng git merge --no-ff:

Nếu bạn muốn cam kết hiệu quả của sự phát triển chi nhánh chủ đề đến chi nhánh chính, nhưng không phải tất cả các cá nhân cam kết, sau đó bạn có thể sử dụng git merge --squash. Khi bạn thực hiện điều này, cam kết không được đánh dấu là hợp nhất và không có phụ huynh thứ hai của nhánh chủ đề. Danh sách các cam kết cá nhân được bao gồm trong nhận xét cam kết cho hợp nhất bị đè bẹp, vì chúng sẽ được liệt kê theo git log.

Chúng tôi đã sử dụng điều này trong một dự án được liên kết với SVN (theo số git svn), để chi nhánh chính của chúng tôi có lịch sử tuyến tính. Bằng cách đó, chúng tôi không phải làm phẳng biểu đồ git commit trước khi chạy git svn dcommit.