2010-11-08 34 views
32

Hiện tại khi tôi đang sử dụng GIT, tôi tạo một chi nhánh cho mỗi công việc và thực hiện các cam kết khác nhau trước khi tôi hoàn tất. Sau đó tôi hợp nhất lại với nhánh chủ của mình và đẩy ngược dòng. Tôi có khả năng có một số chi nhánh tại một thời điểm và cũng flick giữa họ giữa công việc như những điều cây trồng lên.Hợp nhất chi nhánh GIT mà không cần đăng nhập cam kết

Nhưng hầu hết các cam kết này chỉ là lưu điểm, nghĩa là không quan trọng trong sơ đồ lớn của sự vật. Vì vậy, khi tôi hợp nhất các chi nhánh, tôi muốn nó nếu các bản ghi chi nhánh đã không hợp nhất với các bản ghi chủ.

Có cách nào để kết hợp thông điệp tường trình cho cam kết g bên dưới (và không cam kết c hoặc e) không?

a [master] 
| 
b (create branch 'job') 
|\ 
| \ 
| c 
| | 
d e 
| | 
f g (next step is to merge 'job' branch with 'master') 
+0

Tôi muốn thêm vào câu hỏi này: Có cách nào để 'git log' chỉ hiển thị các thông báo * không * đến từ các cam kết trung gian như' c' và 'e' không? – EOL

+0

@EOL: Trừ khi tôi hiểu lầm bạn, đó chính xác là tùy chọn '--first-parent' (được đề cập bởi knittl). Đối với một cam kết hợp nhất, cha mẹ đầu tiên là từ nhánh hợp nhất thành, và cha thứ hai là từ nhánh đã hợp nhất, do đó, sau cha mẹ đầu tiên (thường) có nghĩa là chỉ theo dõi lịch sử của chi nhánh bạn đang truy cập một cách hiệu quả. – Cascabel

+0

@Jefromi: Cảm ơn bạn đã chỉ ra điều này. Tôi thực sự có nghĩa là trái ngược với những gì tôi đã viết: làm thế nào để ẩn 'd' từ' git log'? (Tôi có một thiết lập trong đó nhánh sáp nhập vào một phiên bản Python 2.6 đơn giản, để việc sáp nhập vào nhật ký chi nhánh không thú vị lắm.) – EOL

Trả lời

7

có, nhưng điều đó là vô nghĩa. Tại sao bạn muốn làm điều đó? bạn sẽ mất tất cả lịch sử chi nhánh và thông tin.

bạn có thể sử dụng thông báo cam kết của g cho cam kết hợp nhất của bạn và sau đó duyệt lịch sử với tùy chọn --first-parent.

nếu bạn thực sự muốn mất lịch sử từ việc bạn sử dụng chi nhánh git merge --squash, tôi không khuyên bạn nên nó mặc dù

chỉnh sửa

trong trường hợp bạn không hài lòng bởi vì bạn không xem xét lịch sử của bạn rất sạch sẽ, bạn có thể sử dụng git's rebase feature:

bạn có thể sửa đổi cũ và tạo các cam kết mới từ nhánh hiện tại của bạn (có hiệu lực viết lại nó). nó cho phép bạn viết lại thông điệp cam kết, chia tách cam kết, bí quyết thành cam kết đơn, cam kết đặt hàng lại, v.v.

bạn chỉ nên sử dụng rebasing khi bạn chưa xuất bản chi nhánh của mình (tức là nó chỉ là chi nhánh tư nhân), bởi vì nó sẽ cung cấp cho các nhà phát triển khác nhức đầu và có thể gây ra các vấn đề hợp nhất sau này, nếu ai đó tiếp tục làm việc trên nhánh cũ (trước khi được rebased).

+0

Hi Knittl, tôi đoán là tôi đang tìm một "thực hành tốt nhất". Cam kết điểm C và E có thể là công việc chưa hoàn thành và sẽ không bao giờ là một điểm tôi cần phải quay trở lại. Có lẽ tôi nên sử dụng git stash tại những điểm đó ... Dù cách nào thì vấn đề của tôi là tôi không muốn các thông điệp tường trình "rác" lộn xộn lên nhật ký chủ, nhưng tôi đã tìm thấy lệnh git log này sẽ giúp nhóm các thông điệp tường trình: git log --pretty = format: '% h:% s' --đặt hàng --graph – Adam

+0

@adam, bạn luôn có thể (tương tác) rebase nhánh của bạn để đưa nó vào hình dạng tốt và sau đó hợp nhất với master – knittl

+0

Bạn có thể mở rộng điều "rebase your branch" của bạn không? Điều này nghe có vẻ thú vị. :) – EOL

1

Như đã đề cập trong "Trimming GIT Checkins/Squashing GIT History", nếu cam kết của bạn ce được thực hiện với một bình luận bắt đầu bằng fixup! thì rebase --interactive --autosquash (git1.7 +, February 2010) có thể làm chính xác gì bạn đang sau.

chỉ thị fixup!, bạn có thể giữ bí mật "ẩn" trong thông báo cam kết, trong khi vẫn hưởng lợi từ cam kết tự động sắp xếp lại tùy chọn --autosquash.

Để cam kết với một tiền tố fixup!, bạn có thể xác định bí danh

[alias] 
    fixup = !sh -c 'git commit -m \"fixup! $(git log -1 --format='\\''%s'\\'' [email protected])\"' - 
    squash = !sh -c 'git commit -m \"squash! $(git log -1 --format='\\''%s'\\'' [email protected])\"' - 

Các fixup alias sau đó sẽ được áp dụng đối với những "cam kết (mà) đều được chỉ cần lưu điểm, tức là không phải là quan trọng trong việc lớn kế hoạch của sự vật ".

47

Tôi xem xét hợp nhất - truy vấn cực kỳ hữu ích khi tôi sử dụng phương pháp "chi nhánh cho mỗi đối tượng địa lý". Lịch sử cam kết của tôi trong các nhánh tạm thời là một rác hoàn chỉnh, hoàn toàn vô nghĩa. Và tôi thực sự muốn không thể nhìn thấy lịch sử đó nữa, không chỉ để có thể bỏ qua nó.

Khi các cam kết đi xem xét mã, điều quan trọng là không tạo thêm cam kết.

+0

Tôi phải đồng ý. Nếu bạn đã đẩy cam kết đến một máy chủ từ xa như một nhánh WIP, thì bạn không thể rebase và sửa lịch sử. Đối với các chi nhánh nhỏ, nó hoàn toàn hợp pháp. –

+0

Đúng vậy và đó là quy trình công việc rất phổ biến trong các nhóm có quy mô trung bình. – oxfn

+0

Điều tốt nhất tôi có thể nói, bạn chỉ nói ý kiến ​​của bạn. Bạn đã không trả lời câu hỏi của OP * "Có cách nào để kết hợp thông điệp tường trình cho cam kết g dưới đây (và không cam kết c hoặc e)?" * – jww

Các vấn đề liên quan