Những mô hình phân nhánh Git làm việc cho bạn?

Công ty chúng tôi hiện đang sử dụng mô hình phân nhánh trunk / phát hành / hotfix đơn giản và muốn tư vấn về mô hình phân nhánh nào hoạt động tốt nhất cho công ty hoặc quá trình phát triển của bạn.

1. Mô hình quy trình / phân nhánh

   Dưới đây là ba mô tả chính về điều này tôi đã thấy, nhưng chúng mâu thuẫn một phần với nhau hoặc không đi đủ xa để giải quyết các vấn đề tiếp theo mà chúng tôi gặp phải (như được mô tả dưới đây). Do đó, nhóm của chúng tôi cho đến nay mặc định không phải là giải pháp tuyệt vời. Bạn đang làm một cái gì đó tốt hơn?

   • gitworkflows (7) Trang hướng dẫn
   • (nvie) Một mô hình phân nhánh Git thành công
   • (reinh) Quy trình làm việc Git cho các nhóm Agile

2. Sáp nhập vs nổi loạn (rối và lịch sử tuần tự)

   Nên một pull --rebasehoặc chờ đợi với việc hợp nhất trở lại dòng chính cho đến khi nhiệm vụ của bạn kết thúc? Cá nhân tôi nghiêng về việc hợp nhất vì điều này bảo tồn một minh họa trực quan về cơ sở mà một nhiệm vụ đã được bắt đầu và kết thúc, và tôi thậm chí thích merge --no-ffcho mục đích này. Nó có nhược điểm khác tuy nhiên. Ngoài ra, nhiều người đã không nhận ra thuộc tính hữu ích của việc hợp nhất - rằng nó không giao hoán (sáp nhập một nhánh chủ đề thành chủ không có nghĩa là sáp nhập chủ vào nhánh chủ đề).

3. Tôi đang tìm kiếm một quy trình làm việc tự nhiên

   Đôi khi sai lầm xảy ra vì các thủ tục của chúng tôi không nắm bắt được một tình huống cụ thể với các quy tắc đơn giản. Ví dụ, một bản sửa lỗi cần thiết cho các bản phát hành trước đó tất nhiên phải dựa trên dòng dưới đủ để có thể hợp nhất ngược dòng vào tất cả các nhánh cần thiết (việc sử dụng các thuật ngữ này có đủ rõ ràng không?). Tuy nhiên, có một bản sửa lỗi khiến nó trở thành chủ trước khi nhà phát triển nhận ra rằng nó nên được đặt ở phía dưới và nếu nó đã được đẩy (thậm chí tệ hơn, được hợp nhất hoặc một cái gì đó dựa trên nó) thì tùy chọn còn lại là chọn anh đào, với hiểm họa liên quan của nó. Những quy tắc đơn giản như vậy bạn sử dụng?Ngoài ra trong điều này còn bao gồm sự lúng túng của một nhánh chủ đề nhất thiết phải loại trừ các nhánh chủ đề khác (giả sử chúng được phân nhánh từ một đường cơ sở chung). Các nhà phát triển không muốn hoàn thành một tính năng để bắt đầu một tính năng khác giống như mã họ vừa viết không còn ở đó nữa

4. Làm thế nào để tránh tạo xung đột hợp nhất (do cherry-pick)?

   Điều có vẻ như là một cách chắc chắn để tạo ra một cuộc xung đột hợp nhất là chọn cherry giữa các nhánh, chúng không bao giờ có thể được hợp nhất lại? Sẽ áp dụng cùng một cam kết trong hoàn nguyên (làm thế nào để làm điều này?) Trong một trong hai chi nhánh có thể giải quyết tình huống này? Đây là một lý do tôi không dám thúc đẩy một quy trình làm việc dựa trên hợp nhất.

5. Làm thế nào để phân hủy thành các chi nhánh?

   Chúng tôi nhận thấy rằng sẽ rất tuyệt vời khi lắp ráp một tích hợp đã hoàn thành từ các nhánh chủ đề, nhưng thường thì các nhà phát triển của chúng tôi không làm việc rõ ràng (đôi khi đơn giản như "chọc ngoáy") và nếu một số mã đã đi vào chủ đề "linh tinh", nó không thể được đưa ra khỏi đó một lần nữa, theo câu hỏi trên? Làm thế nào để bạn làm việc với việc xác định / phê duyệt / tốt nghiệp / phát hành các nhánh chủ đề của bạn?

6. Các thủ tục thích hợp như xem xét mã và tốt nghiệp tất nhiên sẽ rất đáng yêu.

   Nhưng chúng tôi chỉ đơn giản là không thể giữ mọi thứ đủ rối để quản lý điều này - có đề xuất nào không? hội nhập ngành, minh họa?

Dưới đây là danh sách các câu hỏi liên quan:

• Một số chiến lược tốt để cho phép các ứng dụng được triển khai là hotfix là gì?
• Mô tả quy trình làm việc để sử dụng Git để phát triển nội bộ
• Quy trình công việc Git để phát triển nhân Linux của công ty
• Làm thế nào để bạn duy trì mã phát triển và mã sản xuất? (cảm ơn vì bản PDF này !)
• quản lý phát hành git
• Git Cherry-pick vs Hợp nhất công việc
• Cách chọn cherry nhiều lượt
• Làm thế nào để bạn hợp nhất các tệp chọn lọc với git-merge?
• Làm thế nào để anh đào chọn một loạt các cam kết và hợp nhất vào một chi nhánh khác
• Công việc của ReinH Git
• quy trình công việc git để thực hiện sửa đổi, bạn sẽ không bao giờ đẩy trở lại nguồn gốc
• Cherry-pick hợp nhất
• Quy trình làm việc Git thích hợp cho hệ điều hành kết hợp và mã riêng?
• Duy trì dự án với Git
• Tại sao không thể hợp nhất tệp Git thay đổi với cha / chủ đã sửa đổi.
• Git phân nhánh / nổi loạn thực hành tốt
• Khi nào "git pull --rebase" sẽ khiến tôi gặp rắc rối?
• DVCS được sử dụng như thế nào trong các đội lớn?

Ngoài ra, hãy kiểm tra xem SCM nhựa viết gì về phát triển theo hướng nhiệm vụ và nếu Nhựa không phải là lựa chọn của bạn, hãy nghiên cứu mô hình phân nhánh của nvie và các tập lệnh hỗ trợ của anh ấy .

Tính năng rắc rối nhất mà các nhà phát triển mới đối với DVCS cần nhận ra là về quy trình xuất bản :

• bạn có thể nhập (tìm nạp / kéo) bất cứ thứ gì từ xa mà bạn cần
• bạn có thể xuất bản (đẩy) lên bất kỳ repo (trần) nào bạn muốn

Từ đó, bạn có thể tôn trọng một vài quy tắc để làm cho câu hỏi của bạn dễ dàng hơn:

• chỉ rebase một nhánh nếu nó không được đẩy (không được đẩy kể từ lần rebase cuối cùng)
• chỉ đẩy lên một repo trần (bắt buộc kể từ Git1.7)
• làm theo lời khuyên của Linus về rebase và sáp nhập

Hiện nay:

Mô hình quy trình / phân nhánh :

mỗi quy trình làm việc đều có để hỗ trợ quy trình quản lý phát hành và được thiết kế riêng cho từng dự án.
Những gì tôi có thể thêm vào quy trình công việc mà bạn đề cập là: mỗi nhà phát triển không nên tạo một nhánh tính năng, chỉ một nhánh "dev hiện tại", bởi vì sự thật là: nhà phát triển thường không biết chính xác chi nhánh của mình sẽ tạo ra: một tính năng, một số (vì cuối cùng nó là một tính năng quá phức tạp), không có tính năng nào (vì chưa sẵn sàng để phát hành), một tính năng khác (vì tính năng ban đầu đã "biến hình"), ...

Chỉ một "nhà tích hợp" mới thiết lập các nhánh tính năng chính thức trên một repo "trung tâm", sau đó các nhà phát triển có thể tìm nạp lại để hợp nhất / hợp nhất phần công việc của họ phù hợp với tính năng đó.

Sáp nhập vs nổi loạn (rối và lịch sử tuần tự) :

Tôi thích câu trả lời của tôi mà bạn đề cập (" Mô tả quy trình làm việc để sử dụng git để phát triển nội bộ ")

Tôi đang tìm kiếm một quy trình làm việc tự nhiên :

để sửa lỗi, nó có thể giúp liên kết từng bản sửa lỗi với một vé từ theo dõi lỗi, giúp nhà phát triển nhớ nơi (ví dụ trên nhánh nào, tức là một nhánh chuyên dụng "để sửa lỗi") anh ấy / cô ấy nên thực hiện các sửa đổi đó.
Sau đó, móc có thể giúp bảo vệ một repo trung tâm chống lại các cú đẩy từ các sửa lỗi không được xác thực hoặc từ các nhánh mà người ta không nên đẩy. (không có giải pháp cụ thể nào ở đây, tất cả điều này cần phải được điều chỉnh phù hợp với môi trường của bạn)

Làm thế nào để tránh tạo xung đột hợp nhất (do cherry-pick)?

Như Jakub Narębski đã nêu trong câu trả lời của mình , việc hái anh đào nên được dành riêng cho các tình huống hiếm khi cần thiết.
Nếu thiết lập của bạn liên quan đến nhiều lựa chọn anh đào (nghĩa là "nó không phải là hiếm"), thì có gì đó đã tắt.

Sẽ áp dụng cùng một cam kết trong hoàn nguyên (làm thế nào để làm điều này?)

git revert nên quan tâm đến điều đó, nhưng đó không phải là lý tưởng.

Làm thế nào để phân hủy thành các chi nhánh?

Chừng nào một chi nhánh chưa được đẩy đi khắp nơi, một nhà phát triển nên tổ chức lại lịch sử cam kết của mình (một khi cuối cùng anh ta / cô ta thấy sự phát triển có hình dạng rõ ràng và ổn định hơn) thành:

• một số chi nhánh nếu cần (một tính năng được xác định rõ ràng)
• một tập hợp các cam kết trong một nhánh (xem phần Kiểm tra Git )

Thủ tục thích hợp như xem xét mã và tốt nghiệp?

Repo chi nhánh tích hợp (tích hợp chuyên dụng) có thể giúp nhà phát triển:

• khởi động lại sự phát triển của anh ấy / cô ấy trên đỉnh của nhánh tích hợp từ xa đó (pull --rebase)
• giải quyết tại địa phương
• đẩy sự phát triển đến repo đó
• kiểm tra với bộ tích hợp mà không dẫn đến một mớ hỗn độn;)

Tôi nghĩ, và tôi có thể sai, rằng một trong những điều bị hiểu lầm nhiều nhất về git là bản chất phân tán của nó. Điều này làm cho rất khác khi nói lật đổ theo cách bạn có thể làm việc mặc dù bạn có thể bắt chước hành vi SVN nếu bạn muốn. Vấn đề là khá nhiều quy trình công việc sẽ làm, điều này thật tuyệt nhưng cũng gây hiểu lầm.

Nếu tôi có hiểu biết về phát triển kernel (tôi sẽ tập trung vào điều đó), mọi người đều có kho git riêng để phát triển kernel. Có một kho lưu trữ, linux-2.6.git, được Torvalds chăm sóc, hoạt động như kho lưu trữ phát hành. Mọi người nhân bản từ đây nếu họ muốn bắt đầu phát triển một tính năng chống lại nhánh "phát hành".

Các kho khác làm một số phát triển. Ý tưởng là sao chép từ linux-2.6, phân nhánh bao nhiêu lần tùy thích cho đến khi bạn có một tính năng "mới" hoạt động. Sau đó, khi điều này đã sẵn sàng, bạn có thể cung cấp nó cho một người được coi là đáng tin cậy, người sẽ kéo chi nhánh này từ kho lưu trữ của bạn vào kho của họ và hợp nhất nó vào dòng chính. Trong kernel linux, điều này xảy ra ở một số cấp độ (trung úy đáng tin cậy) cho đến khi nó đạt tới linux-2.6.git, tại đó nó trở thành "kernel".

Bây giờ đây là nơi mà nó trở nên khó hiểu. Tên chi nhánh không cần nhất quán trong các kho lưu trữ. Vì vậy, tôi có thể git pull origin master:vanilla-codevà lấy một nhánh từ originchủ của nó trong một nhánh trong kho lưu trữ của tôi được gọi làvanilla-code . Cung cấp cho tôi biết những gì đang xảy ra, nó thực sự không thành vấn đề - nó được phân phối theo nghĩa là tất cả các kho lưu trữ là đồng đẳng với nhau và không chỉ được chia sẻ trên một số máy tính như SVN.

Vì vậy, với tất cả những điều này trong tâm trí:

1. Tôi nghĩ rằng tùy thuộc vào mỗi lập trình viên cách họ phân nhánh. Tất cả những gì bạn cần là một kho lưu trữ trung tâm để quản lý các bản phát hành, vv Trunk có thể head. Các bản phát hành có thể là thẻ hoặc chi nhánh và hotfix có thể là các nhánh trong chính chúng. Trên thực tế, có lẽ tôi sẽ phát hành dưới dạng các nhánh để bạn có thể tiếp tục vá chúng.
2. Tôi sẽ hợp nhất và không rebase. Ví dụ: nếu bạn lấy một kho lưu trữ, sao chép nó, phân nhánh và thực hiện một số dev, sau đó lấy từ originkho lưu trữ của bạn, có thể tạo một nhánh khác và hợp nhất mới nhất mastervào yourbranchđể người khác có thể lấy các thay đổi của bạn với ít nỗ lực như khả thi. Theo kinh nghiệm của tôi, rất hiếm khi cần phải thực sự nổi loạn.
3. Tôi nghĩ đó là một trường hợp hiểu cách Git hoạt động và những gì nó có thể làm. Phải mất một thời gian và rất nhiều giao tiếp tốt - tôi chỉ thực sự bắt đầu hiểu những gì đang xảy ra khi tôi bắt đầu sử dụng git với các nhà phát triển khác và ngay cả bây giờ, một số điều tôi không chắc chắn.
4. Hợp nhất xung đột là hữu ích. Tôi biết, tôi biết, bạn muốn tất cả hoạt động, nhưng, thực tế là mã thay đổi và bạn cần phải hợp nhất các kết quả vào một cái gì đó hoạt động. Hợp nhất xung đột trong thực tế chỉ là lập trình nhiều hơn. Tôi chưa bao giờ tìm thấy một lời giải thích dễ dàng về những gì cần làm về chúng, vì vậy đây là: lưu ý các tệp có xung đột hợp nhất, đi và thay đổi chúng thành những gì chúng nên, git add .và sau đó git commit.
5. Tuy nhiên, nó phù hợp. Như tôi đã nói, mỗi người dùng git repository là của riêng họ để chơi và tên nhánh không cần phải giống nhau . Ví dụ: nếu bạn có kho lưu trữ theo giai đoạn, bạn có thể thực thi lược đồ đặt tên, nhưng bạn không cần cho mỗi nhà phát triển, chỉ trong bản phát hành repo.
6. Đây là giai đoạn hợp nhất. Bạn chỉ hợp nhất vào các nhánh phát hành, vv khi bạn xem xét mã để được xem xét / vượt qua kiểm tra chất lượng.

Tôi hy vọng điều đó sẽ giúp. Tôi nhận ra VonC khi vừa đăng một lời giải thích rất giống nhau ... Tôi không thể gõ đủ nhanh!

Chỉnh sửa một số suy nghĩ thêm về cách sử dụng git trong cài đặt thương mại, vì điều này có vẻ phù hợp với OP từ các bình luận:

• Kho lưu trữ phát hành, chúng tôi sẽ gọi nó product.git, có thể truy cập được bởi một số lập trình viên / người kỹ thuật cao cấp chịu trách nhiệm thực sự chăm sóc sản phẩm. Chúng tương tự như vai trò của người duy trì trong OSS.
• Những lập trình viên này có lẽ cũng một phần dẫn đầu phát triển các phiên bản mới, vì vậy họ cũng có thể tự viết mã và duy trì kho lưu trữ varios. Họ có thể quản lý kho lưu trữ cho các tính năng thực sự mới và họ cũng có thể có kho lưu trữ riêng.
• Dưới họ là các lập trình viên chịu trách nhiệm phát triển các bit riêng lẻ. Ví dụ, ai đó có thể chịu trách nhiệm cho công việc UI. Do đó, họ quản lý kho UI.git.
• Bên dưới họ là những lập trình viên thực tế, những người phát triển các tính năng như công việc hàng ngày của họ.

Vậy chuyện gì xảy ra? Chà, mọi người đều bắt đầu mỗi ngày từ nguồn "ngược dòng", tức là kho lưu trữ phát hành (cũng có thể sẽ chứa tài liệu mới nhất từ ​​sự phát triển của những ngày trước). Mọi người làm điều này, trực tiếp. Điều này sẽ đi trên một nhánh trong kho lưu trữ của họ, có thể được gọi là "chủ" hoặc có thể nếu bạn được gọi là "mới nhất". Các lập trình viên sau đó sẽ làm một số công việc. Công việc này có thể là điều họ không chắc chắn, vì vậy họ tạo ra một chi nhánh, thực hiện công việc. Nếu nó không hoạt động, họ có thể xóa chi nhánh và quay trở lại. Nếu vậy, họ sẽ phải hợp nhất vào chi nhánh chính mà họ hiện đang làm việc. Chúng tôi sẽ nói rằng đây là một lập trình viên UI làm việc latest-uivì vậy anh ta làm . Sau đó, anh ta nói với lãnh đạo kỹ thuật của mình (lãnh đạo UI) này, tôi đã hoàn thành một nhiệm vụ như vậy, lấy từ tôi.git checkout latest-ui theogit merge abc-ui-mywhizzynewfeaturegit pull user-repo lastest-ui:lastest-ui-suchafeature-abc. Người lãnh đạo UI sau đó nhìn vào chi nhánh đó và nói rằng, thực sự, điều đó rất tốt, tôi sẽ hợp nhất nó vào ui-latest. Sau đó anh ta có thể nói với mọi người bên dưới anh ta kéo anh ta vềui-latest nhánh hoặc bất kỳ tên nào họ đã đặt cho họ, và vì vậy tính năng này được khám phá bởi các nhà phát triển. Nếu nhóm hài lòng, trưởng nhóm UI có thể yêu cầu trưởng nhóm thử nghiệm rút từ anh ta và hợp nhất các thay đổi. Điều này tuyên truyền cho mọi người (hạ lưu thay đổi), những người kiểm tra nó và gửi báo cáo lỗi, v.v ... Cuối cùng, nếu tính năng vượt qua thử nghiệm, v.v., một trong những khách hàng tiềm năng kỹ thuật hàng đầu có thể hợp nhất nó vào bản sao làm việc hiện tại của chương trình, tại thời điểm đó tất cả các thay đổi sau đó được truyền trở lại. Và như thế.

Đây không phải là cách làm việc "truyền thống" và được thiết kế để "điều khiển ngang hàng" thay vì "phân cấp" như SVN / CVS. Về bản chất, mọi người đều có quyền truy cập, nhưng chỉ tại địa phương. Đó là quyền truy cập vào kho lưu trữ và kho lưu trữ nào bạn chỉ định làm repo phát hành cho phép bạn sử dụng phân cấp.

Một mô hình mà tôi đã sử dụng với kết quả tốt là như sau:

Một repo "may mắn" mọi người đẩy và kéo đến / từ, về cơ bản là một cấu trúc liên kết máy khách-máy chủ.

Không có nhánh chính nên không nhà phát triển nào có thể đẩy bất kỳ mã nào vào "đường chính".

Tất cả các phát triển xảy ra trên các nhánh chủ đề. Chúng tôi đặt tên theo tên để dễ dàng phát hiện ai chịu trách nhiệm cho nó: jn / newFeature hoặc jn / vấn đề-1234

Ngoài ra còn có một ánh xạ gần 1 đến 1 giữa các nhánh và thẻ kanban / scrum trên bảng trắng.

Để phát hành một chi nhánh, nó được đẩy đến repo may mắn và thẻ kanban được di chuyển để sẵn sàng để xem xét.

Sau đó, nếu chi nhánh được chấp nhận bởi đánh giá, nó là một ứng cử viên cho một bản phát hành.

Một bản phát hành xảy ra khi một tập hợp các nhánh được chấp nhận được hợp nhất với nhau và được gắn thẻ với một số phiên bản.

Bằng cách đẩy thẻ mới vào repo may mắn, có một cơ sở mới có thể cho các tính năng mới.

Để tránh xung đột hợp nhất, các nhà phát triển vui lòng yêu cầu cập nhật (hợp nhất) các nhánh chưa phát hành của họ lên thẻ phát hành mới nhất.

Cá nhân, tôi cố gắng và chỉ giữ mã sẵn sàng phát hành trong nhánh chính.

Khi tôi làm việc trên một tính năng mới hoặc sửa lỗi, tôi làm điều đó trong một nhánh. Tôi cũng kiểm tra đơn vị trong chi nhánh. Nếu mọi thứ đều ổn, chỉ sau đó tôi mới hợp nhất / rebase trở lại thành chủ.

Tôi cũng thử và sử dụng các quy ước đặt tên chi nhánh phổ biến, chẳng hạn như:

• bugfix / recursive_loop
• sửa lỗi / sql_timeout
• tính năng / new_layout
• tính năng / nâng cao