Git - Những vấn đề phát sinh từ làm việc trực tiếp trên chủ?

Tôi đã thấy rất nhiều lời khuyên về các mô hình phân nhánh git và ý kiến ​​phổ biến nhất dường như là thực hiện các thay đổi trực tiếp trên nhánh chính là một ý tưởng tồi.

Một trong những đồng nghiệp của chúng tôi khá vui khi thực hiện các thay đổi trực tiếp trên nhánh chính và mặc dù có một vài cuộc trò chuyện, họ dường như không thể thay đổi điều này.

Tại thời điểm này, tôi không thể thuyết phục một đồng nghiệp là một thực hành tồi để làm việc trực tiếp với chủ, nhưng tôi muốn hiểu những điều sẽ xung đột với cách làm việc của anh ta, để biết khi nào tôi cần xem lại vấn đề này.

Có một số vấn đề khi các cam kết được đẩy trực tiếp lên chủ

• Nếu bạn đẩy trạng thái tiến hành công việc sang điều khiển từ xa, bản gốc có khả năng bị hỏng
• Nếu một nhà phát triển khác bắt đầu làm việc cho một tính năng mới từ chủ, cô ấy bắt đầu với trạng thái có khả năng bị hỏng. Điều này làm chậm sự phát triển
• Các tính năng / lỗi khác nhau không bị cô lập, do đó, sự phức tạp của tất cả các nhiệm vụ phát triển đang diễn ra được kết hợp trong một nhánh. Điều này làm tăng lượng giao tiếp cần thiết giữa tất cả các nhà phát triển
• Bạn không thể thực hiện các yêu cầu kéo là cơ chế rất tốt để đánh giá mã
• Bạn không thể squash cam kết / thay đổi lịch sử git nói chung, vì các nhà phát triển khác có thể đã kéo nhánh chính trong thời gian này

Giải thích cho anh ta rằng các tính năng mới cần nhánh phát triển của riêng họ có thể được triển khai đến môi trường thử nghiệm trước khi được đẩy vào sản xuất.

Mặt khác, bạn đang ở trong trạng thái vĩnh viễn của các tính năng đã hoàn thành một nửa. Bạn không thể triển khai các tính năng đã hoàn thành một nửa để sản xuất, vì vậy nếu bạn làm việc trực tiếp trên nhánh chính, mọi người khác phải đợi bạn hoàn thành tính năng của mình trước khi mọi thay đổi của người khác có thể đi vào sản xuất, bao gồm sửa lỗi.

Sử dụng các nhánh độc lập cho các tính năng có nghĩa là mỗi tính năng mới có thể được kiểm tra và triển khai độc lập với các tính năng khác.

Sư phụ nên có khả năng đáng tin cậy. Giai đoạn. Không nên có một nửa công việc hoàn thành trong tổng thể (trừ khi bị vô hiệu hóa với cờ tính năng)

Nói vậy, Ive đã thấy một số đội làm phức tạp dòng chảy của họ.

Không sử dụng PR khi tích hợp để làm chủ là một sai lầm vì các nhà phát triển sẽ không có quyền lựa chọn khi tích hợp xảy ra.

Một nhánh phát triển duy nhất mang lại rất ít giá trị. Thông thường nó chỉ làm phức tạp mọi thứ. Nhiều nhánh tính năng mang lại nhiều giá trị.

Tạo các nhánh cho mỗi môi trường (dev, test, prod) là một sai lầm. Điều này nằm ngoài phạm vi của git và nên được xử lý bởi đường ống phát hành. Việc xây dựng chính xác giống nhau nên được triển khai cho tất cả các môi trường không thể thực hiện được nếu có các nhánh cho từng môi trường.

Nếu một tính năng quá lớn thì không thể thực hiện trong một hoặc hai ngày cho một nhánh tính năng nên ở các nhánh riêng biệt và được tích hợp với PR.

• Master nên phản ánh một nhánh sản xuất, một phiên bản cuối cùng hoạt động.
• Làm việc trực tiếp trong bản gốc có nghĩa là nếu bạn tạo ra lỗi, bạn không có tùy chọn nào khác để "quay lại" ngoài việc đảo ngược / xóa / đặt lại các cam kết, đây không phải là cách làm việc sạch sẽ và có thể khiến bạn mất các phần của mã mới. đã ổn
• Tất nhiên, trong giai đoạn đầu tiên của sự phát triển, có lẽ bạn có thể bắt đầu làm việc trực tiếp với chủ, nhưng sau khi bạn có thứ gì đó để cung cấp, bạn nên sử dụng các nhánh phát triển, thử nghiệm hoặc thử nghiệm để không chạm vào phiên bản làm việc đã hoàn thành, đã xuất bản.

Đầu tiên, tôi muốn chỉ ra rằng trong git, mọi thứ pullhoàn toàn theo nghĩa đen là một hoạt động phân nhánh và mỗi thứ pushlà một sự hợp nhất. Máy mastertrên của nhà phát triển là một nhánh hoàn toàn tách biệt với masterrepo trung tâm mà bạn chia sẻ, với vị thế tương đương từ góc độ kỹ thuật. Thỉnh thoảng tôi sẽ đổi tên phiên bản địa phương của mình thành upstreamhoặc một cái gì đó nếu nó phù hợp với mục đích của tôi hơn.

Tôi chỉ ra điều này bởi vì nhiều tổ chức nghĩ rằng họ đang sử dụng các chi nhánh hiệu quả hơn so với đồng nghiệp của bạn, khi thực sự họ đang làm ít hơn là tạo một tên bổ sung cho một chi nhánh trên đường đi, dù sao đó sẽ không được lưu trong lịch sử. Nếu đồng nghiệp của bạn đang cam kết các tính năng trong một cam kết nguyên tử, thì việc sao lưu dễ dàng như một cam kết hợp nhất của một nhánh tính năng. Phần lớn các nhánh tính năng nên tồn tại rất ngắn và thường xuyên được hợp nhất.

Điều đó đang được nói, nhược điểm chính của phong cách làm việc của ông là gấp đôi. Đầu tiên, nó làm cho rất khó để cộng tác trên một tính năng chưa hoàn thành. Tuy nhiên, sẽ không khó để tạo ra một chi nhánh chỉ trong những thời điểm cần thiết phải có sự hợp tác.

Thứ hai, nó làm cho việc xem xét trước khi hợp nhất rất khó khăn. Về điểm này, bạn không thực sự cần phải thuyết phục anh ta. Bạn có thể áp dụng một công cụ như github, gerrit hoặc gitlab và yêu cầu đánh giá mã yêu cầu kéo và vượt qua các bài kiểm tra tự động cho tất cả các kết hợp. Nếu bạn không làm điều gì đó như thế này, thật lòng mà nói bạn không sử dụng git cho toàn bộ tiềm năng của nó, và không có gì lạ khi đồng nghiệp của bạn không nhìn thấy tiềm năng đó.

Các câu trả lời khác đã đề cập đến các ưu điểm khác nhau (các tính năng riêng biệt, luôn có thể chuyển mã trên master, v.v.) để làm việc KHÔNG trực tiếp trên master.

Đối với tôi bạn dường như có một vấn đề khác. Rõ ràng là bạn không có quy trình phát triển, được tất cả các nhà phát triển của bạn đồng ý hoặc sử dụng (hoặc nhà phát triển của bạn đang nghi vấn là hoàn toàn bỏ qua quy trình).

Bạn có các nhánh tính năng, được hợp nhất thành chủ hoặc bạn có các nhánh phát hành khác nhau không hoặc bạn có sử dụng một quy trình hoàn toàn khác không?

"Đừng sử dụng nhánh chính" là không đủ.

Một trong những đồng nghiệp của chúng tôi khá vui khi thực hiện các thay đổi trực tiếp trên nhánh chính và mặc dù có một vài cuộc trò chuyện, họ dường như không thể thay đổi điều này.

Điều này khiến tôi tin rằng có nhiều vấn đề hơn. Làm việc trên bậc thầy hay không chủ yếu là một phần của triết lý lớn hơn về cách thức, điều gì và khi bạn phát hành sản phẩm.

Vì vậy, song song với "bạn không bao giờ nên làm việc trên chủ", bạn có kiểm tra các tính năng không, bạn có kiểm tra từng công việc khác để bạn xem lại mã của nhau không. Kiểm tra chấp nhận và tích hợp.

Nếu bạn không có điều nào ở trên và bạn chỉ đang làm điều đó để "làm git", bạn cũng có thể làm việc với chủ.

Không có "thực hành xấu" xung quanh làm việc trực tiếp trên chi nhánh. Nhưng bạn phải quyết định những gì hỗ trợ quá trình của bạn tốt nhất:

Câu hỏi 1: Chủ của bạn có nên đại diện cho trạng thái phát hành hiện tại của phần mềm của bạn không? Sau đó, bạn nên giới thiệu một nhánh phát triển toàn cầu và hợp nhất sự phát triển vào cuối của một phát triển phát hành.

Câu hỏi 2: Bạn có muốn có một quy trình xem xét mã? Sau đó, bạn nên có "các nhánh tính năng" sẽ được hợp nhất thành chủ (hoặc phát triển, nếu bạn có) thông qua các yêu cầu kéo.

Câu hỏi 3: Có cần chia sẻ trạng thái mã trung gian cho các nhà phát triển khác chưa được công bố vào sản xuất (hoặc thử nghiệm) không? Đó là trường hợp nhiều hơn một nhà phát triển phát triển một tính năng. Sau đó, bạn nên giới thiệu "chi nhánh tính năng".