💡 Key Takeaways
- The 3 AM Production Crisis That Changed How I Teach Git
- The Foundation: Commands You'll Use Every Single Day
- Branching: Your Parallel Universe Toolkit
- Time Travel: Viewing and Navigating History
Cuộc khủng hoảng sản xuất 3 giờ sáng đã thay đổi cách tôi dạy Git
Đúng 3:17 sáng vào một ngày thứ Ba khi điện thoại của tôi nổ tung với các thông báo. Nhánh sản xuất chính của chúng tôi bị hỏng, các lần triển khai đều thất bại, và không ai có thể hiểu chuyện gì đã xảy ra. Tôi là kỹ sư DevOps cao cấp đang trực, và khi tôi loạng choạng đến laptop, tôi biết chính xác điều gì đã xảy ra — ai đó đã đẩy mạnh vào nhánh chính mà không hiểu rõ những gì họ đang làm.
💡 Những điều quan trọng
- Cuộc khủng hoảng sản xuất 3 giờ sáng đã thay đổi cách tôi dạy Git
- Nền tảng: Các lệnh bạn sẽ sử dụng mỗi ngày
- Branching: Bộ công cụ vũ trụ song song của bạn
- Du hành thời gian: Xem và điều hướng lịch sử
Vụ việc đó đã khiến chúng tôi mất khoảng 47,000 đô la trong doanh thu do sự cố mất kết nối kéo dài bốn giờ. Nhưng quan trọng hơn, nó đã dạy tôi một điều quan trọng: hầu hết các lập trình viên không thực sự cần biết 200 lệnh Git. Họ cần nắm vững khoảng 20 lệnh và hiểu chúng đủ sâu để tránh những sai lầm thảm khốc.
Tôi là Marcus Chen, và tôi đã làm việc như một kỹ sư DevOps và trưởng nhóm kỹ thuật trong 12 năm qua, chủ yếu tại các công ty SaaS từ trung bình đến lớn. Tôi đã hướng dẫn hơn 150 lập trình viên, xem xét hàng ngàn yêu cầu kéo và sửa chữa nhiều thảm họa Git hơn tôi có thể nhớ. Những gì tôi đã học được là việc thành thạo Git không phải là về việc ghi nhớ mọi cờ và tùy chọn — mà là có một mô hình tư duy đáng tin cậy và biết chính xác lệnh nào cần sử dụng trong những tình huống cụ thể.
Biên bản này đại diện cho sự khôn ngoan được tinh chế từ hơn một thập kỷ sử dụng Git trong thực tế. Đây không phải là những lệnh lý thuyết mà tôi tìm thấy trong tài liệu. Đây là 20 lệnh mà tôi sử dụng gần như hàng ngày, những lệnh mà tôi dạy cho mỗi thành viên mới trong đội, và những lệnh đã cứu đội của tôi khỏi hàng giờ thất vọng. Mỗi lệnh ở đây đã giành được vị trí của nó thông qua nhu cầu thực tiễn, không phải tính đầy đủ lý thuyết.
Trước khi chúng ta đi vào chi tiết, hãy để tôi rõ ràng về một điều: đây không phải là phần giới thiệu cho người mới bắt đầu về Git. Nếu bạn hoàn toàn mới với quản lý phiên bản, bạn sẽ muốn bắt đầu với các khái niệm cơ bản ở nơi khác. Hướng dẫn này dành cho các lập trình viên đã biết Git tồn tại và đã sử dụng nó, nhưng muốn nâng cao hiệu suất và sự tự tin của họ. Bạn đã mệt mỏi vì phải tìm kiếm lại những lệnh giống nhau. Bạn muốn một tài liệu tham khảo được chọn lọc, đã được kiểm nghiệm qua thực chiến, thực sự phản ánh cách các chuyên gia sử dụng Git trong môi trường sản xuất.
Nền tảng: Các lệnh bạn sẽ sử dụng mỗi ngày
Hãy bắt đầu với những điều thiết yếu nhất — các lệnh tạo thành xương sống cho quy trình làm việc Git hàng ngày của bạn. Tôi sử dụng những lệnh này thường xuyên đến mức chúng trở thành phản xạ tự nhiên. Nếu bạn đang làm việc trong một đội có bất kỳ kích thước nào, bạn sẽ sử dụng mỗi lệnh này ít nhất một lần mỗi ngày, thường là nhiều lần.
"Sự thành thạo Git không phải là về việc ghi nhớ mọi cờ và tùy chọn — mà là có một mô hình tư duy đáng tin cậy và biết chính xác lệnh nào cần sử dụng trong những tình huống cụ thể."
git status — Đây là lệnh giúp bạn có nhận thức tình huống. Tôi chạy lệnh này khoảng 30-40 lần mỗi ngày, và tôi không ph exh đại. Trước khi bạn cam kết, sau khi bạn cam kết, khi có điều gì đó cảm thấy không ổn, khi bạn đang chuyển đổi giữa các nhiệm vụ — git status cho bạn biết chính xác vị trí của bạn. Nó cho thấy các tệp nào đã được chuẩn bị, tệp nào đã được chỉnh sửa nhưng chưa được chuẩn bị, và tệp nào không được theo dõi. Hãy nghĩ về nó như một la bàn Git của bạn. Đầu ra được mã hóa màu và rõ ràng đáng kinh ngạc, đó là lý do tại sao đây là lệnh đầu tiên tôi dạy bất kỳ ai.
git add — Lệnh này chuẩn bị các thay đổi của bạn để cam kết. Cách sử dụng phổ biến nhất là git add . để chuẩn bị tất cả trong thư mục hiện tại của bạn, nhưng tôi thực sự khuyên bạn nên chọn lọc hơn. Sử dụng git add filename để chuẩn bị các tệp cụ thể, hoặc git add -p để tương tác trong việc chuẩn bị, nơi bạn có thể xem xét và chuẩn bị các phần thay đổi cụ thể. Sự kiểm soát chi tiết này đã cứu tôi rất nhiều lần khi tôi đã thực hiện nhiều thay đổi không liên quan và cần cam kết chúng riêng biệt. Theo kinh nghiệm của tôi, các lập trình viên sử dụng git add bất cẩn tạo ra lịch sử cam kết lộn xộn làm cho việc gỡ lỗi và xem xét mã trở nên khó khăn hơn rất nhiều.
git commit -m "message" — Lệnh này tạo một bức tranh chụp các thay đổi của bạn đã được chuẩn bị. Cờ -m cho phép bạn thêm một thông điệp cam kết trực tiếp. Bây giờ, đây là nơi tôi sẽ chia sẻ một số kiến thức đã được tích lũy: các thông điệp cam kết của bạn quan trọng hơn bạn nghĩ rất nhiều. Tôi đã dành hàng giờ để cố gắng hiểu tại sao một thay đổi nhất định đã được thực hiện, chỉ để tìm thấy một thông điệp cam kết nói "sửa chữa đồ vật" hoặc "cập nhật." Một thông điệp cam kết tốt nên hoàn thành câu này: "Nếu được áp dụng, cam kết này sẽ..." Ví dụ: "Nếu được áp dụng, cam kết này sẽ thêm xác thực người dùng vào điểm cuối đăng nhập." Kỷ luật này đã làm cho việc khảo cổ mã dễ dàng hơn vô cùng cho các đội của tôi.
git push — Lệnh này tải các cam kết cục bộ của bạn lên kho lưu trữ từ xa. Thông thường, bạn sẽ sử dụng git push origin branch-name. Lần đầu tiên bạn đẩy một nhánh mới, bạn sẽ cần git push -u origin branch-name trong đó cờ -u thiết lập theo dõi để các lần đẩy sau có thể chỉ là git push. Tôi không thể nhấn mạnh điều này đủ: đừng bao giờ sử dụng git push --force trên các nhánh chia sẻ trừ khi bạn thực sự biết bạn đang làm gì và đã giao tiếp với đội của mình. Vụ việc 3 giờ sáng mà tôi đã đề cập? Đó là một lần đẩy mạnh đi sai.
git pull — Lệnh này lấy các thay đổi từ kho lưu trữ từ xa và hợp nhất chúng vào nhánh hiện tại của bạn. Tôi bắt đầu mọi phiên làm việc với một lệnh git pull để đảm bảo rằng tôi đang làm việc với mã mới nhất. Một điều quan trọng cần hiểu: git pull thực sự là hai lệnh kết hợp — git fetch theo sau là git merge. Thỉnh thoảng bạn sẽ muốn sử dụng chúng riêng biệt để kiểm soát nhiều hơn, điều này chúng ta sẽ thảo luận sau. Khi bạn kéo và có xung đột, Git sẽ cho bạn biết chính xác tệp nào có xung đột, và bạn sẽ cần giải quyết chúng một cách thủ công trước khi có thể tiếp tục.
Branching: Bộ công cụ vũ trụ song song của bạn
Branching là nơi sức mạnh thực sự của Git xuất hiện. Nó cho phép nhiều lập trình viên làm việc trên các tính năng khác nhau đồng thời mà không chèn chân nhau. Trong đội hiện tại của tôi gồm 23 lập trình viên, chúng tôi thường có 40-60 nhánh hoạt động tại bất kỳ thời điểm nào. Thành thạo các lệnh branching này là điều phân biệt người sử dụng Git bình thường với các chuyên gia tự tin.
| Loại lệnh | Mức độ rủi ro | Tần suất sử dụng | Sai lầm phổ biến |
|---|---|---|---|
| git commit | Thấp | Hàng ngày | Thông điệp cam kết kém, cam kết quá nhiều cùng một lúc |
| git merge | Trung bình | Hàng tuần | Gộp mà không kéo trước, giải quyết xung đột không đúng cách |
| git rebase | Cao | Hàng tuần | Rebase các nhánh đã chia sẻ, mất cam kết trong quá trình xung đột |
| git push --force | Điều kiện nghiêm trọng | Hiếm khi | Force pushing vào các nhánh chính/chia sẻ, ghi đè lên công việc của đội |
| git reset --hard | Cao | Hàng tháng | Mất công việc chưa cam kết, thiết lập sai nhánh |
git branch — Chạy