20 mẹo để làm chủ Git và GitHub- phần 1

Hệ thống Git và GitHub cho phép bạn tìm kiếm, chia sẻ và từ đó cải tiến code. Dưới đây là những cách giúp bạn sử dụng Git và GitHub một cách hiệu quả.

Trong khi có hàng trăm bài hướng dẫn bắt đầu sử dụng Git và GitHub cung cấp một số kinh nghiệm riêng của họ, tuy vậy bạn vẫn không dễ dàng tìm thấy một bài tổng hợp các mẹo hay cho các lập trình viên muốn sử dụng Git và GitHub thông minh hơn.

Đối với những người không quen sử dụng Git hoặc GitHub, vài đoạn tiếp theo sẽ giúp bạn nắm được nền tảng để hiểu về các mẹo. Chúng tôi sẽ liệt kê một số nguồn hữu ích ở cuối bài viết này.

Git là một hệ thống Quản lý Phiên bản Phân tán, được Linus Torvalds viết vào năm 2005 và với sự trợ giúp của cộng đồng Linux. Tôi sẽ tiết lộ cho bạn cách nhanh, gọn, linh hoạt và phổ biến, nhưng bạn nên biết rằng khi bạn clone (clone) một kho Git (“repo”) , bạn sẽ có được toàn bộ lịch sử phiên bản phần mềm đó trên máy tính của mình.

Git bắt đầu như là một công cụ dạng command-line (dòng lệnh), thích hợp với nguồn gốc của nó trong cộng đồng Linux. Bạn vẫn có thể sử dụng dòng lệnh trên Git, nếu bạn thích, nhưng điều đó không bắt buộc. Cụ thể, nếu bạn sử dụng GitHub làm host của mình, bạn có thể sử dụng ứng dụng GitHub miễn phí trên Windows hoặc Mac. Mặt khác, dòng lệnh Git sẽ làm việc cho bất kỳ máy chủ lưu trữ nào và nó được cài đặt sẵn trên hầu hết các hệ thống Mac và Linux.

Chỉ có bạn mới biết sử dụng dòng lệnh hoặc có giao diện người dùng đồ họa (GUI) sẽ thoải mái hơn và từ đó sẽ có được lựa chọn cho bản thân. Nếu bạn thích GUI, ngoài ứng dụng GitHub (Windows và Mac), bạn có thể xem xét SourceTree (Windows và Mac, miễn phí), TortoiseGit (chỉ dành cho Windows, miễn phí) và Gitbox (chỉ dành cho máy Mac với giá 14,99 đô la). Hoặc bạn có thể sử dụng một trình editor hoặc IDE có hỗ trợ Git (xem tại mẹo số 11).

Tip 1: Clone gần như bất cứ thứ gì

Có rất nhiều dự án thú vị có sẵn từ GitHub và các kho Git công cộng khác mà bạn có thể tự do clone về máy tính của mình. Tại sao bạn cần làm điều đó? Lý do thứ nhất là để tìm hiểu về cách viết code, thực hành và các công cụ bằng một ngôn ngữ mà bạn quan tâm. Lý do thứ hai là để tìm hiểu một dự án nhất định hoàn thành mục tiêu của nó như thế nào. Lý do thứ ba đúc kết những điều trên để kết hợp vào các dự án của riêng bạn hoặc sản phẩm. Kiểm tra lại license, để bạn không gặp vấn đề sau.

Định nghĩa về git clone từ trang hướng dẫn sử dụng:

Clone một kho code vào một thư mục mới tạo ra, tạo các branch remote-tracking cho từng branch trong kho lưu trữ clone (có thể hiển thị bằng cách sử dụng git branch -r) tạo ra và kiểm tra một branch ban đầu được nén từ branch hiện đang hoạt động của kho lưu trữ.

Sau khi clone, một git fetch lấy ra mà không có đối số sẽ cập nhật tất cả các branch remote-tracking và một git pull mà không có đối số sẽ nối thêm các remote master branch vào master branch hiện tại, nếu có.

Tip 2: Pull thường xuyên

Nếu bạn pull git thường xuyên, bạn cần giữ bản sao “repo” của bạn được cập nhật và bạn sẽ có cơ hội để hợp nhất code đã thay đổi của bạn với những thay đổi của người khác trong khi sự hợp nhất là dễ hiểu và hoàn thành lý tưởng, khi đơn giản như vậy nó có thể được thực hiện tự động. Một hệ quả của mẹo này là để xem tình trạng dự án của bạn. Nhiều người dùng Git sẽ tự động hiển thị khi bạn cần cập nhật.

Tip 3: Commit sớm và thường xuyên

Commit là một bản cập nhật chi tiết cho một dự án, bao gồm một hoặc nhiều thay đổi đối với một hoặc nhiều tệp tin. Hãy nghĩ nó như một bản ghi task đã hoàn thành, có thể được áp dụng hoặc loại bỏ khỏi dự án. Hãy commit mọi thay đổi trước khi thử nghiệm nó. Commit chỉ áp dụng cho kho lưu trữ trên local của bạn. Xem các mẹo số 4 và 5 về hiệu quả cho mẹo này.

Định nghĩa của git commit từ trang hướng dẫn sử dụng:

Lưu trữ các nội dung hiện tại của chỉ mục trong một commit mới cùng với thông điệp tường trình từ người dùng mô tả các thay đổi.

Tip 4: Tự nhận xét các commit của bạn một cách khách quan

Có 2 kiểu lập trình viên: Những người tự nhận xét commit và những người không.

Tôi tự thừa nhận là một người quá nghiêm khắc với commit log messages. Tôi thiết lập các kho để nhận các tin nhắn cho mỗi commit. Nếu bạn trong nhóm lập trình viên (1) và (2) thì các comment trong từng dòng code là điều quan trọng hơn các commit thay đổi, hãy thử clone một kho mà bạn chưa bao giờ thấy và xác định commit gần đây có thể đã gây ra vấn đề mới nhất được đăng mà không cần đọc tất cả code. Như bạn thấy, các bản commit chính xác sẽ tăng gấp đôi.

Tip 5: Chỉ push khi những thay đổi của bạn đã được test

Lỗi liên quan đến Git tệ nhất mà tôi từng gặp phải xảy ra khi một công ty outsourcing từ Subversion nhưng không đào tạo cho các lập trình viên về sự khác nhau giữa kiểm soát nguồn phân phối và kiểm soát nguồn tập trung. Khoảng một tháng sau, dự án phát sinh những lỗi lạ mà không ai có thể theo dõi được. Tại cuộc họp hàng ngày, các lập trình viên chịu trách nhiệm về việc đó thường phản đối kiểu “Tôi đã fix cách đây hai tuần!” hoặc cáo buộc lập trình viên khác không quan tâm đến việc thay đổi những gì họ đã test cẩn thận.

Cuối cùng, ai đó đã xác định được vấn đề và dạy cho tất cả các lập trình viên cách thức và thời gian để thúc đẩy các commit của họ: nói tóm lại, bất cứ khi nào bạn thử nghiệm thành công trong việc xây dựng cục bộ. Sau đó, công ty đã làm một hội nghị hai ngày trước khi có thể xây dựng và triển khai các sản phẩm được cập nhật, tích hợp.

Tip 6: Branch tự do

Một trong những ưu điểm lớn nhất của Git là các hệ thống kiểm soát phiên bản khác đó là khả năng hợp nhất thường hoạt động tốt, một phần bởi vì Git tự động chọn ancestor tốt nhất để sử dụng phù hợp nhất. Hầu hết các lập trình viên phần mềm cần phải bắt đầu tạo branch trong dự án của họ thường xuyên hơn. Nó cần được thực hiện hàng ngày, chứ không phải là chủ đề trong một cuộc họp. Có khả năng là, khi dự án branch hoàn thành, được chấp nhận và sẵn sàng để chuyển sang dự án chính, hợp nhất sẽ không gây ra bất kỳ vấn đề mà không thể khắc phục.

Tôi biết rằng có một số điều chỉnh, đặc biệt là nếu bạn ở trong một công ty mà không kiểm soát mã nguồn với CVS. Nhưng hãy thử nó. Đó là việc tốt hơn nhiều so với việc khách hàng vô tình nhìn thấy code chưa hoàn thành của bạn khi dự án trunk phải được xuất bản vì bị bug phá vỡ. (Bài viết này giải thích về branch cơ bản và hợp nhất tốt.)

Tip 7: Hợp nhất cẩn thận

Trong khi hợp nhất với Git thường có hiệu quả tốt, nhưng nếu bạn thực hiện chúng mà không suy nghĩ kỹ, đôi khi có thể gặp khó khăn. Điều đầu tiên là đảm bảo bạn không có bất kỳ thay đổi nào. Từ trang manual git merge:

Trước khi áp dụng các thay đổi bên ngoài, bạn nên xác định công việc của mình trong shape và commit tại local, từ đó sẽ không xảy ra xung đột nếu có mâu thuẫn. Xem thêm git-stash.

Xem thêm tại mẹo số 8.

Ngay cả khi nó đạt kết quả không mong đợi trong suốt giai đoạn git merge, bạn sẽ không rơi vào bế tắc:

Nếu bạn đã cố gắng hợp nhất dẫn đến các xung đột phức tạp và muốn bắt đầu lại, bạn có thể khôi phục lại bằng git merge —abort.

Lệnh tiếp theo thường áp dụng trong git merge là git mergetool, giả sử bạn muốn sử dụng một GUI để hợp nhất. Nếu bạn thích phương pháp cũ, bạn có thể chỉnh sửa các tệp xung đột với IDE quen thuộc của bạn và hãy loại bỏ hoàn toàn những dòng <<<<<<<, ======= và >>>>>>>, lưu các tập tin sửa đổi và git add mỗi tập tin bạn đã fix.

Tip 8: Stash trước khi thay đổi branch

Quy trình làm việc của một lập trình viên phần mềm hiếm khi bằng phẳng. Người dùng có thể bị gây khó khăn khi báo cáo lỗi vô cớ, các manager có quyền ưu tiên cho các task khác so với task bạn đã chọn để thực hiện và có thể thay đổi ý định về những gì bạn muốn làm.

Ví dụ, bạn có ba tệp commit để phát hành và một tệp thứ tư trong một state được thay đổi nhưng không hoạt động. (Lệnh git status sẽ cho bạn biết tất cả những điều này nếu bạn không nhớ ở đâu). Đột nhiên bạn cần làm việc để sửa lỗi trong một phiên bản production. Bạn cần phải thay đổi branch ngay, nhưng bạn không thể. Thư mục làm việc của bạn “bẩn” và bạn không muốn hoang phí công sức suốt 2 tiếng.

Nhập git stash. Cuối cùng! Bây giờ bạn đã có tất cả các thay đổi được lưu trữ trong branch WIP (đang tiến hành) và bạn có thể chuyển sang production branch từ thư mục “sạch” của bạn. Khi bạn hoàn thành với điều đó, hãy chuyển về nơi của bạn với git stash apply.

Tip 9: Sử dụng gists để chia sẻ snippet và paste

Các đoạn mã của GitHub “gists”- chia sẻ code snippet – không phải là tính năng Git, nhưng chúng sử dụng Git. Tất cả các gists đều là các kho Git và GitHub Gist làm cho việc chia sẻ chúng trở nên dễ dàng. Bạn có thể tìm kiếm Gist public theo chủ đề, ngôn ngữ lập trình, forked status và starred status. Bạn cũng có thể tạo ra các gist bí mật và chia sẻ chúng bằng URL.

Tip 10: Khám phá GitHub

Nhiều dự án nguồn mở thú vị có chứa trên GitHub. GitHub cung cấp một giao diện trên web giúp tìm một số trong số các dự án đó, nhưng dễ dàng nhất là nhập từ khóa tìm kiếm để tìm repos của nó. Ví dụ: nhập jq hoặc back hoặc ang để tìm ba framework JavaScript mã nguồn mở.

Mời các bạn đón đọc phần 2

Techtalk via Infoworld