Tôi có nên thêm tệp di chuyển Django vào .gitignoretệp không?
Gần đây tôi đã gặp rất nhiều vấn đề về git do xung đột di chuyển và tự hỏi liệu tôi có nên đánh dấu các tệp di chuyển là bỏ qua hay không.
Nếu vậy, tôi sẽ làm cách nào để thêm tất cả các di chuyển mà tôi có trong ứng dụng của mình và thêm chúng vào .gitignoretệp?
Câu trả lời:
Trích dẫn từ tài liệu di chuyển Django :
Các tệp di chuyển cho mỗi ứng dụng nằm trong thư mục "di chuyển" bên trong ứng dụng đó và được thiết kế để cam kết và phân phối như một phần của cơ sở mã của ứng dụng đó. Bạn nên tạo chúng một lần trên máy phát triển của mình và sau đó chạy quá trình di chuyển tương tự trên máy của đồng nghiệp, máy dàn dựng và cuối cùng là máy sản xuất của bạn.
Nếu bạn làm theo quy trình này, bạn sẽ không nhận được bất kỳ xung đột hợp nhất nào trong các tệp di chuyển.
Khi hợp nhất các nhánh kiểm soát phiên bản, bạn vẫn có thể gặp phải trường hợp bạn có nhiều lần di chuyển dựa trên cùng một lần di chuyển gốc, ví dụ: nếu các nhà phát triển khác nhau giới thiệu một lần di chuyển đồng thời. Một cách để giải quyết tình huống này là giới thiệu _merge_migration_. Thường thì việc này có thể được thực hiện tự động bằng lệnh
./manage.py makemigrations --mergesẽ giới thiệu một cuộc di cư mới phụ thuộc vào tất cả các cuộc di cư theo đầu người hiện tại. Tất nhiên điều này chỉ hoạt động khi không có xung đột giữa các lần di chuyển đầu, trong trường hợp đó, bạn sẽ phải giải quyết vấn đề theo cách thủ công.
Do một số người ở đây đề xuất rằng bạn không nên chuyển sang quyền kiểm soát phiên bản, tôi muốn mở rộng thêm về lý do tại sao bạn thực sự nên làm như vậy.
Trước tiên, bạn cần một bản ghi về những lần di chuyển được áp dụng cho hệ thống sản xuất của mình. Nếu bạn triển khai các thay đổi đối với sản xuất và muốn di chuyển cơ sở dữ liệu, bạn cần mô tả trạng thái hiện tại. Bạn có thể tạo một bản sao lưu riêng của các di chuyển được áp dụng cho từng cơ sở dữ liệu sản xuất, nhưng điều này có vẻ rườm rà không cần thiết.
Thứ hai, di cư thường chứa mã tùy chỉnh, viết tay. Không phải lúc nào bạn cũng có thể tự động tạo chúng bằng ./manage.py makemigrations.
Thứ ba, việc di chuyển phải được đưa vào xem xét mã. Chúng là những thay đổi quan trọng đối với hệ thống sản xuất của bạn và có rất nhiều điều có thể xảy ra với chúng.
Vì vậy, tóm lại, nếu bạn quan tâm đến dữ liệu sản xuất của mình, vui lòng kiểm tra quá trình chuyển sang kiểm soát phiên bản.
Bạn có thể làm theo quy trình dưới đây.
Bạn có thể chạy makemigrationscục bộ và điều này tạo tệp di chuyển. Cam kết tệp di chuyển mới này để repo.
Theo tôi, bạn không nên chạy makemigrationstrong sản xuất ở tất cả. Bạn có thể chạy migratetrong sản xuất và bạn sẽ thấy các di chuyển được áp dụng từ tệp di chuyển mà bạn đã cam kết từ cục bộ. Bằng cách này bạn có thể tránh mọi xung đột.
IN LOCAL ENV , để tạo tệp di chuyển,
python manage.py makemigrations
python manage.py migrateBây giờ cam kết các tệp mới được tạo này, giống như bên dưới.
git add app/migrations/...
git commit -m 'add migration files' app/migrations/...TRONG PRODUCTION ENV , chỉ chạy lệnh dưới đây.
python manage.py migratemigratevà KHÔNG BAO GIỜ makemigrationscho các cuộc di cư đã cam kết. Không bao giờ nghĩ đến điều đó.
Trích dẫn từ tài liệu năm 2018, Django 2.0. (hai lệnh riêng biệt = makemigrationsvà migrate)
Lý do có các lệnh riêng biệt để thực hiện và áp dụng di chuyển là vì bạn sẽ thực hiện di chuyển vào hệ thống kiểm soát phiên bản của mình và gửi chúng cùng với ứng dụng của bạn; chúng không chỉ giúp bạn phát triển dễ dàng hơn mà còn có thể được sử dụng bởi các nhà phát triển khác và trong quá trình sản xuất.
TL; DR: cam kết di chuyển, giải quyết xung đột di chuyển, điều chỉnh quy trình làm việc git của bạn.
Cảm thấy như bạn cần phải điều chỉnh quy trình làm việc git của mình , thay vì bỏ qua các xung đột.
Lý tưởng nhất là mọi tính năng mới được phát triển trong một nhánh khác và được hợp nhất trở lại với một yêu cầu kéo .
Các PR không thể được hợp nhất nếu có xung đột, do đó ai cần hợp nhất tính năng của mình cần phải giải quyết xung đột, bao gồm cả việc di chuyển. Điều này có thể cần sự phối hợp giữa các nhóm khác nhau.
Tuy nhiên, điều quan trọng là phải cam kết các tệp di chuyển! Nếu xung đột phát sinh, Django thậm chí có thể giúp bạn giải quyết những xung đột đó ;)
Tôi không thể tưởng tượng tại sao bạn lại nhận được xung đột, trừ khi bạn đang chỉnh sửa di chuyển bằng cách nào đó? Điều đó thường kết thúc không tốt - nếu ai đó bỏ lỡ một số cam kết trung gian thì họ sẽ không nâng cấp từ phiên bản chính xác và bản sao cơ sở dữ liệu của họ sẽ bị hỏng.
Quá trình mà tôi làm theo khá đơn giản - bất cứ khi nào bạn thay đổi mô hình cho một ứng dụng, bạn cũng thực hiện một quá trình di chuyển và sau đó việc di chuyển đó không thay đổi - nếu bạn cần một cái gì đó khác trong mô hình, thì bạn thay đổi mô hình và cam kết di chuyển mới cùng với những thay đổi của bạn.
Trong các dự án greenfield, bạn thường có thể xóa các lần di chuyển và bắt đầu lại từ đầu với lần di chuyển 0001_ khi bạn phát hành, nhưng nếu bạn có mã sản xuất, thì bạn không thể (mặc dù bạn có thể xóa các lần di chuyển xuống thành một).
Giải pháp thường được sử dụng là, trước khi bất kỳ thứ gì được hợp nhất thành tổng thể, nhà phát triển phải thực hiện bất kỳ thay đổi từ xa nào. Nếu có xung đột trong các phiên bản di chuyển, anh ấy nên đổi tên bản di chuyển cục bộ của mình (bản di chuyển từ xa đã được điều hành bởi các nhà phát triển khác và có khả năng là trong sản xuất) thành N + 1.
Trong quá trình phát triển, bạn chỉ cần di chuyển not-commit là được (mặc dù vậy, đừng thêm bỏ qua, đừng bỏ qua addchúng). Nhưng khi bạn đã đi vào sản xuất, bạn sẽ cần chúng để giữ cho lược đồ đồng bộ với các thay đổi mô hình.
Sau đó, bạn cần chỉnh sửa tệp và thay đổi thành dependenciesphiên bản từ xa mới nhất.
Điều này hoạt động cho di chuyển Django, cũng như các ứng dụng tương tự khác (sqlalchemy + alembic, RoR, v.v.).
Có một loạt các tệp di chuyển trong git là lộn xộn. Chỉ có một tệp trong thư mục di chuyển mà bạn không nên bỏ qua. Tệp đó là tệp .py init , Nếu bạn bỏ qua nó, python sẽ không còn tìm kiếm các mô-đun con bên trong thư mục, vì vậy mọi nỗ lực nhập mô-đun sẽ không thành công. Vì vậy, câu hỏi nên là làm thế nào để bỏ qua tất cả các tệp di chuyển ngoại trừ init .py? Giải pháp là: Thêm '0 * .py' vào tệp .gitignore và nó thực hiện công việc một cách hoàn hảo.
Hy vọng điều này sẽ giúp ai đó.
Bỏ qua việc di chuyển, nếu Bạn có DB riêng biệt cho môi trường Phát triển, Giai đoạn và Sản xuất. Đối với nhà phát triển. Mục đích Bạn có thể sử dụng sqlite DB cục bộ và chơi với các di chuyển cục bộ. Tôi khuyên bạn nên tạo thêm bốn nhánh:
Master - Làm sạch mã mới mà không cần di chuyển. Không ai được kết nối với chi nhánh này. Chỉ được sử dụng để đánh giá mã
Phát triển - phát triển hàng ngày. Đẩy / kéo được chấp nhận. Mỗi nhà phát triển đang làm việc trên sqlite DB
Cloud_DEV_env - môi trường DEV trên đám mây / máy chủ từ xa. Chỉ kéo. Giữ các di chuyển cục bộ trên máy, được sử dụng để triển khai mã và di chuyển từ xa cơ sở dữ liệu Dev
Cloud_STAG_env - môi trường máy chủ / đám mây từ xa STAG. Chỉ kéo. Giữ các di chuyển cục bộ trên máy, được sử dụng để triển khai mã và di chuyển từ xa cơ sở dữ liệu Stag
Cloud_PROD_env - môi trường DEV đám mây / máy chủ từ xa. Chỉ kéo. Giữ các di chuyển cục bộ trên máy, được sử dụng để triển khai mã và di chuyển từ xa cơ sở dữ liệu Prod
Lưu ý: 2, 3, 4 - quá trình di chuyển có thể được giữ trong các kho lưu trữ nhưng phải có các quy tắc nghiêm ngặt về hợp nhất các yêu cầu kéo, vì vậy chúng tôi quyết định tìm một người chịu trách nhiệm triển khai, vì vậy người duy nhất có tất cả các tệp di chuyển - triển khai của chúng tôi -er. Anh ấy giữ các di chuyển DB từ xa mỗi khi chúng tôi có bất kỳ thay đổi nào trong Mô hình.
Câu trả lời ngắn gọn,
tôi đề xuất loại trừ di chuyển trong repo. Sau khi hợp nhất mã, chỉ cần chạy ./manage.py makemigrationsvà bạn đã sẵn sàng.
Câu trả lời dài Tôi không nghĩ bạn nên đặt các tệp di chuyển vào repo. Nó sẽ làm hỏng các trạng thái di chuyển trong môi trường dev của người khác và môi trường sản phẩm và sân khấu khác. (tham khảo bình luận của Đường Đường để lấy ví dụ).
Theo quan điểm của tôi, mục đích của việc di cư Django là tìm ra khoảng trống giữa trạng thái mô hình trước đó và trạng thái mô hình mới, sau đó nối tiếp khoảng cách. Nếu mô hình của bạn thay đổi sau khi hợp nhất mã, bạn có thể làm đơn giản makemigrationsđể tìm ra lỗ hổng. Tại sao bạn muốn hợp nhất các di chuyển khác theo cách thủ công và cẩn thận khi bạn có thể đạt được cùng một cách tự động và không có lỗi? Tài liệu Django nói,
Chúng * (di chuyển) * được thiết kế để chủ yếu là tự động
; hãy giữ nó theo cách đó. Để hợp nhất các di chuyển theo cách thủ công, bạn phải hiểu đầy đủ những gì người khác đã thay đổi và bất kỳ sự phụ thuộc nào của các thay đổi. Đó là rất nhiều chi phí và dễ xảy ra lỗi. Vì vậy, tệp mô hình theo dõi là đủ.
Đó là một chủ đề hay về quy trình làm việc. Tôi sẵn sàng cho các lựa chọn khác.
manage.py makemigrations --mergehoạt động hoàn toàn tự động đối với tôi.
makemigrations some_app, không chỉ các mô hình dưới sự kiểm soát của thành viên đó sẽ bị ảnh hưởng, mà các mô hình liên quan khác cũng sẽ bị ảnh hưởng. Tức là, các tệp di chuyển (00 * _ *) trong các ứng dụng khác sẽ bị thay đổi. Và điều đó gây ra nhiều vấn đề xung đột trong quá trình đẩy đến hoặc kéo từ GitHub. Vì hiện tại hệ thống của chúng tôi chưa sẵn sàng để sản xuất, chúng tôi chỉ.gitignorelưu trữ tệp di chuyển. Chúng tôi vẫn chưa biết cách giải quyết khi hệ thống đi vào sản xuất. Có ai có bất kỳ giải pháp?