Hợp nhất chuyển tiếp nhanh có ý nghĩa đối với các nhánh có thời gian ngắn, nhưng trong một lịch sử phức tạp hơn , việc sáp nhập không chuyển tiếp nhanh có thể làm cho lịch sử dễ hiểu hơn và giúp dễ dàng hoàn nguyên một nhóm các cam kết.
Cảnh báo : Không chuyển tiếp nhanh cũng có tác dụng phụ tiềm ẩn. Vui lòng xem lại https://sandofsky.com/blog/git-workflow.html , tránh 'no-ff' với "điểm kiểm tra cam kết" phá vỡ hoặc đổ lỗi, và xem xét cẩn thận liệu đây có phải là cách tiếp cận mặc định của bạn không master.
(Từ nvie.com , Vincent Driessen , đăng " Mô hình phân nhánh Git thành công ")
Kết hợp một tính năng đã hoàn thành để phát triển
Các tính năng đã hoàn thành có thể được hợp nhất vào nhánh phát triển để thêm chúng vào bản phát hành sắp tới:
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop
Các --no-fflá cờ gây ra việc hợp nhất để luôn luôn tạo ra một mới cam kết đối tượng, ngay cả khi việc hợp nhất có thể được thực hiện với một nhanh về phía trước. Điều này tránh mất thông tin về sự tồn tại lịch sử của một nhánh tính năng và các nhóm cùng nhau tất cả các cam kết cùng nhau thêm tính năng này.
Jakub Narębski cũng đề cập đến các cấu hìnhmerge.ff :
Theo mặc định, Git không tạo ra một cam kết hợp nhất bổ sung khi hợp nhất một cam kết là hậu duệ của cam kết hiện tại. Thay vào đó, đầu của chi nhánh hiện tại được chuyển tiếp nhanh.
Khi được đặt thành false, biến này báo cho Git tạo một cam kết hợp nhất bổ sung trong trường hợp đó (tương đương với việc đưa ra --no-fftùy chọn từ dòng lệnh).
Khi được đặt thành ' only', chỉ những phép hợp nhất chuyển tiếp nhanh như vậy mới được phép (tương đương với việc đưa ra --ff-onlytùy chọn từ dòng lệnh).
Chuyển tiếp nhanh là mặc định vì:
- các nhánh sống ngắn rất dễ tạo và sử dụng trong Git
- các nhánh sống ngắn thường cô lập nhiều cam kết có thể được tổ chức lại một cách tự do trong nhánh đó
- những cam kết đó thực sự là một phần của nhánh chính: một khi được tổ chức lại, nhánh chính được chuyển tiếp nhanh để bao gồm chúng.
Nhưng nếu bạn dự đoán một quy trình công việc lặp lại trên một nhánh chủ đề / tính năng (nghĩa là tôi hợp nhất, sau đó tôi quay lại nhánh tính năng này và thêm một số cam kết nữa), thì chỉ hữu ích khi chỉ hợp nhất trong nhánh chính, thay vì tất cả các cam kết trung gian của nhánh tính năng.
Trong trường hợp này, bạn có thể kết thúc cài đặt loại tệp cấu hình này :
[branch "master"]
# This is the list of cmdline options that should be added to git-merge
# when I merge commits into the master branch.
# The option --no-commit instructs git not to commit the merge
# by default. This allows me to do some final adjustment to the commit log
# message before it gets commited. I often use this to add extra info to
# the merge message or rewrite my local branch names in the commit message
# to branch names that are more understandable to the casual reader of the git log.
# Option --no-ff instructs git to always record a merge commit, even if
# the branch being merged into can be fast-forwarded. This is often the
# case when you create a short-lived topic branch which tracks master, do
# some changes on the topic branch and then merge the changes into the
# master which remained unchanged while you were doing your work on the
# topic branch. In this case the master branch can be fast-forwarded (that
# is the tip of the master branch can be updated to point to the tip of
# the topic branch) and this is what git does by default. With --no-ff
# option set, git creates a real merge commit which records the fact that
# another branch was merged. I find this easier to understand and read in
# the log.
mergeoptions = --no-commit --no-ff
OP thêm vào trong các ý kiến:
Tôi thấy một số ý nghĩa trong việc chuyển tiếp nhanh cho các nhánh [tồn tại ngắn], nhưng biến nó thành hành động mặc định có nghĩa là git giả định rằng bạn ... thường có các nhánh [tồn tại ngắn]. Hợp lý?
Câu trả lời của Jefromi:
Tôi nghĩ rằng tuổi thọ của các chi nhánh rất khác nhau từ người dùng này đến người dùng khác. Tuy nhiên, trong số những người dùng có kinh nghiệm, có lẽ có xu hướng có nhiều chi nhánh ngắn hơn.
Đối với tôi, một nhánh tồn tại trong thời gian ngắn là một nhánh mà tôi tạo ra để làm cho một thao tác nhất định trở nên dễ dàng hơn (đánh lại, có khả năng hoặc vá nhanh và thử nghiệm), sau đó xóa ngay lập tức sau khi tôi hoàn thành.
Điều đó có nghĩa là nó có thể được hấp thụ vào nhánh chủ đề mà nó rẽ nhánh và nhánh chủ đề sẽ được hợp nhất thành một nhánh. Không ai cần biết những gì tôi đã làm trong nội bộ để tạo ra một loạt các cam kết thực hiện tính năng đã cho.
Tổng quát hơn, tôi thêm:
nó thực sự phụ thuộc vào quy trình phát triển của bạn :
- nếu nó là tuyến tính, một nhánh có ý nghĩa.
- Nếu bạn cần cách ly các tính năng và làm việc với chúng trong một thời gian dài và liên tục hợp nhất chúng, một số nhánh có ý nghĩa.
Xem " Khi nào bạn nên phân nhánh? "
Trên thực tế, khi bạn xem xét mô hình nhánh Mercurial, nó nằm ở một nhánh cốt lõi trên mỗi kho lưu trữ (mặc dù bạn có thể tạo các đầu ẩn danh, dấu trang và thậm chí các nhánh được đặt tên )
Xem "Git và Mercurial - So sánh và tương phản" .
Mercurial, theo mặc định, sử dụng các bộ mã nhẹ vô danh, theo thuật ngữ của nó được gọi là "người đứng đầu".
Git sử dụng các nhánh có tên nhẹ, với ánh xạ tiêm để ánh xạ tên của các nhánh trong kho lưu trữ từ xa thành tên của các nhánh theo dõi từ xa.
Git "buộc" bạn đặt tên cho các nhánh (tốt, ngoại trừ một nhánh không tên duy nhất, đó là một tình huống gọi là " ĐẦU tách rời "), nhưng tôi nghĩ rằng điều này hoạt động tốt hơn với các luồng công việc nặng nhánh như luồng công việc của nhánh chủ đề, nghĩa là nhiều chi nhánh trong một mô hình kho lưu trữ duy nhất.
no-ff' với "điểm kiểm tra cam kết" phá vỡ hoặc đổ lỗi.