Cả đời tôi, tôi không thể nghĩ ra đoạn giới thiệu nào cả, nên...
Từ điển nhỏ
Vì các thuật ngữ Git và các từ thông dụng về lập trình khác thường được sử dụng mà không cần dịch nên tôi quyết định không dịch chúng. Ở đây tôi sẽ cung cấp cho họ một bản dịch ngắn gọn các thuật ngữ trong bài viết này kèm theo phần “giải mã”.
Cái nĩa - "cái nĩa". Về cơ bản, bạn sao chép dự án cho chính mình để tinh chỉnh nội dung nào đó dựa trên nó.
Yêu cầu kéo - yêu cầu thay đổi. Gửi các thay đổi của bạn đến kho lưu trữ để xem xét (nghĩa là mã này sẽ chỉ được thêm vào dự án chính sau khi được chủ sở hữu kho lưu trữ hoặc đồng nghiệp làm việc xác nhận)
Kéo – “kéo” (ví dụ: vào IDE trên máy tính của bạn) một dự án từ GitHub
Đẩy – “đẩy” một dự án từ máy cục bộ sang GitHub
#1 Chỉnh sửa mã trên GitHub.com
Tôi sẽ bắt đầu với điều mà tôi nghĩ mọi người đều đã biết (mặc dù cá nhân tôi không biết gì về nó một tuần trước). Khi xem bất kỳ tệp văn bản nào trên GitHub, trong bất kỳ kho lưu trữ nào, bạn có thể thấy một cây bút chì nhỏ ở trên cùng bên phải. Nếu bạn nhấp vào nó, bạn có thể chỉnh sửa tập tin này. Sau khi hoàn tất, hãy nhấp vào Đề xuất thay đổi tệp và GitHub sẽ tạo một nhánh và Yêu cầu kéo. Thật tuyệt vời phải không? Anh ấy tự mình tạo ra cái nĩa! Không cần phải phân nhánh và tải mã lên chính mình, thực hiện các thay đổi cục bộ và gửi lại cho GitHub bằng Yêu cầu kéo. Rất thuận tiện nếu bạn cần thực hiện các chỉnh sửa tối thiểu.
không hẳn là một yêu cầu kéo thực sự
#2 Chèn hình ảnh
Mô tả vấn đề không chỉ giới hạn ở những nhận xét bằng văn bản. Bạn có biết bạn có thể dán hình ảnh trực tiếp từ clipboard không? Khi dán, bạn sẽ thấy nó được tải lên (chắc chắn là lên đám mây) và chuyển thành đánh dấu để hiển thị hình ảnh. Duyên dáng!
#3 Định dạng mã
Nếu bạn cần viết một khối mã, hãy bắt đầu bằng ba dấu phẩy ngược và GitHub sẽ cố gắng đoán bạn đang viết bằng ngôn ngữ lập trình nào. Nhưng nếu bạn đang đăng một đoạn mã bằng ngôn ngữ lập trình như Vue, Typescript hoặc JSX, bạn có thể chỉ định rõ ràng ngôn ngữ đó để việc tô sáng cú pháp là chính xác. Lưu ý ```jsx trên dòng đầu tiên:
...đảm bảo hiển thị chính xác đoạn mã:
(Nhân tiện, điều này cũng áp dụng cho Gist. Nếu bạn chỉ định phần mở rộng .jsf cho ý chính, cú pháp JSF sẽ được đánh dấu). Đây là danh sách tất cả các cú pháp được hỗ trợ .
#4 Kết thúc vấn đề bằng cách sử dụng “từ thần kỳ” trong Yêu cầu Kéo
Giả sử bạn tạo Yêu cầu kéo để khắc phục sự cố #234. Bạn có thể chèn văn bản "khắc phục sự cố #234" vào mô tả yêu cầu của mình (hoặc bất kỳ vị trí nào trong bất kỳ nhận xét yêu cầu thay đổi nào). Sau đó, việc hợp nhất Yêu cầu Kéo sẽ “tự động” giải quyết vấn đề. Thật tuyệt phải không? Đây là thông tin thêm về điều này trong tài liệu .
#5 Liên kết tới bình luận
Bạn đã bao giờ cần tạo một liên kết đến một bình luận cụ thể và không biết làm thế nào? Những ngày đó đã qua lâu rồi vì tôi sẽ tiết lộ cho bạn một bí mật: Để tạo liên kết đến nhận xét, bạn chỉ cần nhấp vào ngày/giờ bên cạnh tiêu đề.
Nhìn này, gaearon giờ đã có ảnh rồi!
#6 Liên kết mã
Vì vậy, bạn muốn tạo một liên kết đến một dòng mã cụ thể. Trong trường hợp này, hãy thử cách này: Nhấp vào số dòng bên cạnh mã mong muốn trong tệp đang mở. Ồ, thấy không? URL đã thay đổi, số dòng hiện đã hiển thị trong đó! Nếu bạn giữ phím SHIFT và nhấp vào số dòng khác, thì đấy! – URL sẽ thay đổi lần nữa và phạm vi hàng sẽ được đánh dấu. URL này bây giờ sẽ trỏ đến tệp này và phạm vi dòng này. Nhưng chờ đã, nó trỏ đến luồng hiện tại. Nếu tập tin thay đổi thì sao? Trong trường hợp này, bạn có thể cần một liên kết cố định tới tệp ở trạng thái hiện tại. Tôi rất lười biếng nên tôi đã chụp một ảnh chụp màn hình của tất cả những điều trên:
Nhân tiện, về URL...
#7 Sử dụng URL GitHub làm dòng lệnh
Điều hướng qua GitHub bằng giao diện người dùng được tổ chức rất thuận tiện. Nhưng đôi khi, để đến một vị trí cụ thể, bạn chỉ cần nhập vị trí đó vào URL sẽ nhanh hơn. Ví dụ: nếu tôi muốn đến một nhánh mà tôi đang làm việc và xem nó so sánh với nhánh chính như thế nào, tôi chỉ cần nhập /compare/branchname sau tên kho lưu trữ. Điều này sẽ đưa tôi đến trang khác cho chi nhánh đó:
Nhưng đây là những khác biệt so với nhánh chính, nhưng nếu trước đây tôi đã làm việc với nhánh tích hợp, tôi có thể nhập /compare/integration-branch...my-branch vào URL
Dành cho những người yêu thích phím nóng: CTRL+L hoặc CMD+L di chuyển con trỏ đến thanh URL (ít nhất là trong trình duyệt Chrome và Firefox). Điều này, kết hợp với tính năng tự động hoàn thành của trình duyệt, giúp việc điều hướng giữa các nhánh dễ dàng hơn nhiều. Mẹo chuyên nghiệp: Sử dụng các mũi tên để điều hướng qua các đề xuất tự động hoàn thành của Chrome và nhấn SHIFT+DELETE để xóa các mục khỏi lịch sử (ví dụ: sau khi hợp nhất một nhánh). (Tôi không biết liệu việc đọc các phím tắt này có dễ dàng hơn không nếu tôi đặt một khoảng trắng trong chúng, chẳng hạn như SHIFT + DELETE. Nhưng về mặt kỹ thuật, “+” không phải là một phần của chúng, vì vậy tôi không thích tùy chọn này. Đó là vì những chuyện như thế này mà tôi mất ngủ cả đêm, Rhonda.)
#8 Tạo danh sách các vấn đề
Bạn có muốn có một hộp kiểm trong phần mô tả vấn đề của mình không?
Và bạn có muốn một thanh tiện lợi như “2 trên 5” xuất hiện khi bạn xem một vấn đề từ danh sách không?
НиHowих проблем! Создавать интерактивные кнопки-флажки можно с помощью следующего синтаксиса:
[ ] Screen width (integer)
[x] Service worker support
[x] Fetch support
[ ] CSS flexbox support
[ ] Custom elements
Синтаксис: пробел, дефис, пробел, открывающаяся квадратная скобка, пробел (or x), закрывающаяся квадратная скобка, пробел и Howие-нибудь слова. После этого вы сможете действительно ставить/убирать галочки с этих кнопок! Мне это, почему-то, кажется Howим-то техническим волшебством. Вы можете ставить галочки! И при этом исходный текст меняется! Страшно подумать, что они придумают дальше. А, и если эта проблема есть на панели проекта, то там тоже будет отображаться ход выполнения:
Если вам непонятно, что я имею в виду под "панелью проекта" – читайте ниже. Всего на пару сантиметров ниже на этой странице.
#9 Панели проектов в GitHub
Для больших проектов я всегда использовал Jira. А для своих личных проектов я всегда использовал Trello. Оба этих инструмента мне очень нравятся. Когда несколько недель назад я узнал, что GitHub предлагает свой собственный вариант, прямо на закладке Projects репозитория, я подумал, что иметь смысл продублировать набор задач, с которыми я уже работаю в Trello.
Ничего веселого тут нет А теперь то же самое в проекте GitHub:
Постепенно ваши глаза привыкнут к неконтрастному изображению
Ради ускорения я добавил все вышеуказанное в виде заметок (notes), то есть они не являются "настоящими" проблемами (issues) GitHub. Но мощь управления задачами в GitHub состоит в интеграции с остальным репозиторием – так что, вероятно, лучше добавить существующие проблемы из репозитория на панель. Нажмите Add Cards в верхнем правом углу и найдите то, что хотели бы добавить. Здесь пригодится специальный синтаксис поиска: например, наберите is:pr is:open и вы сможете перетащить любой открытый Pull Request на панель, or label:bug, если нужно исправить Howие-то ошибки.
А ещё можно преобразовать существующие заметки в проблемы.
И, наконец, из формы существующей проблемы, добавить её в проект в правой панели.
Она попадёт в список triage данной панели проекта, так что вы сможете выбрать, в Howой столбец её поместить
Когда описание "таска" находится в том же репозитории, что и реализующий этот таск code, это очень (ооооочень) удобно. Это значит, что через много лет вы сможете выполнить команду git blame для Howой-либо строки codeа и выяснить всю подоплёку задачи, которая к этой строке привела, без того, чтобы отслеживать это всё в Jira/Trello/еще где-нибудь.
Недостатки
Trong ba tuần qua, tôi đã thử nghiệm làm mọi thứ trong GitHub thay vì Jira (trong một dự án nhỏ, kiểu Kanban) và yêu thích nó. Nhưng tôi không thể tưởng tượng được điều này đối với một dự án Scrum nơi tốc độ phát triển và những thứ tương tự cần được đánh giá và tính toán hợp lý. Tin vui là các dự án GitHub có rất ít “tính năng đặc biệt” nên việc chuyển sang hệ thống khác sẽ không mất nhiều thời gian. Vì vậy, hãy thử và xem bạn thích nó đến mức nào. Tôi không biết điều này quan trọng đến mức nào nhưng tôi đã nghe nói về ZenHub và mở nó ra lần đầu tiên cách đây 10 phút. Về cơ bản, đây là một phần mở rộng của GitHub, nơi bạn có thể xếp hạng các vấn đề và tạo ra các "sử thi" cũng như phần phụ thuộc. Có biểu đồ về tốc độ phát triển và mức độ kiệt sức; Có vẻ như đó chỉ là một điều tuyệt vời. Đọc thêm: Tài liệu GitHub về Dự án.
#10 Gwiki
Đối với một tập hợp các trang không có cấu trúc—như Wikipedia— thì GitHub Wiki (mà từ giờ trở đi tôi sẽ gọi là Gwiki) là một lựa chọn tuyệt vời. Đối với một tập hợp các trang có cấu trúc - ví dụ như tài liệu của bạn - không nhiều lắm. Không có cách nào để chỉ ra rằng “trang này là con của trang đó”; không có những thứ tiện lợi như nút “Phần tiếp theo” và “Phần trước”. Hansel và Gretel chắc chắn sẽ bị lạc ở đây, vì cũng không có “breadcrumb” (toán tử gỡ lỗi đặc biệt - xấp xỉ trans.) ở đây. (Lời tác giả: Bạn đã đọc câu chuyện này chưa? Thật là vô nhân đạo. Hai tên côn đồ trẻ tuổi giết một bà già tội nghiệp đói khát, thiêu sống bà trong chính lò nướng của bà . Và tất nhiên, để lại một mớ hỗn độn không ai có thể hiểu được. Tôi nghĩ đó là lý do tại sao giới trẻ ngày nay nhạy cảm quá – những câu chuyện đọc cho trẻ em trước khi đi ngủ ngày nay chưa đủ tàn nhẫn!) Tiếp tục – để dùng thử Gwiki thực sự, tôi đã nhập một vài trang từ NodeJS dưới dạng trang wiki, sau đó tạo một trang tùy chỉnh thanh bên để mô phỏng cấu trúc thực tế của trang web. Thanh bên này luôn ở đó, mặc dù trang hiện tại không được đánh dấu. Các liên kết sẽ phải được duy trì thủ công, nhưng nhìn chung mọi thứ đều hoạt động tốt. Nếu muốn bạn có thể tham khảo :
Điều này khó có thể cạnh tranh với thứ gì đó như GitBook (được sử dụng trong tài liệu Redux ) hoặc một trang web riêng. Nhưng đây đã là 80% rồi và mọi thứ đều có trong kho lưu trữ của bạn. Tôi chỉ là một fan hâm mộ của điều này. Tôi khuyên rằng nếu bạn đã sử dụng hết tệp README.md và cần một số trang khác nhau dành cho hướng dẫn sử dụng hoặc tài liệu chi tiết hơn thì bạn nên gắn bó với Gwiki. Nếu việc thiếu cấu trúc/điều hướng làm phiền bạn, hãy chuyển sang thứ khác.
#11 Trang GitHub
Bạn có thể đã biết rằng Trang GitHub có thể được sử dụng để lưu trữ một trang web tĩnh. Và nếu bạn chưa biết thì bây giờ bạn đã biết rồi. Tuy nhiên, phần này dành riêng cho một chủ đề cụ thể hơn: sử dụng Jekyll để tạo trang web. Ở dạng đơn giản nhất, GitHub Pages + Jekyll có thể hiển thị tệp README.md bằng một chủ đề đẹp mắt. Ví dụ: hãy xem trang readme của tôi từ about-github :
Nếu bạn nhấp vào tab cài đặt cho trang GitHub này, hãy bật Trang GitHub và chọn chủ đề Jekyll...
Sau đó, bạn có thể tạo toàn bộ trang web tĩnh chủ yếu dựa trên các tệp đánh dấu có thể chỉnh sửa dễ dàng, về cơ bản biến GitHub thành CMS. Mặc dù tôi chưa thực sự sử dụng điều này, nhưng đây là cách các trang web được xây dựng bằng khung Bootstrap bằng React, vì vậy không có gì khủng khiếp về nó. Tôi lưu ý rằng Ruby phải chạy trên máy cục bộ (người dùng Windows sẽ trao đổi những cái nhìn hiểu biết ở đây và đi theo hướng khác, người dùng macOS sẽ nói: “Có vấn đề gì vậy, bạn đang đi đâu vậy? Ruby là một nền tảng phổ quát! Ngoài ra còn có GEMS hệ thống quản lý gói!”) ( Cũng cần lưu ý rằng "Nội dung hoặc hành vi hung hăng hoặc đe dọa" không được phép trên Trang GitHub, vì vậy bạn sẽ không thể đăng phiên bản câu chuyện Hansel và Gretel của mình ở đó).
Quan điểm của tôi
Càng xem xét sự kết hợp GitHub Pages + Jekyll (đối với bài viết này), tôi càng nghĩ toàn bộ ý tưởng này có mùi kỳ lạ. Ý tưởng "tạo trang web của riêng bạn với nỗ lực tối thiểu" thật tuyệt vời. Nhưng để làm việc với nó, bạn vẫn cần phiên bản hiện tại trên máy cục bộ. Và đối với một thứ quá "đơn giản" thì có quá nhiều lệnh dòng lệnh. Tôi lướt qua bảy trang trong phần Bắt đầu và cảm thấy như điều đơn giản duy nhất ở đây chính là tôi . Và tôi thậm chí còn chưa tìm ra cú pháp đơn giản cho trang chính hoặc những điều cơ bản về “Cơ chế tạo khuôn mẫu dựa trên ngôn ngữ Liquid” đơn giản. Tôi thà tự mình viết một trang web còn hơn! Thành thật mà nói, tôi hơi ngạc nhiên khi Facebook sử dụng điều này cho tài liệu React khi họ có thể xây dựng các trang hệ thống trợ giúp của mình bằng React và kết xuất trước dưới dạng tệp HTML tĩnh hàng ngày . Tất cả những gì họ cần làm là tìm cách nhận các tệp đánh dấu hiện có như thể chúng đến từ CMS. Chuyện gì xảy ra nếu...
#12 Sử dụng GitHub làm CMS
Giả sử chúng ta có một trang web có một số văn bản nhưng chúng ta không muốn lưu trữ văn bản đó dưới dạng đánh dấu HTML. Thay vào đó, chúng tôi muốn lưu trữ các đoạn văn bản ở đâu đó mà người dùng không phải là nhà phát triển có thể dễ dàng chỉnh sửa. Tốt nhất là với một số tùy chọn phiên bản. Có lẽ ngay cả với một số loại quy trình đánh giá ngang hàng. Đây là những gì tôi đề xuất: sử dụng các tệp đánh dấu được lưu trữ trong kho lưu trữ để lưu trữ văn bản. Và sử dụng một thành phần ở phía máy khách để truy xuất những đoạn văn bản này và hiển thị chúng trên trang. Tôi là người hâm mộ React, vì vậy đây là ví dụ về thành phần <Markdown> thích hợp, được cung cấp đường dẫn đến tệp đánh dấu, sẽ trích xuất, phân tích cú pháp và hiển thị dưới dạng HTML.
classMarkdownextendsReact.Component{constructor(props){super(props);// Конечно, вам нужно заменить это на свой URLthis.baseUrl ='https://raw.githubusercontent.com/davidgilbertson/about-github/master/text-snippets';this.state ={
markdown:'',};}componentDidMount(){fetch(`${this.baseUrl}/${this.props.url}`).then(response => response.text()).then((markdown)=>{this.setState({markdown});});}render(){return(<div dangerouslySetInnerHTML={{__html:marked(this.state.markdown)}}/>);}}
(Tôi sử dụng gói được đánh dấu npm ở đây để phân tích đánh dấu trong HTML) URL trỏ đến kho lưu trữ ví dụ của tôi, nơi chứa các tệp đánh dấu trong thư mục /text-snippets . (Bạn cũng có thể sử dụng API GitHub để tìm nạp nội dung , nhưng tôi nghi ngờ bạn sẽ cần điều đó.) Bạn có thể sử dụng một thành phần như thế này:
constPage=()=>(<div className="page"><div className="about-us"><Markdown url="about-us.md"/></div><div className="disclaimer"><p>A very important disclaimer:</p><Markdown url="disclaimers/home-page-disclaimer.md"/></div></div>);
Vì vậy, theo một cách nào đó, GitHub hoạt động như CMS của bạn cho những đoạn văn bản mà bạn muốn lưu trữ. Ví dụ trên chỉ truy xuất đánh dấu sau khi thành phần được tải trong trình duyệt. Nếu bạn cần một trang web tĩnh, bạn sẽ phải hiển thị nó trên máy chủ. Tin tốt! Không có gì ngăn cản bạn truy xuất tất cả các tệp đánh dấu trên máy chủ (sử dụng bất kỳ chiến lược bộ nhớ đệm nào bạn muốn). Nếu bạn quyết định đi theo con đường này, bạn nên sử dụng API GitHub để lấy danh sách tất cả các tệp đánh dấu trong một thư mục. Phần thưởng - Tiện ích GitHub! Tôi đã sử dụng tiện ích mở rộng Octotree Chrome được một thời gian và giới thiệu nó cho bạn. Không phải không có đặt chỗ, nhưng tôi vẫn khuyên bạn nên dùng nó. Nó hiển thị một bảng điều khiển ở bên trái với chế độ xem dạng cây của kho lưu trữ mà bạn đang duyệt.
Và từ video này tôi đã biết về octobox , đối với tôi, đây cũng là một tiện ích rất tốt cho đến nay. Đây là hộp thư đến cho các vấn đề GitHub của bạn. Đó là tất cả những gì bạn cần biết về anh ấy. Nói về màu sắc, tôi chụp tất cả các ảnh chụp màn hình ở trên với chủ đề nhẹ nhàng để không làm bạn sợ. Nhưng nếu tôi thích màu tối trong mọi thứ khác, thì tại sao lại sử dụng GitHub nhợt nhạt chết người?
Ở đây tôi đã sử dụng kết hợp tiện ích mở rộng Stylish cho trình duyệt Chrome (có thể áp dụng chủ đề cho bất kỳ trang web nào) và kiểu GitHub Dark . Và đối với những người mới bắt đầu, nhà phát triển GitHub có công cụ chủ đề tối (tích hợp sẵn, bạn chỉ cần bật nó) và chủ đề Atom One Dark cho Chrome.
Cai Xô nhỏ
Nói đúng ra thì nó không hoàn toàn phù hợp ở đây, nhưng tôi không thể không nhắc đến Bitbucket. Hai năm trước, tôi bắt đầu một dự án và dành nửa ngày để chọn hosting git tốt nhất. Vì vậy, Bitbucket đã giành chiến thắng với tỷ số cách biệt đáng kể. Quy trình đánh giá mã của họ vượt xa đối thủ cạnh tranh (điều này đã rất lâu trước khi GitHub có khái niệm về người đánh giá). Kể từ đó, GitHub cũng đã nhận được nhiều đánh giá. Thật không may, tôi đã không có cơ hội sử dụng Bitbucket trong năm qua - có lẽ họ lại tiếp tục tiến lên một lĩnh vực nào đó. Vì vậy tôi khuyên những người chịu trách nhiệm lựa chọn dịch vụ lưu trữ git cũng nên chú ý đến Bitbucket.
Phần kết luận
Đó là tất cả! Tôi hy vọng rằng tôi có thể nói với bạn ít nhất ba điều mà trước đây bạn chưa biết. Và tôi cũng hy vọng rằng bạn đã có thời gian vui vẻ khi đọc bài viết của tôi.
GO TO FULL VERSION