Bắt đầu với Git & GitHub: Phân biệt Git vs GitHub và tư duy quản lý phiên bản đúng cách
Hướng dẫn Git và GitHub cho người mới: phân biệt vai trò, hiểu working directory, staging area, commit, branch, remote và xây dựng quy trình quản lý phiên bản đúng cách.
Khi mới học lập trình, nhiều người dùng hai từ Git và GitHub như thể chúng là một công cụ. Thực tế, chúng giải quyết hai bài toán khác nhau. Hiểu sự khác biệt này — cùng với tư duy quản lý phiên bản — sẽ giúp bạn tránh phần lớn lỗi phổ biến khi làm việc với source code.
Git và GitHub khác nhau như thế nào?
Nói ngắn gọn:
Git là công cụ quản lý lịch sử dự án.
GitHub là một nơi phổ biến để lưu repository Git và làm việc cùng người khác.
Bạn có thể dùng Git mà không cần GitHub.
GitHub không phải lựa chọn duy nhất; GitLab và Bitbucket cũng cung cấp dịch vụ tương tự.
Git giống như hệ thống lưu lịch sử và nhánh của tài liệu. GitHub giống như không gian trực tuyến để chia sẻ tài liệu đó, thảo luận và xét duyệt thay đổi.
Bình luận
Vì sao cần quản lý phiên bản?
Hãy tưởng tượng bạn sửa một tính năng trong ba ngày rồi phát hiện hướng triển khai không phù hợp. Nếu chỉ sao chép thư mục theo kiểu project-final, project-final-v2, project-final-fixed, bạn sẽ sớm gặp các vấn đề:
Không biết phiên bản nào thực sự ổn định.
Không biết ai đã thay đổi dòng code nào.
Khó quay lại một trạng thái cũ.
Dễ ghi đè công việc của người khác.
Không thể review từng thay đổi một cách rõ ràng.
Git giải quyết các vấn đề đó bằng một lịch sử có cấu trúc. Mỗi commit là một mốc có nội dung, tác giả, thời điểm và thông điệp giải thích.
Tư duy quan trọng: Git lưu snapshot, không chỉ lưu file
Một cách hiểu đơn giản là mỗi commit đại diện cho một ảnh chụp trạng thái của dự án tại một thời điểm. Git tối ưu cách lưu trữ ở phía sau, nhưng về mặt tư duy, bạn có thể xem lịch sử như sau:
Commit A: khởi tạo dự án.
Commit B: thêm trang đăng nhập.
Commit C: sửa lỗi kiểm tra email.
Bạn không chỉ lưu “phiên bản mới nhất”. Bạn đang tạo một chuỗi quyết định có thể kiểm tra và quay lại.
Ba khu vực cần hiểu trong Git
Trước khi học lệnh, hãy hình dung file của bạn di chuyển qua ba khu vực:
Working directory — nơi bạn đang mở và chỉnh sửa file.
Staging area — nơi bạn chọn những thay đổi sẽ nằm trong commit tiếp theo.
Repository — nơi Git lưu các commit vào lịch sử.
Luồng cơ bản:
Điểm quan trọng là git add không đơn thuần có nghĩa “thêm file vào Git”. Nó có nghĩa: chọn phiên bản hiện tại của thay đổi này cho commit tiếp theo.
Bắt đầu một repository Git
Trường hợp 1: Khởi tạo dự án trên máy
Di chuyển vào thư mục dự án và chạy:
Kiểm tra trạng thái:
Tạo commit đầu tiên:
Trường hợp 2: Lấy dự án có sẵn từ GitHub
git clone tải repository về máy và tự động thiết lập remote mặc định có tên origin.
Quy trình làm việc cơ bản hằng ngày
1. Kiểm tra trạng thái
Hãy hình thành thói quen chạy lệnh này trước và sau mỗi bước quan trọng. Nó cho biết branch hiện tại, file đã sửa, file đã staged và file chưa được Git theo dõi.
2. Xem nội dung thay đổi
Để xem những thay đổi đã staged:
Đừng commit một thay đổi bạn chưa đọc lại.
3. Chọn thay đổi cho commit
Thêm một file cụ thể:
Thêm tất cả thay đổi phù hợp:
Với người mới, thêm từng file hoặc từng nhóm liên quan giúp hạn chế đưa nhầm file vào commit.
4. Tạo commit
Một commit nên nhỏ, có mục đích rõ ràng và vẫn giữ dự án ở trạng thái hợp lý.
5. Đồng bộ với GitHub
Lấy thay đổi mới từ remote:
Đẩy commit lên GitHub:
Nếu đây là lần đầu đẩy một branch mới:
Sau khi thiết lập upstream, những lần tiếp theo thường chỉ cần git push.
Local repository và remote repository
Repository trên máy là local repository. Repository trên GitHub là remote repository. Chúng không tự động giống nhau mọi lúc.
commit lưu thay đổi vào repository trên máy.
push gửi commit từ máy lên remote.
fetch tải thông tin mới từ remote nhưng chưa tích hợp vào branch hiện tại.
pull thường tải và tích hợp thay đổi từ remote.
Kiểm tra các remote đã cấu hình:
Thêm GitHub repository làm remote:
Branch: không gian an toàn để phát triển
Branch cho phép bạn phát triển tính năng hoặc sửa lỗi mà không tác động trực tiếp lên nhánh chính.
Tạo và chuyển sang branch mới:
Xem danh sách branch:
Chuyển branch:
Một cách đặt tên branch dễ đọc:
Tư duy đúng không phải là “mỗi người sở hữu một branch vĩnh viễn”, mà là mỗi thay đổi có mục đích rõ ràng được thực hiện trong một branch ngắn hạn.
Merge và Pull Request
Sau khi hoàn thành một branch, bạn cần tích hợp thay đổi vào branch chính.
Về mặt Git, thao tác đó có thể được thực hiện bằng merge. Trong quy trình cộng tác trên GitHub, bạn thường mở một Pull Request.
Pull Request giúp nhóm:
Đọc phần khác biệt giữa hai branch.
Thảo luận về cách triển khai.
Chạy kiểm tra tự động.
Review và yêu cầu chỉnh sửa.
Ghi lại lý do một thay đổi được chấp nhận.
Quy trình phổ biến:
Cách viết commit có ích
Tránh các thông điệp mơ hồ:
Thay vào đó, mô tả mục đích của thay đổi:
Một số nguyên tắc:
Dùng động từ rõ ràng.
Mỗi commit chỉ nên tập trung vào một thay đổi hợp lý.
Không trộn refactor, sửa lỗi và format toàn dự án nếu chúng không liên quan.
Không commit code hỏng chỉ để “lưu tạm” trên branch dùng chung.
Nội dung commit quan trọng hơn việc tuân thủ cứng nhắc một chuẩn đặt tên.
.gitignore: đừng đưa mọi thứ vào repository
Tạo file .gitignore để bỏ qua dependencies, output build, file tạm và thông tin cục bộ:
Nếu một file đã được Git theo dõi trước khi thêm vào .gitignore, bỏ nó khỏi index bằng:
Sau đó commit thay đổi và thay mới mọi secret có nguy cơ đã bị lộ.
Khi có conflict, Git không bị “hỏng”
Conflict xảy ra khi Git không thể tự quyết định cách kết hợp những thay đổi cạnh tranh. Đây là tình huống bình thường trong cộng tác.
Khi gặp conflict:
Đọc thông báo từ Git.
Chạy git status để xem file cần xử lý.
Mở từng file và chọn nội dung đúng.
Xóa các conflict marker.
Kiểm tra lại ứng dụng.
Stage file đã giải quyết và tiếp tục merge hoặc rebase.
Conflict marker thường có dạng:
Đừng xóa marker một cách máy móc. Hãy hiểu ý định của cả hai thay đổi trước khi quyết định kết quả cuối cùng.
Những lỗi tư duy phổ biến của người mới
“Commit là backup lên Internet”
Không hoàn toàn đúng. Commit được tạo ở local; cần push để gửi lên GitHub.
“Cứ git add . rồi commit là được”
Cách này dễ đưa file tạm, log hoặc thay đổi không liên quan vào commit. Luôn chạy git status và git diff --staged trước khi commit.
“Một commit càng lớn càng tiết kiệm thời gian”
Commit lớn khó review, khó tìm lỗi và khó hoàn tác. Commit nhỏ nhưng có ý nghĩa thường hiệu quả hơn.
“Branch chỉ dành cho team”
Ngay cả khi làm một mình, branch vẫn giúp bạn thử nghiệm mà không làm nhánh chính mất ổn định.
“GitHub là Git”
Nhầm lẫn này khiến nhiều người không hiểu vì sao vẫn có thể commit khi mất mạng hoặc vì sao commit chưa xuất hiện trên GitHub.
“Gặp lỗi thì xóa thư mục .git”
Thư mục .git chứa lịch sử và cấu hình repository. Xóa nó thường làm mất toàn bộ lịch sử Git cục bộ. Hãy đọc lỗi, kiểm tra trạng thái và tìm cách phục hồi phù hợp trước.
Quy trình khuyến nghị cho một thay đổi mới
Sau đó, mở Pull Request, chờ kiểm tra và review trước khi merge.
Cheat sheet cho người mới
Tóm tắt
Git giúp bạn quản lý lịch sử và nhánh của dự án ngay trên máy. GitHub cung cấp remote repository cùng các tính năng cộng tác như Pull Request, review và CI/CD.
Điều quan trọng nhất không phải là học thuộc thật nhiều lệnh, mà là hình thành quy trình:
Hiểu mình đang ở branch nào.
Đọc lại thay đổi trước khi stage.
Chỉ stage những file liên quan.
Tạo commit nhỏ, rõ mục đích.
Đồng bộ cẩn thận với remote.
Dùng branch và Pull Request để bảo vệ nhánh chính.
1# 1. Về nhánh chính và cập nhật code2gitswitchmain3gitpull45# 2. Tạo branch ngắn hạn6gitswitch-cfeature/user-profile78# 3. Sau khi sửa code, kiểm tra thay đổi9gitstatus10gitdiff1112# 4. Chọn file liên quan13gitaddsrc/profile.tssrc/profile.test.ts1415# 5. Kiểm tra chính xác nội dung sắp commit16gitdiff--staged1718# 6. Tạo commit19gitcommit-m"feat: add user profile section"2021# 7. Đẩy branch lên GitHub22gitpush-uoriginfeature/user-profile
Bài viết liên quan
Những bài viết có cùng chủ đề hoặc công nghệ bạn có thể muốn đọc tiếp.
Hướng dẫn Git Aliases và .gitconfig thực chiến: alias an toàn, log đẹp, cấu hình pull/push/rebase, includeIf cho tài khoản work/personal, bảo mật và chia sẻ dotfiles.
Phân tích Gitflow vs GitHub Flow vs Trunk-Based Development: cấu trúc branch, ưu nhược điểm, điều kiện áp dụng, ma trận quyết định và lộ trình chuyển đổi cho từng loại dự án.
Hướng dẫn git worktree từ cơ bản đến thực tế: tạo nhiều working tree, làm feature và hotfix song song, review PR, quản lý list/remove/prune/lock/repair và tránh lỗi phổ biến.
Shan DevCập nhật 10 phút đọcĐang tải lượt xem