Phân biệt Git với nền tảng hosting, working tree, index, commit, branch và tag; thực hành nhánh, fast-forward, tag và revert trong repository riêng.
Một nhóm lưu hướng dẫn dưới các tên final, final-new và final-fixed. Khi một câu bị sửa sai, không ai biết nên khôi phục bản nào hoặc vì sao thay đổi được đưa vào. Quản lý phiên bản giúp ghi các trạng thái có lịch sử và so sánh được, nhưng hiệu quả còn phụ thuộc cách chọn thay đổi, thông điệp và quy trình review.
Bài 056.2, Quản lý mã nguồn, tham chiếu Open Source Essentials 050-100 trang in 267–279, biên soạn độc lập và đối chiếu ngày 23/10/2026. Kiến thức tiên quyết là tệp, thư mục và dòng lệnh cơ bản. Lab đã chạy bằng Git 2.39.5, Apple Git, trên macOS trong một repository tạm riêng, không remote và không truy cập mạng. Đây là phiên bản đã kiểm chứng, không phải tuyên bố Git mới nhất.
Sau bài học, bạn có thể phân biệt repository, working tree, index, commit, branch, tag và merge; tạo lịch sử nhỏ rồi đảo một thay đổi bằng commit mới. Lab không tác động repository công việc, không đẩy mã lên dịch vụ và không thay cấu hình Git toàn cục.
SCM thường được dùng để nói về quản lý source; VCS là hệ thống kiểm soát phiên bản, còn revision control nhấn mạnh theo dõi các lần sửa. Trong tài liệu nhập môn chúng thường xuất hiện gần nghĩa. Một quy trình đầy đủ vẫn cần review, phân quyền, build và kiểm tra ngoài việc lưu phiên bản.
Git là hệ thống phân tán, có thể tạo commit cục bộ. Subversion tự mô tả là VCS tập trung, với repository trung tâm giữ lịch sử; working copy không phải bản sao toàn bộ lịch sử như một clone Git đầy đủ. CVS là một hệ thống tập trung lâu đời được nhắc trong mục tiêu, không phải công cụ mà lab yêu cầu triển khai.
Không mặc định mọi clone Git đều chứa toàn bộ lịch sử và đối tượng: các chế độ shallow hoặc partial có thể giới hạn phần nhận. Cũng không coi VCS là bản sao lưu hoàn chỉnh của mọi tài sản, cấu hình và dữ liệu vận hành. Cần xác định những gì thật sự được theo dõi và cách bảo vệ bản sao repository.
Git cung cấp cơ chế kiểm soát phiên bản; GitHub, GitLab hoặc nền tảng khác bổ sung tài khoản, review, issue và những dịch vụ liên quan. Một commit Git không đòi hỏi phải có tài khoản cloud. Chức năng, giấy phép và điều kiện tự triển khai của từng nền tảng cần được xem riêng, không suy từ tên dịch vụ.
Repository công khai giúp người khác đọc nội dung theo cơ chế nền tảng, nhưng chưa tự cấp một giấy phép nguồn mở cho mọi tệp. Repository riêng cần phân quyền và quản lý tài khoản phù hợp. Việc người dùng bấm sao trên một nền tảng không phải chứng nhận chất lượng hoặc quyền sử dụng.
Không đưa mật khẩu, token hay dữ liệu người dùng vào lịch sử để “lưu tạm”. Một tệp bị xóa khỏi bản mới có thể vẫn ở commit cũ. Nếu bí mật thật bị lộ, cần xử lý credential theo quy trình của tổ chức; chỉnh lịch sử một mình chưa làm credential hết hiệu lực.
Working tree là các tệp đang làm việc. Index, được dùng qua git add, chuẩn bị nội dung cho lần commit tiếp theo. Nếu sửa tệp sau khi add, thay đổi mới chưa tự vào index. So sánh phần chưa stage và đã stage giúp tránh đưa thiếu hoặc thừa nội dung.
Commit ghi trạng thái được chọn cùng thông tin và quan hệ lịch sử. Tạo commit cục bộ khác với push, vốn chuyển đối tượng và cập nhật tham chiếu ở remote theo quyền và quy tắc. Không mô tả commit chỉ xuất hiện khi đẩy lên máy chủ.
Tên tác giả và email trong commit là metadata, chưa phải xác minh danh tính mạnh. Thông điệp nên mô tả điều thay đổi và lý do đủ để người đọc hiểu. Lab dùng danh tính giả cục bộ; nếu làm dự án thật, dùng danh tính theo chính sách và lưu ý khả năng thông tin được công khai.
Branch là một tham chiếu phát triển có thể tiến tới commit mới; dùng nhánh ngắn giúp tách một phần công việc để review. Tag thường đánh dấu điểm cụ thể, chẳng hạn bản phát hành. Git hỗ trợ tag có chú thích; tên tag không tự bảo đảm rằng binary đi kèm đúng là bản được build từ nó.
Merge tích hợp lịch sử theo điều kiện cụ thể. Fast-forward có thể chỉ đưa nhánh đích tiến tới commit đã có. Merge thành công về văn bản chưa chứng minh hai thay đổi phối hợp đúng về hành vi; vẫn cần kiểm tra phù hợp.
Khi có conflict, đọc các phiên bản và ý định thay đổi rồi giải quyết nhất quán. Không xóa dấu đánh conflict rồi coi việc đã xong. Pull request hay merge request là cơ chế review trên nền tảng, không phải tên khác của lệnh commit hoặc điều kiện bắt buộc để Git chạy cục bộ.
Submodule liên kết repository riêng tại một commit được ghi trong dự án cha. Nó khác branch trong cùng repository. Việc lấy source của dự án cha chưa tự bảo đảm nội dung submodule đã được khởi tạo hoặc cập nhật đúng; đọc hướng dẫn trước khi chạy các bước liên quan mã bên ngoài.
Mở terminal tại nơi dành cho bài học và chạy khối dưới. mktemp -d tạo thư mục mới; biến lpi_lab_dir chỉ lưu đường dẫn của bài, không thay biến hệ thống. Giữ cùng cửa sổ terminal cho các bước sau.
lpi_lab_dir=$(mktemp -d)
cd "$lpi_lab_dir"
git --version
git init -b main
git config user.name 'LPI Demo'
git config user.email 'demo@example.invalid'
git config commit.gpgsign false
Các lệnh config không dùng --global, chỉ tác động repository học. Tắt yêu cầu ký commit ở fixture để không gọi khóa cá nhân trong lab; đây không phải đề xuất tắt chính sách ký của dự án thật. Chạy pwd nếu cần xác nhận thư mục trước khi tạo tệp.
printf 'Ticket: open\n' > guide.txt
git add guide.txt
git diff --cached
git commit -m 'Add DEMO guide'
git status
Kết quả mong đợi có một commit và working tree sạch. git diff --cached cho thấy nội dung chuẩn bị commit. Nếu báo thiếu danh tính, kiểm tra hai giá trị config trong repository; không sao chép credential hoặc tên người khác để vượt lỗi.
Không dùng git add . theo thói quen khi chưa biết thư mục chứa gì. Trong lab chỉ add đúng guide.txt; cách chỉ rõ tệp giúp nối hành động với đầu ra cần quan sát. Chưa có remote nên commit vẫn hoàn toàn cục bộ.
git switch -c codex/demo-guide
printf 'Ticket: open\nStatus: verified\n' > guide.txt
git diff
git add guide.txt
git diff --cached
git commit -m 'Clarify DEMO status'
Trước add, diff thông thường hiện dòng được thêm; sau add, diff cached hiện thay đổi trong index. Đây là thông tin giả để học thao tác, không xác nhận ticket thật đã được kiểm chứng. Từ “verified” chỉ là nội dung fixture.
Nếu lệnh tạo nhánh nói tên đã tồn tại, kiểm tra bạn có đang lặp lại bài trong repository cũ không. Không chạy lệnh xóa hoặc reset để ép bài tiếp tục. Một thư mục học mới giúp tránh lẫn lịch sử giữa các lần thử.
git switch main
git merge --ff-only codex/demo-guide
git tag -a v0.1.0 -m 'DEMO snapshot'
git show v0.1.0:guide.txt
git log --oneline --decorate
Trong fixture này, main chưa có thay đổi riêng nên fast-forward thành công. Tệp ở tag có hai dòng. --ff-only sẽ từ chối nếu không thể fast-forward, giúp tình huống không âm thầm tạo kiểu tích hợp khác. Bài chưa tạo hoặc giải quyết conflict.
Tag v0.1.0 đánh dấu snapshot học tập, không xuất bản sản phẩm hoặc đẩy tag đi đâu. Sau khi tạo, cần kiểm tra tham chiếu và nội dung thay vì chỉ thấy tên xuất hiện trong danh sách.
git revert --no-edit HEAD
cat guide.txt
git log --oneline
git status --short
git remote -v
Revert tạo thay đổi đảo ngược trong lịch sử. Ở fixture tuyến tính, nội dung trở lại một dòng Ticket: open, có ba commit, working tree sạch và không remote. Tag trước đó vẫn trỏ tới trạng thái hai dòng. Đây là kết quả đã quan sát trên môi trường nêu đầu bài.
Không áp dụng khối lệnh này tùy tiện vào dự án thật: HEAD có thể là commit khác hoặc merge commit, và revert có thể gặp conflict. Lab kết thúc bằng giữ repository học để xem lại; không cần chạy lệnh xóa thư mục hay sửa lịch sử.
Commit khác push ở đâu? Commit ghi lịch sử cục bộ; push trao đổi với remote. Index có phải bản hiện tại trên máy chủ không? Không, nó chuẩn bị nội dung commit. Tag cũ có đổi theo revert không? Trong lab không, tag vẫn đánh dấu commit đã chọn.
Lab đã kiểm tra init, diff, stage, commit, branch, fast-forward, tag và revert. Nó chưa kiểm tra remote authentication, review trên nền tảng, submodule hoặc conflict. Khi chuyển sang làm nhóm, đọc quy tắc nhánh và quyền trước, không lấy lịch sử đơn giản này làm bảo đảm mọi tình huống hợp nhất đều dễ dàng.
Khung mục tiêu: LPI Open Source Essentials 056.2. Tài liệu Git và Apache Subversion được dẫn trực tiếp tại thuật ngữ tương ứng. Mọi tệp, commit và tag trong bài chỉ thuộc fixture DEMO được biên soạn riêng.
Chọn chat, email, issue, ticket và tài liệu theo mục tiêu; hiểu federation, wiki, CMS, DMS, rồi lập báo cáo, ghi chú quyết định và dàn ý tài liệu DEMO.
Phân biệt IDE, build, linter, debugger, các loại test và môi trường CI/CD; chạy lab Node để thấy cú pháp hợp lệ vẫn có thể sai hành vi rồi khôi phục.
Nhận diện maintainer, contributor, quản trị và tài trợ; đọc DCO, CLA, quy tắc ứng xử, rồi soạn phản hồi đóng góp tài liệu qua tình huống DEMO riêng.
Đọc alpha, beta, RC, SemVer, LTS và EOL; phân biệt các lớp tương thích, dùng release notes và lập hồ sơ nâng cấp với ba thay đổi API giả định DEMO.