Một số ví dụ về các thực hành thường được sử dụng để đặt tên các nhánh git là gì? [đóng cửa]


1121

Tôi đã sử dụng kho git cục bộ tương tác với kho CVS của nhóm tôi trong vài tháng nay. Tôi đã tạo ra một số nhánh gần như thần kinh, hầu hết trong số đó đã hợp nhất trở lại vào thân cây của tôi. Nhưng việc đặt tên đang bắt đầu trở thành một vấn đề. Nếu tôi có một nhiệm vụ dễ dàng được đặt tên bằng một nhãn đơn giản, nhưng tôi hoàn thành nó trong ba giai đoạn, mỗi giai đoạn bao gồm nhánh riêng và tình huống hợp nhất của chúng, thì tôi có thể lặp lại tên nhánh mỗi lần, nhưng điều đó làm cho lịch sử hơi khó hiểu. Nếu tôi nhận được cụ thể hơn trong các tên, với một mô tả riêng cho từng giai đoạn, thì các tên nhánh bắt đầu dài và khó sử dụng.

Tôi đã học được cách xem qua các chủ đề cũ ở đây rằng tôi có thể bắt đầu đặt tên các nhánh với một / trong tên, tức là chủ đề / nhiệm vụ hoặc một cái gì đó tương tự. Tôi có thể bắt đầu làm điều đó và xem nếu nó giúp giữ mọi thứ được tổ chức tốt hơn.

Một số thực hành tốt nhất để đặt tên chi nhánh git là gì?

Chỉnh sửa: Không ai thực sự đề xuất bất kỳ quy ước đặt tên. Tôi xóa chi nhánh khi tôi hoàn thành chúng. Tôi chỉ tình cờ có một số xung quanh do quản lý liên tục điều chỉnh các ưu tiên của tôi. :) Như một ví dụ về lý do tại sao tôi có thể cần nhiều hơn một nhánh trong một nhiệm vụ, giả sử tôi cần phải thực hiện cột mốc riêng biệt đầu tiên trong nhiệm vụ cho kho lưu trữ CVS của nhóm. Vào thời điểm đó, do sự tương tác không hoàn hảo của tôi với CVS, tôi sẽ thực hiện cam kết đó và sau đó giết chi nhánh đó. (Tôi đã thấy quá nhiều sự kỳ lạ khi tương tác với CVS nếu tôi cố gắng tiếp tục sử dụng cùng một chi nhánh vào thời điểm đó.)


Có - có lẽ tốt để không giữ xung quanh hoặc đẩy các nhánh không hữu ích sau khi bạn hoàn thành với chúng. Trừ khi có một lý do chính đáng để giữ một nhánh chủ đề (ví dụ, để tham khảo nó sau này), không có vấn đề gì trong việc xóa nó. Git làm cho việc phân nhánh dễ dàng, và một hệ quả là bạn có thể kết thúc với rất nhiều nhánh tầm thường nằm xung quanh có thể được làm sạch mà không cần phải quảng cáo nhiều.
Eric Walker


2
Để hoàn thiện, có một số chuỗi ký tự bạn không thể sử dụng .
Nick Westgate

18
Cần phải có một nơi cho các loại câu hỏi này trong mạng StackExchange. Rất khó chịu khi ai đó hỏi một câu hỏi hay như thế này và sau đó nó bị đóng cửa vì không tuân theo các quy tắc. Nếu nó tiếp tục xảy ra thì điều đó có lẽ sẽ báo hiệu sự cần thiết phải hỗ trợ các loại câu hỏi này bằng cách nào đó. Chỉ, những điều này có lẽ sẽ phải được triển khai trong trang Overflow vì chúng liên quan mật thiết đến các câu hỏi kiểu lập trình. Đối với tôi, tràn không phải là "câu hỏi có thể trả lời khách quan" (quá cụ thể), đó là "Câu hỏi lập trình".
Nick Res

@Wim Chúng tôi sử dụng các khóa phát hành jira, kết hợp với một tiêu đề ngắn, ví dụ:KEY-1234/allow-users-to-do-smart-stuff
RobAu

Câu trả lời:


938

Dưới đây là một số quy ước đặt tên chi nhánh mà tôi sử dụng và lý do cho chúng

Quy ước đặt tên chi nhánh

  1. Sử dụng nhóm mã thông báo (từ) ở đầu tên chi nhánh của bạn.
  2. Xác định và sử dụng mã thông báo dẫn ngắn để phân biệt các nhánh theo cách có ý nghĩa đối với quy trình làm việc của bạn.
  3. Sử dụng dấu gạch chéo để tách các phần của tên chi nhánh của bạn.
  4. Không sử dụng số trần làm bộ phận hàng đầu.
  5. Tránh tên mô tả dài cho các nhánh sống lâu.

Mã thông báo nhóm

Sử dụng mã thông báo "nhóm" trước tên chi nhánh của bạn.

group1/foo
group2/foo
group1/bar
group2/bar
group3/bar
group1/baz

Các nhóm có thể được đặt tên bất cứ điều gì bạn muốn để phù hợp với quy trình làm việc của bạn. Tôi thích sử dụng danh từ ngắn cho tôi. Đọc để rõ hơn.

Mã thông báo ngắn được xác định rõ

Chọn mã thông báo ngắn để chúng không thêm quá nhiều tiếng ồn vào mỗi tên chi nhánh của bạn. Tôi sử dụng những thứ này:

wip       Works in progress; stuff I know won't be finished soon
feat      Feature I'm adding or expanding
bug       Bug fix or experiment
junk      Throwaway branch created to experiment

Mỗi mã thông báo này có thể được sử dụng để cho bạn biết phần nào trong quy trình làm việc của bạn mà mỗi nhánh thuộc về.

Có vẻ như bạn có nhiều nhánh cho các chu kỳ thay đổi khác nhau. Tôi không biết chu kỳ của bạn là gì, nhưng hãy giả sử chúng là 'mới', 'thử nghiệm' và 'đã được xác minh'. Bạn có thể đặt tên cho các chi nhánh của mình bằng các phiên bản rút gọn của các thẻ này, luôn được đánh vần theo cùng một cách, để cả hai nhóm và nhắc nhở bạn đang ở giai đoạn nào.

new/frabnotz
new/foo
new/bar
test/foo
test/frabnotz
ver/foo

Bạn có thể nhanh chóng cho biết các nhánh nào đã đạt đến từng giai đoạn khác nhau và bạn có thể nhóm chúng lại với nhau một cách dễ dàng bằng các tùy chọn khớp mẫu của Git.

$ git branch --list "test/*"
test/foo
test/frabnotz

$ git branch --list "*/foo"
new/foo
test/foo
ver/foo

$ gitk --branches="*/foo"

Sử dụng dấu gạch chéo để tách các phần

Bạn có thể sử dụng hầu hết mọi dấu phân cách bạn thích trong tên nhánh, nhưng tôi thấy dấu gạch chéo là linh hoạt nhất. Bạn có thể thích sử dụng dấu gạch ngang hoặc dấu chấm. Nhưng dấu gạch chéo cho phép bạn thực hiện một số đổi tên chi nhánh khi đẩy hoặc tìm nạp đến / từ xa.

$ git push origin 'refs/heads/feature/*:refs/heads/phord/feat/*'
$ git push origin 'refs/heads/bug/*:refs/heads/review/bugfix/*'

Đối với tôi, dấu gạch chéo cũng hoạt động tốt hơn để mở rộng tab (hoàn thành lệnh) trong trình bao của tôi. Cách tôi định cấu hình, tôi có thể tìm kiếm các nhánh có các phần phụ khác nhau bằng cách nhập các ký tự đầu tiên của phần đó và nhấn phím TAB. Zsh sau đó đưa cho tôi một danh sách các nhánh khớp với phần mã thông báo mà tôi đã nhập. Điều này hoạt động cho các mã thông báo trước cũng như các mã được nhúng.

$ git checkout new<TAB>
Menu:  new/frabnotz   new/foo   new/bar


$ git checkout foo<TAB>
Menu:  new/foo   test/foo   ver/foo

(Zshell rất có thể cấu hình về việc hoàn thành lệnh và tôi cũng có thể định cấu hình nó để xử lý dấu gạch ngang, dấu gạch dưới hoặc dấu chấm theo cùng một cách. Nhưng tôi chọn không.)

Nó cũng cho phép bạn tìm kiếm các nhánh trong nhiều lệnh git, như thế này:

git branch --list "feature/*"
git log --graph --oneline --decorate --branches="feature/*" 
gitk --branches="feature/*" 

Hãy cẩn thận: Như Slipp chỉ ra trong các bình luận, dấu gạch chéo có thể gây ra vấn đề. Vì các nhánh được triển khai dưới dạng đường dẫn, bạn không thể có một nhánh có tên là "foo" và một nhánh khác có tên là "foo / bar". Điều này có thể gây nhầm lẫn cho người dùng mới.

Không sử dụng số trần

Không sử dụng sử dụng số trần (hoặc số hex) như một phần của sơ đồ đặt tên chi nhánh của bạn. Bên trong mở rộng tab của tên tham chiếu, git có thể quyết định rằng một số là một phần của sha-1 thay vì tên nhánh. Ví dụ, trình theo dõi vấn đề của tôi đặt tên lỗi với số thập phân. Tôi đặt tên cho các chi nhánh liên quan của mình là CRnnnnn thay vì chỉ nnnnn để tránh nhầm lẫn.

$ git checkout CR15032<TAB>
Menu:   fix/CR15032    test/CR15032

Nếu tôi cố gắng mở rộng chỉ 15032, git sẽ không chắc chắn liệu tôi muốn tìm kiếm tên của SHA-1 hay chi nhánh, và các lựa chọn của tôi sẽ bị hạn chế phần nào.

Tránh các tên mô tả dài

Tên chi nhánh dài có thể rất hữu ích khi bạn đang xem danh sách các chi nhánh. Nhưng nó có thể gây cản trở khi nhìn vào các bản ghi một dòng được trang trí vì các tên nhánh có thể ăn hầu hết các dòng đơn và viết tắt phần hiển thị của nhật ký.

Mặt khác, tên nhánh dài có thể hữu ích hơn trong "hợp nhất cam kết" nếu bạn không thường xuyên viết lại chúng bằng tay. Thông báo cam kết hợp nhất mặc định là Merge branch 'branch-name'. Bạn có thể thấy hữu ích hơn khi có các thông báo hợp nhất xuất hiện Merge branch 'fix/CR15032/crash-when-unformatted-disk-inserted'thay vì chỉ Merge branch 'fix/CR15032'.


156
Một nhược điểm của việc sử dụng kết hợp các biểu mẫu như bug/20574/frabnotz-finderbug/20424là một khi bạn bắt đầu mà không có mã thông báo phụ, bạn không thể thêm một biểu mẫu sau và ngược lại. EG: Nếu bạn tạo một bug/20424nhánh, bạn không thể tạo một bug/20424/additional-fixingnhánh sau (trừ khi bạn xóa bug/20424chi nhánh). Tương tự, nếu bug/20574/frabnotz-finderđã là một nhánh, bạn không thể tạo một bug/20574nhánh. Tôi có xu hướng sử dụng một dấu phân cách không mã thông báo phụ trong các trường hợp như thế này (ví dụ bug/20574_frabnotz-finder) hoặc chọn tên mặc định cho mã thông báo phụ (ví dụ bug/20424/main).
Slipp D. Thompson

5
Nó cũng có lợi ích khi nhắc một số công cụ dựa trên GUI Git để cho phép thu gọn các phân chia mã thông báo như chế độ xem danh sách thư mục. Trong ví dụ trên, bạn sẽ thấy một featurenhóm và một bugnhóm, có thể mở rộng để hiển thị foo, barcác thẻ cho cái trước và a 20574, 20592nhóm và 20424, 21334thẻ cho cái sau.
Slipp D. Thompson

47
Tôi sẽ bắt đầu một chiến dịch để không bao giờ sử dụng dấu gạch chéo trong đặt tên nhánh git. Lý do cho điều này là vì nếu trên CI chẳng hạn, bạn muốn tham khảo tên chi nhánh khi mã đóng gói chẳng hạn, bạn muốn tham khảo tên của chi nhánh khi xây dựng uri hoặc PATH (ví dụ) một uri trong một kịch bản bash; bạn sẽ gặp khó khăn khi xây dựng uri do dấu gạch chéo thêm một phần url. Có, nó có thể thay thế dấu gạch chéo nhưng nó sẽ khiến tôi mất nhiều thời gian để sắp xếp.
Adam Spence

13
Đây có phải là một vấn đề mà dấu gạch chéo về phía trước có ý nghĩa đối với git trong một số trường hợp? Ví dụ, để phản hồi git branch -avà nhận remotes/origin/master, v.v. Khi tôi thấy git nói với tôi về một chi nhánh, tôi không sử dụng dấu gạch chéo về phía trước và vì vậy khi tôi nhìn thấy một cái, tôi biết đó là một tài liệu tham khảo "đặc biệt".
Dogweather

11
Bạn có thể sử dụng một số ví dụ thay vì foo và bar xin vui lòng?
Worthy7

329

Một mô hình phân nhánh Git thành công của Vincent Driessen có những gợi ý tốt. Một hình ảnh dưới đây. Nếu mô hình phân nhánh này hấp dẫn bạn, hãy xem xét phần mở rộng dòng chảy thành git . Những người khác đã bình luận về dòng chảy

Mô hình của Drind bao gồm

  • Một nhánh chủ, chỉ được sử dụng để phát hành. Tên điển hình master.

  • Một nhánh "phát triển" ra khỏi nhánh đó. Đó là cái được sử dụng cho hầu hết các công việc chính. Tên thường gọi develop.

  • Nhiều nhánh tính năng của nhánh phát triển. Tên dựa trên tên của tính năng. Chúng sẽ được hợp nhất trở lại để phát triển, không phải vào các nhánh chính hoặc phát hành.

  • Chi nhánh phát hành để giữ các bản phát hành ứng viên, chỉ sửa lỗi và không có tính năng mới. Tên điển hình rc1.1.

Hotfix là các nhánh tồn tại trong thời gian ngắn cho các thay đổi xuất phát từ chủ và sẽ chuyển sang chủ mà không có chi nhánh phát triển.

nhập mô tả hình ảnh ở đây


129
Ngoại trừ việc nó không thực sự giải quyết được câu hỏi, vì nó để lại một loạt các quy ước đặt tên cho người dùng, đặc biệt là cho các nhánh tính năng (chúng có thể là "mọi thứ trừ chủ, phát triển, phát hành- hoặc hotfix- "
Brian

1
@Brian Một quy ước đặt tên tính năng sẽ giúp gì trong bối cảnh các vấn đề mà mô hình giải quyết? Tôi không thực sự thấy, hiện tại, làm thế nào để tạo sự khác biệt hơn nữa trong các tính năng thực sự có ích. Có thể trong tương lai so với phiên bản tiếp theo, nhưng điều đó có thể thương lượng và do đó không nên là một phần của tên. Để dễ đọc, có lẽ chỉ cần chuẩn bị trước chúng với tính năng- * là đủ. Bạn đã bỏ phiếu một vài lần vì vậy tôi chỉ tò mò muốn nghe quá trình suy nghĩ của bạn ...
Nick Res

2
Mặc dù thông tin tốt câu trả lời này giải quyết câu hỏi về dòng chảy hơn là quy ước đặt tên. Tôi nghĩ OP muốn biết những từ thực tế sẽ sử dụng (danh từ so với động từ), dấu phân cách, trường hợp, v.v.
Caltor

6
Cuốn sách Giao hàng liên tục (trang 36) lập luận rằng mô hình này là loại phản đối với Tích hợp liên tục, ... về cơ bản, nó không thực sự "nhanh nhẹn".
Markon

Điều này không thực sự trả lời câu hỏi đã được hỏi. Điều này không cung cấp cái nhìn sâu sắc về việc tích hợp một quy trình công việc cụ thể vào một lịch trình phát triển và phát hành bao trùm, tuy nhiên, op đang tìm kiếm lời khuyên về các quy ước về những gì thực sự gọi là các chi nhánh.
bánh xe

56

Sở thích cá nhân của tôi là xóa tên chi nhánh sau khi tôi hoàn thành một nhánh chủ đề.

Thay vì cố gắng sử dụng tên chi nhánh để giải thích ý nghĩa của chi nhánh, tôi bắt đầu dòng chủ đề của thông điệp cam kết trong lần xác nhận đầu tiên trên chi nhánh đó với nhánh Branch: Tiết và bao gồm các giải thích thêm trong phần thân của thông điệp nếu chủ đề không cho tôi đủ không gian.

Tên chi nhánh trong sử dụng của tôi hoàn toàn là một tay cầm để chỉ một nhánh chủ đề trong khi làm việc với nó. Khi công việc trên nhánh chủ đề đã kết thúc, tôi thoát khỏi tên nhánh, đôi khi gắn thẻ cam kết để tham khảo sau.

Điều đó làm cho đầu ra của git branchcũng hữu ích hơn: nó chỉ liệt kê các nhánh tồn tại lâu và các nhánh chủ đề hoạt động, không phải tất cả các nhánh.


53

Tôi đã trộn và kết hợp từ các chương trình khác nhau mà tôi đã thấy và dựa trên công cụ tôi đang sử dụng.
Vì vậy, tên chi nhánh hoàn thành của tôi sẽ là:

tên / tính năng / vấn đề-theo dõi số / mô tả ngắn

mà sẽ dịch sang:

mike / blog / RSSI-12 / logo-fix

Các phần được phân tách bằng dấu gạch chéo về phía trước vì chúng được hiểu là các thư mục trong SourceTree để dễ dàng tổ chức. Chúng tôi sử dụng Jira để theo dõi vấn đề của chúng tôi để bao gồm cả số giúp tìm kiếm dễ dàng hơn trong hệ thống. Bao gồm số đó cũng làm cho nó có thể tìm kiếm được khi cố gắng tìm ra vấn đề đó bên trong Github khi cố gắng gửi yêu cầu kéo.


Tôi cũng vậy, ngoại trừ số lỗi / số tính năng trong thông báo cam kết (đối với tích hợp GitHub -> Pivotal Tracker).
Leo

Tôi đang tự hỏi RSSI có nghĩa là gì.
Renshuki

@DRhuki nó chỉ là một khóa dự án Jira chung. Dù bạn sử dụng trình theo dõi vấn đề nào, hãy chèn ID vé
MikeG

@MikeG cảm ơn bạn vì sự chính xác!
Renshuki

3
Tôi sử dụng tương tự ngoại trừ tôi chuyển số vấn đề cùng với mô tả:name/feature/issue-tracker-number-short-description
lephleg 15/11/18

22

Tại sao phải mất ba chi nhánh / sáp nhập cho mọi nhiệm vụ? Bạn có thể giải thích thêm về điều đó?

Nếu bạn sử dụng hệ thống theo dõi lỗi, bạn có thể sử dụng số lỗi như một phần của tên chi nhánh. Điều này sẽ giữ cho các tên nhánh duy nhất và bạn có thể đặt tiền tố cho chúng bằng một hoặc hai từ ngắn gọn và mô tả để giữ cho chúng có thể đọc được, giống như con người "ResizeWindow-43523". Nó cũng giúp làm cho mọi thứ dễ dàng hơn khi bạn đi dọn dẹp các chi nhánh, vì bạn có thể tìm kiếm các lỗi liên quan. Đây là cách tôi thường đặt tên cho các chi nhánh của tôi.

Vì các nhánh này cuối cùng được hợp nhất trở lại thành chủ, bạn nên xóa chúng một cách an toàn sau khi bạn hợp nhất. Trừ khi bạn hợp nhất với --squash, toàn bộ lịch sử của chi nhánh vẫn sẽ tồn tại nếu bạn cần.


12

Lưu ý, như được minh họa trong cam kết e703d7 hoặc cam kết b6c2a0d (tháng 3 năm 2014), bây giờ là một phần của Git 2.0, bạn sẽ tìm thấy một quy ước đặt tên khác (mà bạn có thể áp dụng cho các chi nhánh).

"Khi bạn cần sử dụng không gian, sử dụng dấu gạch ngang" là một cách lạ để nói rằng bạn không được sử dụng khoảng trắng.
Bởi vì thông thường các mô tả dòng lệnh sử dụng nhiều từ có dấu gạch ngang, bạn thậm chí không muốn sử dụng khoảng trắng ở những nơi này.

Tên chi nhánh không thể có khoảng trắng (xem " Những ký tự nào là bất hợp pháp trong tên chi nhánh? " Và git check-ref-formattrang man ).

Vì vậy, đối với mỗi tên nhánh sẽ được biểu thị bằng một biểu thức nhiều từ, sử dụng dấu ' -' (dấu gạch ngang) làm dấu phân cách là một ý tưởng tốt.


7

Theo gợi ý của farktronix, chúng tôi đã sử dụng số vé của Jira cho tương tự như vậy, và tôi dự định tiếp tục sử dụng chúng cho các chi nhánh git. Nhưng tôi nghĩ rằng số lượng vé có lẽ là đủ độc đáo. Mặc dù có thể có một từ mô tả trong tên chi nhánh như farktronix đã lưu ý, nếu bạn thường xuyên chuyển đổi giữa các nhánh, bạn có thể muốn gõ ít hơn. Sau đó, nếu bạn cần biết tên chi nhánh, hãy tìm trong Jira để biết các từ khóa liên quan trong vé nếu bạn không biết nó. Ngoài ra, bạn nên bao gồm số vé trong mỗi bình luận.

Nếu chi nhánh của bạn đại diện cho một phiên bản, có vẻ như quy ước chung là sử dụng định dạng xxx (ví dụ: "1.0.0") cho tên chi nhánh và vx.xx (ví dụ "v1.0.0") cho tên thẻ (để tránh xung đột) . Xem thêm: is-there-an-standard-đặt tên-quy ước-cho-git-tags


1
Có một vấn đề với xung đột? Nếu mục đích là để một v1.2.4nhánh cuối cùng dẫn đến một điểm cuối với một v1.2.4thẻ (tôi có đúng không khi cho rằng đây là tình huống mà cả hai bạn đều đặt tên nhánh và thẻ sau một phiên bản) , thì có vấn đề gì không? Thẻ vẫn có thể đạt được tại refs/tags/v1.2.4và chi nhánh tại refs/heads/v1.2.4, và nó xuất hiện Git sẽ thích tên thẻ hơn khi nó mơ hồ (có cảnh báo).
Slipp D. Thompson

1
Đối với ví dụ về phiên bản, như tôi đã đề cập trong câu trả lời của mình, một thực tiễn được đề xuất là tiền tố với "v" cho tên thẻ, không phải chi nhánh. Tránh sự mơ hồ nếu bạn có thể để tránh thông tin sai lệch và bởi vì điều đó có thể gây ra vấn đề khi di chuyển đến bất kỳ VCS mới nhất và lớn nhất tiếp theo là gì.
Gary S. Weaver

2
Gần đây tôi đã làm việc với một repo nơi chúng tôi giới hạn từng nhánh phiên bản với một thẻ cùng tên. Nó hoạt động khá tốt vì không có chút mơ hồ nào (thẻ chỉ vào lần cam kết cuối cùng trên nhánh tương ứng trong hầu hết các trường hợp), và khi có thể, Git đã thực hiện đúng điều đó (với một cảnh báo). Tôi thích nó bởi vì nếu ai đó phạm sai lầm xương đầu và cam kết hơn nữa với một nhánh bị giới hạn, Git sẽ tiếp tục chọn thẻ, đó là ý định. Sự mơ hồ có thể làm cho mọi thứ đơn giản hơn khi hệ thống kiểm soát mọi thứ và ý định rõ ràng.
Slipp D. Thompson
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.