Những lợi thế của việc sử dụng phân nhánh như một nhà phát triển solo là gì?

Trước hết, tôi biết rằng nhiều câu hỏi đã được hỏi về VCS với tư cách là nhà phát triển solo, nhưng chúng thường quá rộng. Điều này chỉ liên quan đến việc phân nhánh, và nó vẫn được đánh dấu là một bản sao ... một lần nữa, được cho là trùng lặp với một câu hỏi khác quá rộng và không liên quan đến việc phân nhánh cụ thể. Đó là cách câu hỏi của tôi độc đáo.

Những lợi thế, nếu có, của việc sử dụng phân nhánh như một nhà phát triển solo là gì? Tôi thường thấy nó được đề xuất ngay cả trong bối cảnh solo-dev, nhưng theo như tôi có thể thấy, ngoài việc sử dụng một thân cây 'chính chủ' để phát triển và phân nhánh để làm việc, mã sẵn sàng phát hành, tôi không thấy cách Tôi có thể khai thác sức mạnh của sự phân nhánh (ví dụ, để ngăn chặn các tính năng mới) mà không làm phức tạp quá trình phát triển.

Những lợi thế chủ yếu giống như đối với các nhóm các nhà phát triển. Bằng cách sử dụng nhánh chính luôn sẵn sàng phát hành và các nhánh tính năng để phát triển các tính năng mới, bạn luôn có thể giải phóng nhánh chính. Tìm một lỗi quan trọng trong khi làm việc trên một tính năng? Chuyển nhánh, sửa chữa, phát hành, chuyển trở lại và tiếp tục phát triển.

Hoặc có thể đây là một dự án sở thích và bạn chỉ thích có thể làm việc một chút với tính năng này và một chút về điều đó, khi tâm trạng tấn công bạn. Về cơ bản, bạn đang mô phỏng một nhóm nhiều người bằng cách cắt thời gian.

Sự phân nhánh ngầm mà các DVCS thực hiện trên các bản sao có nghĩa là các nhánh chính thức trên kho lưu trữ có thẩm quyền ít liên quan đến việc phối hợp mọi người và nhiều hơn về việc điều phối các hướng phát triển, và thậm chí một người có thể thực hiện nhiều trong số đó.

Phát triển lâu dài

Việc phân nhánh cho một nhóm người sẽ hữu ích cho tính năng phát triển dài hạn mà không phù hợp với chu kỳ phát hành của bạn.

Bạn có thể nhận một chi nhánh cho thay đổi kéo dài nhiều tháng của mình và vẫn có thể đẩy bất kỳ sửa lỗi hàng ngày hoặc thay đổi từ chi nhánh chính của bạn theo định kỳ.

Điều này có lợi thế hơn 'công tắc' trong một nhánh duy nhất ở đó nhánh chính của bạn luôn ở trạng thái có thể triển khai và bạn được đảm bảo rằng không có gì trong tính năng chạy dài có ảnh hưởng đến mã khác, đã được thử nghiệm trước đó.

Tính năng thử nghiệm

Một nhánh cũng có thể hữu ích cho các tính năng mà bạn có thể muốn tạo nguyên mẫu, nhưng có thể không bao giờ biến nó thành mã được triển khai của bạn. Hoàn thành những điều này trên một nhánh mà cuối cùng tôi bị vứt bỏ có nghĩa là bạn không bao giờ làm ô nhiễm cơ sở mã chính của mình một cách không cần thiết.

Tôi sử dụng nó để bảo trì trang web quan trọng. Tôi là nhà phát triển duy nhất nhưng tôi có một bậc thầy, phát triển và phát hành chi nhánh.

Quá trình làm việc của tôi để thiết lập trang web trông như thế này:

1. Làm việc chi nhánh tổng thể. Làm cam kết ban đầu.

2. Thanh toán phát triển chi nhánh. Đừng làm bất cứ điều gì, phát triển các chức năng như một bộ đệm thử nghiệm để hợp nhất thành chủ.

3. Thanh toán phát hành chi nhánh. Mã hóa vấn đề của bạn, khi nó được thực hiện, kéo nó vào phát triển, xem có vấn đề nào phát sinh không, hợp nhất các xung đột, v.v ... khắc phục những vấn đề đó.

Khi đủ các vấn đề được sáp nhập vào phát triển để phát hành và phát triển đã được kiểm tra tính ổn định, hãy kéo phát triển thành chủ.

   Master
     |
   Develop  - E
   / |  \  \
 A   B   C  D

Bằng cách đó, bạn có được một bộ sưu tập thử nghiệm đầy đủ trong quá trình phát triển, nơi bạn có thể kiểm tra tính ổn định, các vấn đề, v.v ... mà không phải mạo hiểm làm tổn thương Master và phải quay lại cam kết nếu chúng có hại.

Ngoài ra, bằng cách sử dụng các nhánh riêng lẻ để cam kết, bạn có thể "rời bỏ" công việc bạn đã làm, bắt đầu làm mới một thứ khác để khắc phục vấn đề khẩn cấp hơn và giải quyết vấn đề đó sớm hơn.

Trong cuộc sống thực, tôi thường có một nhánh phát hành, và kéo cái đó phát triển và sau đó thành chủ. Đôi khi thật tẻ nhạt, nhưng ít nhất hai tháng một lần tôi phải bỏ công việc xuống mũ vì ai đó có ý tưởng rằng tôi phải tạo RightNow ™ và bằng cách đó tôi có thể nhanh chóng chuyển về trạng thái cơ bản, tạo ra điều đó và sau đó tiếp tục nơi tôi đang ở. Đặc biệt với các dự án lớn mất nhiều tuần, đây là một vị thần mà tôi có thể nhanh chóng chuyển đổi chi nhánh.

Hãy xem xét kịch bản này: Bạn luôn làm việc trên một chi nhánh chính và bạn có AwesomeCodeThing ™ trong các công trình mà lá cành Thạc sĩ của bạn trong phẫu thuật tim mở và một YugeBug ™ bật lên mà cần sửa chữa khẩn cấp khác hàng ngàn người dùng sẽ phàn nàn với bạn về BigProblems ™
Các cách duy nhất để nhanh chóng giải quyết vấn đề của bạn trong một kịch bản như vậy,

1. kiểm tra các cam kết trước đó của bạn,
2. xem khi nào cam kết ổn định cuối cùng của bạn là (chửi là tùy chọn)
3. quay trở lại cam kết đó
4. sửa chữa, đẩy sửa chữa ra sản xuất
5. giải quyết tất cả các xung đột và sự cố mà bạn hiện đang cố gắng để quay lại trạng thái AwesomeCodeThing ™
6. từ bỏ, khóc và bắt đầu công việc. (không bắt buộc)

Nếu bạn sử dụng chi nhánh:

1. Thanh toán chính
2. tạo chi nhánh UrgentFix ™ và sửa lỗi
3. kéo UrgentFix ™ thành chủ
4. đẩy mạnh sản xuất
5. Hợp nhất chủ để phát triển
6. Hợp nhất phát triển thành AwesomeCodeThing ™
7. lấy bia và tiếp tục làm việc

Các nhánh giúp dễ dàng làm việc trên nhiều tính năng cùng một lúc, điều này có thể khá hữu ích khi các ưu tiên thay đổi trong quá trình thực hiện dự án.

Nói rằng bạn quyết định một tính năng quan trọng hơn bây giờ. Có lẽ bạn rất cần phải vá một lỗi nghiêm trọng trong một hệ thống trực tiếp. Bạn có thể làm việc với khách hàng trên nhiều tính năng trong một khoảng thời gian dài và có thể muốn demo riêng từng tiến trình của tính năng. Có lẽ bạn vừa đọc về một khai thác 0 ngày khó chịu và muốn truy cập vào nó trước khi khách hàng nói về nó.

Nếu bạn đang sử dụng các nhánh cho từng tính năng / hotfix, thông thường sẽ dễ dàng hơn, sạch hơn và nhanh hơn để cô lập và triển khai các sửa đổi này thay vì sử dụng một nhánh duy nhất cho mọi thứ. Điều này đúng cho dù bạn là nhà phát triển duy nhất hay là một phần của nhóm.

Đối với một quá trình thực tế, tôi thấy luồng git hoạt động tốt. Bảng chit Flow git của Daniel Kummer là một tài nguyên tuyệt vời, nó đáng để xem xét ngay cả khi bạn không sử dụng git.

Như các áp phích khác đã đề cập, các ưu điểm rất giống với làm việc theo nhóm: Khả năng phát triển độc lập và kiểm tra các tính năng, duy trì một nhánh chính riêng cho các triển khai hotfix / sản xuất, thử nghiệm.

Đối với cá nhân tôi, tôi thường có xu hướng làm việc trong tổng thể nếu tôi biết khu vực tôi đang làm việc rất tốt, nó chỉ thêm chi phí cho chi nhánh vì dù sao tôi cũng sẽ hợp nhất chúng.

Tuy nhiên, nếu tôi có bất kỳ do dự nào về những thay đổi tôi đang thực hiện, tôi sẽ phân nhánh và chỉ PR / hợp nhất một khi chi nhánh hoạt động như mong đợi và thường được kiểm tra đầy đủ. Theo cách đó, nếu tôi phát hiện ra một vấn đề mà quay lại là cách hành động tốt nhất, thì đó là một cam kết duy nhất thay vì toàn bộ một chuỗi (tôi không bao giờ có thể nhớ cú pháp để quay lại một loạt các cam kết nhưng một lần duy nhất là dễ dàng).