- vừa được xem lúc

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

0 0 51

Người đăng: KhanhVQ

Theo Viblo Asia

  • 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.

Bình luận

Bài viết tương tự

- vừa được xem lúc

Đặt tên commit message sao cho "tình nghĩa anh em chắc chắn bền lâu"????

. Lời mở đầu. .

1 1 701

- vừa được xem lúc

Tập hợp những câu lệnh GIT hữu dụng

Dưới đây là một vài ví dụ về các câu lệnh Git mà tôi thường dùng. git config --global user.name "John Doe". git config --global user.

0 0 55

- vừa được xem lúc

Cấu hình CI/CD với Github (phần 2): Trigger một work flow

Events trigger. Bạn có thể cấu hình cho workflows chạy khi có một sự kiện nào đó xảy ra trên GitHub, theo một lịch có sẵn hoặc cũng có thể là một sự kiện nào đó xảy ra ngoài GitHub.

0 0 70

- vừa được xem lúc

Cấu hình CI/CD với Github (phần 1): Một ít lý thuyết

CI/CD là gì. Về mặt khái niệm là vậy nhưng về mặt triển khai thì CI/CD là quá trình tự động thực hiện các quá trình build, test, release, deploy khi có các trigger như commit/merge code lên một branch định sẵn hoặc có thể là tự động chạy theo một lịch cố định.

0 0 118

- vừa được xem lúc

Giới thiệu về Git LFS

. Git LFS là gì . Git LFS làm điều này bằng cách thay thế các tệp lớn trong repo của bạn bằng một con trỏ nhỏ.

0 0 29

- vừa được xem lúc

Git workflow được Google và Facebook sử dụng có gì hay ho

Với developer thì Git hẳn là công cụ rất quen thuộc và không thể thiếu rồi. Thế nhưng có mấy ai thực sự hiểu được Git.

0 0 66