GitHub từ người mới bắt đầu đến chuyên gia: Hướng dẫn toàn diện

1. Git và GitHub: Ai Quản Lý Cái Gì?

Git là công cụ quản lý phiên bản được cài đặt trên máy tính của bạn. Khi offline, bạn vẫn có thể commit, xem lịch sử, tạo nhánh và merge. GitHub là nền tảng kho lưu trữ từ xa và cộng tác; nó nhận các commit được Git đẩy lên và cung cấp Issues, Pull Requests, Actions, code review và quản lý quyền.

Điều dễ gây nhầm lẫn nhất trong Git là cùng một sửa đổi có thể tồn tại ở bốn vị trí khác nhau. Sơ đồ bên dưới phân tích workspace, staging area, local repository và remote repository thành bốn lớp.

Nhấn save chỉ ghi nội dung vào ổ cứng. git add chịu trách nhiệm chọn lọc, git commit để lại một phiên bản ở local, và git push gửi các commit này lên GitHub.

Vì vậy, trước khi commit, hãy kiểm tra diff, chạy thử hoặc test; sau khi push thành công, hãy quay lại trang web để kiểm tra lại. Bằng cách này, nếu có vấn đề xảy ra, bạn có thể biết ngay nó dừng lại ở lớp nào.

2. Trước Khi Bắt Đầu: Chỉ Chuẩn Bị Bốn Thứ

Bạn cần Git, tài khoản GitHub, trình soạn thảo và một dự án thực hành. VS Code là đủ cho trình soạn thảo, và dự án có thể là một trang web hoặc tài liệu Markdown.

Đầu tiên, xác nhận Git trong terminal:

1git --version

Bài thực hành này sử dụng macOS và Git 2.49.0. Người dùng Windows có thể sử dụng Git Bash hoặc terminal tích hợp trong VS Code; các lệnh Git bên dưới đều giống nhau.

Tiếp theo, cấu hình tác giả commit:

1git config --global user.name "Your Name"
2git config --global user.email "Your Email"

Đây là thông tin tác giả được ghi vào bản ghi commit; nó không chịu trách nhiệm đăng nhập vào GitHub. Nếu bạn chỉ muốn cấu hình cho dự án thực hành hiện tại, hãy thay --global bằng --local.

Đăng nhập GitHub là một việc riêng. Dòng lệnh thường sử dụng ba phương pháp:

• GitHub CLI, ủy quyền qua trình duyệt với gh auth login;
• HTTPS, sử dụng Personal Access Token hoặc credential manager;
• SSH, thêm khóa công khai vào GitHub và xác thực qua khóa sau này.

Người mới bắt đầu có thể chọn GitHub CLI hoặc HTTPS. Khi sử dụng HTTPS, nếu terminal yêu cầu Password, hãy điền Token; mật khẩu tài khoản thông thường không còn được áp dụng. Không viết Token vào lệnh, URL từ xa, README, chat hoặc ảnh chụp màn hình.

3. Đừng Vội init: Xác Nhận Terminal Đang Ở Đâu

Bài thực hành này bắt đầu với một trang web đơn giản. Nó có thể mở được trong trình duyệt nhưng chưa có lịch sử Git.

Có ba tệp trong dự án:

1index.html
2style.css
3.gitignore

Trong VS Code, chọn "Open Folder," đừng chỉ click vào một tệp HTML. Sau đó chạy trong terminal tích hợp:

1pwd
2ls

pwd hiển thị thư mục hiện tại, và ls liệt kê các tệp. Chỉ tiếp tục sau khi thấy index.html và style.css.

Việc kiểm tra này có vẻ ngớ ngẩn, nhưng nó ngăn ngừa loại tai nạn rắc rối nhất: ai đó thực thi git init trên Desktop, Documents, hoặc thậm chí là thư mục home của người dùng, và sau đó git add . đưa hàng nghìn tệp không liên quan vào staging area. Git không hỏng; chỉ là thư mục đã sai.

4. git init Làm Gì?

Bây giờ khởi tạo kho lưu trữ:

1git init -b main
2git status --short

git init -b main tạo một thư mục .git trong thư mục hiện tại và đặt tên nhánh ban đầu là main. .git là một thư mục ẩn nơi lưu trữ thông tin như commit, nhánh, staging area và địa chỉ từ xa. Các tệp dự án vẫn giữ nguyên; Git bắt đầu quan sát chúng từ thời điểm này.

?? trong ảnh chụp màn hình cho biết các tệp chưa được theo dõi. Các tệp tồn tại, nhưng Git chưa quyết định có ghi lại chúng hay không.

Để xác nhận thư mục gốc của kho lưu trữ, bạn có thể chạy:

1git rev-parse --show-toplevel

Đầu ra phải là thư mục dự án hiện tại. Nếu nó báo fatal: not a git repository, hãy kiểm tra thư mục trước, sau đó xem git init đã được thực thi chưa.

5. Commit Đầu Tiên: Giữ Một Điểm Bắt Đầu Đáng Tin Cậy

Dự án chưa được sửa đổi, vậy tại sao phải commit trước? Bởi vì tất cả các thay đổi tiếp theo đều cần một điểm bắt đầu có thể so sánh được. Đầu tiên, mở trang web trong trình duyệt để xác nhận tiêu đề, thẻ và khu vực đăng ký được hiển thị; thu nhỏ cửa sổ để xem có thanh cuộn ngang ở chiều rộng di động không.

Sau đó xem .gitignore. Nội dung được sử dụng lần này là:

1.env
2.env.*
3*.log
4node_modules/
5dist/
6build/

.gitignore được sử dụng để chặn khóa, nhật ký, phụ thuộc và các tạo phẩm xây dựng. Nó chủ yếu hoạt động trên các tệp chưa được theo dõi. Nếu một khóa đã được commit và sau đó bạn thêm nó vào .gitignore, lịch sử đó vẫn tồn tại; xử lý thực sự cũng bao gồm thu hồi hoặc xoay vòng khóa.

Bắt đầu chọn tệp cho commit đầu tiên:

1git add index.html style.css .gitignore
2git status --short
3git diff --cached --stat

A trong trạng thái là viết tắt của Added, cho biết tệp đã vào staging area. git diff --cached --stat sẽ cho bạn biết bạn đang chuẩn bị commit bao nhiêu tệp và đại khái có bao nhiêu dòng đã được thay đổi. Để xem nội dung cụ thể, hãy chạy:

1git diff --cached

Commit sau khi xác nhận:

1git commit -m "chore: Khởi tạo trang tuyển dụng AI trong khuôn viên trường"
2git log --oneline
3git status

Một Commit có thể được hiểu là một ảnh chụp nhanh dự án với tác giả, thời gian, mô tả và commit cha. ffdf4ff là phiên bản rút gọn của hash commit này; sử dụng nó trong kho lưu trữ hiện tại có thể định vị chính xác phiên bản.

feat, fix, docs, style, chore là các loại commit phổ biến, không phải cú pháp Git bắt buộc. Quan trọng hơn tiền tố là mô tả bằng tiếng Việt (hoặc tiếng Anh) theo sau nó: đã làm gì, đối tượng nào đã được sửa đổi và tại sao.

6. Commit Thứ Hai: Coi Sửa Đổi Của AI Như Bản Nháp Cần Xem Xét

Tiếp theo, thêm một nút "Xem Phương Thức Đăng Ký" vào trang. Khi sử dụng các công cụ lập trình AI, tôi viết các ranh giới vào prompt:

1Chỉ sửa đổi index.html, thêm một liên kết "Xem Phương Thức Đăng Ký" bên dưới văn bản giới thiệu,
2liên kết đến #apply trong trang. Không sửa đổi style.css, không thực thi Git commits.
3Cho tôi biết tệp nào đã được sửa đổi khi hoàn thành.

Sửa đổi thủ công cũng đơn giản:

1<a class="cta" href="#apply">Xem Phương Thức Đăng Ký</a>

AI nói đã xong, nhưng đừng commit vội. Chạy:

1git status --short
2git diff -- index.html
3git diff --check

git diff hiển thị các thay đổi trong workspace chưa được đưa vào staging. Dòng + màu xanh lá là dòng đã thêm, dòng - màu đỏ là dòng đã xóa. git diff --check không có đầu ra, cho biết không tìm thấy vấn đề định dạng rõ ràng như khoảng trắng ở cuối; nó sẽ không kiểm tra xem nút có thể click được cho bạn hay không.

Quay lại trình duyệt và làm mới, click vào nút, sau đó thu nhỏ cửa sổ. Trang sẽ cuộn đến khu vực đăng ký, và nút cùng các thẻ vẫn bình thường trên màn hình hẹp.

Chỉ commit sau khi kiểm tra thành công:

1git add index.html
2git diff --cached
3git commit -m "feat: Thêm mục đăng ký để xem nhanh phương thức ứng tuyển"
4git log --oneline -2

Lúc này, có hai phiên bản rõ ràng trong kho lưu trữ: trang bắt đầu và nút đăng ký. Nếu nút có vấn đề sau này, bạn có thể trực tiếp tìm commit nào đã thêm nó.

Nhân tiện, hãy phân biệt hai lệnh diff:

1git diff             # Sự khác biệt giữa workspace và staging area
2git diff --cached    # Sự khác biệt giữa staging area và commit gần nhất

Nếu git diff không có đầu ra, tệp có thể chưa được lưu hoặc đã được đưa vào staging hoặc commit. Kiểm tra git status, git diff --cached và git log theo thứ tự sẽ đáng tin cậy hơn là gõ đi gõ lại git add ..

7. Nhánh: Để Lại Một Chỗ Thử Nghiệm Cho Các Thay Đổi Không Chắc Chắn

Nút chỉ thêm một dòng, vì vậy rủi ro nhỏ. Thay đổi toàn bộ chủ đề từ tím sang cam có thể đẹp hoặc có thể trông lòe loẹt; loại sửa đổi này phù hợp với một nhánh.

1git switch -c experiment/warm-theme
2git branch --show-current

Một nhánh về mặt khái niệm là một tên trỏ đến một commit nhất định. Khi một nhánh mới được tạo lần đầu, nó trỏ đến cùng một commit với main, vì vậy các tệp hoàn toàn giống nhau. Chỉ khi nhánh thử nghiệm tạo ra các commit mới, hai dòng mới phân kỳ.

Trong sơ đồ, main màu xanh lam vẫn trỏ đến commit thứ hai, trong khi experiment màu cam đã trỏ đến commit thứ ba. Dự án không sao chép hai bộ tệp; chỉ có các con trỏ cho hai tên nhánh thay đổi.

Sửa đổi các biến màu trong style.css, làm mới trang để xác nhận, sau đó commit:

1git diff -- style.css
2git diff --check
3git add style.css
4git commit -m "style: Thử chủ đề ấm áp trong nhánh thử nghiệm"
5git log --oneline --graph --decorate --all

HEAD cho biết bạn đang đứng ở đâu. Trong ảnh chụp màn hình, HEAD trỏ đến experiment/warm-theme, trong khi main vẫn ở commit nút.

Quyết định giữ chủ đề ấm áp, chuyển về main và merge:

1git switch main
2git merge experiment/warm-theme

Fast-forward xảy ra ở đây vì main không có commit mới nào trong quá trình thử nghiệm. Git trực tiếp di chuyển con trỏ main về phía trước đến commit chủ đề ấm áp; các thay đổi đã được merge thành công.

Các nhánh đã merge có thể được xóa an toàn:

1git branch -d experiment/warm-theme

-d viết thường kiểm tra xem nhánh đã được merge chưa. -D viết hoa sẽ xóa mạnh và các commit trong nhánh chưa được merge có thể mất tham chiếu; đừng sử dụng nó như một lệnh dọn dẹp hàng ngày.

8. Xung Đột Không Phải Là Điều Bí Ẩn; Git Chỉ Không Dám Chọn Cho Bạn

Để xác minh xung đột, tôi đã sao chép kho lưu trữ. main đã thay đổi tiêu đề chính thành "Hãy để sự sáng tạo trong khuôn viên trường được nhiều người nhìn thấy hơn," và nhánh feature đã thay đổi cùng một dòng thành "Biến một ý tưởng thành một tác phẩm thực sự có thể sử dụng được." Git đã dừng lại trong quá trình merge:

Các dấu hiệu xung đột được chia thành ba phần:

1<<<<<<< HEAD
2Nội dung của nhánh hiện tại
3=======
4Nội dung của nhánh sẽ được merge vào
5>>>>>>> feature/rewrite-heading

Phương pháp xử lý là chỉnh sửa tệp, để lại văn bản cuối cùng mong muốn, xóa ba bộ dấu hiệu, kiểm tra nó, sau đó chạy:

1git add index.html
2git commit

Nếu bạn không muốn xử lý vào lúc đó, bạn có thể hủy bỏ merge:

1git merge --abort

Xung đột có nghĩa là hai người hoặc hai Agent đã đưa ra câu trả lời khác nhau cho cùng một vị trí và Git không thể tự mình chọn.

9. Gửi Kho Lưu Trữ Local Lên GitHub

Dự án đã có lịch sử local; bây giờ hãy lên GitHub để tạo một kho lưu trữ. Click vào + ở góc trên bên phải, chọn "New repository," và điền tên kho lưu trữ, ví dụ:

1campus-ai-demo

Đối với lần thực hành đầu tiên, nên đặt chế độ Private. Vì local đã có README, .gitignore và lịch sử commit, hãy giữ kho lưu trữ GitHub mới trống; đừng khởi tạo README, license hoặc .gitignore trên web. Nếu không, local và remote sẽ mỗi bên có một phần lịch sử ban đầu và lần push đầu tiên sẽ yêu cầu xử lý mối quan hệ giữa hai bên trước. Hướng dẫn chính thức "Adding locally hosted code" của GitHub cũng nhắc nhở rõ ràng về điều này.

Sao chép địa chỉ HTTPS:

1https://github.com/YourUsername/campus-ai-demo.git

Quay lại terminal của dự án:

1git remote add origin https://github.com/YourUsername/campus-ai-demo.git
2git remote -v
3git push -u origin main

origin là bí danh cho địa chỉ từ xa; nó có thể hoạt động với các tên khác, nhưng cộng đồng có thói quen gọi remote chính là origin. -u sẽ thiết lập mối quan hệ theo dõi giữa main local và origin/main; các thao tác tiếp theo thường chỉ cần chạy git push.

Sơ đồ terminal bên dưới đã sử dụng một kho lưu trữ trần local để chạy qua push và clone, vì vậy nó không thay đổi tài khoản GitHub hiện có. Khi chuyển sang GitHub, chỉ cần thay thế URL origin; logic để Git chuyển commit và thiết lập mối quan hệ theo dõi là giống nhau.

Sau khi push thực sự hoàn tất, hãy quay lại trang web GitHub và làm mới để xác nhận rằng các tệp, README, nhánh mặc định và lịch sử commit đều hiển thị. Thông báo thành công trong terminal là một lớp bằng chứng và kiểm tra web là một lớp khác.

10. Đọc Kho Lưu Trữ GitHub Lần Đầu: Cách Đọc Những Thứ Này Trên Trang

Dưới đây là trang thực tế của kho lưu trữ tài liệu GitHub chính thức, được chụp màn hình vào ngày 15 tháng 8 năm 2026.

Khi mở một kho lưu trữ, hãy xem các vị trí này trước:

• Code: Tệp, thư mục, nhánh và commit;
• Issues: Lỗi, yêu cầu, nhiệm vụ và thảo luận;
• Pull requests: Các thay đổi đang chờ xem xét hoặc merge;
• Actions: Kiểm thử tự động, xây dựng và triển khai;
• Security: Chính sách bảo mật và các chức năng liên quan đến lỗ hổng;
• Insights: Đóng góp, lưu lượng truy cập và hoạt động của kho lưu trữ;
• README: Giới thiệu dự án và điểm vào sử dụng;
• LICENSE: Cách nó được phép sử dụng, sửa đổi và phân phối.

Khi đọc một dự án không quen thuộc, đừng nhìn chằm chằm vào Stars trước. Hãy trả lời năm câu hỏi trước: Nó giải quyết vấn đề gì, nó chạy như thế nào, nó phụ thuộc vào cái gì, nó có được bảo trì gần đây không và giấy phép cho phép tôi làm gì. Stars phản ánh sự chú ý; chúng không kiểm tra bảo mật, khả năng tương thích hoặc ủy quyền cho bạn.

11. clone, fetch, pull, push: Đừng Nhầm Lẫn Bốn Hướng

Đưa một kho lưu trữ từ xa vào máy tính của bạn lần đầu tiên:

1git clone https://github.com/OWNER/REPO.git

Clone mang về các tệp, lịch sử commit và cấu hình từ xa, thường tự động đặt tên remote là origin. Tải xuống ZIP chỉ cung cấp một ảnh chụp nhanh các tệp tại thời điểm đó, không có lịch sử đầy đủ và sẽ không thiết lập mối quan hệ từ xa.

Ba hành động thường được sử dụng sau đó là:

1git fetch origin   # Tải xuống thông tin từ xa, không thay đổi tệp làm việc hiện tại
2git pull           # fetch và sau đó tích hợp vào nhánh hiện tại
3git push           # Gửi các commit local lên remote

Để xem những gì đã xảy ra từ xa trước, bạn có thể:

1git fetch origin
2git status -sb
3git log --oneline HEAD..origin/main

Khi xác nhận không có sự phân kỳ ở local và bạn chỉ muốn chấp nhận các bản cập nhật fast-forward:

1git pull --ff-only

pull sẽ fetch trước, sau đó thực hiện merge hoặc rebase dựa trên cấu hình. Các nhóm nên thống nhất phương pháp tích hợp trước lần cộng tác đầu tiên và đừng dựa vào force push để giải quyết vấn đề khi xảy ra phân kỳ.

12. Từ Kho Lưu Trữ Cá Nhân Đến Cộng Tác Trên GitHub

Pull Request là một đề xuất merge và là nơi diễn ra sự cộng tác. Thảo luận, code review và kiểm tra tự động đều xoay quanh cùng một tập hợp các thay đổi và nó được merge vào main chỉ sau khi xác nhận.

Giả sử Issue là "Thêm mô tả thời gian sự kiện," các thao tác local có thể được thực hiện như sau:

1git switch -c feat/event-time
2# Sửa đổi và kiểm tra trang
3git add index.html
4git commit -m "feat: Thêm mô tả thời gian sự kiện"
5git push -u origin feat/event-time

Sau khi push, GitHub thường nhắc tạo Pull Request. PR là một đề xuất merge hiển thị mô tả, commit, khác biệt tệp, nhận xét, đánh giá và kiểm tra tự động. Nó sẽ không tự động vào main chỉ vì nó được tạo.

Một PR mà mọi người sẵn sàng xem xét nên giải thích ít nhất ba điều: những gì đã thay đổi, tại sao nó được thay đổi và cách xác minh nó. Các thay đổi càng tập trung, người đánh giá càng dễ phát hiện vấn đề.

Trong cùng một nhóm, nếu bạn có quyền ghi vào kho lưu trữ, bạn có thể gửi PR trực tiếp từ một nhánh. Khi đóng góp cho một dự án mã nguồn mở không quen thuộc, thông lệ phổ biến là Fork nó vào tài khoản của bạn trước, sau đó clone Fork của riêng bạn:

1git clone https://github.com/YourUsername/ProjectName.git
2cd ProjectName
3git remote add upstream https://github.com/OriginalAuthor/ProjectName.git
4git remote -v

Thường có hai remote ở đây:

1origin    Fork của riêng bạn
2upstream  Kho lưu trữ của tác giả gốc

Đồng bộ hóa dự án gốc:

1git fetch upstream
2git switch main
3git merge --ff-only upstream/main
4git push origin main

Sau đó hoàn thành các sửa đổi trong một nhánh mới, push lên Fork của riêng bạn, sau đó gửi PR đến upstream. Fork, clone và nhánh giải quyết ba việc khác nhau: Fork là một bộ không gian kho lưu trữ trên GitHub, clone đưa kho lưu trữ về local và nhánh là một dòng phát triển trong một kho lưu trữ.

13. README và LICENSE Xác Định Liệu Người Khác Có Dám Sử Dụng Nó Không

README nên trả lời ít nhất những câu hỏi này:

1. Dự án là gì;
2. Nó giải quyết vấn đề gì;
3. Cách cài đặt hoặc chạy nó;
4. Nó đã hoàn thành đến mức độ nào;
5. Các tệp chính nằm ở đâu;
6. Ai là tác giả, tài liệu và nguồn trích dẫn.

Nếu mã có thể chạy nhưng README mơ hồ, bạn có thể không tự mình sử dụng được nó ba tháng sau. Một README tối thiểu không cần phải đẹp; chỉ cần viết rõ dự án, phương pháp chạy và trạng thái.

Các kho lưu trữ công khai cũng không tự động có nghĩa là có được giấy phép mã nguồn mở. Giải thích giấy phép chính thức của GitHub nêu rõ: khi không có giấy phép, các quy tắc bản quyền mặc định vẫn được áp dụng và tác giả giữ quyền sao chép, phân phối và tạo các tác phẩm phái sinh. Công khai có nghĩa là người khác có thể nhìn thấy nó và Fork nó theo Điều khoản dịch vụ của GitHub; để lấy mã vào dự án công khai hoặc thương mại của riêng bạn, bạn cũng cần xem LICENSE trong kho lưu trữ.

MIT, Apache-2.0, GPL, v.v., có các nghĩa vụ khác nhau. Khi gặp phải sử dụng thương mại, phân phối lại hoặc giấy phép hỗn hợp, hãy đọc toàn bộ tệp và tham khảo ý kiến chuyên gia nếu cần; đừng chỉ hỏi AI "Tôi có thể sử dụng nó cho mục đích thương mại không?"

14. Sau Khi Mắc Lỗi: Xác Định Thay Đổi Đang Ở Lớp Nào

Thuốc hối hận nên được chọn theo trạng thái.

Đã đưa nhầm tệp vào staging nhưng muốn giữ nội dung tệp:

1git restore --staged filename

Thông báo commit gần nhất được viết sai và chưa được push:

1git commit --amend -m "Thông báo commit mới"

Một commit trên nhánh dùng chung cần được thu hồi:

1git revert commit_hash

revert sẽ tạo ra một commit đảo ngược mới và lịch sử cũ vẫn hiển thị, phù hợp với các nhánh đã được push và được nhiều người sử dụng.

git restore filename sẽ loại bỏ các sửa đổi chưa được commit; git reset --hard sẽ đưa commit, staging area và workspace trở về một vị trí được chỉ định; git push --force có thể ghi đè các commit từ xa. Ba loại thao tác này yêu cầu xác nhận mục tiêu và sao lưu trước khi thực hiện; đừng coi chúng như các nút sửa chữa chung trong giai đoạn cơ bản.

15. Tám Lỗi Phổ Biến Nhất: Kiểm Tra Theo Thứ Tự Này

1. fatal: not a git repository

1pwd
2ls
3git status

Thông thường, thư mục sai hoặc dự án hiện tại chưa được git init.

2. Author identity unknown

1git config --local user.name "Your Name"
2git config --local user.email "Your Email"

3. nothing to commit

Kiểm tra xem tệp đã được lưu chưa, bạn có sửa đổi một bản sao khác không và các thay đổi đã được commit chưa:

1git status
2git log --oneline -3

4. remote origin already exists

1git remote -v
2git remote set-url origin CorrectGitHubAddress

5. src refspec main does not match any

Kho lưu trữ có thể chưa có commit hoặc nhánh hiện tại không được đặt tên là main:

1git log --oneline
2git branch --show-current

6. Authentication failed or 403

Kiểm tra URL từ xa, quyền sở hữu kho lưu trữ, quyền tài khoản và phương thức xác thực. Không gửi Token cho người khác để khắc phục sự cố.

7. rejected non-fast-forward

Có các commit từ xa không có ở local. Fetch và xem sự khác biệt trước; đừng chỉ force push:

1git fetch origin
2git status -sb
3git log --oneline --graph --decorate --all -10

8. Merge Conflict

Chạy git status để tìm các tệp UU, xác định thủ công nội dung cuối cùng, kiểm tra, sau đó add và commit; nếu chưa xử lý ngay, git merge --abort.

Khi một sinh viên hoặc đồng nghiệp chỉ nói "Git bị hỏng", hãy yêu cầu họ cung cấp năm đầu ra sau:

1pwd
2git status
3git branch --show-current
4git log --oneline -5
5git remote -v

Sau đó, thêm hệ điều hành, lệnh đầy đủ vừa được thực thi và thông báo lỗi đầy đủ. Hầu hết các vấn đề sẽ nhanh chóng rơi vào một trong các lớp: thư mục, trạng thái, danh tính, địa chỉ từ xa hoặc quyền.

16. Trong Kỷ Nguyên AI, Git Giống Như Một Hệ Thống Chấp Nhận Hơn

AI có thể gõ lệnh cho bạn, nhưng nó không thể tự động biết được những sửa đổi nào đáp ứng được mục đích kinh doanh. Nếu một lời nhắc thay đổi 20 tệp và bạn không xem diff, không chạy dự án và không kiểm tra các khóa, Git sẽ chỉ trung thực ghi lại mớ hỗn độn này.

Một cách ổn định hơn là thu hẹp nhiệm vụ và đặt con người vào vị trí chấp nhận. Sau khi phạm vi, sự khác biệt, kiểm thử và kiểm tra khóa đều vượt qua, con người sẽ quyết định xem những sửa đổi này có thể trở thành một commit hay không.

Khi để AI vận hành Git, cũng hãy đưa ra các ranh giới:

1Vui lòng kiểm tra git status và git diff trước, và chỉ tóm tắt các thay đổi hiện tại.
2Không được loại bỏ bất kỳ nội dung chưa commit nào, không thực thi reset --hard, clean hoặc force push.
3Cung cấp kết quả xác minh sau khi hoàn thành sửa đổi, không tự động commit hoặc push.

Việc bạn có thể ghi nhớ các lệnh hay không không còn quan trọng nữa. Bạn cần có khả năng đọc trạng thái, biết AI đã di chuyển những gì, đánh giá xem việc xác minh đã đủ chưa và dừng lại khi các thao tác nguy hiểm xuất hiện.

17. Chạy Lại Toàn Bộ Quy Trình

1# 1. Xác nhận vị trí
2pwd
3ls
4
5# 2. Khởi tạo
6git init -b main
7git status
8
9# 3. Commit đầu tiên
10git add index.html style.css .gitignore
11git diff --cached
12git commit -m "chore: Khởi tạo dự án"
13
14# 4. Sửa đổi, kiểm tra, kiểm thử, commit lại
15git status --short
16git diff
17git diff --check
18git add index.html
19git commit -m "feat: Thêm mục đăng ký"
20
21# 5. Thử nghiệm nhánh
22git switch -c experiment/warm-theme
23git add style.css
24git commit -m "style: Thử nghiệm với chủ đề ấm áp"
25git switch main
26git merge experiment/warm-theme
27
28# 6. Kết nối với GitHub
29git remote add origin https://github.com/YourUsername/RepoName.git
30git remote -v
31git push -u origin main
32
33# 7. Kiểm tra cuối cùng
34git status
35git log --oneline --graph --decorate --all
36git remote -v
37git diff --check
38git ls-files

Khi bạn có thể giải thích lệnh nào thay đổi lớp nào và có thể độc lập xử lý một thư mục sai, lỗi staging và xung đột merge, GitHub không còn chỉ là một trang web để lưu trữ mã nguồn. Bạn đã có thể biến các dự án cá nhân thành các kho lưu trữ có thể được xem xét, kiểm toán và cộng tác.

Bước tiếp theo không yêu cầu tiếp tục thu thập các lệnh. Hãy tìm một dự án nhỏ thực sự và thực hiện nó trong 7 ngày liên tiếp: mỗi ngày chỉ hoàn thành một sửa đổi nhỏ, xem diff, kiểm thử, commit, sau đó push lên GitHub. Lịch sử commit sẽ từ từ biến tập hợp những điều này thành thói quen làm việc của bạn.

Tôi là Miles, một chuyên gia thuật toán AI đã chuyển từ công ty lớn sang FDE. Tôi đã làm nghiên cứu và phát triển thuật toán, triển khai tối ưu hóa và đào tạo doanh nghiệp. Theo dõi tôi @miles_mazy Cùng phát triển, cùng kiếm tiền.