Những thói quen tốt khi làm việc với Git


#1

Tôi bắt đầu sử dụng Git từ 4 năm trước, nhưng chỉ tới hai năm gần đây khi đi làm thực tế mới thực sự hiểu được tầm quan trọng của những thói quen tốt khi làm việc với git. Hiểu được tầm quan trọng của những thói quen này giúp tôi lập trình hiệu quả hơn, khiến dự án đi nhanh hơn và code có ít lỗi hơn.

Về tầm quan trọng của git, có lẽ tôi sẽ không bàn ở đây. Bạn đọc có thể tham khảo bài viết Biến Git và GitHub trở thành công cụ đắc lực cho Software Engineer.

Tôi viết bài này với mong muốn chia sẻ những kinh nghiệm mà tôi cho là hữu ích. Hy vọng các bạn cũng tìm thấy điều tương tự.

Trước khi bắt đầu, tôi xin nhấn mạnh một điều:

Thời gian đọc code có thể gấp nhiều lần thời gian viết code. Bạn có thể đọc code của bạn hoặc code của người khác. Hãy quen với việc code có trách nhiệm.

Các khái niệm trong git không được dịch ra tiếng Việt.

1. Hãy luôn bắt đầu project bằng git init

Đừng đợi đến khi project “đủ lớn” rồi mới bắt đầu dùng git. Hãy học thói quen chia một việc lớn thành nhiều bước nhỏ, mỗi bước nhỏ tương ứng với một commit hoặc một branch (trước khi merge). Mỗi commit hoặc branch nên có một message cụ thể để về sau có thể tìm lại dễ dàng.

2. Không bao giờ commit thằng vào master branch

Master branch luôn là nơi có phiên bản làm việc ổn định nhất. Mọi code được commit/merge vào master đều phải được review. Những người lập trình kỳ cựu nhất cũng không bao giờ tự tin rằng code của mình viết không hề có lỗi. Ngoài ra, việc review code trước khi merge cũng giúp tránh xung đột (conflict). Xung đột xảy ra khi branch của bạn và một branch khác đã được merge chinh sửa cùng một dòng code.

Để tránh việc git push -force khi có xung đột (từ chính mình hoặc đồng đội). Github hoặc Gitlab repo có thể được cấu hình sao cho master branch được “bảo vệ”, chỉ có admin hoặc code đã được approve bởi đồng đội mới được merge.

yoda | MERGE CONFLICT? GIT PUSH --FORCE | image tagged in yoda | made w/ Imgflip meme maker)

Github: Configuring protected branches and required status checks

Gitlab: Protected branches

3. Luôn review code trước khi merge

Nếu làm trong nhóm, bạn nên nhờ (request) những người có kinh nghiệm với đoạn code bạn đang làm review trước khi merge. Có một người khác cùng xem code của bạn giúp độ tin cậy của code cao hơn. Ngoài ra, việc review code cũng giúp các thành viên trong nhóm học hỏi lẫn nhau và cách code của nhau. Theo thời gian, các thành viên trong một dự án sẽ hiểu hơn về tư duy code chung của cả nhóm và có phong cách code dần giống nhau. Việc này sẽ giúp việc đọc hiểu/chỉnh sửa code về sau nhanh hơn.

Nếu bạn làm một mình, bạn cũng có thể kiểm tra lại những gì mình đang làm trước khi nhấn nút “merge”. Việc này, theo kinh nghiệm bản thân, giúp tránh được nhiều lỗi không đáng có.

4. Giữ commit và branch càng nhỏ càng tốt

Cố gắng giữ diff của mỗi commit và branch càng nhỏ càng tốt. Mỗi branch chỉ làm một việc cụ thể và mỗi commit là một bước nhỏ có tên rõ ràng trong đó. Không nên gộp nhiều công việc vào trong một branch và mỗi git. Diff nhỏ cũng giúp việc review được dễ dàng hơn và giúp tránh tạo ra những lỗi mà bạn không nhìn ra.

5. Thường xuyên rebase vào master

Có lẽ việc đau đầu nhất khi làm việc với git là khi branch của bạn có conflicts trước khi merge vào master (việc báo code bị xung đột chính là một điểm quan trọng và các phần mềm quản lý phiên bản mang lại). Để hạn chế việc này, bạn không nên để branch của mình quá xa so với commit cuối cùng ở master. Một vài thói quen tốt:

  • Giữ diff ở mỗi commit và branch nhỏ. Bạn càng sửa nhiều thì càng dễ xung đột với code khác.
  • Hoàn thiện commit và branch thật nhanh. Bạn càng để lâu thì xác suất có người khác “đụng” đến phần bạn đang làm càng cao.
  • Thường xuyên rebase vào master. Nếu bạn càng có nhiều commit trên branch của bạn và để càng lâu thì xác suất có xung đột khi rebase càng cao. Tuy nhiên, việc rebase thường xuyên giúp hạn chế xung đột trước khi merge (thường khó giải quyết hơn nhiều). Ngoài ra, việc này cũng luôn giúp branch của bạn cập nhật nhất với master.

Để rebase branch hiện tại vào master:

git checkout master  # to master
git pull  # update master
git checkout - # back to the previous branch
git rebase master  # rebase to the updated master

6. Theo dõi đồ thị commit của cả dự án

Khi làm trong một project lớn với nhiều thành viên, việc biết được vị trí code của mình là cực kỳ quan trọng. Vị trí code của mình thể hiện những bước đã được thực hiện trong branch hiện tại, các branch khác của mình và đồng đội cũng như biết xem mình đang ở sau master bao nhiêu commit. Hiện các phần mềm hỗ trợ git đều có chức năng này. Tuy nhiên, vì phải code trên nhiều máy khác nhau, bao gồm code qua ssh, tôi thường không cài đặt phần mềm quản lý nào mà làm việc trực tiếp với câu lệnh của git trên cửa sổ dòng lệnh.

Đây là alias có trong tất cả các máy làm việc của tôi:

gitviewbranches='git log --all --graph --decorate --oneline'

Dưới đây là kết quả khi chạy gitviewbranches trong project dịch sách “Dive into Deep Learning” (https://d2l.aivivn.com/):

Từ hình phía trên, tôi có thể biết được các branch gần với master, các commit của mỗi branch và biết rằng có một vài branch đang khá xa so với master. (Trong project này, mỗi người được giao chỉnh sửa những dòng cố định nên xung đột ít xảy ra.)

7. Luôn có unit test

Việc này không chỉ với git mà trong bất kỳ dự án nào, chúng ta cũng cần viết unit test. Unit test giúp bạn kiểm tra được từng hàm/lớp mình viết có chạy đúng như mong muốn không. Càng nhiều code có unit test càng tốt. Khi bạn làm việc với từng hàm nhỏ, bạn có thể viết unit test để kiểm tra chức năng và bắt lỗi. Nếu không, khi bạn làm việc với các hàm lớn hơn, bạn sẽ thường mất rất nhiều thời gian để dò lỗi.

Unit tests còn giúp đảm bảo khi code được sửa đổi, logic chính không bị ảnh hưởng và khiến công việc của reviewer dễ dàng hơn khi họ biết logic chính của hàm đã chạy chính xác, ít nhất là trên những unit test đã viết.

8. Giới hạn số ký tự trong một dòng code

Google yêu cầu mỗi dòng code không quá 80 ký tự.

Màn hình máy tính ngày càng rộng, tại sao chúng ta phải giới hạn số ký tự trên một dòng code. Câu trả lời là tính đọc được (readability) của code là một việc rất quan trọng. Không phải ai cũng có màn hình rộng và không phải lúc nào bạn cũng có màn hình rộng theo người. Việc một dòng code quá dài khiến nó bị wrap thành nhiều dòng nhỏ thường khiến code khó đọc.

Ngoài ra, khi review code, màn hình thường được chia làm hai, thể hiện code trước và sau khi thay đổi. Nếu dòng quá dài, việc review cũng sẽ gặp nhiều khó khăn.

Ngoài ra, nhiều lập trình viên có thói quen chia terminal thành hai nửa theo chiều dọc. Một nửa để code (vim, emacs, nano, …), nửa kia để chạy câu lệnh. Nếu dòng code quá dài thì việc đọc code sẽ bị ảnh hưởng.

9. Continuous Integration

Cuối cùng, cả Github và Gitlab đều hỗ trợ các chức năng kiểm tra code tự động, bao gồm kiểm tra chiều dài mỗi dòng code và chạy các unit test. Nếu hệ thống của bạn không quá lớn, bạn có thể sử dụng Github Actions hoặc Gitlab Pipelines để cấu hình.

Trên đây là những kinh nghiệm đúc kết lại sau 2 năm lập trình trong các nhóm lớn. Nếu bạn có câu hỏi về git, hãy để lại trong comment, tôi sẽ cố gắng trả lời.

Tôi có kế hoạch viết thêm một bài về những thói quen tốt khi lập trình Python. Mời bạn đón đọc.


[04/14/2020 10:00] Tầm quan trọng của git đã được nhấn mạnh nhiều . . .
[04/14/2020 10:00] Tầm quan trọng của git đã được nhấn mạnh nhiều . . .
#2

Chào Tiep, mình có 1 vấn đề khi sử dụng git. Ví dụ: Trước ngày 1.1.2020, mình lưu trữ code trên Repo của server A. Vì 1 lý do security mình phải move sang repo của Server B. Mình đã git init và push code lên server B. Nhưng trên Repo của server không còn tracking (ai đã change gì, push code gì…) của những ngày trước 1.1.2020 nữa. Cho mình hỏi làm sao để push lại các tracking trước ngày 1.1.2020 lên Repo của server B (giả sử mình có 1 thứ mục chứa những tracking cũ trước ngày 1.1.2020) Thanks Tiep


#3

Bạn có thể làm theo hướng dẫn ở đây để chuyển remote repo