Làm thế nào để hạn chế conflict khi làm việc với GIT

Define cấu trúc source code, modulle hoá ngay từ sớm: để tránh conflict thì việc quan trọng nhất vẫn là hạn chế tối đa việc code chung một file, một dòng. Các bạn nên chia nhỏ ứng dụng thành các module nhỏ và chi cho mỗi developer một module nếu có thể. Một số quy

  • Define cấu trúc source code, modulle hoá ngay từ sớm: để tránh conflict thì việc quan trọng nhất vẫn là hạn chế tối đa việc code chung một file, một dòng. Các bạn nên chia nhỏ ứng dụng thành các module nhỏ và chi cho mỗi developer một module nếu có thể.
  • Một số quy ước trước khi tiến hành code: trước khi code chúng ta nên có những quy ước riêng của team trước khi code để tránh conflict code, ví dụ như tách thành những file, sử dụng import/export thay vì viết tất cả các hàm trong một file, các function mới sẽ được define ở dưới cùng….
  • Dữ cho thay đổi của bạn là ít nhất:
    • hạn chế thay đổi các dòng/file có sẵn nếu có thế, thay vào đó các bạn có thể thêm dòng mới.
    • Ngoài ra “hay đổi của bạn là ít nhất” cũng hiểu là không nên thay đổi qua nhiều source trong một lần tạo merge request. Các bạn nên tạo merge request cho mỗi feature NHỎ, không nên dồn quá nhiều source code vào một merge reuqest để tránh conflict cũng dễ dàng hơn cho người review các merge quest của bạn
  • Rebase hoặc merge từ base branch (thường là branch develop trong work flow) trước khi tạo merge request. Trước khi tạo merge request lên cho người khác review bạn PHẢI rebase hoặc merge ( mình thì mình thích merge hơn 😌 ) vì hai nguyên nhân:
    • Nếu có conflict code với base branch thì bạn sẽ resolve ở local trước khi push lên và tạo merge reuqest. Việc này không tránh được hoàn toàn conflict nhưng sẽ phát hiện và xử lý sớm (vì để đến người review thì họ cũng sẽ reject và bắt bạn resolve conflict trước thôi :v )
    • Lấy source mới về để chắc chắn là các function khách không ảnh hưởng đến function của bạn. ví dụ như bạn có một function dùng chung đã bị xoá bởi một member khách nhưng bạn vẫn gọi đến hàm đó làm cho hệ thống bui fail (lúc đấy thì lại được bao nước cả team thì… 😜 ).
  • Kiểm tra trươc khi tạo merge reuqest và assign cho reviewer: các bạn nên selt review trước khi tạo merge reuqest và assign cho người reivew. Tốt nhất là team nên define một check list hoặc nếu không có thì các bạn cũng nên tự có một check list: không bị conflict code, coding convention, đã xoá hết console log, tên biến có thể hiểu được, vân vân và mây mây các thứ…. để có thể tự review merge request của mình.

Nguồn: viblo.asia

Bài viết liên quan

Thay đổi Package Name của Android Studio dể dàng với plugin APR

Nếu bạn đang gặp khó khăn hoặc bế tắc trong việc thay đổi package name trong And

Lỗi không Update Meta_Value Khi thay thế hình ảnh cũ bằng hình ảnh mới trong WordPress

Mã dưới đây hoạt động tốt có 1 lỗi không update được postmeta ” meta_key=

Bài 1 – React Native DevOps các khái niệm và các cài đặt căn bản

Hướng dẫn setup jenkins agent để bắt đầu build mobile bằng jenkins cho devloper an t

Chuyển đổi từ monolith sang microservices qua ví dụ

1. Why microservices? Microservices là kiến trúc hệ thống phần mềm hướng dịch vụ,