Git Commands Cheat Sheet: The 20 Commands You Actually Use — txt1.ai

Cuộc Khủng Hoảng Sản Xuất 3 Giờ Sáng Đã Thay Đổi Cách Tôi Suy Nghĩ Về Git

Tôi sẽ không bao giờ quên đêm mà toàn bộ quy trình triển khai của chúng tôi bị phá vỡ vào lúc 3 giờ sáng. Tôi là một kỹ sư DevOps cao cấp tại một công ty khởi nghiệp fintech, đã năm năm trong sự nghiệp, và tôi vừa nhận được thông báo vì ai đó đã force-push vào nhánh chính và xóa ba ngày công việc của bốn nhóm khác nhau. Tay tôi run rẩy khi tôi nhìn vào terminal của mình, biết rằng mỗi giây đều quan trọng—chúng tôi có những thời hạn quy định, các bên liên quan tức giận, và một đội ngũ các lập trình viên mệt mỏi đang chờ tôi sửa chữa điều này.

Đó là khi tôi nhận ra điều gì đó quan trọng: Tôi đã sử dụng Git trong nửa thập kỷ, nhưng tôi chỉ thực sự biết khoảng 20 lệnh. Mọi thứ khác đều chỉ là tiếng ồn. Tài liệu Git liệt kê hơn 160 lệnh, nhưng trong khoảnh khắc khủng hoảng đó, tôi đã với lấy cùng một vài công cụ mà tôi đã sử dụng hàng ngàn lần trước đó. Và bạn biết không? Chúng là đủ. Chúng đã cứu chúng tôi vào đêm đó.

Kể từ đó, tôi đã làm việc với hơn 200 lập trình viên tại ba công ty, thực hiện vô số đánh giá mã và cứu nhiều kho lưu trữ hơn tôi có thể đếm. Tôi đã theo dõi việc sử dụng Git thực tế của mình trong hai năm qua bằng cách phân tích lịch sử shell, và dữ liệu thật sự gây ấn tượng: 94% các tương tác Git của tôi chỉ liên quan đến 20 lệnh. 6% còn lại được chia đều giữa hàng chục thao tác mờ ám mà tôi có thể sử dụng một lần mỗi quý.

Bài viết này không phải là một tài liệu tham khảo Git toàn diện khác mà bạn sẽ đánh dấu và không bao giờ đọc. Đây là danh sách lệnh đã được thử nghiệm trong thực chiến, có giá trị thật cho 99% công việc hàng ngày của bạn. Tôi sẽ chỉ cho bạn chính xác cách tôi sử dụng từng lệnh, các cờ thật sự quan trọng, và các mô hình tư duy đã giúp tôi giữ vững tâm trí qua hàng trăm xung đột hợp nhất và tình huống khẩn cấp khi triển khai.

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 mà tôi sử dụng rất thường xuyên đến nỗi ngón tay tôi gõ chúng mà không cần suy nghĩ. Năm lệnh này tạo thành xương sống của mỗi quy trình làm việc Git, và nếu bạn không thành thạo bất cứ điều gì khác, hãy thành thạo những điều này.

Sau khi phân tích hai năm lịch sử shell của đội mình, tôi đã phát hiện ra điều gì đó nghịch lý: những lập trình viên biết ít lệnh Git thường có năng suất cao hơn. Họ đã thành thạo 20 lệnh thiết yếu và có thể thực hiện chúng mà không cần suy nghĩ, trong khi những người đã ghi nhớ toàn bộ tài liệu thường mất vài giây quý giá để tranh luận giữa các tùy chọn tương tự trong những khoảnh khắc quan trọng.

git status là người bạn đồng hành không thể thiếu của tôi. Tôi thực hiện lệnh này có lẽ 50 lần mỗi ngày, và tôi không ph exa. Trước mỗi lần commit, sau mỗi lần pull, bất cứ khi nào tôi bối rối về những gì đang diễn ra—git status là bước đầu tiên của tôi. Nó cho bạn biết tệp nào đã được stage, tệp nào đã được chỉnh sửa nhưng chưa stage, và tệp nào chưa được theo dõi. Đầu ra có mã màu và cực kỳ dễ đọc. Tôi đã thấy các lập trình viên junior vật lộn hàng giờ với các vấn đề Git mà sẽ lập tức rõ ràng nếu họ chỉ chạy git status.

Dưới đây là quy trình làm việc của tôi: Tôi gõ git status thường xuyên đến nỗi tôi đã tạo bí danh là "gs" trong cấu hình shell của mình. Mỗi khi tôi chuyển đổi bối cảnh hoặc quay lại từ một cuộc họp, git status là cách tôi nhớ những gì tôi đang làm. Nó giống như một dấu trang cho trạng thái hiện tại của bạn.

git add là cách bạn stage các thay đổi để commit. Mẫu phổ biến nhất là git add . điều này sẽ stage tất cả mọi thứ trong thư mục hiện tại của bạn, nhưng thực tế tôi khuyên bạn không nên sử dụng điều này một cách mù quáng. Thay vào đó, tôi dùng git add -p (chế độ patch) cho khoảng 60% các commit của mình. Điều này cho phép bạn xem xét từng thay đổi một cách tương tác và chỉ stage những phần bạn muốn. Nó chậm hơn, đúng, nhưng nó đã cứu tôi khỏi việc commit code gỡ lỗi, API keys, và các câu lệnh console.log đáng xấu hổ nhiều lần hơn tôi có thể đếm.

Để làm việc nhanh chóng, git add filename sẽ stage một tệp cụ thể. Tôi sử dụng điều này khi tôi tự tin về những gì tôi đang commit. Thông điệp chính ở đây là staging tách biệt với committing—bạn có thể stage các tệp theo cách từng bước, xem lại chúng với git status, và sau đó commit khi bạn đã sẵn sàng.

git commit tạo một snapshot của các thay đổi đã được stage của bạn. Tôi sử dụng git commit -m "message" cho những thay đổi nhỏ, rõ ràng, nhưng đối với bất cứ điều gì quan trọng, tôi chỉ gõ git commit và để nó mở trình chỉnh sửa của tôi. Điều này buộc tôi phải viết một thông điệp commit thích hợp với tiêu đề và nội dung. Những thông điệp commit tốt là tài liệu cho chính bạn trong tương lai. Tôi đã tiêu tốn vô số giờ để đào bới lịch sử git cố gắng hiểu lý do tại sao một thay đổi được thực hiện, và những thông điệp commit chi tiết xứng đáng với trọng lượng của chúng.

Mẫu thông điệp commit của tôi: dòng đầu tiên là một tóm tắt ngắn gọn (50 ký tự hoặc ít hơn), sau đó là một dòng trống, sau đó là một giải thích chi tiết về những gì đã thay đổi và tại sao. "Tại sao" là điều quan trọng—diff cho thấy những gì đã thay đổi, nhưng chỉ bạn mới có thể giải thích lý do.

git push gửi các commit của bạn đến kho lưu trữ từ xa. Phần lớn thời gian, git push là tất cả những gì bạn cần. Nếu bạn đang push một nhánh mới lần đầu tiên, bạn sẽ cần git push -u origin branch-name để thiết lập theo dõi. Cờ -u (viết tắt của --set-upstream) có nghĩa là các push và pull trong tương lai trên nhánh này sẽ không yêu cầu bạn chỉ định tên từ xa và nhánh.

Một cờ quan trọng cần biết: git push --force-with-lease. Không bao giờ, không bao giờ sử dụng git push --force trừ khi bạn hoàn toàn chắc chắn rằng bạn muốn ghi đè lịch sử từ xa. Biến thể --force-with-lease an toàn hơn vì nó sẽ thất bại nếu người khác đã push các commit mà bạn không có ở địa phương. Tôi đã thấy --force xóa bỏ toàn bộ công việc của các nhóm. Đừng trở thành người đó.

git pull 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 chạy lệnh này mỗi sáng trước khi bắt đầu công việc và trước mỗi lần push. Hành vi mặc định là ổn cho hầu hết các trường hợp, nhưng tôi thích git pull --rebase vì nó giữ lịch sử sạch sẽ bằng cách tránh các commit hợp nhất không cần thiết. Tôi đã thiết lập điều này là mặc định của mình với git config --global pull.rebase true.

Branching: Bộ Công Cụ Vũ Trụ Song Song Của Bạn

Các nhánh là nơi sức mạnh thực sự của Git tồn tại. Chúng cho phép bạn làm việc trên các tính năng, thực nghiệm, và sửa lỗi trong môi trường cách ly mà không ảnh hưởng đến mã nguồn chính. Tôi tạo khoảng 10-15 nhánh mỗi tuần, và những lệnh này giúp quy trình làm việc đó trở nên liền mạch.

git branch liệt kê tất cả các nhánh địa phương của bạn. Nhánh hiện tại được đánh dấu bằng một dấu sao. Tôi sử dụng git branch -a để xem các nhánh từ xa nữa, và git branch -d branch-name để xóa các nhánh mà tôi đã hoàn tất. Cờ -d là an toàn - nó không cho phép bạn xóa một nhánh có những thay đổi chưa được hợp nhất. Nếu bạn hoàn toàn chắc chắn rằng bạn muốn xóa một nhánh (có thể đó là một thử nghiệm không thành công), hãy sử dụng git branch -D branch-name.

Tôi thường xuyên dọn dẹp các nhánh cũ. Một kho lưu trữ có 50 nhánh lỗi thời sẽ gây nhầm lẫn và làm khó khăn trong việc tìm kiếm những gì bạn đang tìm. Mỗi thứ Sáu, tôi chạy git branch --merged để xem các nhánh nào đã được hợp nhất vào nhánh chính, sau đó xóa chúng. Nó giống như việc dọn dẹp bàn làm việc của bạn—cảm giác thật tốt.

git checkout chuyển đổi giữa