Hướng dẫn Git của Beej

 (beej.us)
1 điểm bởi GN⁺ 2025-02-06 | 1 bình luận | Chia sẻ qua WhatsApp
  • Đây là trang hướng dẫn cung cấp bản phân phối HTML·PDF dưới nhiều định dạng cho độc giả muốn học hoặc tham khảo Git
  • Bản hướng dẫn này mặc định có thể có lỗi, và các nội dung Git sai có thể được đề xuất chỉnh sửa qua email
  • Bản HTML có thể được chọn theo môi trường đọc như bản chia chương, một trang duy nhất, widescreen, ZIP, v.v.
  • PDF có thể tải xuống theo các tổ hợp US Letter·A4, một mặt·hai mặt, bản có tô sáng cú pháp·bản đen trắng
  • Người dịch và tác giả có thể clone trên GitHub toàn bộ tài liệu rồi làm theo README để làm việc

Các định dạng phát hành để đọc

Đề xuất chỉnh sửa và tài liệu làm việc gốc

  • Bản hướng dẫn này mở ra khả năng có lỗi, và nhận đề xuất chỉnh sửa qua email
  • Người dịch và tác giả chỉ cần clone kho GitHub và làm theo README

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-02-06
Các ý kiến trên Hacker News

  • Nếu phát hiện chỗ nào sai, hãy gửi lên. Tôi sẽ tự tổng hợp và sửa — Beej

    • Không hẳn là sai, nhưng nếu nói về vim trong ngữ cảnh Git thì cũng đáng đưa thêm :cq. Nó thoát với trạng thái kết thúc khác 0, có thể khiến Git không hoàn tất commit hoặc tác vụ
    • Đây thật sự là một công trình tuyệt vời, cảm ơn vì đã tạo ra một tài liệu toàn diện như vậy. Tôi chưa đọc hết, nhưng cách diễn đạt ở mục 5.1 khiến tôi chú ý
      Ở https://beej.us/guide/bggit/html/split/branches-and-fast-for... có nói “branch mặc định là main” và “trước đây là master, các repository cũ vẫn còn master”, nhưng điều này không đúng. Git vẫn dùng master làm mặc định, và chỉ cho phép đổi trong tương lai đối với git init bằng git config --global init.defaultBranch
      Căn cứ: https://github.com/git/git/blob/bc204b742735ae06f65bb20291c9...
      Ngoài ra, cách nói “repository cũ” truyền đi thông điệp không đúng. GitHub đã quyết định thay đổi này, các nơi khác làm theo, và bản thân Git cũng cho phép cấu hình nói trên; đây không phải là vấn đề repository mới/cũ mà gần với vấn đề sở thích hơn
    • Tôi từng là một trong rất nhiều học viên ở Lambda School, và buổi học khi đó là một trong những khoảnh khắc ấn tượng nhất
    • Tôi đã đọc hướng dẫn lập trình C khi còn là thiếu niên, và giờ là lập trình viên firmware, tôi vẫn cảm thấy mình nợ tác giả rất nhiều
    • Không hẳn là sai, nhưng git worktree cũng đáng được nhắc đến. Trong workflow của tôi, nó là phần cốt lõi, và nhiều người thậm chí không biết nó tồn tại
      Đây là một cách tốt để giữ các branch không bị rối vào nhau mà không phải xử lý phiền phức với stash

  • Beej's Guide to Network Programming và Beej's Guide to Unix IPC mà tôi đọc khi còn là thiếu niên vừa dễ tiếp cận vừa có chiều sâu, và đã ảnh hưởng lớn đến việc sau này tôi trở thành kiểu lập trình viên như thế nào
    [0] https://beej.us/guide/bgnet/
    [1] https://beej.us/guide/bggit/

    • [1] là https://beej.us/guide/bgipc/
    • Tôi cũng tương tự. Tôi là thiếu niên vào giữa thập niên 90 và bị mê hoặc bởi mã máy chủ IRCd và bot
      Tôi mua lại một cuốn Slackware Linux Unleashed kèm CD-ROM, trong đó có các ví dụ networking bằng C; những đoạn mã đó khiến tôi bối rối nên tôi tìm đến trang networking của Beej. Từ đó tôi càng bị cuốn vào một cái hang thỏ sâu hơn, rồi thường lang thang qua nhiều hiệu sách để tìm sách lập trình
      Sau khi mua cuốn tài liệu tham khảo xuất sắc của Richard Stevens thì tôi không ngoái lại nữa, và đến giờ vẫn biết ơn Beej vì đã giúp niềm đam mê ấy thành hiện thực
    • Thời học cách dùng select, tôi nhớ mình đã dịch hướng dẫn mạng của Beej sang tiếng Ý vì muốn làm cho một port scanner nào đó (có lẽ là “grabb”?) chạy nhanh hơn. Đó là những ngày vui
    • Tôi vào đây để kiểm tra xem có phải cùng một người không, và khi thấy kiểu thiết kế web cũ mà mỗi trang đều có cá tính riêng, tôi gần như chắc chắn
      Đó là thời tôi lưu trang lại để đọc offline nhằm tránh làm cha nổi giận vì tiền điện thoại, và khi code chạy được thì cảm giác như một sự xác nhận vượt lên trên những thất bại và lời từ chối trước đó trong đời. Niềm vui khi gửi được thông điệp từ máy tính này sang máy tính khác thật lớn

  • Thấy câu “Lệnh cũ: git checkout”, tôi mới biết có git switch, và cũng không biết git checkout được xem là phương án cũ. Cảm thấy mình già đi
    Tôi bắt đầu học Git gần 10 năm trước nên cũng hợp lý, nhưng thật lạ khi nghĩ rằng người học Git bây giờ có thể bối rối vì sao tôi dùng git checkout. Cảm giác như đang dùng cách nói lỗi thời
    Quay lại bài viết, nếu lúc tôi học mà có hướng dẫn này thì chắc đã rất hữu ích. Dễ theo dõi và xử lý tốt các câu hỏi thường gặp
    Tôi cũng nhớ khá vui chuyện từng hoảng sợ trước merge conflict đầu tiên rồi bỏ cuộc, sau đó tìm cách đi vòng để tránh conflict

    • git switch là lệnh khá mới và được phát hành lần đầu vào năm 2019
      Có các thảo luận vào năm 2021 và vài tuần trước; trong thảo luận sau còn nêu rằng về mặt tài liệu, git switch vẫn được xem là tính năng thử nghiệm
      https://news.ycombinator.com/item?id=28024972
      https://news.ycombinator.com/item?id=42649858
    • Tôi không nghĩ git checkout hiện vẫn bị xem là “phương án cũ”. Lần cuối tôi kiểm tra thì switch vẫn còn là thử nghiệm, và tôi cũng chưa từng nghĩ đến việc rời bỏ workflow và các lệnh đã học khi học Git khoảng 15 năm trước
      Mọi việc tôi muốn làm vẫn hoạt động y như cũ, git checkout cũng vẫn làm những việc như trước, và tôi không gặp vấn đề gì khi cộng tác với người khác bằng Git, vậy thì không có lý do gì phải đổi workflow

  • Việc cần đến một hướng dẫn hơn 30 phần để giải thích cách dùng Git tự nó đã khiến tôi cảm thấy như Git đã bỏ lỡ bức tranh tổng thể

    • Tôi không hiểu vì sao các lập trình viên lại nổi giận dữ dội đến vậy trước thực tế là một công cụ phức tạp, làm những việc phức tạp trên các cấu trúc dữ liệu phức tạp, thì ở mức nào đó cũng có độ phức tạp
    • Nếu người ta dành chỉ một nửa công sức than phiền về Git để học Git, có lẽ đã chẳng cần tạo một hướng dẫn hơn 30 phần để giải thích những nội dung có thể tìm thấy trong trang hướng dẫn sử dụng
      Commit là snapshot của cây, và có một danh sách tổ tiên. Thường là một, nhưng không phải lúc nào cũng vậy. Tag là nhãn tên commit không thay đổi, còn branch là nhãn tên commit có thể thay đổi. Index là một proto-commit nhỏ đang trong quá trình thực hiện, được điền bằng add trước khi commit
      Đó là Git. Nếu muốn biết thêm, đừng đọc hướng dẫn; hãy tìm kiếm kiểu như “cách chuyển sang một commit Git cụ thể mà không ảnh hưởng đến cây”, “cách chỉ commit một phần trong các file đã thay đổi”, “cách sao chép commit từ nơi khác vào cây hiện tại”
      Các trừu tượng cơ bản là tối giản và dễ hiểu. Những việc bạn muốn làm với các trừu tượng đó mới tinh vi và phức tạp. Cứ học cái trước rồi tìm kiếm cái sau là được, không cần đọc hướng dẫn
    • Cách dùng Git có thể giải thích bằng 5 dòng bình luận HN: git clone, git checkout, git pull, git add + commit + push, git reset / rebase
    • Dù vậy vẫn có thể tự bắn vào chân mình
    • Đúng mà cũng không hẳn. Các lệnh dành cho người dùng của Git có lẽ đủ tốt cho 95% người dùng
      rebase -i có hướng dẫn kèm theo về lệnh nào làm gì, và cách định dạng đầu ra git log theo sở thích và mức đánh đổi chỉ cần vài đoạn là đủ. Tôi cho rằng các lệnh dành cho người dùng thông thường cũng bao gồm cả những thứ khá lặt vặt như git gc, git fsck, git rev-parse
      Các lệnh cấp thấp chắc chắn khó hiểu hơn, và bản thân chúng làm được nhiều việc mà các lệnh dành cho người dùng, vốn tối ưu cho các trường hợp phổ biến, không phải lúc nào cũng dễ làm được
      Tóm lại, Git lớn, thậm chí khổng lồ, nhưng với đa số lập trình viên thì một phần đáng kể tính năng của nó nằm khá xa khỏi luồng chính

  • Điều đáng sợ là hướng dẫn lại dài đến vậy
    Tôi biết các hướng dẫn của Beej nhìn chung rất bao quát, nhưng tôi chưa thực sự cảm nhận được mức độ đồ sộ của những sắc thái tinh vi trong Git cho đến khi thấy cái này
    Với Jujutsu thì có lẽ hướng dẫn sẽ mỏng hơn nhiều, hoặc ít nhất là dễ để con người tự khám phá và học dần hơn

    • Tôi cố thiết kế phần lớn các hướng dẫn của mình sao cho khi cảm thấy đã đọc đủ thì có thể dừng lại. Không cần đọc hết
      Tôi cảm thấy hướng dẫn này chỉ bao phủ khoảng 10% Git, nhưng hy vọng nó bao phủ được 90% cách dùng phổ biến
    • Hướng dẫn này thiên về bao quát, còn ở thái cực ngược lại có một tài liệu một trang chứa 90% các lệnh Git bạn sẽ cần về sau: https://wizardzines.com/git-cheat-sheet.pdf
    • Đây có vẻ là dấu hiệu cho thấy Git không phải công cụ phù hợp với đa số, nhưng bằng cách nào đó đã trở thành chuẩn

  • Ở chỗ làm, mỗi năm một hai lần tôi tổ chức một khóa nhập môn mô hình dữ liệu Git kéo dài 2 giờ
    Tôi thực sự đi vào thư mục .git, giải nén các file và cho thấy mọi thứ chỉ là biểu diễn dạng văn bản thuần của các cấu trúc dữ liệu cơ bản. Thật tuyệt khi thấy khoảnh khắc mọi người bỗng hiểu ra trong đầu
    Chúng tôi chia sẻ tài liệu công thức Git cơ bản để nhân viên mới bắt đầu commit code, nhưng phần lớn chỉ làm theo mà không hiểu chuyện gì đang diễn ra
    Ngược lại, người đã học lớp này, dù không biết hết mọi lệnh, vẫn có được hiểu biết thực tế khá hợp lý về những gì thật sự xảy ra trong Git. Lệnh thì dễ tìm kiếm, nên chỉ cần mô hình tư duy đúng thì bản thân lệnh không phải vấn đề lớn. Thế nhưng gần như mọi cuộc thảo luận về Git trên HN đều trôi sang chuyện dòng lệnh
    Điều thú vị là lớp này nghe giống alt text của https://xkcd.com/1597/. Khác biệt là với độc giả kỹ thuật, đó thực sự là cách đúng để dạy Git, và một khi đã hiểu thì bạn có được nền tảng sẽ không quên
    Thành thật mà nói, tỷ suất lợi ích trên thời gian bỏ ra cao đến mức không làm thì mới lạ

    • Tôi cũng đã thử một lần và nó thật sự rất hay, cuộc thảo luận sau đó cũng cực kỳ tuyệt vời
      Ở slide cuối của bài trình bày, tôi đưa vào các câu hỏi để đồng nghiệp trả lời dựa trên mô hình dữ liệu Git. Ví dụ như “có thể chuyển một commit sang branch khác không?”, “điều gì đảm bảo rằng đồ thị commit không có chu trình?”
      Thật sự rất thỏa mãn khi mọi người không chỉ dùng Git, mà còn suy nghĩ bằng Git
    • Câu “chỉ cần mô hình tư duy đúng thì lệnh không phải vấn đề lớn” ban đầu nghe có lẽ giống kiểu lập luận thường thấy hồi thập niên 90: “nếu hiểu mọi tầng và mọi phần của Linux thì dùng Linux rất dễ”. Về lý thuyết thì đúng, nhưng với đa số người thì nghe như chuyện bất khả thi trong thực tế
      May là từ đầu tôi đã xem một video giải thích một phần mô hình nội bộ của Git, và nhận ra rằng thực tế không cần nhiều hay sâu kiến thức nội bộ đến vậy mà vẫn tạo ra khác biệt lớn. Chỉ cần biết khoảng 5% cách Git hoạt động là tôi đã hiểu rõ hơn nhiều các lệnh đang làm gì và nên dùng chúng thế nào
    • Tôi tò mò liệu bạn có thể chia sẻ tài liệu hoặc bản ghi của khóa 2 giờ đó không, nếu không có thông tin độc quyền hay ràng buộc nào ngăn cản việc công khai
      Nếu nó dựa trên tài liệu công khai và đủ súc tích để gói gọn trong 2 giờ, rất mong bạn chia sẻ trong luồng này hoặc dưới bài HN. Tôi tin rằng với cùng một chủ đề, càng có nhiều tài liệu học tập với giả định, ẩn dụ và trọng tâm khác nhau thì càng tốt
    • Tôi tò mò không biết có bản sao bài trình bày hoặc video không, hoặc có tài liệu tương tự nào đáng giới thiệu không
    • Hãy chia sẻ video đi

  • Tôi biết dùng ở mức nào đó các luồng Git thông thường, merge, rebase, v.v., nhưng thay vì cố giỏi Git hơn, tôi đang nghiêm túc cân nhắc chuyển sang jujutsu. jj tương thích với Git, và tôi có thể dùng một mình trong khi đồng nghiệp vẫn dùng Git bình thường

  • Tôi cảm thấy có một mẹo mà nhiều hướng dẫn và hầu hết các Git GUI đều bỏ sót. Ngoại lệ là magit xử lý khá tốt
    Đó là đặt nhánh upstream không phải là origin/feature/foo của feature/foo, mà là đích bạn định merge, tức nhánh tích hợp như master hoặc origin/master
    Làm vậy sẽ đơn giản hóa rất nhiều thứ. Khi chạy git status, nó cho biết bạn đã tách khỏi nhánh tích hợp bao xa nên rất hữu ích, và nếu chạy git rebase không có tham số thì nó sẽ rebase ngay lên upstream
    Để origin/feature/foo làm upstream thì kém hữu ích hơn. Các lập trình viên thường cũng “sở hữu” nhánh của mình trên remote, nên việc nó đã tách khỏi đó bao xa không có nhiều ý nghĩa, và cũng hiếm khi muốn rebase lên đó
    Nếu đặt push.default thành "current", git push cũng sẽ push feature/foo lên origin/feature/foo đúng như mong đợi
    Tôi tự hỏi vì sao cách thiết lập này lại không phổ biến hơn

  • Phần cộng tác hoàn toàn không đề cập đến nhánh tính năng. Tôi nghĩ đây là một quy trình làm việc khá phổ biến
    Có lẽ sẽ hữu ích nếu đối chiếu với cách “mọi người dùng nhánh riêng của mình” trong hướng dẫn. Ngoài ra, ở phần 17 cũng đáng bàn về cách tái sử dụng nhánh cho pull request trên GitHub so với cách tạo nhánh mới cho từng PR

  • Tôi chưa đọc bài viết, nhưng có vẻ sẽ hay. Một đề xuất khác là khóa học Git của boot.dev do Primeagen giảng dạy
    Khóa học có tính tương tác và đi sâu đến mức thao tác trực tiếp với các tệp bên trong thư mục .git. Sau khi học xong khóa đó, tôi đã có một mô hình tư duy hoàn toàn mới về cách Git hoạt động