Ngày 5: Sử dụng Git hiệu quả

Bức tranh toàn cảnh: Git – Quản lý phiên bản

Trước khi bắt đầu tìm hiểu về git, chúng ta cần hiểu quản lý phiên bản là gì và tại sao chúng ta cần làm vậy? Trong bài mở đầu về git này, chúng ta sẽ đi qua khái niệm quản lý phiên bản và kiếm thức cơ bản về git.

Quản lý phiên bản là gì?

Git không phải là hệ thống quản lý phên bản duy nhất, vì vậy ở đây chúng ta sẽ đề cập đến những lựa chọn và phương pháp có sẵn cho việc quản lý phiên bản.

Lợi ích rõ ràng nhất và lớn nhất của quản lý phiên bản là khả năng theo dõi lịch sử của dự án. Chúng ta có thể xem lại kho lưu trữ (repository) bằng cách sử dụng git log và xem lại toàn bộ các commit cũng như comments cũng như những gì đã diễn ra trong toàn bộ dự án. Đừng lo, chúng ta sẽ đi vào cách lệnh ở phần sau. Bây giờ, hãy tưởng tượng đây là một dự án phần mềm thực tế với rất nhiều mã nguồn và có nhiều người đang làm việc chung để phát triển sản phẩn tại các thời điểm khác nhau, tất cả các kỹ sư đã đóng góp code, và tất cả những người review code đều được ghi lại ở đây để cho chúng ta biết điều gì đã xảy ra, khi nào, bởi ai và ai đã review.

Quản lý phiên bản trước đây sẽ giống như việc tạo một bản sao phiên bản code của bạn theo cách thủ công trước khi bạn thực hiện các thay đổi. CÓ thể bạn cũng không cần sử dụng những phiên bản cũ nữa nhưng nó được tạo ra để bạn có thể yên tâm hơn, nhỡ đâu…

Tôi đã bắt đầu áp dụng quản lý phiên bản không chỉ đối với mã nguồn mà hầu hết mọi thứ, ví dụ như dự án này (90DaysOfDevOps). Tại sao lại không sử dụng các tính năng như khôi phục, ghi lại mọi thứ đã diễn ra.

Tuy nhiên, để tránh hiểu lầm Quản lý phiên bản không hoạt động như một bản sao lưu

Một lợi ích khác của quản lý phiên bản là khả năng quản lý nhiều phiên bản của một dự án. Lấy ví dụ như chúng ta có một ứng dụng miễn phí và sau đó là ứng dụng trả phí có sẵn trên tất cả các hệ điều hành. Phần lớn mã được chia sẽ giữa hai ứng dụng. Chúng tôi có thể sao chép và dán mã của mình cho từng commit vào từng ứng dụng, nhưng điều đó sẽ rất lộn xộn, đặc biệt là khi bạn mở rộng quy mô phát triển với nhiều nhân sự, cũng sẽ rất dễ mắc lỗi.

Ứng dụng trả phí là nơi chúng ta có các chứ năng bổ sung, hãy gọi chúng là các commit trả phí, bản miễn phí sẽ chỉ chứa các commit bình thường.

Cách chúng ta có thể làm được điều này trong quản lý phiên bản là thông qua phân nhánh (branching)

Phân nhánh cho phép hai luồng mã cùng tồn tại cho một ứng dụng như chúng ta đã nói ở trên. Nhưng chúng ta vẫn muốn các tính năm mới có trong phiên bản miễn phí có trong phiên bản trả phí, để làm được điều này, chúng ta có một thứ gọi là merge.

Bây giờ, điều này có vẻ dễ dàng nhưng việc merge có thể phức tạp vì bạn có thể có một nhóm làm việc trên phiên bản miễn phí và một nhóm khác làm việc với phiên bản trả phí và điều gì sẽ xảy ra nếu cả hai cùng thay đổi đến cấu trúc tổng thể của mã. CÓ thể một biến được cập nhật và làm hỏng phần nào đó. Sau đó, bạn có các conflict làm một chức năng không chạy được. Quản lý phiên bản không thể khắc phục được các conflict do bạn tạo ra. Nhưng quản lý phiên bản cho phép điều này được quản lý một cách dễ dàng.

Nói chung, lý do chính nếu bạn chưa sử dụng quản lý phiên bản cho tới thởi điểm này có thể là bạn chưa cộng tác bao giờ. Sẽ có ngày càng nhiều trường hợp mà chúng ta cần tới khả năng chia sẽ mã giữa các nhà phát triển. Có thể là một bài trình bày chung mà bạn đang làm việc với đồng nghiệp hoặc thử thách 90DaysOfDevOps, nơi bạn có cộng đồng và các chỉnh sửa, cập nhật sẽ được cộng đồng đóng góp trong suốt dự án.

Nếu không có quản lý phiên bản, làm thể nào các nhóm phát triển phần mềm có thể giải quyết vấn đề này? Tôi thấy thật khó khăn khi để theo dõi tất cả mọi thứ khi tôi đang thực hiện các dự án của mình. Tôi hi vọng họ sẽ chia nhỏ mã theo từng module chức năng một, có thể sẽ là từng miếng ghép nhỏ cho một bức tranh lớn để giải quyết các vấn đề trước khi tất cả được release.

Với quản lý phiên bản, chúng ta có một nguồn sự thật duy nhất (single source of truth). Chúng ta có thể làm việc trên các module khác nhau nhưng nó cho phép chúng ta cộng tác tốt hơn.

Một việc khác cần đề cập tới là không chỉ các nhà phát triển có thể hưởng lợi từ quản lý phiên bản, tất cả các thành viên và các công cụ có thể nhìn rõ dự án và tận dụng, các công cụ quản lý dự án có thể được liên kết và theo dõi tiến độ công việc. Chúng ta cũng có thể có một máy build, chẳng hạn như là một Jenkins server mà chúng ta sẽ nói trong phần sau. Một công cụ xây dựng mà nguồn và đóng gói hệ thống, tự động hoá quá trình kiểm thử và các metrics liên quan tới mã nguồn.

Git là gì?

Git là một công cụ theo dõi các thay đổi đối với mã nguồn hoặc bất kỳ tệp nào hoặc cũng có thể nói Git là một hệt thống quản lý phiên bản phân tán mã nguồn mở.

Có nhiều cách à git có thể được sử dụng trên các hệ thống của chúng ta, phổ biến nhất hoặc ít nhất là đối với tôi, tôi đã sử dụng dòng lệnh (command line), nhưng chúng ta cũng có các công cụ và giao diện người dùng đồng hoạ như Visual Studio Code, các công cụ này có các chức năng của git mà chúng ta có thể tận dụng.

Bây giờ chúng ta sẽ xem qua một cách tổng quát trước khi cài đặt git trên máy của mình.

Hãy sử dụng thư mục mà chúng ta đã tạo trước đó.

Để sử dụng thư mục này với quản lý phiên bản, trước tiên chúng ta cần khởi tạo thư mục nào bằng lệnh git init. Hiện tại, chỉ cần nghĩ rằng lệnh này đặt thư mục của chúng ta làm kho lưu trữ trong cơ sở dữ liệu ở đâu đó trên máy tính của chúng ta.

Bây giờ chúng ta có thể tạo một số tệp và thư mục cho mã nguồn hoặc cũng có thể đã có sẵn từ trước đó. Sử dụng lệnh git add . sẽ đặt tất cả cả tệp và thư mục trong thư mục của chúng ta vào một chiếc hộp nhưng chúng ta chưa commit bất cứ thứ gì vào cơ sở dữ liệu đó. Thao tác này có nghĩa là tất cả các tệp thuộc thư mục thực thi lệnh git add đã sẵn sàng để được thêm vào.

Sau đó, chúng ta có thể muốn tiếp tục và commit các tệp của mình, việc này có thể thực hiện bằng lệnh git commit -m "My First Commit". Chúng ta có thể đưa ra lý do cho commit của mình, điều này được khuyến khích để chúng ta có thể biết điều gì xảy ra trong mỗi commit.

Bây giờ chúng ta có thể thấy những gì xảy ra trong lịch sử của dự án. Sử dụng lệnh git log

Nếu chúng ta tạo một tệp bổ sung có tên là samplecode.ps1, thì trạng thái sẽ bị thay đổi. Chúng ta cũng có thể kiểm tra trạng thái của kho lưu trữ của mình bằng cách sử dụng git status, lệnh này cho chúng ta thấy không có gì để commit và chúng ta có thể thêm một tệp mới có thên samplecode.ps1. Sau đó, nếu chạy lại lệnh git status một lần nữa bạn sẽ thấy file mà chúng ta có thể commit.

Thêm tệp mới của chúng ta bằng lệnh git add samplecode.ps1 và sau đó chạy lại lệnh git status một lần nữa và thấy tệp này đã được sẵn sàng để commit.

Sau đó dùng lệnh git commit -m "My Second Commit".

git status bây giờ cũng thể hiện rằng chúng ta đã dọn dẹp mọi thứ.

Sau đó, chúng ta có thể sử dụng lệnh git log để hiện thị các commit mới nhất và commit đầu tiên.

Nếu chúng ta muốn xem các thay đổi giữa các lần commit của mình, tức là những tệp nào đã được thêm hoặc sửa đổi, chúng ta có thể sử dụng git diff b8f8 709a

Nó sẽ hiển thị những gì đã thay đổi, trong trường hợp của chúng ta, một tệp mới đã được thêm vào.

Chúng ta sẽ đi sâu hơn vào vấn đề này sau nhưng chúng ta có thể nhảy giữa các commit của mình, đại loại là chúng ta có thể du hành thời gian! Bằng cách sử dụng hash của commit, có thể sử dụng lệnh git checkout 709a để nhảy ngược thời gian mà không làm mất tệp mới của chúng ta.

Nhưng sau đó, chúng ta cũng sẽ muốn tiếp tục và có thể thực hiện điều này theo cách tương tự với hash của commit hoặc bạn có thể thấy như ở đây chúng ta sử dụng git switch - câu lệnh hoàn tác thao tác trước đó.

TLDR:

• Theo dõi lịch sử của một dự án
• Quản lý nhiều phiên bản khác nhau của một dự án
• Chia sẽ mã giữa các kỹ sư phát triển và mở rộng phạm vi các nhóm và công cụ sử dụng
• Phối hợp làm việc giữa các nhóm
• Ồ, và có thể du hành thời gian!

Điều này giống như một bước nhảy mới nhưng hy vọng rằng bạn có thể thấy bức tranh toàn cảnh đằng sau quản lý phiên bản mà không thực sự biết các câu lệnh cụ thể và sức mạnh của chúng.

Tiếp theo, chugsn ta sẽ cài đặt và thiết lập git trên máy cục bộ của bạn, đồng thời tìm hiểu sâu hơn một chút về một số trường hợp sử dụng và các câu lệnh trong Git.

Cài đặt & Cấu hình Git

Git là một công cụ quản lý phiên bản ã nguồn mở, đa nền tảng. Nếu bạn giống tôi, sử dụng Ubuntu hoặc các hệ điều hành Linux khác, bạn có thể thấy rằng git đã được cài đặt sẵn, tuy nhiên chúng ta vẫn sẽ đi qua việc cài đặt và cấu hình nó.

Ngay cả khi bạn đã cài đặt git trên hệ thống của mình, bạn cũng nên đảm bảo rằng chúng ta luôn có bản cập nhật mới nhất.

Cài đặt Git

Như đã đề cập, Git là công cụ đa nền tảng, chúng ta sẽ nhắc tới Windows và Linux và bạn cũng có thể tìm thấy hướng dẫn cho macOS tại đây

Đối với Windows, chúng ta có thể download trình cài đặt từ trang web chính thức.

Ngoài ra các bạn có thể xem thêm bài viết Setup Gitlap nội bộ (tự động backup dữ liệu) hoặc Setup Gitlap CICD pipelines private registry

Bạn cũng có thể sử dụng winget trên máy tính Windows của mình, và sử dụng nó như trình quản lý gói ứng dụng trên máy của bạn.

Trước khi chúng ta cài đặt bất cứ thứ gì, hãy kiểm tra phiên bản hiện tại trên máy của bạn. Mởi cửa sổ PowerShell và chạy git --version

Chúng ta cũng có thể kiểm tra phiên bản Git trên WSL Ubuntu của mình.

Tại thời điểm viết bài, bản phát hành mới nhất trên Windows là 2.35.1, vì vậy tôi sẽ hướng dẫn việc update một vài thứ. Linux cũng có thể tương tự như vậy.

Sau khi tải xuống trình cài đặt phiên bản mới nhất và chạy qua trình hướng dẫn và ghi lại những điều đó tại đây. Lưu ý quan trọng là git sẽ gỡ cài đặt các phiên bản trước đó rồi mới cài đặt phiên bản mới nhất.

Có nghĩ là quy trình bên dưới cũng là quy trình mà chúng ta phải trải qua đối với việc bạn cài git lần đầu tiên.

Đây là một cài đặt khá đơn giản. Sau khi tài xuống, click đúp và bắt đầu. Đọc qua thoả thuận về giấy phép GNU. Nhưng hãy nhớ đây là phần mềm mã nguồn mở và miễn phí.

Bây giờ chúng ta có thể chọn các thành phần bổ sung mà chúng ta muốn cài đặt cũng như liên kết với git. Trên Windows, tôi luôn đảm bảo rằng mình đã cài đặt Git Bash vì điều này cho phép chúng ta chạy các lệnh bash trên Windows.

Sau đó, chúng ta có thể chọn phần mềm SSH mà chúng ta muốn sử dụng. Tôi chọn OpenSSH như bản có thể thấy trong phần tìm hiểu về Linux.

Chúng ta cũng có thể bật các tính năng thử nghiệm, đối với tôi, tôi không cần chúng nên đã không bật chúng, bạn luôn có thể quay lại việc cài đặt để bật các tính năng này.

Cài đặt hoàn tất, bây giờ chúng ta có thể chọn mở Git Bash hoặc đọc bản ghi chú cho bản phát hành mới nhất.

Bước kiểm tra cuối cùng là mở PowerShell và thử lại câu lệnh kiểm tra phiên bản git.

Sau các bước siêu đơn giản ở trên, chúng ta sẽ có phiên bản mới nhất của git. Đối với Linux, quá trình có thể sẽ mất thời gian hơn một chúng nhưng tôi cũng muốn nói qua về nó.

Tôi chỉ cần chạy lệnh sudo apt-get install git.

Bạn cũng có thể chạy các câu lệnh dưới dây để add thêm git repository cho các cài đặt phần mềm.

sudo add-apt-repository ppa:git-core/ppa -y
sudo apt-get update
sudo apt-get install git -y
git --version

Cấu hình Git

Khi lần đầu tiên sử dụng git, chúng ta phải xác định một số cài đặt sau.

• Tên
• Email
• Editor mặc định
• Ký tự kết thúc dòng

Điều này có thể thực hiện ở ba cấp độ.

• Hệ thống = tất cả người dùng
• Global = tất cả repositories của người dùng hiện tại
• Local = repository hiện tại

Ví dụ: git config --global user.name "Michael Cade" git config --global user.email [email protected]" Tuỳ thuộc vào hệ điều hành của bạn, text editor mặc định sẽ được tự xác định. Với Ubuntu của tôi, câu lệnh tiếp theo sẽ sử dụng nano. Lệnh dưới đây sẽ thay đổi editor thành Visual Studio Code.

git config --global core.editor "code --wait"

bây giờ, nếu chúng ta muốn kiểm tra tất cả các cầu hình git thì có thể sử dụng lệnh sau

git config --global -e

Trên tất cả các máy, tệp này sẽ được đặt tên là .gitconfig. Trên máy Windows của tôi, bạn sẽ tìm thấy tệp này trong thư mục người dùng của mình.

Lý thuyết Git

Như tôi đã đề cập ở trên rằng có các loại quản lý phiên bản khác nhau và chúng ta có thể chia thành hai loại chính. Một là Client-Server và loại còn lại là hệ phân tán.

Quản lý phiên bản Client-Server

Trước khi git xuất hiện, Client-Server là phương thức chính để quản lý phiên bản. Ví dụ cho điều này sẽ là Apache Subversion là một một hệ thống kiểm soát phiên bản mã nguồn mở được ra mắt vào năm 2000.

Trong mô hình quản lý phiên bản Client-Server này, bước đầu tiên nhà phát triểu cần làm là tải xuống mã nguồn và các tệp từ máy chủ. Điều này không giải quyết các xung đột nhưng nó loại bỏ sự phức tạp của các xung đột và cách giải quyết chúng.

Bây giờ, giả sử chúng ta có hai nhà phát triển làm việc trên cùng một tệp và một người xong trước, upload file của họ lên server trước với những thay đổi của họ. Khi người thứ hai cập nhật file đó, xung đột sẽ xảy ra.

Vì vậy, bây giờ người thứ hai cần kéo thay đổi mã của người đầu tiên xuống và giải quyết các xung đột trong mã nguồn rồi sau đó mới commit lên máy chủ.

Distributed Version Control

Git không phải là hệ thống quản lý phiên bản phân tán duy nhất. Nhưng nó rất thông dụng.

Một số lợi ích chính của Git là:

• Nhanh
• Thông minh
• Linh hoạt
• An toàn & Bảo mật

Khác với mô hình kiểm soát phiên bản Client-Server, mỗi nhà phát triển tải xuống một repository thì nó sẽ bao gồm tất cả mọi thứ. Lịch sử các commit, tất cả các nhánh,…

Giới thiệu về git

Chúng ta đã tìm hiệu về quản lý phiên bản và một số quy trình, workflow của git với tư cách là một hệ thống quản lý phiên bản. Sau đó chúng ta đã cài đặt git trên hệ thống, cập nhật và cấu hình. Chúng ta cũng đã đi sâu hơn một chút và điểm khác nhau cơ bản trong hệ thống quản lý phiên bản Client-Server và hệ thống quản lý phiên bản phân tán ví dụ như Git.

Bây giờ, chúng ta sẽ tìm hiểu các câu lệnh cơ bản và trường hợp sử dụng chúng với git.

Trợ giúp với git

Sẽ có lúc bạn không thể nhớ hoặc không biết lệnh cần sử dụng để hoàn thành công việc với git. Bạn sẽ cần giúp đỡ.

Google hoặc bất kỳ công cụ tìm kiểm nào có thể là điểm đến đầu tiên khi bạn tìm kiếm sự trờ giúp.

Tiếp sau đó có thể là trang chính thức của git và tài liệu. git-scm.com/docs Tại đây, bạn sẽ không những chỉ tìm thấy tài liệu tham khảo tốt cho tất cả các câu lệnh, mà còn có rất nhiều các tài nguyên khác.

Xem thêm: Sử dụng Tele sai khiến Gitlap (phương pháp Chatops)

Chúng ta cũng có thể truy cập tài liệu tương tự sau, điều này cực kỳ hữu ích nếu bạn không có kết nối nào từ terminal. Ví dụ: nếu chúng ta sử dụng lệnh git add, chúng ta có thể chạy git add --help và đọc hướng dẫn dưới đây.

Chúng ta cũng có thể dụng git add -h để cung cấp tống hợp các tuỳ chọn có sẵn mà chúng ta có thể sử dụng.

Những câu chuyện xung quanh Git

“Git không có quyền kiểm soát truy cập” – bạn có thể trao quyền cho một leader để duy trì mã nguồn.

“Git quá nặng” – Git có thể cung cấp các kho lưu trữ nông (shallow repositories), có nghĩa là lịch sử git sẽ được cắt giảm nếu bạn có một project lớn.

Những thiếu sót thực tế

Không phải là phương pháp lý tưởng cho các tệp nhị phân. Tuyệt vời cho mã nguồn nhưng không tuyệt vời cho các tệp thực thi hoặc video chẳng hạn.

Git không thân thiện với người dùng, việc chúng ta phải dành thời gian để nói và tìm hiểu các lệnh và chứng năng của công cụ có lẽ là minh chứng rõ ràng nhất cho việc đó.

Nhìn chung, git khó học nhưng dễ sử dụng.

Xem thêm: Tích hợp gửi thông báo Gitlap CICD đến Tele 2 phút hơn

Hệ sinh thái git

Tôi muốn trình bày ngắn gọn về hệ sinh thái xung quanh git nhưng không đi quá sâu và việc đó. Điều quan trọng là phải nhắc đến ở góc độ high-level.

Hầu như tất cả các công cụ phát triển hiện đại đều hỗ trợ git.

• Công cụ phát triển – chúng ta đã đề cập tới Visual Studio Code, bạn sẽ tìm thấy các plugin và các tích hợp của git trong Sublime text và các trình soạn thảo văn bản và IDE khác.
• Công cụ nhóm – Cũng được đề cập trong các công cụ như Jenkins theo góc nhìn CI/CD, Slack từ góc độ dịch vụ nhắn tin và Jira từ góc độ quản lý dự án và theo dõi vấn đề.
• Cloud providers – Tất cả các nhà cung cấp điện toán đám mây lớn đều hỗ trợ git, Microsoft Azure, Amazon AWS và Google Cloud Platform.
• Các dịch vụ dựa trên Git – Sau đó, chúng ta có GitHub, GitLab và BitBucket mà chúng tôi sẽ đề cập rõ hơn ở phần sau. Các dịch vụ này có thể coi như là một mạng xã hội dành cho mã nguồn.

Git Cheatsheet

Chúng ta chưa đề cập đến hầu hết các lệnh này nhưng sau khi xem xét một số cheatsheet có sẵ, tôi cũng muốn ghi lại một số câu lệnh git và mục đích sử dụng của chúng. Chúng ta không cần phải nhớ tất cả những câu lệnh này, với việc thực hành và sử dụng nhiều hơn, bạn sẽ học được một số điều cơ bản về git.

Tôi đã lấy những câu lệnh từ atlassian nhưng viết lại chúng và đọc mô tả là một cách hay để biết các lệnh làm gì cũng như bắt đầu thực hành trong công việc hàng ngày.

Cơ bản về Git

Git Hoàn tác thay đổi

Git viết lại lịch sử

Git Phân nhánh (Branch)

Git Remote Repositories

Git Diff

Git Config

Git Rebase

Git Pull

Git Reset

Git Push

Staging & Changing

Chúng ta đã đề cập đến một số điều cơ bản nhưng việc đưa mọi thứ vào một kịch bản hoàn chỉnh giúp tôi học và hiểu cách thức, lý do chúng ta thực hiện theo cách này tốt hơn. Trước khi chúng ta sử dụng bất kỳ dịch vụ dựa trên git nào như GitHub, git có các chức năng mà bạn có thể tận dụng trên máy của mình.

Chúng ta sẽ lấy thư mục dự án mà chúng ta đã tạo ở bài dầu tiên về git và đi qua lần lượt các bước với git. Chúng ta tạo một thư mục trên máy của mình và khởi tạo git với lệnh git init.

Chúng ta cũng có thể thấy rằng thư mục đã được khởi tạo có một thư mục ẩn.

Đây là nơi lưu trữ thông tin chi tết về git repository cũng như thông tin liên quan đến các nhánh và commit của chúng ta.

Xem thêm: Gitlap CICD nâng cao trên môi trường staging

Stage các tệp

Chúng ta bắt đầu làm việc với thư mục rỗng hoặc có thể chúng ta có một số mã nguồn vào những ngày làm việc trước đó. Đầu tiên, chúng ta tạo tệp readme.md và có thể thấy tệp đó trong thư mục, tiếp theo chúng ta kiểm tra với git status và git đã biết về tệp readme.md nhưng chúng ta chưa commit tệp đó.

Chúng ta có thể stage tệp readme.md với lệnh git add README.md và có thể thấy thay đổi có thể được commit mà trước đó cũng ta không có và một tệp mới màu xanh lá cây.

Tiếp theo chúng ta sẽ commit tệp này với commit đầu tiên của chúng ta. Chúng ta có thể làm điều này với lệnh git commit -m "Meaningful message" để có thể dễ dàng hiểu rằng mỗi commit đã thay đổi điều gì. Ngoài ra, hãy chú ý rằng chữ thập màu vàng bây giờ đã thay đổi thành dấu tính màu xanh lá cây. Đây là thứ tôi có trong terminal của mình với theme mà tôi sử dụng, thứ mà chúng ta đã đề cập trong phần nói về Linux.

Commit các thay đổi

Chúng ta rất có thể muốn thêm nhiều tệp hơn hoặc thậm chí thay đổi các tệp chúng ta có trong thư mục của mình. Chúng tôi đã thực hiện commit đầu tiên của mình ở trên. Nhưng bây giờ, chúng ta sẽ thêm nhiều chi tiết và nhiều tệp hơn.

Chúng ta có thể lặp lại các quy trình của mình như trước đó, tạo hoặc chỉnh sửa tệp của mình > git add . để thêm tất cả các file vào khu vực staging sau đó sử dụng git commit -m "meaningful message". Nhưng để đưa ra một thông điệp có ý nghĩa cho thay đổi trong commit của mình, bạn có lẽ không nên viết ra những thứ như

git commit -m "Chà, tôi đã thay đổi một số mã vì nó không hoạt động và khi tôi sửa mã đó, tôi cũng đã thêm một số thứ mới trong readme.md để đảm bảo rằng mọi người đều biết về trải nghiệm của người dùng và sau đó tôi pha một ấm trà."

Ý tôi là điều này cũng có thể sẽ hiệu quả mặc dù hơi dài dòng nhưng các tốt hơn ở đây là nên thêm thông điệp bằng một trình soạn thảo văn bản.

Nếu chúng ta chạy git commit sau khi chạy git add, git sẽ mở trình soạn thảo văn bản mặc định của chúng ta, trong trường hợp của tôi là nano. Dưới đây là các bước tôi đã thực hiện để thêm một số thay đổi vào tệp, chạy git status để thấy những thứ đã được staged và chưa được staged. Sau đó, tôi đã sử dụng git add để thêm tệp vào khu vực staging, cuối cùng là lệnh git commit để mở nano.

Khi nano mở ra, bạn có thể thêm mô tả ngắn hoặc dài của mình rồi lưu lại tệp.

Best Practices khi Commit

Ở đây có sự cân bằng giữa việc commit khi nào và commit thường xuyên. Chúng ta không muốn đợi đến cuối dự án trước khi commit, mỗi commit phải có ý nghĩa và chúng cũng không được kết hợp các nhiệm vụ không liên quan tới nhau. Nếu bạn có một bản sửa lỗi và một lỗi đánh máy, hãy chắc chắn rằng chúng là hai commit riêng biệt như một best practice.

Làm cho thông điệp commit có ý nghĩa.

Về cách diễn đạt, nhóm hoặc bạn nên tuân theo một cách diễn đạt cho mỗi lần commit.

Bỏ qua khu vực staging

Có phải chúng ta luôn phải stage các thay đổi của mình trước khi commit chúng?

Câu trả lời là có nhưng đừng coi đây là một lối tắt, bạn phải chắc chắn 100% rằng bạn không cần một snapshot để quay lại, đó là một việc làm mạo hiểm.

Xoá tệp

Còn việc xoá tệp khỏi dự án của chúng tôi thì sao, có thể chúng ta có một tệp khác trong thư mục mà chúng ta đã cam kết nhưng hiện tại dự án không còn cần hoặc sử dụng tệp đó nữa, các tốt nhất là chúng ta nên xoá tệp đó.

Chỉ vì chúng ta xoá tệp đó khỏi thư mục, git vẫn biết tệp này và chúng ta cũng cần xoá tệp khỏi repository. Bạn có thể thấy workflow như bên dưới.

Nó có thể hơi khó nhớ hoặc khó thực hiện nếu bạn có một dự án lớn với nhiều tệp và thư mục cần xoá. Chúng ta có thể làm điều này với một lệnh duy nhất git rm oldcode.ps1.

Đổi tên hoặc Di chuyển tệp

Trong hệ điều hành của chúng ta, chúng ta có thể đổi tên và di chuyển các tệp của mình. Chúng ta chắc chắn sẽ cần phải làm điều này rất nhiều lần trong dự án của chúng ta. Tương tự như xoá, quy trình sẽ gồn 2 bước, chúng ta thay đổi các tệp trên hệ điều hành của mình, sau đó sửa đổi và đảm bảo rằng khu vực staging hoặc các tệp được thêm vào một các chính xác. Các bước như sau:

Tuy nhiên, giống như xoá các tệp khỏi hệ điều hành và sau đó là git repository, chúng ta có thể thực hiện việc đổi tên này bằng cách sử dụng lệnh git.

Bỏ qua tệp (ignore files)

Chugns ta có thể có yêu cầu bỏ qua các tệp hoặc thư mục trong dự án của mình, thứ mà chúng ta chỉ sử dụng ở local hoặc nó sẽ tốn không gian nếu chia sẻ với toàn bộ dự án, một ví dụ tốt có thể là các logs. Tôi cũng nghĩ nên sử dụng điều này cho các file bí mật (secrets) mà bạn không muốn chia sẻ công khai hoặc giữa các nhóm.

Chúng ta có thể bỏ qua các tệp bằng cách thêm các thư mục hoặc tệp vào tệp .gitignore trong thư mục dự án của chúng ta.

Bạn có thể mở tệp .gitignore và thấy rằng chúng ta có thư mục log/. Nhưng chúng ta vẫn có thể thêm các tệp và thư mục tại đây để chúng được bỏ qua.

Sau đó chúng ta có thể kiểm tra git status và xem điều gì đã xảy ra.

Cũng có những ách mà bạn có thể cần quay lại và bỏ qua các tệp và thư mục, có thể bạn muốn chia sẻ thư mục logs nhưng sau đó nhận ra bạn không muốn. Bạn sẽ phải dùng lệnh git rm --cached để xoá tệp và thư mục khỏi khu vực staging nếu bạn có một thư mục đã theo dõi trước đó mà bây giờ bạn muốn bỏ qua.

Trạng thái ngắn

Chúng ta đã sử dụng git status rất nhiều để hiểu những gì chúng ta có trong khu vực staging của mình và những gì chúng ta không có, đây là một lệnh rất toàn diện với nhiều thông tin chi tiết. Dần dần, hầu hết những gì bạn muốn biết là cái gì đã được sửa đổi hoặc có gì mới. Chúng ta có thể sử dụng git status -s cho một bản tóm tắt ngắn của các chi tiết này. Tôi thường đặt một phím tắt trên hệ thống của mình để chỉ sử dụng git status -s so với lệnh chi tiết đầy đủ

Sau đây, chúng ta sẽ tiếp tục xem qua các ví dụ ngắn về các lệnh git phổ biến.