Biến Git và GitHub trở thành công cụ đắc lực cho Software Engineer

1. Git

From 06f2790b5ca3fea45515e33c9660ad6265120a5a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=C5=81ukasz=20Langa?= <lukasz@langa.pl>
Date: Wed, 4 Mar 2020 23:16:55 +0100
Subject: [PATCH] Rename FileMode into just Mode The mode was never just about files to begin with.There are no other modes in
Black, this can be the default one.
--- black.py | 40 +++++++++++++++++++--------------------- 
1 file changed, 19 insertions(+), 21 deletions(-)
diff --git a/black.py b/black.py
index 52096819..31859d1a 100644
--- a/black.py
+++ b/black.py
@@ -186,7 +186,7 @@ class Feature(Enum):
  @dataclass-class 
FileMode:
+class Mode:     
target_versions: Set[TargetVersion] = field(default_factory=set)     
line_length: int = DEFAULT_LINE_LENGTH     
string_normalization: bool = True
@@ -209,6 +209,10 @@ def get_cache_key(self) -> str:         
return ".".join(parts) 
+# Legacy name, left for integrations.
+FileMode = Mode
+
+ 
def supports_feature(target_versions: Set[TargetVersion], feature: Feature) -> bool:     
return all(feature in VERSION_TO_FEATURES[version] for version in target_versions)

1.1. Git là gì?

1.2. Sử dụng Git như thế nào?

> git add a.py
> git add b.py
> git commit -m "Thay doi file a va b"

> git add c.py
> git commit -m "Thay doi file c"

1.3. Các nguyên tắc khi làm việc với Git

• Tách nhánh mới để làm việc. Như đã nói ở trên, việc tách nhánh mới giúp các thành viên có thể làm việc độc lập với nhau. Ngoài ra, bằng cách làm việc trên một nhánh riêng biệt, ta có thể đảm bảo rằng code trên nhánh mặc định (master) luôn là code ổn định và có thể được đưa lên môi trường production.
• Viết commit message rõ ràng, dễ hiểu. Mỗi commit đều có một message, là nơi để lập trình viên tóm tắt những thay đổi được lưu lại trong commit này. Commit message rõ ràng và tường minh giúp cho các thành viên khác có thể dễ hình dung về những thay đổi hơn khi nhìn vào git log hoặc git tree. Conventional Commits là một quy ước viết commit message thường được dùng.

• Mỗi commit chỉ nên có một trách nhiệm duy nhất. Nguyên tắc Single Responsibility (S trong SOLID) là một nguyên tắc cơ bản trong thiết kế phần mềm. Tạo Git commit là một trong nhiều tính huống khác ta có thể áp dụng nguyên tắc này. Mỗi commit chỉ nên lưu lại những thay đổi nhỏ, có liên quan trực tiếp đến nhau. Thay vì tạo ra một commit với rất nhiều thay đổi (hàng trăm dòng code và hàng chục file được thay đổi), ta nên chia ra thành nhiều commit nhỏ. Điều này giúp dễ quan sát các thay đổi, và việc quay lại một trạng thái trước đây cũng dễ dàng hơn vì lịch sử đã được chia nhỏ.
• Tránh commit những thay đổi không cần thiết, hoặc không nên được lưu lại. Giả sử rằng trong dự án của bạn cần lưu lại những cấu hình cho việc kết nối vào cơ sở dữ liệu, hoặc là khoá bí mật dùng trong việc mã hoá thông tin… Những thông tin này tuyệt đối không được lưu lại với Git, vì một khi bạn đưa những thông tin này lên một remote repository công khai, bất cứ ai cũng có thể xem được và truy cập vào cơ sở dữ liệu của bạn… Ngoài ra, còn những thông tin khác như các thành phần phụ thuộc của dự án cũng không nên được lưu lại, ví dụ như npm_modules khi làm việc với JavaScript, hoặc venv khi làm việc với Python.

1.4. Các tính năng khác của Git

• hooks. Hooks là một tính năng rất mạnh mẽ của Git. Với tính năng này, ta có thể thêm các hành động tuỳ chỉnh vào từng giai đoạn làm việc với Git, ví dụ như trước và sau khi commit/push… Thường dùng nhất là pre-commit hook, được chạy trước mỗi commit. Thậm chí còn có một framework chuyên để quản lý chúng. Pre-commit hooks thường được sử dụng để format code theo một chuẩn chung (black/prettier), chạy các chương trình phân tích tĩnh (static analysis) như mypy, eslint… để giảm thiểu lỗi.
• annotate/blame. Khi sử dụng câu lệnh này, với mỗi dòng trong một file, ta có thể biết được người gần nhất sửa dòng này là ai, và sửa vào lúc nào. Các kỹ sư ở Got It rất hay dùng để blame nhau, đúng như tên gọi của câu lệnh, ví dụ như: Chỗ này chú J, chú K viết khó đọc thế, chỗ này ai viết mà tinh tế thế, hoá ra là anh M.

• cherry pick. Khi dùng câu lệnh git merge để hợp nhất hai nhánh lại làm một, ta sẽ mang tất cả commit của nhánh tính năng vào nhánh chính. Tuy nhiên, không phải lúc nào ta cũng muốn làm vậy, chẳng hạn như khi cần deploy và test trước một số thay đổi chọn lọc từ nhánh tính năng. Đây là lúc ta sử dụng đến câu lệnh cherry-pick để copy thay đổi từ những commit cần thiết sang một nhánh khác. Đơn vị nhỏ nhất có thể cherry pick là một commit, nên nếu commit quá lớn thì ta sẽ không thể chọn ra những thay đổi cần thiết.
• Ngoài các tính năng kể trên, bạn đọc có thể tham khảo thêm các tính năng khác như submodule, stash, rebase, status, diff…

1.5. Tìm hiểu thêm về Git

• Giới thiệu tổng quan về các tính năng của Git: https://git-scm.com/about.
• Tài liệu trên trang web chính thức của Git: https://git-scm.com/doc.
• Hướng dẫn sử dụng Git: https://www.atlassian.com/git/tutorials.
• Khoá học về Git trên Codecademy: https://www.codecademy.com/learn/learn-git.
• Git cheatsheet: https://ndpsoftware.com/git-cheatsheet.html.

2. GitHub

2.1. Tổng quan về GitHub

2.2. GitHub và tuyển dụng

• Code rõ ràng và dễ đọc, theo quy chuẩn. Với các dự án mã nguồn mở, bất kì ai cũng có thể xem toàn bộ mã nguồn, qua đó có thể đánh giá chất lượng của dự án. Có thể nói rằng chất lượng code là tiêu chí quan trọng nhất khi đánh giá ứng viên thông qua các dự án cá nhân. Việc viết code dễ đọc có thể bắt đầu bằng cách làm theo các quy ước thông dụng như PEP8 với Python và ESLint với JavaScript. Cài đặt các pre-commit hooks để đảm bảo rằng các quy ước được tuân thủ cũng là một điểm cộng.
• Sử dụng các công cụ hỗ trợ. Ngoài cách đảm bảo chất lượng code thông qua việc làm theo các quy ước, viết test giúp ta chắc chắn rằng code đã được viết đúng logic. Viết test đúng và đủ cũng là một phần không thể thiếu trong các dự án được đầu tư nghiêm túc. Ta có thể cài đặt sao cho test được tự động chạy mỗi khi push code lên GitHub với các công cụ như Travis CI, CircleCI, Azure Pipelines; cùng với đó là theo dõi tỉ lệ code đã được kiểm tra bởi test với các công cụ như Coveralls, Codecov… Thông qua khả năng sử dụng các công cụ một cách thích hợp, ta có thể đánh giá được xem tác giả có quan tâm và đảm bảo chất lượng của dự án hay không, cùng với đó là khả năng tìm hiểu và áp dụng các công nghệ, kĩ thuật phổ biến.

• Cung cấp mô tả rõ ràng về các dự án. Các dự án cá nhân cần có một tiêu đề và mô tả ngắn gọn nhưng vẫn đầy đủ. Ngoài ra, mỗi dự án nên có một file README chứa những thông tin cơ bản về dự án. File README này sẽ được hiển thị tại trang chủ của dự án, ví dụ như https://github.com/psf/black, nó sẽ là ấn tượng đầu tiên khi truy cập vào dự án của bạn trên GitHub. Vì vậy, có một file README rõ ràng, dễ đọc, mô tả chi tiết về dự án là một điểm cộng rất lớn trong quá trình review GitHub. Các bạn có thể tham khảo các bài viết sau để tìm hiểu thêm về cách viết README: https://www.makeareadme.com/, https://github.com/kylelobo/The-Documentation-Compendium.
• Quản lý dự án. GitHub cung cấp khả năng quản lý dự án với tính năng Issues. Với Issues, bạn có thể theo dõi bug và các yêu cầu tính năng mới cho mỗi dự án. Tận dụng hợp lý tính năng này là một cách để thể hiện kĩ năng quản lý dự án và làm việc nhóm.
• Giấy phép (License). Có thể bạn chưa để ý đến license, nhưng đây là một điều rất quan trọng với các dự án mã nguồn mở. Chúng cho phép lập trình viên khác sử dụng, cũng như đóng góp các thay đổi, nâng cấp cho dự án của bạn. Một số loại giấy phép phổ biến phải kể đến MIT, Apache License 2.0… Bạn có thể tìm hiểu thêm tại https://choosealicense.com/, hoặc tham khảo một ví dụ về giấy phép MIT tại https://github.com/psf/black/blob/master/LICENSE.
• Tạo trang cá nhân với GitHub. Có một trang web cá nhân là một trong những điều gây ấn tượng mạnh với nhà tuyển dụng. GitHub cho phép bạn tạo trang web cá nhân và trang web cho các dự án của bạn. Hướng dẫn chi tiết có tại https://pages.github.com/.

Tài liệu tham khảo