Làm cách nào để bắt đầu sử dụng Git cho các cơ sở mã khác nhau từ các máy chủ khác nhau?

Bối cảnh: Gần đây tôi đã kế thừa một loạt các dự án tại công ty của mình và tôi đang cố gắng giải quyết một số vấn đề cơ bản với cách chúng được xử lý. Cụ thể, các nhà phát triển trước đó (không còn hoạt động với công ty) đã không sử dụng bất kỳ hình thức kiểm soát nguồn nào, tạo ra ít tài liệu và không thực sự có bất kỳ quy trình phát triển tốt nào.

Vì vậy, bây giờ tôi đã có ba máy chủ dự án (phát triển, dàn dựng, sản xuất) bao gồm hầu hết các trang web và ứng dụng và công cụ được xây dựng cho các ứng dụng và API của bên thứ ba mà chúng tôi sử dụng, cho đến các kho lưu trữ tập lệnh SQL và các thứ khác. Suy nghĩ đầu tiên của tôi là đưa tất cả những điều này vào Git trước khi thay đổi và sửa lỗi được thực hiện, nhưng tôi gặp khó khăn trong việc tìm ra cách tốt nhất để làm điều đó.

Rất nhiều sự phát triển trước đó đã được thực hiện trực tiếp trên các máy chủ sản xuất, điều này đã tạo ra sự phân chia giữa các cơ sở mã của mỗi máy chủ. Không rõ ngay sự khác biệt nằm ở đâu - Tôi đang thấy các bản sửa lỗi ở phía sản xuất không được tiến hành phát triển / dàn dựng, cũng như các tính năng mới về sự phát triển chưa được chuyển sang dàn dựng / sản xuất .

Câu hỏi: Điều gì sẽ là cách tốt nhất để tôi tổ chức và chuyển những thứ này vào Git? Làm cách nào để cấu trúc repos / chi nhánh của tôi để phù hợp với sự khác biệt trong mã?

Tôi đã xem xét việc tiếp tục phát triển từ các bản sao của mã máy chủ sản xuất và giữ các cơ sở mã phát triển / dàn dựng làm tài liệu tham khảo lịch sử. Điều này có khả năng là một điểm để bắt đầu không, vì dù sao tôi cũng không biết gì về mã dev / staging? Tôi chỉ có thể tạo repos của các máy chủ sản xuất cho từng trang web, công cụ, tập lệnh, v.v., tạo các nhánh cho mã dev / staging hiện có và bất kỳ sự phát triển mới nào sẽ phân nhánh từ cơ sở mã của máy chủ sản xuất. Điều này có nghĩa không?

Đẩy các công cụ sản xuất vào masterchi nhánh của một repo mới. Tạo một developnhánh từ đó, và sau đó hợp nhất máy chủ dàn vào đó. Bạn có thể kết thúc với những xung đột cần được giải quyết. Khi chúng được giải quyết, hãy tạo một cái khác feature_branchtừ developvà hợp nhất máy chủ phát triển vào nó. Giải quyết bất kỳ xung đột nào phát sinh.

Điều này để lại cho bạn 3 nhánh, đại diện cho môi trường sản xuất, dàn dựng và phát triển của bạn. Sản xuất -> master, dàn dựng -> develop, phát triển -> feature_branch. Do đó, tất cả sự phát triển được thực hiện feature_branchesvà chỉ được hợp nhất vào developchi nhánh khi tính năng được thực hiện, thử nghiệm và ổn định. Vì nó ổn định, nó có thể được sử dụng như dàn dựng. Cắt một releasenhánh từ developkhi bạn sẵn sàng phát hành, buộc bất kỳ đầu lỏng nào, hợp nhất nó vào master, và sau đó bạn có bản dựng sản xuất mới của mình.

Một trong những đơn đặt hàng đầu tiên của bạn sau khi nhận được thiết lập này là hợp nhất feature_branchtrở lại thành develop*, và sau đó developquay lại master. Hãy nhớ rằng feature_branchcó thể chứa mã và các tính năng chưa được kiểm tra, vì vậy hãy thận trọng khi hợp nhất nó vào developvà sau đó master. Khi đã xong, tất cả các nhánh sẽ chứa cùng một mã và bất kỳ sự phát triển nào được thực hiện trên máy chủ sản xuất hiện được chuyển trở lại vào "máy chủ" phát triển.

Trong mô hình này, mỗi dự án sẽ ở trong repo riêng của nó và repo đó sẽ có một chi nhánh mastervà developcộng feature_branchesvới bất kỳ công việc nào đang được thực hiện.

EDIT, để giải quyết ý kiến: Có, đây là Gitflow.

Chiến lược này (hay nói chung là Gitflow) giữ cho hệ thống 3 cấp độ hiện có (sản xuất, dàn dựng, phát triển) với một lộ trình hợp nhất rõ ràng từ phát triển đến sản xuất. Nhập các cơ sở mã theo cách này cũng cho phép các nhánh được đồng bộ hóa trong khi duy trì hiện trạng trong sản xuất - ít nhất là cho đến khi các phép hợp nhất có thể được kiểm tra. Điều này hoàn thành một vài mục tiêu: lấy mã trong kiểm soát nguồn, được mã hóa và hợp nhất các mã khác nhau (do đó không còn lỗi trong sản xuất nhưng không phát triển) và cung cấp một quy trình hay để sử dụng tiếp theo (một quy trình được xác định rõ và được sử dụng bởi rất nhiều người / đội / công ty). Nếu OP thấy rằng Gitflow không phù hợp với các dự án / nhóm / công ty của anh ấy khi anh ấy sử dụng nó / công ty phát triển, thì nó '

* Bạn có thể muốn cắt một nhánh tính năng khác và xóa bất kỳ tính năng mới rõ ràng nào và hợp nhất nhánh đó vào develop(và sau đó vào master). Điều này giúp bạn không phải kiểm tra các tính năng mới trên tất cả các thử nghiệm khác mà bạn sẽ thực hiện.

Tôi sẽ đề xuất stagingmã làm đường cơ sở tốt nhất cho lần nhập đầu tiên của bạn. Đó là bởi vì có những thay đổi productionkhông xảy ra staging, do các bản sửa lỗi nóng, nhưng ít hơn nhiều nếu có bất kỳ thay đổi nào trong stagingđó production. Tương tự như vậy, có những thay đổi trong developmentđó staging, do các tính năng mới, nhưng có thể ít hơn nhiều nếu có bất kỳ thay đổi nào trong stagingđó development.

Lưu ý, bạn không muốn staginglàm đường cơ sở sau lần nhập đầu tiên. Đây chỉ là một tình huống tạm thời do những thay đổi không được theo dõi trước đây. Các hoạt động chi nhánh diễn ra suôn sẻ hơn nhiều nếu bạn thêm các thay đổi thay vì xóa chúng. Sau lần nhập đầu tiên của bạn, hãy chuyển sang bất kỳ mô hình phân nhánh nào phù hợp với nhu cầu của bạn trong tương lai.

Vì vậy, hãy kiểm tra stagingmã của bạn vào một stagingchi nhánh, sau đó thực hiện git checkout -b master stagingđể tạo masterchi nhánh của bạn và kiểm tra mã sản xuất của bạn vào đó. Sau đó làm một git checkout -b development stagingđể tạo developmentchi nhánh của bạn và kiểm tra mã phát triển của bạn vào đó.

Bây giờ hãy kiểm tra developmentchi nhánh của bạn và hợp nhất master vào nó. Điều này sẽ cho phép bạn giải quyết số lượng lớn các xung đột hợp nhất trong khi vẫn duy trì masternhư một bản ghi về những gì thực sự trong sản xuất. developmentbây giờ chứa tất cả các thay đổi từ mọi môi trường. Bây giờ bạn có thể chuyển sang bất kỳ mô hình phân nhánh nào phù hợp với bạn nhất.

Đó là một ý tưởng tốt để có lịch sử. Tôi sẽ tạo kho lưu trữ (hoặc một cho mỗi sản phẩm) từ môi trường ổn định nhất. Tạo các nhánh hoặc khác cho những người khác.

Ở một cấp độ cao:

1. Tạo một repo mới
2. Từ một bản sao làm việc dựa trên sản xuất: thêm tất cả, cam kết và đẩy
3. Thanh toán tổng thể vào một thư mục mới
4. Đối với mỗi môi trường bổ sung XYZ
   1. Tạo chi nhánh Archive-XYZ
   2. Thay thế mọi thứ bằng XYZnguồn (ngoại trừ .git)
   3. thêm tất cả, cam kết và đẩy

Ngoài ra, nếu bạn nghi ngờ về giá trị của điều này, git diff > XYZ.diffthay vì thực sự cam kết và thúc đẩy, và lưu trữ các khác biệt.

Dù bằng cách nào, bạn nên kết thúc ở trạng thái mà bạn có thể dễ dàng so sánh mã bạn đang chạy trong mỗi môi trường mà bạn có thể sử dụng để giải quyết trên một điểm bắt đầu duy nhất cho mỗi dự án. Và, nếu một cái gì đó bị phá vỡ, về mặt lý thuyết bạn sẽ có thể so sánh các thay đổi của bạn với bất kỳ môi trường nào trong ba môi trường.