Khi mình còn là sinh viên, chập chững triển khai những dự án đầu tiên. Các thành viên trong nhóm đều có nhiệm vụ cụ thể cho việc lập trình giao tiếp phần cứng. Ví dụ như có bạn phụ trách giao tiếp UART, I2C; bạn thì kiêm phần thuật toán xử lý; bạn khác thì chịu trách nhiệm về hiển thị màn hình LCD. Việc trao đổi mã nguồn cho nhau chỉ đơn giản là gửi qua các kênh chat như Telegram, Skype, Zalo (với những file nhỏ), Gmail (với những file lớn). Việc hợp nhất mã nguồn một cách thủ công (copy/paste) từ nhiều thành viên và việc kiểm thử tiêu tốn mất hằng giờ đồng hồ. Xung đột (Conflict) xảy ra liên tục và nguy cơ mắc lỗi do tích hợp thiếu sót hay nhầm lẫn là điều không thể tránh khỏi. Chúng mình liên tục lãng phí thời gian vào việc quản lý phiên bản, thay vì tập trung vào việc viết code.
Chắc hẳn là nhiều bạn cũng gặp những trường hợp tương tự này. Sau đó, mọi thứ thay đổi hoàn toàn khi mình tìm hiểu và áp dụng Git, GitHub cho các dự án. Việc chia sẻ mã nguồn trong đội nhóm của mình trở nên dễ dàng, có tổ chức và hiệu quả hơn. Với chuỗi bài viết chia sẻ về Git và Github này, mình hy vọng có thể giúp các bạn hiểu được cách thức hoạt động của Git và có thể áp dụng để quản lý mã nguồn các dự án cá nhân.
Trước khi đi đến định nghĩa về Git. Chúng ta cùng tìm hiểu một khái niệm rất phổ biến: “Version Control System” (viết tắt là VCS – Hệ thống quản lý phiên bản).
1. Version Control System – Hệ thống quản lý phiên bản
1.1. Version Control System là gì?
Có rất nhiều định nghĩa về Version Control System. Tại bài viết này, mình sẽ chỉ ra định nghĩa được chia sẻ bởi Gitlab như sau:
“A version control system (VCS) is the software that manages project changes, allowing developers to store versions, compare updates, and revert when necessary.”
Version Control System (VCS – Hệ thống Quản lý Phiên bản) là một loại phần mềm thiết yếu có vai trò quản lý và theo dõi mọi thay đổi xảy ra trong một dự án phát triển phần mềm. VCS cung cấp ba khả năng cốt lõi cho các nhà phát triển:
- Store versions (Lưu trữ các phiên bản): VCS lưu trữ toàn bộ sự thay đổi cập nhật của mã nguồn dự án với các commit (cam kết các thay đổi) của những người cộng tác. Xây dựng một lịch sử chi tiết không thể xóa bỏ của dự án, cho phép nhà phát triển giữ lại mọi cột mốc phát triển.
- Compare updates (So sánh các bản cập nhật): VCS có thể so sánh sự khác nhau giữa những lần cập nhật mã nguồn. Nó cho biết chính xác dòng code nào đã được thêm vào, xóa đi hoặc sửa đổi. Điều này cực kỳ quan trọng để rà soát mã (review) và tìm lỗi (debugging).
- Revert when necessary (Hoàn nguyên khi cần thiết): Nếu một thay đổi mới gây ra lỗi hoặc không hoạt động như mong muốn, VCS cho phép nhà phát triển quay trở về bất kỳ phiên bản ổn định nào trong lịch sử. Tính năng này mang lại sự an toàn và giảm thiểu rủi ro cho quá trình phát triển.
1.2. Các loại Version Control System
Version Control System bao gồm 3 loại:
- Local Version Control System (LVCS): Quản lý phiên bản cục bộ
- Centralized Version Control Systems (CVCS): Quản lý phiên bản tập trung
- Distributed Version Control Systems (DVCS): Quản lý phiên bản phân tán.
Chúng ta cùng tìm hiểu chi tiết về 3 loại VSC này.
1.2.1. Local Version Control System (LVCS): Quản lý phiên bản cục bộ
- LVCS là hình thức quản lý phiên bản đơn giản và sơ khai nhất. LVCS sử dụng một cơ sở dữ liệu cục bộ đơn giản trên máy tính cá nhân của người dùng.
- Hạn chế lớn nhất là LVCS không hỗ trợ làm việc nhóm và toàn bộ lịch sử dự án đều nằm ở một nơi duy nhất (trên máy tính cá nhân), khiến dự án có nguy cơ bị mất nếu ổ đĩa gặp sự cố.
- Công cụ phổ biến thuộc LVCS là RCS (Revision Control System).
Hình 1. Local Version Control System
1.2.2. Centralized Version Control Systems (CVCS): Quản lý phiên bản tập trung
- CVCS là thế hệ VCS tiếp theo, nhắm khắc phục hạn chế của LVCS về vấn đề cộng tác giữa các người phát triển phần mềm. CVCS hoạt động với một máy chủ duy nhất, là nơi lưu trữ toàn bộ các tệp và lịch sử các phiên bản dự án. Tất cả các thành viên tham gia dự án phải kết nối với máy chủ trung tâm, thực hiện thay đổi, và sau đó cam kết (commit) những thay đổi đó trở lại máy chủ.
- Vẫn còn hạn chế khi máy chủ gặp sự cố. Nếu chưa có những sao lưu dự phòng ngay tại thời điểm đó thì lịch sử của dự án bị mất đi.
- Công cụ phổ biến thuộc CVCS là CVS, Subversion, and Perforce.
Hình 2. Centralized Version Control System
1.2.3. Distributed Version Control Systems (DVCS): Quản lý phiên bản phân tán
- DVCS là thế hệ VCS mới nhất, khắc phục được nhược điểm của CVCS về vấn đề máy chủ tập trung. Mỗi thành viên phát triển khi tham gia dự án, họ cần tải về máy tính cá nhân bản sao toàn bộ lịch sử của dự án.
- Các cam kết (commits) được thực hiện cục bộ trên máy tính của người phát triển. Khi muốn chia sẻ, họ đẩy (push) các thay đổi từ kho lưu trữ cục bộ (local repository) của mình lên kho lưu trữ từ xa (remote repository), và ngược lại.
- Nếu máy chủ trung tâm bị hỏng, bất kỳ bản sao cục bộ nào của nhà phát triển đều có thể được sử dụng để khôi phục lại máy chủ. Mỗi bản sao là một bản sao lưu đầy đủ.
- Công cụ phổ biến thuộc DVCS là Git, Mercurial, Bazaar.
Hình 3. Distributed Version Control System
Vậy Git là một trong những công cụ thuộc Distributed Version Control System được sử dụng rất phổ biến. Tại mục tiếp theo, chúng ta cùng tìm hiểu chi tiết hơn về Git.
2. Git là gì?
2.1. Định nghĩa
Theo git-csm (trang web chính thức của Git), git được giải thích như sau:
“Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Git is lightning fast and has a huge ecosystem of GUIs, hosting services, and command-line tools.”
“Git là một hệ thống quản lý phiên bản phân tán mã nguồn mở và miễn phí. Nó được thiết kế để quản lý các dự án, từ rất nhỏ đến rất lớn, với tốc độ và hiệu quả cao. Git hoạt động cực kỳ nhanh chóng và được hỗ trợ bởi một hệ sinh thái rộng lớn bao gồm GUIs (giao diện đồ họa), hosting services (dịch vụ lưu trữ), và command-line tools (công cụ dòng lệnh).”
2.2. Nguyên tắc hoạt động
Để sử dụng Git một cách hiệu quả, chúng ta cần hiểu rõ được nguyên tắc cơ bản về cách thức hoạt động của Git.
2.2.1. Snapshots, Not Differences: Lưu trữ dạng ảnh chụp snapshot, không phải là lưu trữ sự thay đổi.
- Delta_based (các VCS khác): lưu trữ dữ liệu dưới dạng một phiên bản gốc, sau đó ghi lại danh sách các tập tin (gọi là deltas) thay đổi giữa các phiên bản liên tiếp.
- Snapshot_based (Git): mỗi khi người dùng commit (cam kết các thay đổi), Git sẽ chụp “bức ảnh” toàn bộ (snapshot) về trạng thái của tất cả các tệp trong dự án tại thời điểm đó. Để tối ưu hiệu suất, nếu một tệp không thay đổi, Git sẽ không lưu trữ lại tệp đó mà chỉ tạo một tham chiếu đến bản sao đã lưu trước đó. Các bạn xem hình 4 để hiểu rõ sự khác nhau giữa Git và các VCS khác nhé!
Hình 4. Cách thức hoạt động của Delta_based và Snapshot_based
2.2.2. Nearly Every Operation Is Local – Hoạt động mang tính cục bộ
Hầu hết các thao tác của Git (như xem lịch sử thay đổi, so sánh các phiên bản, cam kết thay đổi) chỉ cần các tệp và tài nguyên có sẵn trên máy tính cục bộ của bạn. Từ đó giúp cho tốc độ xử lý gần như tức thời (do không phụ thuộc vào độ trễ mạng) và cho phép người dùng làm việc hiệu quả ngay cả khi không kết nối Internet.
2.2.3. Git Has Integrity – Git mang tính toàn vẹn dữ liệu
Tất cả những thay đổi trước khi được lưu trữ đều được kiểm tra bằng Hàm băm SHA-1 (SHA-1 hash). Đảm bảo tính bất biến của dữ liệu. Bất kỳ sự thay đổi ngẫu nhiên hay cố ý nào đều sẽ bị Git phát hiện ngay lập tức, loại bỏ rủi ro mất hoặc hỏng thông tin.
2.2.4. Git Generally Only Adds Data – Git chỉ thêm dữ liệu
Hầu hết các hoạt động trong Git chỉ đơn thuần là thêm dữ liệu mới vào cơ sở dữ liệu. Điều này khiến Git cực kỳ khó mất dữ liệu không có chủ đích và giúp các hành động trở nên dễ dàng hoàn tác (undoable).
2.2.5. Ba trạng thái của Git – Các tệp mà bạn làm việc sẽ lần lượt được chuyển đổi qua ba trạng thái của Git, đó là modified, staged, committed.
- Modified (Đã Chỉnh sửa): trạng thái tệp đã được thay đổi trong working directory nhưng chưa được đánh dấu để lưu.
- Staged (Đã Sắp xếp/Đóng gói): trạng thái tệp đã được lựa chọn để đánh dấu và sẽ chuyển qua trạng thái tiếp theo. Tệp này nằm trong khu vực được gọi là staging area.
- Committed (Đã Cam kết): Dữ liệu đã được lưu trữ an toàn và vĩnh viễn trong cơ sở dữ liệu cục bộ của Git đó là thư mục .git.
Các bạn xem hình 5 để hiểu rõ hơn quy trình làm việc cơ bản của Git.
Hình 5. Working directory, Staging area, and Git directory
Tại những bài viết sau, mình sẽ hướng dẫn các bạn về những câu lệnh giúp chuyển đổi các tệp qua từng trạng thái trên. Các bạn nhớ đón chờ nhé!
3. Ví dụ trực quan về Git
Mình sẽ mô phỏng việc phát triển phần mềm cho một hệ thống đo nhiệt độ và hiển thị trên màn hình LCD với vi điều khiển STM32.
Trong Git, branch (nhánh) là một chuỗi các commit độc lập. Tại ví dụ này, chúng ta sẽ làm việc với 2 branch: Main branch và Feature branch.
- Main branch: luồng phát triển cốt lõi và ổn định của firmware. Ví dụ với chuỗi các commit:
| 1 | Initialize Project | Khởi tạo dự án CubeMX cơ bản cho STM32, cấu hình Clock cơ bản và GPIO cho LED. |
| 2 | Config UART Protocol | Cấu hình ngoại vi UART để in thông tin debug ra máy tính qua Terminal. |
| 3 | Initialize & config LCD | Viết code khởi tạo và thiết lập màn hình LCD để sẵn sàng hiển thị. |
| 4 | Set up Display Layout | Thiết lập bố cục hiển thị ban đầu, in tiêu đề cố định lên LCD. |
| 5 | Add Sensor Basic Readout | Viết hàm đọc giá trị thô (raw data) từ cảm biến nhiệt độ và in ra UART. |
- Feature branch: luồng phát triển tính năng thử nghiệm hoặc cải tiến tạm thời đang được phát triển song song. Ví dụ với chuỗi các commit:
| A | Add Low Power Mode | Thực hiện cấu hình Low Power Mode cho vi điều khiển để tiết kiệm pin. (Phát triển tính năng sau khi khởi tạo LCD tại commit 3) |
| B | Implement Buzzer Alarm | Thêm cấu hình ngoại vi Timer và PWM cho chân GPIO điều khiển kích hoạt còi báo khi nhiệt độ vượt quá ngưỡng 40 độ C. |
Sau khi Feature branch được kiểm thử ổn định, chúng ta sẽ combine (hợp nhất) vào Main branch. Kết quả là firmware hiện tại vừa có tính năng hiển thị nhiệt độ vừa có thể hoạt động ở Low Power Mode. Các bạn quan sát hình 6 mô phỏng chuỗi các commit cho ví dụ trên.
Hình 6. Mô phỏng trực quan ví dụ về chuỗi các commit
4. Ai là người sử dụng Git?
Git là công cụ quản lý mã nguồn được sử dụng phổ biến. Nên lập trình viên là nhóm người dùng cốt lõi của công cụ này. Một số công ty (như Google, Facebook, Microsoft, Linkedln,…) và dự án lớn (như dịch vụ GitHub, GitLab…) sử dụng Git để quản lý mã nguồn của họ.
Với khả năng giúp người dùng theo dõi lịch sử thay đổi và quản lý phiên bản, Git còn được ứng dụng bởi đa lĩnh vực khác.
- Nghiên cứu khoa học: quản lý mã nguồn, dữ liệu và tài liệu của dự án
- Thiết kế: quản lý file thiết kế và dữ liệu liên quan
- Giáo dục: quản lý nội dung lớp học, cộng tác nghiên cứu, giao nộp bài tập
- Văn học: quản lý bản thảo, cộng tác và quản lý lịch sử sửa đổi chi tiết.
Git không chỉ giới hạn trong lĩnh vực lập trình, mà là một hệ thống quản lý dữ liệu linh hoạt có thể được sử dụng bởi bất kỳ ai và bất kỳ lĩnh vực nào cần theo dõi sự thay đổi của dữ liệu thông tin.
Qua bài viết này, mình đã giới thiệu đến các bạn tổng quan về Version Control System và Git. Tại bài viết tiếp theo, mình sẽ giới thiệu về việc set up git trên máy tính cục bộ, các lệnh cơ bản về config name và email, navigation và làm việc với file, folder, các bạn cùng đón chờ nhé!
Chúc các bạn thành công!
N.T.Nhien