Using Git & GitHub

コラム 3.5

翻訳の進捗

本章で学ぶこと:

  • 本書を理解する上で、GitHubの使い方を学びます。
  • GitHub は Git というバージョン管理システムを基にした、オープンソースプロジェクト向けのソーシャルリポジトリです。(???) GitHub の基本的な役割は、コードを共有してプロジェクトのコラボレーションをしやすくすることです。 また、GitHub は素晴らしい学習ツールでもあります。 この補足事項では、Discover Meteor を理解する上での GitHub の使い方を学びます。

    この補足事項では、Git や GitHub について知らない読者の方を想定しています。 もしあなたがどちらも使いこなせるのなら、この章まで飛ばしても大丈夫です。

    コミットをする

    git リポジトリの基本的なワーキングブロック(???)は、コミットです。 コミットとは、一定時間のコード(???)の状態のスナップショットと考えることができます。

    Microscope の完成したコードを(give?) の代わりに あらゆる面でスナップショットを撮って、オンラインの GitHub 上で見ることができます。(???)

    たとえば、前章でのコミットは次のようになります:

    A Git commit as shown on GitHub.
    A Git commit as shown on GitHub.

    ここで見ているのは、postitem.js ファイルの “diff”(“difference”) です。 これはコミットによって取り込まれた変化です。 この場合、ゼロから postitem.js ファイルを作ったため、背景が緑色に表示されています。

    後々本書で出てくる例を見比べてみましょう

    Modifying code.
    Modifying code.

    今回は修正した行の背景だけが緑色になっています。

    もちろん、コードを加えたり修正するだけでなく、コードを削除することもあります。

    Deleting code.
    Deleting code.

    これが GitHub の最初の使い方です。何か変更されたのか、一目瞭然です。

    コミットされたコードを見る

    Git のコミット表示は このコミットに(include?)された変化を表示していますが、  変化していないファイルを見たいという時は、  コードが(at this stage of the process?)で(???)

    またしても GitHub が(comes through?)します。  コミットページで、Browse code ボタンをクリックしましょう。

    The Browse code button.
    The Browse code button.

    これで(specific?=特定の?)コミットを示すリポジトリにアクセスしました。 

    The repository at commit 3-2.
    The repository at commit 3-2.

    GitHubは私たちがGitHubを見ている時に、多くの視覚的なヒントを伝えません。 しかし、「普通」の(master view?)を比較して、ファイル構造が違っていることが一目でわかります。

    The repository at commit 14-2.
    The repository at commit 14-2.

    ローカルコミットへのアクセス

    これまでオンラインの GitHub で、どのようにコミットされたコードを見るのか学習しました。 一方で、ローカル環境で同じことしたいときはどうしたらよいのでしょうか? たとえば、現在のプロセスで想定通りにアプリが動くかどうか確かめるための特定のコミットで、ローカル環境でアプリを動かしたいといましょう。 (???)

    これをするために、git コマンドライン(utility?)を使って本書での最初の一歩を進みましょう。  まず第一に、Git がインストールされているか確認します。 それから次のようにして Microscope リポジトリをクローン(言い換えると、ローカルにコピーをダウンロード)します。   ~~~bash $ git clone git@github.com:DiscoverMeteor/Microscope.git github_microscope ~~~

    この github_microscope は(at the end?)では、アプリをクローンして入れておくローカルディレクトリの名前です。  すでに microscope ディレクトリが存在している(Assuming?=場合は?)、 他の名前を(pick?=選びます?)(GitHub リポジトリと同じ名前を使う必要はありません)。   git コマンドライン(utility?)を使い始めるために、リポジトリ(into?)cd しましょう。

    $ cd github_microscope
    

    私たちは GitHub からリポジトリをクローンしたので、 アプリのすべてのコードをダウンロードしました。つまり、私たちは( last ever?=最後に?)コミットされたコードを見ています。

    ありがたいことに、( other ones?)に影響を及ぼさずに 時間の流れをさかのぼって 特定のコミットを(“check out” ?)する方法があります。では、試してみましょう。

    $ git checkout chapter3-1
    Note: checking out 'chapter3-1'.
    
    あなたは'detached HEAD'状態になっています。
     周りを見渡して、実験的に変化させて、(them?)をコミットします。
     すると、この状態でどのようなコミットも
     他の checkout をすることで、どのようなブランチにも 影響を与えずに、
     捨てることができます。
    
    コミットを保持するために新しいブランチoこを作りたいという場合、
     再び checkout コマンドで -b を使って行います。
    
      git checkout -b new_branch_name
    
    HEAD is now at a004b56... Added basic posts list template and static data.
    

    私たちは Git によって(“detached HEAD”?)状態を知ることができます。 Gitが関係する限り、私たちは過去のコミットを見れるだけで、修正することはできません。 これは水晶の玉で過去を調べる魔法使いのようなものだと考えることができます。

    (Git には 過去のコミットを変えるコマンドがあります。   これは時間の流れをさかのぼって、蝶を踏みつけるタイムトラベラーのようなものです。   しかし、この点はこの短い紹介の範囲を超えてしまいます。)

    なぜ(chapter3-1?)をタイピングできるのかというと、  私たちは(correct chapter marker?)で Microscope のすべてのコミットを( pre-tagged?)したからです。  (this weren’t the case?)、最初にコミットのハッシュか(unique identifier?)を見つける必要があります。 

    またしても、 GitHub は私たちの生活を(???)しやすくしてくれました。  (as shown here?=この図のように?)、青いコミットヘッダーボックスの右下の隅にコミットハッシュを見つけることができます。  

    Finding a commit hash.
    Finding a commit hash.

    タグの代わりに ハッシュを使ってみましょう。

    $ git checkout c7af59e425cd4e17c20cf99e51c8cd78f82c9932
    Previous HEAD position was a004b56... Added basic posts list template and static data.
    HEAD is now at c7af59e... Augmented the postsList route to take a limit
    

    最後に、水晶の玉を見ることをやめたくなって、現在に戻りたくなったらどうするのでしょうか?  私たちは Git に(master branch?)をチェックしたいと伝えます。

    $ git checkout master
    

    Historical Perspective

    これはもうひとつのよくある状況です: あなたがファイルを見ていると、今まで見たことのない変化に気づきました。  (The thing is,?=要するに?)、あなたはいつファイルを変更させたか覚えていません。  (right one?)を見つけるまで、一つ一つコミットを見ていく (???)  しかし、 GitHub の History 機能でもっと簡単にする方法があります。

    最初に、GitHub でリポジトリの ファイルにアクセスして、“History” ボタンを見つけます。

    GitHub's History button.
    GitHub’s History button.

    このファイルに影響を与えたすべてのコミットを整ったリストで(have?)します。

    Displaying a file's history.
    Displaying a file’s history.

    The Blame Game

    締めくくりに、Blame を見ていきましょう。  

    GitHub's Blame button.
    GitHub’s Blame button.

    (neat view?)は 誰がファイルとコミットを変更したのか行ごとに、表示します。  (言い換えると、うまくいかなくなった時に誰のせいかということがわかります。)  

    GitHub's Blame view.
    GitHub’s Blame view.

    Git と GitHub はかなり複雑なツールです。そのため、1つの章ですべてのことをカバーすることは見込めません。  実際のところ、これで私たちは やっと Git と GitHub でできることを少しだけ学ぶことができました。 (???)  とはいえ、本書の残りを理解していく上でいくらか役立つとわかるでしょう。(???)