Bạn đã bao giờ sửa xong một file, chạy thử thì báo lỗi, rồi mới chợt nhận ra mình không còn nhớ bản nào mới là bản chạy được? Đội ngũ bên mình gặp chuyện này rất thường xuyên ở các bạn mới học. Có bạn sinh viên mất cả buổi tối chỉ vì xoá nhầm một đoạn code đã chạy đúng từ trước. Vì vậy, chúng tôi luôn khuyên bạn làm quen với git cho người mới bắt đầu ngay từ những dự án nhỏ đầu tiên, đừng đợi đến khi có việc làm mới học.
Vì sao người mới nên dùng Git ngay từ đầu
Nói ngắn gọn, Git là công cụ ghi lại lịch sử thay đổi của dự án. Bạn có thể hình dung nó như một cuốn nhật ký: mỗi lần sửa code, Git ghi lại dòng nào đã đổi, đổi thành gì và vào lúc nào. Nhờ vậy, bạn có thể quay về bất kỳ phiên bản nào mà không phải lo mất công sức đã bỏ ra.
Chúng tôi thường nhắc các bạn học Git song song với việc viết code, đừng để dành đến lúc đi làm. Lý do rất đơn giản. Dự án càng lớn, lỗi càng khó lần ra. Khi đã có lịch sử rõ ràng, việc tìm nguyên nhân nhanh hơn rất nhiều. Đội ngũ từng theo dõi một nhóm sinh viên tìm lỗi suốt hai ngày liền, và cuối cùng chỉ cần so sánh hai commit gần nhau là họ thấy ngay chỗ sai. Nếu có Git từ đầu, họ đã tiết kiệm được gần hết khoảng thời gian đó.
Cũng cần phân biệt rõ Git và GitHub. Git là phần mềm chạy ngay trên máy bạn. GitHub là dịch vụ trên mạng, nơi lưu bản sao dự án và hỗ trợ làm việc nhóm. Bạn hoàn toàn có thể dùng Git mà không cần GitHub, nhưng chiều ngược lại thì không đúng: GitHub luôn cần Git đi kèm.
Cài đặt Git và khai báo tên, email đầu tiên
Git hỗ trợ đầy đủ trên Windows, macOS và Linux. Bạn tải bộ cài từ trang chính thức git-scm.com rồi cài như các phần mềm thông thường. Trên macOS, nhiều máy đã có sẵn Git khi bạn cài công cụ dòng lệnh của Apple.
Sau khi cài xong, bạn cần cho Git biết tên và email của mình. Mỗi lần commit, Git sẽ ghi kèm thông tin này, giống như bạn ký tên dưới một bản ghi chép. Mở terminal và chạy hai lệnh sau:
git config --global user.name "Nguyen Van A"git config --global user.email "[email protected]"
Để kiểm tra, gõ git --version. Nếu hiện ra số phiên bản thì bạn đã cài thành công. Nếu báo “command not found”, thường là terminal chưa nhận đường dẫn mới. Đóng và mở lại terminal thường sẽ giải quyết được.
Tạo kho lưu trữ và hiểu ba vùng làm việc
Một dự án được Git theo dõi gọi là repository, viết tắt là repo. Có hai cách để bắt đầu. Nếu dự án mới hoàn toàn, bạn chạy git init trong thư mục đó. Nếu repo đã có sẵn trên mạng, bạn dùng git clone kèm địa chỉ để tải về máy.
Phần này nhiều người mới thấy rối. Tuy nhiên, khi hiểu được nó thì mọi thứ phía sau sẽ dễ theo hơn. Git có ba vùng. Thư mục làm việc là nơi bạn sửa file. Vùng staging là nơi bạn chọn những thay đổi sẽ được lưu. Repository là nơi các mốc lưu nằm lại vĩnh viễn.
Hãy tưởng tượng bạn chuẩn bị đồ đi xa. Đồ bày bừa trong phòng là thư mục làm việc. Đồ đã xếp vào va-li là staging. Còn bức ảnh chụp sau chuyến đi chính là commit trong repository.
Mỗi file trong Git đi qua một số trạng thái: untracked (Git chưa theo dõi), modified (đã sửa nhưng chưa chọn lưu), staged (đã đưa vào vùng chờ) và committed (đã lưu thành mốc). Bạn sẽ thấy các trạng thái này khi chạy lệnh status.
Các lệnh dùng hằng ngày: status, add, commit và log
Đây là bộ lệnh bạn sẽ gõ nhiều nhất. Trước mỗi thao tác, hãy chạy git status để xem tình hình: file nào đã đổi, file nào đang chờ lưu. Thói quen này giúp bạn tránh phần lớn lỗi commit nhầm.
Khi đã chắc chắn, dùng git add tenfile.js để đưa file vào staging. Bạn cũng có thể thêm cả thư mục, hoặc dùng git add . cho mọi thay đổi. Với người mới, chúng tôi khuyên nên thêm từng file một để kiểm soát tốt hơn. Sau đó, tạo mốc lưu bằng git commit -m "Thêm form đăng nhập".
Message commit nên nói rõ bạn đã làm gì. “Sửa lỗi nút gửi không hoạt động” hữu ích hơn hẳn so với “update” hay “abc”. Sáu tháng sau, khi cần tìm nguyên nhân một lỗi, chính những dòng message này sẽ giúp bạn định hướng nhanh.
Muốn xem lại lịch sử, gõ git log. Mỗi commit sẽ hiện ra kèm mã định danh, tên tác giả, thời gian và message. Nếu muốn xem gọn hơn, thêm --oneline vào cuối lệnh.
Làm việc với nhánh: tạo, chuyển và gộp branch
Nhánh (branch) là một đường phát triển song song. Bạn có thể thử một tính năng mới trên nhánh riêng mà không ảnh hưởng đến bản chính đang chạy ổn định. Khi thử xong và thấy ổn, bạn gộp vào. Nếu không ưng, bạn bỏ nhánh đi.
Tạo nhánh bằng git branch them-trang-gio-hang, rồi chuyển sang đó bằng git switch them-trang-gio-hang. Hai bước này có thể gộp thành git switch -c them-trang-gio-hang. Khi xong việc, quay về nhánh chính và chạy git merge them-trang-gio-hang để gộp thay đổi.
Đôi khi hai nhánh cùng sửa một dòng code, và Git không tự quyết định nên giữ bản nào. Lúc đó sẽ xuất hiện xung đột (conflict). Git đánh dấu vị trí xung đột ngay trong file. Bạn mở ra, chọn giữ phần nào hoặc viết lại cho hợp lý, rồi add và commit để hoàn tất. Đừng hoảng khi gặp chuyện này, vì nó khá phổ biến khi làm nhóm.
Đồng bộ với GitHub: remote, push và pull
Remote là bản sao của repo đặt ở nơi khác, thường là GitHub. Bạn thêm remote bằng git remote add origin https://github.com/ten-ban/du-an.git. Tên “origin” chỉ là quy ước. Bạn có thể đổi, nhưng hầu hết mọi người đều giữ nguyên.
Đẩy code lên bằng git push -u origin main. Tham số -u chỉ cần dùng lần đầu, các lần sau gõ git push là đủ. Ngược lại, khi muốn lấy code mới nhất từ đồng đội về, bạn dùng git pull.
Với nhóm nhỏ, quy trình phổ biến là mỗi người làm việc trên nhánh riêng, push lên, rồi mở yêu cầu gộp (pull request). Đồng đội sẽ xem trước khi gộp vào nhánh chính. Cách làm này vừa giữ chất lượng, vừa giúp người mới làm quen với việc review code.
Sửa khi commit nhầm: đổi message, bỏ file và hoàn tác
Commit nhầm là chuyện ai cũng gặp, và may là Git có nhiều cách sửa. Nếu chỉ sai message của lần commit gần nhất, bạn chạy git commit --amend -m "Message đúng". Lệnh này thay thế commit cuối thay vì tạo thêm một commit mới.
Nếu lỡ add nhầm một file vào staging, bạn đưa nó ra bằng git restore --staged tenfile. File vẫn nằm nguyên trong thư mục làm việc, chỉ là không còn trong danh sách chờ lưu.
Trường hợp đã commit xong mới nhận ra sai, nhưng bạn muốn hủy commit và giữ lại thay đổi, hãy dùng git reset --soft HEAD~1. Con số 1 nghĩa là lùi lại một commit. Thay đổi sẽ quay về trạng thái đang staged, để bạn sửa rồi commit lại.
Cần cẩn thận với git reset --hard. Lệnh này xoá luôn thay đổi trong thư mục làm việc, và phần đã xoá thường không khôi phục được. Đừng dùng khi chưa chắc chắn, nhất là khi còn code chưa lưu mà bạn cần.
Lỗi thường gặp của người mới và cách tránh
Lỗi phổ biến nhất là commit nhầm những file không nên đưa lên, ví dụ file cấu hình chứa mật khẩu, khoá API, hoặc thư mục node_modules nặng hàng trăm megabyte. Khi đã push lên mạng, việc xoá đi phức tạp hơn nhiều so với lúc còn nằm trên máy.
Cách phòng tránh là tạo file .gitignore ngay từ đầu dự án, liệt kê những thứ Git phải bỏ qua. Ví dụ với dự án Node.js, bạn thêm dòng node_modules/ và .env. Làm việc này trước commit đầu tiên là dễ nhất.
Lỗi thứ hai là làm việc trực tiếp trên nhánh main. Nhánh chính nên giữ ổn định, còn thử nghiệm nên đi trên nhánh riêng. Thói quen tạo nhánh trước khi bắt tay vào việc mới sẽ giúp bạn yên tâm hơn nhiều.
Nếu bạn muốn học bài bản hơn, hãy xem lộ trình học lập trình cho người mới để biết nên học theo thứ tự nào. Phần nền tảng về tư duy giải bài toán cũng rất quan trọng, bạn có thể đọc thêm giải thuật cho người mới tiếp cận bài toán từng bước. Khi đã quen Git, bạn sẽ thấy việc theo dõi thay đổi trong các dự án C trở nên thuận tiện hơn nhiều, đặc biệt khi học về con trỏ (pointer) trong C, nơi một chỗ sửa sai có thể gây lỗi rất khó tìm.
Câu hỏi thường gặp
Git có khác GitHub không?
Có. Git là công cụ quản lý phiên bản chạy trên máy bạn. GitHub là dịch vụ lưu trữ repo Git trên mạng, kèm các tính năng làm việc nhóm như pull request. Có thể hình dung Git là bộ máy, còn GitHub là bãi đỗ xe chung cho bộ máy đó.
Có cần học Git trước khi học lập trình không?
Không bắt buộc. Bạn có thể bắt đầu học ngôn ngữ trước và học Git khi có dự án thật đầu tiên. Tuy vậy, dành một buổi tối để nắm các lệnh cơ bản là đủ dùng và sẽ tiết kiệm nhiều công sức về sau.
Commit nhầm rồi đã push lên thì phải làm sao?
Nếu chỉ là lỗi nhỏ, tạo commit mới để sửa lại là cách an toàn nhất, nhất là khi người khác đã kéo code về. Viết lại lịch sử bằng reset rồi force push chỉ nên làm khi chắc chắn không ai đang dùng nhánh đó. Nếu có mật khẩu bị lộ, hãy đổi mật khẩu trước, rồi mới tính đến chuyện dọn lịch sử.
Mỗi ngày nên commit bao nhiêu lần là hợp lý?
Không có con số cố định, nhưng bạn nên commit mỗi khi hoàn thành một việc nhỏ có ý nghĩa, thường là vài lần mỗi ngày. Commit quá lớn thì khó tìm lỗi, còn commit quá vụn thì lịch sử rối. Nguyên tắc đơn giản: mỗi commit nên là một thay đổi bạn có thể giải thích trong một câu.