Git là gì và vì sao lập trình viên cần nó

Git là hệ thống quản lý phiên bản

Git là chương trình ghi lại lịch sử thay đổi của các tệp trong dự án. Mỗi khi bạn lưu lại trạng thái mã nguồn, Git tạo một ảnh chụp (commit) kèm tác giả, thời gian và mô tả. Bạn có thể quay lại bất kỳ ảnh chụp nào, so sánh nó với bản hiện tại, hoặc tìm xem ai đã thay đổi một dòng cụ thể và vì sao.

Nếu bạn từng lưu các thư mục như «du_an_v2», «du_an_final» và «du_an_final_THAT_SU_FINAL», thì bạn đã quản lý phiên bản theo cách thủ công. Git làm việc tương tự một cách tự động, gọn gàng và không sợ mất dữ liệu. Vì vậy, khi lập trình viên nói «git là gì», họ không chỉ hỏi về một chương trình mà về một công cụ làm việc cơ bản, quan trọng không kém trình soạn thảo code.

Git khác gì so với thư mục chứa bản sao và ổ đĩa đám mây

Ổ đĩa đám mây chỉ giữ phiên bản mới nhất của tệp và, may mắn lắm, vài bản sao tự động. Git lưu một lịch sử có ý nghĩa: bạn tự quyết định khi nào lưu thay đổi và ghi rõ đã làm gì. Ngoài ra, Git còn làm được những việc mà ổ đĩa nào cũng không làm được:

• phát triển nhiều luồng công việc cùng lúc (nhánh) và gộp chúng lại;
• hiển thị sự khác biệt giữa các phiên bản theo từng dòng (git diff);
• gộp các chỉnh sửa của nhiều người trên cùng một tệp;
• tìm commit đã gây ra lỗi (git bisect);
• làm việc không cần internet, vì toàn bộ lịch sử nằm trên máy của bạn.

Git nghĩa là gì và tên gọi đến từ đâu

Git không có cách viết tắt chính thức — đây không phải là từ viết tắt. Linus Torvalds đặt tên chương trình theo phong cách riêng: trong tiếng lóng Anh-Anh, «git» nghĩa là một người «khó chịu, bướng bỉnh». Chính Torvalds đùa rằng ông đặt tên mọi dự án theo tên mình. Nghĩa đen của từ git trong tiếng Anh gần với «đồ khốn», «kẻ hay gây sự».

Trong README đầu tiên của dự án, tác giả đưa ra vài cách giải thích hài hước: chẳng hạn «global information tracker» — khi mọi thứ chạy tốt, và một cách diễn đạt chửi thề — khi mọi thứ hỏng. Vì vậy, nếu bạn được hỏi trong buổi phỏng vấn «Git viết tắt từ gì», câu trả lời đúng là: không viết tắt từ gì cả, đây là một cái tên, không phải chữ viết tắt.

Khi nói và viết, người ta dùng «Git» với chữ G viết hoa. Đây là một cái tên riêng, và cách phát âm phổ biến là «ghít».

Git ra đời như thế nào

Trước năm 2005, những người phát triển nhân Linux sử dụng hệ thống độc quyền BitKeeper. Khi giấy phép miễn phí dành cho cộng đồng bị thu hồi, Torvalds chỉ trong vài tuần đã viết một hệ thống mới. Yêu cầu của ông rất khắt khe: tốc độ trên một dự án khổng lồ, làm việc hoàn toàn phân tán, bảo vệ lịch sử khỏi bị hỏng, và làm việc thuận tiện với hàng nghìn nhánh song song.

Ít lâu sau, Junio Hamano đảm nhận việc phát triển dự án và đến nay vẫn là người bảo trì chính của Git. Ngày nay, Git là một hệ thống mã nguồn mở theo giấy phép GPLv2, và GitHub, GitLab, Bitbucket, Gitea cùng nhiều nền tảng doanh nghiệp đều được xây dựng trên nền tảng này.

Git hoạt động như một hệ thống: cấu trúc bên trong

Để Git không còn là một tập hợp lệnh khó hiểu, hãy nắm ba ý tưởng sau. Chúng giải thích gần như toàn bộ cách hệ thống hoạt động.

1. Ảnh chụp, không phải phần khác biệt

Nhiều hệ thống cũ lưu thay đổi dưới dạng một tập hợp các chỉnh sửa trên tệp. Git tư duy theo ảnh chụp: mỗi commit là trạng thái đầy đủ của dự án tại thời điểm lưu. Để tiết kiệm dung lượng, các tệp không thay đổi không được sao chép lại — commit chỉ trỏ tới đối tượng đã được lưu sẵn. Khi đóng gói kho lưu trữ, Git còn nén các đối tượng giống nhau, nên lịch sử của một dự án lớn cũng chiếm ít dung lượng.

2. Mọi thứ được định danh bằng hash

Mỗi đối tượng trong Git — nội dung tệp (blob), cấu trúc thư mục (tree), commit — đều có một mã định danh được tính từ chính nội dung của nó. Theo truyền thống đó là SHA-1 (40 ký tự thập lục phân), các phiên bản mới cho phép tạo kho lưu trữ dùng SHA-256. Không thể sửa một commit cũ mà không bị phát hiện: hash của nó thay đổi, và hash của mọi commit sau đó cũng thay đổi theo.

$ git log --oneline -3
a3f9c21 Thêm form đăng nhập
7b02e4d Sửa kiểm tra email
1c8d5f0 Commit đầu tiên

Các chuỗi ngắn bên trái là hash rút gọn của commit. Nhờ chúng, bạn có thể truy cập bất kỳ phiên bản nào: git show 7b02e4d.

3. Ba trạng thái của tệp

Đây là nền tảng của Git, và gần như buổi phỏng vấn nào cũng hỏi về nó. Một tệp trong dự án có thể nằm ở một trong ba khu vực:

Vùng chuẩn bị là điểm khác biệt của Git so với nhiều hệ thống khác. Nó cho phép đưa vào commit chỉ một phần thay đổi: ví dụ, sửa lỗi thành một commit riêng, còn đổi tên biến thành một commit khác. Nhờ vậy, lịch sử dễ đọc.

Phân tán: vì sao mỗi người đều có một bản sao đầy đủ

Git là một hệ thống quản lý phiên bản phân tán (DVCS). Khi bạn clone, bạn nhận không chỉ các tệp mới nhất mà toàn bộ lịch sử dự án. Hầu hết thao tác — commit, xem lịch sử, tạo nhánh, so sánh — đều chạy trên máy cục bộ và gần như tức thì, không cần máy chủ.

Trong mô hình này, một máy chủ như GitHub chỉ là thêm một bản sao của kho lưu trữ, được nhóm thống nhất coi là bản chính. Nếu máy chủ không khả dụng, công việc vẫn tiếp tục: bạn vẫn commit và gửi thay đổi sau bằng git push. Nếu máy chủ bị mất hoàn toàn, lịch sử vẫn có thể được khôi phục từ bất kỳ bản clone nào.

Git và GitHub không phải là một

Đây là nhầm lẫn phổ biến ở người mới. Git là chương trình chạy trên máy của bạn. GitHub là dịch vụ web lưu trữ kho Git và cung cấp công cụ làm việc nhóm: pull request, review code, quản lý công việc, CI. GitLab và Bitbucket là các dịch vụ tương tự.

Bạn hoàn toàn có thể dùng Git mà không cần GitHub — ví dụ cho ghi chú cá nhân hoặc dự án cục bộ. Ngược lại, GitHub không có ý nghĩa gì nếu không có Git, vì nó được xây dựng quanh các kho Git.

Kiến thức cơ bản về Git: vòng làm việc tối thiểu

Đây là công việc hằng ngày trông như thế nào. Vài lệnh sau bao quát phần lớn những gì lập trình viên làm mỗi ngày.

# tạo kho lưu trữ trong thư mục hiện tại
git init

# xem những gì đã thay đổi
git status

# thêm tệp vào vùng chuẩn bị
git add index.html style.css

# lưu lại một ảnh chụp
git commit -m "Dựng giao diện trang chủ"

# xem lịch sử
git log --oneline

# tạo nhánh và chuyển sang nhánh đó
git switch -c feature/login

# gộp nhánh vào nhánh chính
git switch main
git merge feature/login

# gửi thay đổi lên máy chủ
git push origin main

Lệnh git switch xuất hiện từ Git 2.23 như một cách dễ hiểu hơn để thay thế một phần chức năng của git checkout. Trong các hướng dẫn cũ, bạn sẽ gặp git checkout -b feature/login — hai lệnh này làm việc giống nhau.

Điều gì xảy ra khi chạy git commit

Git lấy nội dung của vùng chuẩn bị, lưu từng tệp thành một blob, xây các đối tượng tree cho thư mục và tạo đối tượng commit. Trong commit ghi lại: tham chiếu tới tree, tham chiếu tới commit cha (hoặc hai commit cha — sau một lần gộp), tác giả, người commit và thông điệp. Sau đó con trỏ của nhánh hiện tại được chuyển sang commit mới. Nhánh trong Git thực chất là một tệp chứa hash của commit mới nhất, nên việc tạo nhánh chỉ mất vài mili giây.

Vì sao lập trình viên cần Git: lý do thực tế

Có thể thử nghiệm mà không sợ

Mọi thay đổi đều có thể hoàn tác. Làm hỏng code — git restore tệp sẽ khôi phục phiên bản đã lưu gần nhất. Commit sai đã nằm trong lịch sử — git revert tạo một commit đảo ngược mà không viết lại lịch sử chung. Điều này thay đổi cách làm việc: bạn thử nghiệm táo bạo hơn, vì quay lại chỉ tốn vài giây.

Làm việc nhóm có trật tự

Mỗi lập trình viên làm việc trên nhánh riêng và không cản trở người khác. Khi công việc hoàn thành, thay đổi được review và gộp vào nhánh chính. Nếu hai người cùng sửa một đoạn code, Git sẽ báo xung đột và cho bạn giải quyết một cách có chủ đích, thay vì âm thầm ghi đè công việc của người khác.

Lịch sử là tài liệu

Thông điệp commit tốt trả lời câu hỏi «vì sao code lại như vậy». Lệnh git blame tệp cho biết ai và trong commit nào đã thay đổi từng dòng lần cuối, còn git log -p tệp cho thấy toàn bộ quá trình tiến hóa của tệp. Sau một năm, điều này tiết kiệm được hàng giờ truy tìm.

Yêu cầu của nhà tuyển dụng

Kiến thức về Git gần như có trong mọi tin tuyển dụng lập trình viên, tester, kỹ sư DevOps, chuyên viên phân tích dữ liệu. Trong phỏng vấn, người ta kiểm tra không phải việc thuộc lòng các lệnh, mà là sự hiểu biết: merge khác rebase thế nào, vùng chuẩn bị là gì, hoàn tác commit ra sao, giải quyết xung đột như thế nào. Hồ sơ GitHub với lịch sử commit gọn gàng cũng đóng vai trò như một portfolio.

Ai khác cũng cần Git

Git hữu ích ở mọi nơi có tệp văn bản và cần lịch sử thay đổi: người viết tài liệu kỹ thuật (tài liệu Markdown), người dựng giao diện, nhà phân tích (script SQL, notebook), quản trị viên (cấu hình máy chủ, hạ tầng dưới dạng code). Với các tệp nhị phân lớn — video, PSD, bộ dữ liệu — người ta dùng tiện ích mở rộng Git LFS, vì bản thân Git được tối ưu cho văn bản.

Pro Git — cuốn sách hay nhất về Git

Nếu muốn đi sâu, hãy bắt đầu với cuốn «Pro Git» của Scott Chacon và Ben Straub. Sách miễn phí, phát hành theo giấy phép mã nguồn mở và được đăng trên trang chính thức git-scm.com ở mục Book, kể cả bản dịch tiếng Việt. Đây chính là «git pro» mà nhiều người tìm kiếm: một giáo trình đầy đủ từ kiến thức cơ bản tới cấu trúc bên trong.

Cách đọc hiệu quả:

• chương 1–3 (giới thiệu, kiến thức cơ bản, phân nhánh) — tối thiểu bắt buộc, hãy lặp lại các lệnh trên terminal;
• chương về làm việc với kho từ xa và GitHub — khi bạn bắt đầu làm việc nhóm;
• chương «Git từ bên trong» — khi bạn muốn thật sự hiểu cách các đối tượng và tham chiếu được tổ chức.

Nguồn tham khảo chính thức thứ hai là trợ giúp tích hợp sẵn: git help commit hoặc git commit --help mở tài liệu đầy đủ của lệnh, còn git commit -h hiển thị tóm tắt các tùy chọn.

Những hiểu lầm thường gặp ở người mới

• «Git tự động lưu tệp». Không đúng. Cho đến khi bạn commit, các thay đổi chỉ tồn tại trong thư mục làm việc.
• «Commit được đưa lên GitHub ngay lập tức». Commit là cục bộ. Nó chỉ được gửi lên máy chủ sau khi chạy git push.
• «git add chỉ dùng cho tệp mới». git add cũng đưa vào vùng chuẩn bị các thay đổi của tệp đã được theo dõi.
• «Thứ đã xóa khỏi lịch sử thì không lấy lại được». Hầu như luôn lấy lại được: git reflog ghi lại các lần di chuyển con trỏ, và commit «bị mất» có thể tìm theo hash.
• «Nhánh là bản sao của dự án». Nhánh chỉ là một con trỏ nhẹ tới commit, không phải bản sao của tệp.

Bắt đầu học từ đâu

1. Cài đặt Git và kiểm tra phiên bản: git --version.
2. Thiết lập tên và email: git config --global user.name và user.email.
3. Tạo một kho lưu trữ thử nghiệm, thực hiện 5–10 commit, xem git log và git diff.
4. Thực hành với nhánh: tạo, gộp, cố tình gây xung đột và giải quyết nó.
5. Tạo tài khoản GitHub, đưa kho lưu trữ lên đó và mở pull request đầu tiên.

Cách này nhanh hơn nhiều so với việc đọc tài liệu tham khảo liên tục: bạn thấy ngay mỗi lệnh làm thay đổi trạng thái kho như thế nào.

Tóm lại

Git là hệ thống quản lý phiên bản phân tán, lưu lịch sử dự án dưới dạng ảnh chụp, bảo vệ lịch sử bằng hash và cho phép nhóm làm việc song song trên các nhánh. Tên Git không phải là chữ viết tắt, còn «git là gì» trong thực tế là câu hỏi về một công cụ bắt buộc của mọi lập trình viên. Hãy nắm vững chu trình add — commit — push, hiểu ba khu vực của tệp và các nhánh, sau đó đi sâu hơn qua cuốn Pro Git. Tất cả những điều này, từng bước từ commit đầu tiên đến pull request, được hướng dẫn thực hành trong khóa học Git.