Trong luồng GitHub, bạn có thể sử dụng nhánh tính năng trên nhánh tính năng khác không?


22

Chúng tôi sử dụng GitHub Flow trong dự án của chúng tôi và hầu hết thời gian, chúng tôi mở một nhánh tính năng mới từ master , thực hiện một số công việc ở đó, mở PR, xem lại mã và hợp nhất trở lại thành master .

Tuy nhiên, công việc hiện tại của tôi phụ thuộc vào một vấn đề khác đang được giải quyết feature-branch-A. Là nó tốt hơn để tạo chi nhánh của tôi từ chi nhánh khác hoặc đó là trái với tinh thần của GitHub Flow?

Thay thế sẽ là dựa vào chi nhánh của tôi dựa trên chủ và hợp nhất - trong các thay đổi từ feature-branch-A(thường xuyên).

Tùy chọn nào được ưa thích trong luồng GitHub?

Câu trả lời:


24

Đây là quy trình công việc mà tôi theo dõi khi tôi phân nhánh từ một nhánh tính năng:

  1. Tạo feature-branch-Btừfeature-branch-A
  2. Làm việc trên feature-branch-B
  3. Nếu nhiều cam kết được thêm vào feature-branch-Asau khi phân nhánh, hãy rebase feature-branch-Blênfeature-branch-A
  4. Kết thúc công việc feature-branch-Bvà chờ đợi cho đến khi feature-branch-Ađược hợp nhất vào master.
  5. Sau khi feature-branch-Ađược hợp nhất vào master, rebase feature-branch-Blênmaster
  6. Hợp nhất feature-branch-Bthànhmaster

Bằng cách làm theo quy trình công việc trên, có vẻ như bạn đã phân nhánh từ mastersau khi feature-branch-Ađược hợp nhất. Bạn không phải đợi đến khi feature-branch-Ađược hợp nhất để bắt đầu công việc feature-branch-B. Tuy nhiên, bạn sẽ có được một lịch sử sạch mà không có bất kỳ cây phức tạp.


Đây chính xác là câu trả lời tôi đang tìm kiếm! Bạn đã cứu tôi đau đầu của việc sắp xếp nó ra, cảm ơn!
Vance Palacio

Đừng rebase cam kết đã được công bố ... daolf.com/posts/git-series-part-2
Sebi2020

8

Tôi nghĩ rằng điều này là hoàn toàn ok nếu bạn tạo tính năng này ở một tính năng khác.

Nhưng đừng làm điều đó khá thường xuyên. Tôi thấy một nhà phát triển đã thực hiện điều này và một hoặc hai tuần anh ta ném 10 PR ra để hợp nhất. Điều đó đã hoàn toàn mệt mỏi cho các thành viên khác để xem xét và khó để hợp nhất quá. Cố gắng đừng làm cây trong git. Điều đó giúp với bisect để tìm lỗi.


7

Một điều quan trọng mà git-Flow dự định giải quyết là khả năng suy luận về vai trò của một nhánh nhất định và những gì nó phân nhánh và hợp nhất với nó.

Lý tưởng nhất là tất cả các chi nhánh hợp nhất trở lại dòng mã mà chúng được hợp nhất từ ​​đó. Đây thường là một sự hợp nhất từ ​​dòng chính (trong dòng git này là dev). Tính năng nhánh nhánh và hợp nhất từ ​​dev, phát hành nhánh nhánh và hợp nhất từ ​​dev (có thêm hợp nhất vào master). Hot fix chi nhánh và hợp nhất từ ​​master (với sự hợp nhất bổ sung đó trở lại dev).

Mỗi nhánh mã từ và hợp nhất trở lại cha mẹ của nó. Một dòng mã có thể lấy mã từ các bộ mã khác bất cứ lúc nào nếu cần thiết.

Nếu nhánh từ nhánh tính năng là "Tôi muốn khám phá cách khắc phục sự cố trong nhánh tính năng đó" - hoàn toàn tốt. Nó phân nhánh từ nhánh tính năng, cam kết một số mã và hợp nhất trở lại nhánh tính năng (hoặc bị loại bỏ).

  1. chi nhánh từ tính năng
  2. khám phá ý tưởng
  3. hợp nhất để tính năng

Tuy nhiên, những gì bạn muốn tránh là một cái gì đó trông giống như:

  1. chi nhánh từ tính năng bắt buộc
  2. làm việc trên mã
  3. hợp nhất từ ​​dev khi tính năng được yêu cầu hoàn tất
  4. xác minh chức năng (và các cam kết bổ sung) trong nhánh tính năng
  5. hợp nhất để phát triển

Lý do là bắt đầu và kết thúc không khớp - điều này khiến cho việc hiểu điều này là và khó khăn hơn một chút. Không phải là không thể, nhưng nó chỉ khiến người khác mất thêm một chút thời gian để hiểu vai trò của nó.

Tuy nhiên, nếu đây là tính năng mới phụ thuộc vào mã chưa được tìm thấy trong dev, luồng sẽ là:

  1. chi nhánh từ nhà phát triển
  2. hợp nhất từ ​​tính năng bắt buộc
  3. làm việc trên mã
  4. hợp nhất từ ​​dev khi tính năng được yêu cầu hoàn tất
  5. xác minh chức năng (và các cam kết bổ sung) trong nhánh tính năng
  6. hợp nhất để phát triển

Lưu ý rằng điều này bắt đầu với một nhánh từ dev và kết thúc bằng một hợp nhất thành dev.

Tất cả những gì đã nói, có lẽ điều tốt nhất để làm là tránh thực hiện hợp nhất từ ​​tính năng này sang tính năng khác. Chi nhánh tính năng, làm bất cứ điều gì sơ bộ là cần thiết ... và chờ đợi.

  1. chi nhánh từ nhà phát triển
  2. làm việc trên mã
  3. hợp nhất từ ​​dev khi tính năng được yêu cầu hoàn tất
  4. xác minh chức năng (và các cam kết bổ sung) trong nhánh tính năng
  5. hợp nhất để phát triển

Điều này cung cấp tập hợp các nhánh và mã ổn định nhất.

Một cái gì đó để xem xét cho công việc trong tương lai sẽ có một tính năng để xuất bản các giao diện cần thiết cho khả năng tương tác với các tính năng khác - ngay cả khi mã triển khai chưa hoàn tất. Điều này sẽ được hợp nhất với dev và sau đó tính năng bắt buộc có thể hoạt động trên các giao diện đó như tính năng trong tương lai. Điều này có thể sẽ cho phép tính năng trong tương lai tiến xa hơn (mã hóa các giao diện, kiểm tra các gốc thực thi giao diện) so với khi nó phải chờ tính năng bắt buộc để hợp nhất để phát triển.


Trong bộ bước thứ ba của bạn, nhược điểm là bước 1 cần chứa một số "cam kết giả". Trong tình huống của tôi, tôi không có bất cứ điều gì hữu ích để cam kết cho đến khi required-featuređược hợp nhất.
Borek Bernard

Tôi vẫn chỉ ra nó là một trong những bài viết yêu thích của tôi về phân nhánh: Chiến lược phân nhánh SCM nâng cao . Mặc dù nó tập trung vào một hệ thống kiểm soát phiên bản tập trung, các ý tưởng về vai trò mà nó thể hiện chính xác là ánh xạ tới luồng git.

Và như với cam kết giả, đó là lý do tại sao đoạn cuối đó là ở đó. Những gì có thể hữu ích là một tính năng chạy và hoàn thành là "cung cấp giao diện để làm công cụ". Sau đó, cả tính năng bắt buộc và tính năng trong tương lai có thể hoạt động trên các giao diện đó. Mặc dù tính năng bắt buộc hoạt động trong việc thực hiện các giao diện, tính năng trong tương lai sẽ có thể loại bỏ chúng và thực hiện các thử nghiệm chống lại chúng - chờ tính năng được yêu cầu được hợp nhất với dev.

Tự hỏi làm thế nào xấu bộ thứ hai của bạn là bước. Có phải vấn đề trong thực tế là một chi nhánh không có điểm bắt đầu và kết thúc "giống nhau" không? Tôi không nghĩ rằng nó sẽ làm phiền tôi quá nhiều nhưng có lẽ đó là một yếu tố gây rối lớn?
Borek Bernard

Đây là vấn đề mô tả rõ ràng thông qua chi nhánh, cam kết và hợp nhất lịch sử xem nhánh nào là nhánh mẹ. Trong luồng git, bạn nên theo dõi hệ thống được mô tả trong các nhánh tính năng của luồng git . Các nhánh tính năng từ nhánh phát triển và hợp nhất trở lại để phát triển. Khi bạn bắt đầu phân nhánh từ các nhánh tính năng khác, nó trở nên ít rõ ràng hơn về vai trò của nhánh đó. Tôi sẽ khuyến khích bạn đợi cho đến khi tính năng bắt buộc được thực hiện nếu bạn không thể tiến hành mã mà không có nó ngay bây giờ.

1

Một nhánh tính năng thường được coi là kém ổn định hơn thân cây (phát triển / chính), do đó bạn có thể tự mình chịu nhiều thay đổi cơ bản hơn bình thường nếu bạn dựa vào công việc của mình.

Ngoài ra, trong khi bình thường cau mày nếu nhánh bị đẩy, không có gì lạ khi khởi động lại các nhánh tính năng trên nhánh cha của chúng, để có một lịch sử đẹp hơn, nhưng điều đó sẽ phức tạp hơn nếu có thêm các nhánh treo ở đó, vì vậy bạn về cơ bản là tạo ra một hạn chế mới cho chủ sở hữu chi nhánh mẹ, cũng như những vấn đề đau đầu tiềm ẩn cho chính bạn.

Điều đó nói rằng, không có quy tắc nghiêm ngặt chống lại nó. Đây chỉ là mô hình và thực hành tốt nhất sau khi tất cả.

Chỉnh sửa: bỏ lỡ một phần câu hỏi của bạn. Hợp nhất nhánh tính năng thành nhánh của bạn, dựa trên chủ nhân không thực sự tránh được bất kỳ vấn đề nào được đề cập ở trên và thực sự có thể tạo ra một lịch sử thậm chí còn phức tạp hơn.

Do đó, nếu tôi ở trong đôi giày của bạn và tôi có thể trì hoãn công việc cho đến khi tính năng này được thực hiện hoặc làm một việc khác trước, tôi sẽ làm điều đó.

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.