GitHub の 12 の驚くべき機能

イントロは一生思いつかないので…

#1 GitHub.com でコードを編集する

誰もがすでに知っていると思うことから始めます（ただし、私自身、1週間前にはまったく知りませんでした）。GitHub 上の任意のリポジトリ内のテキスト ファイルを表示すると、右上に小さな鉛筆が表示されます。それをクリックすると、このファイルを編集できます。完了したら、「ファイル変更の提案」をクリックすると、GitHub がフォークとプルリクエストを作成します。すごいですね。彼はフォークを自分で作成しました。コードをフォークして自分にアップロードし、ローカルで変更を加えて、プル リクエストとともに GitHub に送り返す必要はありません。最小限の編集が必要な場合に非常に便利です。 まったく本物のプルリクエストではありません

#2 画像の挿入

問題の説明はテキストのコメントだけに限定されません。クリップボードから画像を直接貼り付けることができることをご存知ですか? 貼り付けると、(間違いなくクラウドに) アップロードされ、画像を表示するためのマークアップに変換されることがわかります。優雅！

#3 コードのフォーマット

コードのブロックを記述する必要がある場合は、3 つのバッククォートから始めると、GitHub がどのプログラミング言語で記述されているかを推測しようとします。ただし、Vue、Typescript、JSX などのプログラミング言語でコードを投稿する場合は、構文の強調表示が正しく行われるように言語を明示的に指定できます。最初の行の ```jsx に注目してください。 ...コード スニペットが正しく表示されるようにする: (ちなみに、これは Gist にも当てはまります。Gist に .jsf 拡張子を指定すると、JSF 構文が強調表示されます。) 以下は、サポートされているすべての構文のリストです。

#4 プル リクエストで「魔法の言葉」を使用して問題を解決する

問題 #234 を修正するプル リクエストを作成するとします。「問題 #234 を修正」というテキストをリクエストの説明 (または変更リクエストのコメントの任意の場所) に挿入できます。この後、プル リクエストをマージすると、問題は「自動的に」解決されます。かっこいいですね。詳細については、ドキュメントを参照してください。

#5 コメントへのリンク

特定のコメントへのリンクを作成する必要があるが、その方法が分からなかったことがありますか? そんな日々はとうに過ぎ去りました。秘密をお話しします。コメントへのリンクを作成するには、タイトルの横にある日付/時刻をクリックするだけです。 見て、gaearon に写真が追加されました。

#6 コードリンク

したがって、コードの特定の行へのリンクを作成したいとします。この場合は、次のことを試してください。開いているファイル内の目的のコードの横にある行番号をクリックします。うわー、わかりますか？URL が変更され、行番号が表示されるようになりました。SHIFT キーを押しながら別の行番号をクリックすると、出来上がりです。– URL が再び変更され、行の範囲が強調表示されます。この URL は、このファイルとこの範囲の行を指すようになります。しかし、待ってください。これは現在のスレッドを指しています。ファイルが変更されたらどうなるでしょうか? この場合、おそらく現在の状態のファイルへの永久リンクが必要になります。私はとても怠け者なので、上記すべてのスクリーンショットを 1 枚撮りました。 ちなみにURLについてですが…

#7 GitHub URL をコマンドラインとして使用する

UI を使用した GitHub 内での移動は、非常に便利に構成されています。ただし、特定の場所にアクセスするには、URL にその場所を入力する方が速い場合があります。たとえば、作業中のブランチに移動して、マスターとの比較を確認したい場合は、 リポジトリ名の後に「/compare/branchname」と入力するだけです。これにより、そのブランチの差分ページが表示されます。 ただし、これらはマスター ブランチとの違いですが、以前に統合ブランチを使用した場合は、 URL に/compare/integration-branch...my-branchと入力できます。 ホットキー愛好家向け: CTRL+L または CMD+L を押すと、カーソルが URL バーに移動します (少なくとも Chrome および Firefox ブラウザでは)。これをブラウザのオートコンプリートと組み合わせると、ブランチ間の移動がはるかに簡単になります。 プロのヒント:矢印を使用して Chrome のオートコンプリート候補を移動し、Shift+Delete を押して履歴から項目を削除します (ブランチのマージ後など)。(SHIFT + DELETE のように、これらのショートカット キーにスペースを入れると読みやすくなるかどうかはわかりません。ただし、技術的には「+」はショートカット キーの一部ではないため、このオプションは好きではありません。こんな事があるから夜も眠れないんだよ、ロンダ）

#8 問題のリストを作成する

問題の説明にチェックボックスが必要ですか? また、リストから問題を表示するときに「2/5」のような気の利いたバーを表示したいと思いませんか? 問題ない！次の構文を使用して対話型チェックボックスを作成できます。

• [ ] 画面幅 (整数)
• [x] Service Worker のサポート
• [x] フェッチのサポート
• [ ] CSS フレックスボックスのサポート
• [ ] カスタム要素

構文:スペース、ハイフン、スペース、左大括弧、スペース (または x)、右大括弧、スペース、およびいくつかの単語。その後、実際にこれらのボタンをオン/オフにすることができます。どういうわけか、これは私にとってある種の技術的な魔法のように思えます。ボックスにチェックを入れることができます。そして同時に元のテキストも変更されます。彼らが次に何を思いつくかを考えるのは恐ろしいです。ああ、この問題がプロジェクト パネルにある場合は、そこにも進行状況が表示されます。 「プロジェクト パネル」の意味がわからない場合は、以下をお読みください。このページでは数センチ下にあります。

#9 GitHub のプロジェクト パネル

大規模なプロジェクトでは、私は常に Jira を使用してきました。個人的なプロジェクトでは、私は常に Trello を使用してきました。私はどちらのツールもとても気に入っています。数週間前、GitHub がリポジトリの[プロジェクト]タブで独自のオプションを提供していることを知ったとき、Trello ですでに作業している一連のタスクを複製するのが理にかなっていると思いました。 ここには何も面白いことはありませんが、GitHub プロジェクトでも同じことが行われています。 徐々に目が低コントラストの画像に慣れてきます。 速度を上げるために、上記のすべてをメモとして追加しました。つまり、これらは「実際の」GitHub の問題ではありません。ただし、GitHub の課題管理の威力は、リポジトリの残りの部分との統合にあります。そのため、既存の課題をリポジトリからダッシュボードに追加する方がよいでしょう。右上隅にある「カードの追加」をクリックして、追加したいカードを見つけます。ここで、特別な検索構文が役に立ちます。たとえば、「is :pr is:open」と入力すると、開いているプル リクエストをパネルにドラッグできます。バグを修正する必要がある場合は、 「label:bug」をドラッグすることもできます。 既存のメモを課題に変換することもできます。 最後に、既存の問題フォームから、それを右側のパネルのプロジェクトに追加します。 これはそのプロジェクト パネルの優先順位リストに追加されるため、どの列に配置するかを選択できます。 「タスク」の記述が、このタスクを実装するコードと同じリポジトリにあると、非常に便利です。これは、今から何年も後に、 Jira/Trello/その他の場所ですべてを追跡することなく、コード行に対してgitblameを実行して、その行につながった問題の全体を把握できるようになるということを意味します。

欠陥

ここ 3 週間、私は Jira ではなく GitHub ですべてを行うことを実験し (カンバン スタイルのような小さなプロジェクトで)、それを気に入っています。しかし、開発速度などを適切に評価し、計算する必要があるスクラムプロジェクトでは、これは想像できません。幸いなことに、GitHub プロジェクトには「特別な機能」がほとんどないため、別のシステムに切り替えるのにそれほど時間はかかりません。それで、それを試してみて、どれだけ気に入ったかを確認してください。これがどれほど重要かわかりませんが、ZenHubについて聞いて、10分前に初めて開きました。これは本質的に GitHub の拡張機能であり、問​​題を評価したり、「エピック」や依存関係を作成したりできます。開発速度とバーンアウトのグラフがあります。どうやらすごいことのようです。詳細:プロジェクトに関する GitHub ドキュメント。

#10 グウィキ

Wikipedia のような非構造化ページのセットの場合は、GitHub Wiki (以降は単に Gwiki と呼びます) が最適です。たとえば、ドキュメントなどの構造化されたページのセットの場合は、それほど重要ではありません。「このページがあのページの子である」ことを示す方法はなく、「次のセクション」や「前のセクション」ボタンのような便利なものもありません。ここにも「ブレッドクラム」（特別なデバッグ演算子 - 約変換）がないため、ヘンゼルとグレーテルは間違いなくここで迷子になるでしょう。(著者注:この物語を読んだことがありますか? まさに非人道的です。二人の若い凶悪犯が、お腹を空かせた哀れな老婦人を殺害し、自宅のオーブンで生きたまま焼き殺しました。そしてもちろん、誰も理解できない完全な混乱を残しました。それが理由だと思います。最近の若者はとても敏感です - 最近の就寝前に子供たちに読み聞かせる物語は、それほど残酷ではありません!) 次に進みます - Gwiki を実際に試すために、NodeJS からいくつかのページを wiki ページとして入力し、カスタムのサイトの実際の構造をシミュレートするサイドバー。現在のページは強調表示されませんが、このサイドバーは常に表示されます。リンクは手動で維持する必要がありますが、全体的にはすべて正常に機能します。必要に応じて、見てみましょう: これは、GitBook ( Reduxドキュメントで使用されています) や特注の Web サイトのようなものと競合することはほとんどありません。ただし、これはすでに全体の 80% に相当し、すべてがリポジトリ内に正しくあります。私はただのファンです。単一の README.md ファイルでは大きくなりすぎて、ユーザー マニュアルやより詳細なドキュメント用に複数の異なるページが必要な場合は、Gwiki を使用するのが合理的であることをお勧めします。構造やナビゲーションの欠如が気になる場合は、別の項目に進んでください。

#11 GitHub ページ

GitHub Pages を使用して静的 Web サイトをホストできることはすでにご存知かもしれません。知らなかったとしても、今ならわかります。ただし、このセクションでは、 Jekyllを使用したWeb サイトの作成という、より具体的なトピックを取り上げます。最も単純な形式では、GitHub Pages + Jekyll は見栄えの良いテーマを使用して README.md ファイルをレンダリングできます。たとえば、about-githubの readme ページを見てください。 この GitHub サイトの設定タブをクリックすると、GitHub Pages が有効になり、Jekyll テーマが選択されます。 次に、 Jekyll テーマのスタイルのページを取得します。 その後、主に簡単に編集可能なマークアップ ファイルに基づいて静的サイト全体を作成し、実質的に GitHub を CMS に変えることができます。実際に使ったことはありませんが、このように React を使った Bootstrap フレームワークで Web サイトを構築する仕組みなので、それほどひどいものではありません。Ruby はローカル マシン上で実行する必要があることに注意してください (Windows ユーザーはここで理解のある視線を交わし、別の方向に進みますが、macOS ユーザーはこう言います。「何が問題ですか、どこへ行くのですか? Ruby はユニバーサル プラットフォームです。GEMS もあります)」 (「攻撃的または脅迫的なコンテンツや行動」は GitHub ページでは許可されていないため、そこに自分のバージョンのヘンゼルとグレーテルの物語を投稿することはできないことにも注意してください)。

私の意見

GitHub Pages と Jekyll の組み合わせ (この記事について) を調べれば調べるほど、アイデア全体が奇妙に思えてきました。「最小限の労力で自分のウェブサイトを作る」というアイデアは素晴らしいです。ただし、作業するにはローカル マシン上に現在のバージョンが必要です。そして、これほど「単純」なものの割に、コマンドラインコマンドが多すぎます。「はじめに」セクションの 7 ページをざっと読んで、簡単なのは私だけだと感じました。そして、メインページの簡単な構文や、簡単な「リキッド言語に基づくテンプレートメカニズム」の基本すら理解していません。自分でWebサイトを書きたい！正直に言うと、Facebook が React を使用してヘルプ システム ページを構築し、毎日静的 HTML ファイルとして事前レンダリングできるはずなのに、これを React ドキュメントに使用していることに少し驚きました。必要なのは、既存のマークアップ ファイルを CMS から来たかのように受信する方法を見つけることだけです。もしも...

#12 GitHub を CMS として使用する

テキストを含む Web サイトがあるとしますが、そのテキストを HTML マークアップとして保存したくないとします。代わりに、開発者以外のユーザーが簡単に編集できる場所にテキストの塊を保存したいと考えています。できれば、何らかのバージョン管理オプションを使用します。おそらく、ある種の査読プロセスが存在する可能性もあります。私が提案するのは、リポジトリに保存されているマークアップ ファイルを使用してテキストを保存することです。そして、これらのテキストを取得してページに表示するクライアント側のコンポーネントを使用します。私は React のファンなので、マークダウン ファイルへのパスを指定すると、それを抽出し、解析し、HTML としてレンダリングする適切な <Markdown> コンポーネントの例を次に示します。

class Markdown extends React.Component {
    constructor(props) {
      super(props);

      // Конечно, вам нужно заменить это на свой URL
      this.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)}} />
      );
    }
}

(ここでは、HTML のマークアップを解析するために npmマーク付きパッケージ を使用します) URL は、/text-snippetsディレクトリーにマークアップ ファイルを含むサンプル リポジトリーを指します。(GitHub API を使用してコンテンツを取得することもできますが、それが必要になるとは思えません。) このようなコンポーネントは次のように使用できます。

const Page = () => (
  <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>
);

したがって、GitHub は、ある意味、ホストしたいテキストの CMS として機能します。上記の例では、コンポーネントがブラウザにロードされた後にのみマークアップを取得します。静的サイトが必要な場合は、サーバー上でそれをレンダリングする必要があります。朗報です！(任意のキャッシュ戦略を使用して) サーバー上のすべてのマークアップ ファイルを取得することを妨げるものは何もありません。この方法を選択する場合は、GitHub API を使用してディレクトリ内のすべてのマークアップ ファイルのリストを取得するのが合理的です。 ボーナス - GitHub ユーティリティ! 私はOctotree Chrome 拡張機能をかなり長い間使用しているので、あなたにお勧めします。予約がないわけではありませんが、それでもお勧めします。左側にパネルが表示され、参照しているリポジトリのツリー ビューが表示されます。 そして、このビデオからoctoboxについて学びました。これも今のところ非常に優れたユーティリティであるように思えます。これは、GitHub の問題の受信箱です。あなたが彼について知る必要があるのはそれだけです。色について言えば、皆さんを怖がらせないように、上記のスクリーンショットはすべて明るいテーマで撮影しました。しかし、他のすべてにおいて暗い色を好むのであれば、なぜ死ぬほど青白い GitHub を我慢する必要があるのでしょうか? ここでは、Chrome ブラウザーのスタイリッシュ拡張機能 (テーマをあらゆる Web サイトに適用できます) とGitHub ダークスタイルを組み合わせて使用​​しました。まず、GitHub 開発者ツールのダーク テーマ (組み込み、有効にするだけで済みます) とChrome 用のAtom One Darkテーマです。

ビットバケット

厳密に言えば、ここでは完全に適切ではありませんが、Bitbucket について触れずにはいられません。2 年前、私はプロジェクトを開始し、最適な Git ホスティングを選択するのに半日を費やしました。したがって、Bitbucket が大幅な差をつけて勝利しました。彼らのコード レビュー パイプラインは競合他社よりもはるかに進んでいます (これは GitHub にレビューアーという概念が存在するずっと前のことです)。それ以来、GitHub でもレビューを獲得しています。残念ながら、私はここ 1 年間 Bitbucket を使用する機会がありませんでした。おそらく彼らはまた何かを前進させたのでしょう。したがって、Git ホスティング サービスを選択する責任がある人には、Bitbucket にも注目することをお勧めします。

結論

それだけです！これまで知らなかった少なくとも 3 つのことをお伝えできれば幸いです。また、私の記事を読んで楽しい時間を過ごしていただければ幸いです。