Skip to main content

疫学のための R ハンドブック

46 Git と Github を使ったバージョン管理と共同作業

この章では、Git を使った共同作業の概要を説明します。より詳細なチュートリアルは、下部にある「リソース」セクションでご覧いただけます。

46.1 Git とはなにか？

Git は、フォルダ内の変更を追跡することができるバージョン管理ソフトウェアです。Word や LibreOffice、Google Docs の「変更履歴」オプションのように、あらゆる種類のファイルに対して使用することができます。これは、バージョン管理のための最も強力で最も使用されるオプションの 1 つです。

なぜ聞いたことがないのか？ ー ソフトウェア開発の経験がある人は日常的にバージョン管理ソフト（Git、Mercurial、Subversion など）の使い方を学んでいますが、データ分析分野の人はあまりバージョン管理スキルを教わっていません。そのため、疫学者のほとんどは学生時代にバージョン管理ソフトの存在を知らず、仕事する中で学ばなければなりません。

待って、Github って聞いたことあるけど、同じなの？ ー 正確には違いますが、よく一緒に使うことがありますので、その方法をご紹介します。簡単に言いますと

  • Git はバージョン管理システムで、ソフトウェアの一つです。あなたのコンピュータ上でローカルに使用することもできますし、あるフォルダをホストサイトと同期させることもできます。デフォルトでは、ターミナルを使って Git にコマンドラインで指示を与えます。

  • Git クライアント /GUI を使えば、コマンドラインを使わずに、（少なくとも単純で超一般的なものについては）同じ動作を行うことができます。

  • フォルダをホストサイトに保存して他の人と共同作業をしたい場合は、Github、Gitlab、Bitbucket などにアカウントを作成してください。

そこで、クライアント / GUI である Github Desktop を使用すると、バックグラウンドで Git を使用して、自分のコンピュータのローカルファイルと Github サーバーのリモートファイルの両方を管理することができます。

46.2 なぜ Git と Github を組み合わせて使うの？

Git を使うことで、以下のようなことが期待されます。

  1. 文書化されたバージョンを増分の変更とともにアーカイブし、以前の状態に簡単に戻すことができます。
  2. 並行してブランチを持つこと、つまり、レビュー後に変更を統合するための構造化された方法で開発版/「動く」版を持つこと。

これは、他の人と共同作業をしなくても、自分のコンピュータでローカルに行うことができます。今までに

  • コードの一部分を削除してしまって 2 ヶ月後には実際に必要だったことに気づいて後悔したり

  • 一時停止していたプロジェクトに戻ってきて、あるモデルにトリッキーな修正をしたかどうかを思い出そうとしたり

  • model_1.R というファイルと、model_1_test.R というファイルと、model_1_not_working.R というファイルを用意して、いろいろ試してみたり

  • ファイル report.Rmd、ファイル report_full.Rmd、ファイル report_true_final.Rmd、ファイル report_final_20210304.Rmd、ファイル report_final_20210402.Rmd があり、自分のデータ保管技術を呪っていたのですね。

Git は上記の手助けをしてくれるので、それだけでも学ぶ価値があります。

しかし、Github のようなオンラインリポジトリと併用することで、共同プロジェクトをサポートすることができ、さらに強力になります。これにより、以下の点が促進されます。

  • 共同作業：他の人がレビュー、コメント、変更の承認/却下が可能

  • コード、データ、アウトプットを共有し、一般から（またはチーム内で）フィードバックを募る

また、以下のことは避けることができます。

  • 「おっと、前回のバージョンを送るのを忘れていたので、2 日分の作業をこの新しいファイルでやり直さなければならない」

  • Mina、Henry、Oumar の 3 人が 1 つのスクリプトで同時に作業を行い、それぞれの変更を手動でマージする必要があります。

  • 2 人の人が Dropbox と Sharepoint で同じファイルを変更しようとすると、同期エラーが発生します。

複雑なようですね、私はプログラマーではありませんが、、、

確かに複雑なときもあります。高度な使い方の例は、とても怯んでしまいます。しかし、R や Excel のように、エキスパートにならなくてもツールのメリットを享受することができます。ちょっとした関数や概念を学ぶだけで、変更点の追跡、オンラインリポジトリ上でのファイルの同期、同僚との共同作業などが、ごく短時間でできるようになります。

学習曲線を考えると、緊急時の状況でこれらのツールを学ぶのに最適なタイミングではないかもしれません。しかし、学習は段階的に行うことができます。いくつかの概念を身につければ、ワークフローは非常に効率的かつ迅速になります。Git を使った共同作業が必要なプロジェクトに携わっていないのであれば、共同作業で Git を使う前に、1 人で Git を使うことでツールの利用に自信を持つことができるでしょう。

46.3 環境構築

Git をインストール

Git とは、コンピュータの舞台裏にあるエンジンのことで、変更、ブランチ（バージョン）、マージ、リバートを追跡することができます。まず、https://git-scm.com/downloadsから Git をインストールする必要があります。

GUI をインストール (必須ではないが推奨)

Git には独自のコマンド言語があり、コマンドライン・ターミナルに入力することができます。しかし、多くのクライアントソフトや GUI があり、開発者ではない人が日常的に Git と直接やりとりする必要はほとんどないでしょうし、GUI は通常、ファイルの変更やブランチを視覚化するツールを提供します。

初心者向けのものから複雑なものまで、あらゆる OS で多くの選択肢が存在します。 初心者向けの GUI としては、この章で紹介する RStudio の Git ペインや Github Desktop などがあります。中級者向け（より強力だがより複雑）のオプションとしては、Sourcetree、Gitkracken、Smart Git などがあります。

Git clients の簡単な解説

注釈：実際にはすべての GUI が内部的に Git を使用しているので、複数の GUI を試してみたり、特定のプロジェクトで GUI を切り替えたり、 GUI がサポートしていないアクションのために時間的にコンソールを使用したり、あるいは Github 上でオンラインでさまざまなアクションを実行したりすることができます。

後述するように、RStudio の Terminal ペイン（R コンソールの隣にあるタブ）や Git Bash ターミナルなどのターミナルに Git コマンドを書き込まなければならないこともあります。

Github アカウント

github.com で無料のアカウントを登録します。

携帯電話のアプリで 2 要素認証を設定するように表示されることがあります。詳しくは、Github の ヘルプドキュメント をご覧ください。

Github Desktop を使用している場合は、インストール後に以下の 手順 に従って Gitub の認証情報を入力することができます。認証情報を登録しておかないと、後で Github からプロジェクトをクローンしようとしたときに認証情報を求められます。

46.4 用語と概念と基本機能

R を学ぶときのように、Git を理解するためにはかなりの量の用語を覚えなければなりません。 ここでは、Basics to get you going / interactive tutorialを参照してください。 次のセクションでは、GUI の使い方を紹介しますが、前提概念を理解するためにも、GUI を使うときにも必要になるので、このセクションで用語や概念を覚えておくといいでしょう。

リポジトリ

Git のリポジトリ（repo）とは、プロジェクトのすべてのサブフォルダーやファイル（データ、コード、画像など）とそれらの変更履歴を含むフォルダーのことです。リポジトリの変更を追跡するようになると、Git はすべての追跡情報を含む隠しフォルダを作成します。典型的な Git リポジトリは、R プロジェクトフォルダーです（ハンドブックの R プロジェクトの設定 の章を参照）。

次のセクションでは、Github、Github Desktop、または RStudio からGit リポジトリを作成（inittialize）する方法を紹介します。

コミット

コミット（commit）とは、ある時点でのプロジェクトのスナップショットです。プロジェクトに変更を加えた場合、ファイルに加えられた変更（差分）を追跡するために、新しいコミットを作成します。例えば、何行かのコードを編集し、関連するデータセットを更新したとします。変更が保存されると、これらの変更を 1 つの「コミット」に束ねることができます。

各コミットには固有の ID（ハッシュ）があります。バージョンコントロールの目的では、コミットに基づいてプロジェクトを過去に戻すことができるので、比較的小さくまとまったものにしておくとよいでしょう。また、「コミット・メッセージ」と呼ばれる変更内容の簡単な説明を添付します。

ステージされた変更とは？変更をステージするとは、次のコミットに備えて、変更をステージ・エリアに追加することです。これは、あるコミットにどの変更を含めるかをきめ細かく決められるということです。例えば、あるスクリプトでモデルの仕様を作成し、その後別のスクリプトで図を作成した場合、2 つの異なるコミットを作成することは理にかなっています（モデルではなく図の変更を戻したい場合に簡単にできます）。

ブランチ

ブランチは、リポジトリ内の変更点の中でも独立したラインとして表され、プロジェクトファイルの並行した別バージョンを意味します。

ブランチは、変更内容を main ブランチに反映させる前にテストするのに便利です。main ブランチは、通常、プロジェクトの主要/最終/ライブバージョンです。ブランチでの実験が終わったら、その変更を main ブランチにマージして取り込むことができますし、変更がうまくいかなかった場合はブランチを削除することもできます。

注：ブランチを使う際に他の人と共同作業をする必要はありませんし、リモートのオンラインリポジトリがある必要もありません。

ローカルとリモートのリポジトリ

クローンとは、Git リポジトリのコピーを別の場所に作成することです。

例えば、Github からオンラインリポジトリをパソコンにクローンしたり、ローカルリポジトリから始めてオンラインで Github に クローンすることができます。

リポジトリをクローンすると、プロジェクトファイルは 2 つの場所に存在することになります。

  • あなたの物理的なコンピュータ上の ローカル リポジトリ。ここで、ファイルやコードに実際の変更を加えます。

  • リモート、オンラインリポジトリ：Github リポジトリ（またはその他のウェブホスト）にあるプロジェクトファイルのバージョン。

これらのリポジトリを同期させるためには、より多くの機能を使うことになります。Sharepoint や Dropbox その他の同期ソフトウェアとは異なり、Git は自動的にオンラインのものに基づいてローカルのリポジトリを更新したり、その逆を行ったりしません。いつ、どのように同期させるかは、あなたが決めることです。

  • git fetch は、リモートリポジトリから新しい変更点をダウンロードしますが、ローカルリポジトリは変更しません。リモートリポジトリの状態をチェックしていると考えてください。

  • git pull は、リモートリポジトリから新しい変更点をダウンロードして、ローカルリポジトリを更新します。

  • ローカルで 1 つまたは複数のコミットを行った後、そのコミットをリモートリポジトリに git push できます。これにより、変更が Github 上に送信され、他の人が変更点を確認したり、必要に応じてプルできます。

46.5 始める: 新規リポジトリを作成

新規リポジトリを作成する方法はたくさんあります。コンソールからでも、Github からでも、GUI からでも可能です。

2 つの方法があります。

  • 既存または新規の Github リポジトリから新規 R プロジェクトを作成する (初心者の方にお勧めです)。または
  • 既存の R プロジェクトに Github リポジトリを作成する。

最初に作成するファイル

新規リポジトリを作成する際に、オプションで以下のファイルをすべて作成することもできますし、後からリポジトリに追加することもできます。これらのファイルは通常、リポジトリの “root” フォルダーに置かれます。

  • README ファイルとは、あなたのプロジェクトがなぜ存在するのか、そしてそれを使うために何を知っておくべきなのかを理解するために、誰かに読んでもらうためのファイルです。最初は空ですが、後で完成させましょう。

  • .gitignore ファイルとは、Git が無視すべき (変更を追跡しない) フォルダやファイルを各行に記述したテキストファイルのことです。詳細や例は こちら を参照ください。

  • 自分の作業に対して、ライセンスを選ぶことができます。他の人々は、どのような条件であなたの成果を使用したり複製したりできるかを知ることができます。詳しくは、Creative Commons licensesをご覧ください。

Github で新規リポジトリを作成する

新規リポジトリを作成するには、Github にログインし、新規リポジトリを作成する緑色のボタンを探してください。新規の空リポジトリは、ローカルコンピュータにクローンできます（次のセクションを参照）。

リポジトリを public （インターネット上で誰でも見ることができる）にするか private （許可を得た人だけが見ることができる）にするかを選択する必要があります。これは、データが機密である場合に重要な意味を持ちます。リポジトリがプライベートの場合、Github actions を使ってコードをクラウド上で自動的に実行する場合など、高度で特別な状況では、いくらかの課金が発生します。

Github リポジトリからのクローン

既存の Github リポジトリをクローンして、コンピュータ上に新規ローカル R プロジェクトを作成することができます。

Github リポジトリは、すでに存在していてコンテンツが含まれているものでも、作成したばかりの空のリポジトリでもよいです。後者の場合、基本的には Github リポジトリとローカル R プロジェクトを同時に作成することになります（上記の説明を参照）。

注釈：Github リポジトリのコントリビュート権を持っていない場合は、まずそのリポジトリを自分のプロファイルに フォーク (fork)してから、他の作業を進めることができます。フォークについては本章の最後で説明しますが、まずは他のセクションをお読みになることをお勧めします。

ステップ1： Github でリポジトリに移動し、緑色の “Code” ボタンをクリックして、HTTPS クローン URL をコピーします（以下の画像を参照）。

次のステップは、どのような GUI でも実行できます。ここでは、RStudio と Github デスクトップを例に説明します。

RStudio の場合

RStudio で、File > New Project > Version Control > Git をクリックして、新規 R プロジェクトを開始します。

  • “Repository URL” を聞かれたら、Github から HTTPS URL を貼り付けます。
  • R プロジェクトに短くてわかりやすい名前をつけます。
  • 新規 R プロジェクトをローカルに保存する場所を選択します。
  • “Open in new session” にチェックを入れ、“Create project” をクリックします。

これで、Github リポジトリのクローンである、新規のローカル RStudio プロジェクトが開きました。また、このローカルプロジェクトと Github リポジトリがリンクされました。

Github Desktop の場合

  • File > Clone a repository をクリックします。
  • URL タブを選択します。
  • 最初のボックスに Github からの HTTPS URL をペーストする。
  • ローカルリポジトリを作成するフォルダを選択する。
  • “CLONE” をクリックする。

既存の R プロジェクトからの新規 Github リポジトリの作成

別の設定方法として、コンテンツを含む既存の R プロジェクトがある場合、ここから Github リポジトリを作成します。

  1. プロジェクトのために、新規の空 Github リポジトリを作成します（上記の手順を参照）。
  2. このリポジトリをローカルにクローンします（上記の HTTPS の手順を参照）。
  3. 既存の R プロジェクトからすべてのコンテンツ（コード、データなど）を、この新規の空ローカルリポジトリにコピーします（例：コピー＆ペーストを使用）。
  4. RStudio で新規プロジェクトを開き、Git ペインに移動します。新規ファイル群はファイルの変更として登録され、Git によって追跡されるようになります。したがって、これらの変更をコミットとして束ねて、Github にプッシュできます。一旦プッシュすると、Github 上のリポジトリにすべてのファイルが反映されます。

このプロセスの詳細については、以下の Github のワークフローのセクションを参照してください。

どのように見えますか？

RStudio の場合

Github リポジトリを新規 R プロジェクトにクローンすると、RStudio に “Git” タブが表示されます。このタブは、R Environment と同じ RStudio のペインに表示されます。

上の画像で丸で囲ったボタンは、後に参照するので注意してください（左から順に）。

  • 保存したファイルの変更をローカルブランチに Commit するボタン（新しいウィンドウが開きます）。
  • 青色の矢印で Pull （ローカル版のブランチに、そのブランチのリモート / Github 版で行われた変更を反映させる）
  • 緑の矢印で Push (ローカルバージョンのブランチのコミットや変更を、そのブランチのリモート / Github バージョンに送信)
  • RStudio の Git タブ
  • 右側に表示されているローカルブランチをベースにして、新しいブランチを作成するためのボタン。ほとんどの場合、main ブランチからブランチを作成します。
  • 現在作業しているブランチ
  • コードや他のファイルに加えた変更は、以下のように表示されます。

Github Desktop の場合

Github Desktop は、すべてのリポジトリを管理するための独立したアプリケーションです。Github Desktop を開くと、作業したいリポジトリを選択して、そこから Git の基本的な操作を行うことができます。

46.6 Git + Github 作業の流れ

流れの概要

上記のセットアップが完了すると、ローカルの R プロジェクトに接続された（クローンされた）Github レポジトリができあがります。(デフォルトで作成される) main ブランチは、いわゆる “live” バージョンで、 すべてのファイルが含まれています。修正を加えたいときには、main ブランチから new branch を作成するのがよいでしょう (“Make a Copy” のように)。 ブランチの作成は簡単で速く、Git の典型的な作業の進め方になります。

典型的な作業の流れは次のとおりです。

  1. ローカルリポジトリが最新であることを確認し、そうでない場合は更新します

  2. 以前作業していたブランチに移動するか、新しいブランチを作成していくつかのことを試してみます

  3. ローカルコンピュータでファイルを編集し、このブランチに 1 回または数回コミットします

  4. ブランチのリモートバージョンに対し、あなたの変更で更新します（プッシュ）

  5. ブランチに満足したら、作業用ブランチのオンライン版をオンラインの “main” ブランチにマージして、変更を移行します

他のチームメンバーも、各々のブランチで同じことをしているかもしれませんし、あなたと同じ作業ブランチにコミットを追加しているかもしれません。

以下では、上記のプロセスを順を追って詳しく説明します。ここでは、私たちが作成した概略図を紹介します。二元配置の表形式になっているので、疫学業務担当者にも理解しやすいでしょう。

ここに別の図があります。

注釈：最近まで “master” ブランチという言葉が使われていましたが、現在は “main” ブランチと呼ばれています。

画像ソース

46.7 新規ブランチを作成

作業するブランチを選択すると、Git は作業ディレクトリを、前回、選択したブランチで作業したときの状態にリセットします。

RStudio の Git ペインの場合

“main” ブランチにいることを確認し、紫のアイコンをクリックして新しくブランチを作成します（上の画像を参照）。

  • ブランチの名前を、一言で説明できる名前にするよう求められます（必要に応じてアンダースコアを使用できます）。
  • ローカルでは、同じ R プロジェクトに属していますが、“main” ブランチでの作業ではなくなっていることがわかります。
  • 新規ブランチを作成すると、Github のウェブサイトでもブランチとして表示されるようになります。

ブランチは、RStudio の Git ペインで History をクリックすると表示されます。

Github Desktop の場合

このプロセスは上記と非常によく似ており、ブランチに名前を付けるよう促されます。その後、“Publish you branch to Github” というプロンプトが表示され、新規ブランチがリモートリポジトリにも表示されるようになります。

Console の場合

舞台裏で実際に行われているのは、git branch で新しくブランチを作成し、git checkout でそのブランチに移動することです (つまり、次のコミットがそのブランチで行われることを Git に伝えます)。あなたの git リポジトリで以下のコマンドを実行することと等しいです。

git branch my-new-branch  # 新規にブランチを作成
git checkout my-new-branch # 作成したブランチに移動
git checkout -b my-new-branch # 上の 2 つを同時に行う

Console の使い方については、末尾の Git コマンドの項を参照してください。

46.8 変更をコミット

これで、コードの編集や新規ファイルの追加、データセットの更新などができるようになりました。

すべての変更は、それぞれのファイルが保存された時点から追跡されます。変更されたファイルは RStudio の Git タブ、Github Desktop、またはターミナルの git status コマンドで表示されます (下記参照)。

実質的な変更 (コードへセクションの追加や更新など) を行った場合は、必ず一旦作業を停止して、その変更をコミットしてください。コミットとは、共通の目的に関連した変更の「カタマリ」と考えてください。変更をコミットした後でも、ファイルの修正を続けることは可能です。

コミットに関するアドバイス: 一般的には、問題が発生したときに簡単に元に戻せるような小さなコミットを行い、共通の目的に関連する変更をまとめてコミットするのが良いでしょう。これを実現するためには、頻繁にコミットすることが必要です。最初のうちは、頻繁にコミットすることを忘れてしまうかもしれませんが、そのうちに習慣になります。

RStudio の場合

以下の例では、前回のコミット以降、R Markdown スクリプト「collaboration.Rmd」が変更され、いくつかの PNG 画像が追加されています。

ファイル名の横にある黄色、青、緑、赤の四角は何を表しているのか気になりますよね。下記が、RStudio cheatsheet からのスクリーンショットで、その意味を説明しています。なお、黄色の「？」がついた変更でも、ステージ、コミット、プッシュは可能です。

  • Git タブの “Commit” ボタンを押すと、新しいウィンドウが開きます（下図）。

  • 左上のボックスにあるファイル名をクリックします。

  • そのファイルに加えた変更を確認します（以下、緑または赤でハイライトされる）

  • ファイルをステージすると、その変更がコミットに反映されます。ファイル名の横にあるボックスにチェックを入れてください。あるいは、複数のファイル名をハイライトしてから “Stage” をクリックすることもできます。

  • 短くてわかりやすい コミット・メッセージを書く（必須）

  • “Commit” ボタンを押します。成功またはエラーメッセージを示すポップアップ・ボックスが表示されます。

これで、さらに変更を加え、何度でもコミットすることができます。

Github Desktop の場合

左側に変更されたファイルのリストが表示されます。テキストファイルを選択すると、右ペインに変更内容の概要が表示されます（この表示は、.docs や .xlsx などの複雑なファイルでは機能しません）。

変更をステージするには、ファイル名の近くにある小さなボックスにチェックを入れます。このコミットに追加したいファイルを選択し、コミットに名前を付け、必要に応じてメッセージを付けて commit ボタンをクリックします。

Console の場合

舞台裏では、ファイルを選択/ステージするための git add と、実際にコミットを行うための git commit という 2 つの機能が使われています。

git status # 変更を見る

git add new_pages/collaboration.Rmd  # コミットするファイルを選択 (= 変更をステージ)

git commit -m "Github Desktop からコミットについて記述メッセージ" # メッセージをつけて変更をコミット

git log  # 過去のコミットの情報を表示

過去のコミットを修正

ある変更をコミットして作業を続けているうちに、（あなたの考えでは）過去のコミットに「属する」べき変更を行ったことに気付いた場合、どうなるでしょうか。 心配ありません。これらの変更は、前のコミットに追加することができます。

RStudio では、COMMIT ボタンと同じ行に “Amend previous commit” ボックスがあるので、とてもわかりやすいはずです。

理由は不明ですが、Github Desktop ではこの機能は実装されていません。コミットはしたが、まだプッシュはしていない場合、COMMIT ボタンのすぐ下に “UNDO” ボタンが表示されます。このボタンをクリックすると、コミットを元に戻すことができます（ただし、ステージされたファイルと コミット・メッセージは保持されます）。 変更内容を保存し、必要に応じて新規ファイルをコミットに追加し、再度コミットします。

Console では

git add [YOUR FILES] # 変更をステージ

git commit --amend  # 以前のコミットを修正

git commit --amend -m "コミット・メッセージの更新"  # 以前のコミットを修正「かつ」コミット・メッセージを更新

注釈: すでに公開されており他の共同作業者と共有しているコミットを変更する前に、もう一度考えましょう。

46.9 プルしてから、変更を Github にプッシュ

「まずプルしてからプッシュする」

プロジェクトに取り掛かる前にフェッチしてプルし、ローカルコンピュータ上のブランチバージョンをリモート/Github バージョンで行われた変更に更新するのは良い習慣です。 プルは頻繁に行いましょう。躊躇することはありません。プッシュする前に必ずプルしましょう。

変更が完了してコミットし、プロジェクトの状態に満足したら、コミットした内容をブランチのリモート/Github バージョンにプッシュします。

リポジトリで作業している間は、この作業を繰り返します。

注釈: リモートリポジトリにプッシュされた変更(そしておそらく他の人が既にプルした変更)を元に戻すよりも、コミットされたがプッシュされていない（つまりローカルに残っている）変更を元に戻す方がはるかに簡単なので、作業していたタスクの変更が終わった後でプッシュすると良いでしょう。

RStudio の場合

PULL - まず、フェッチとプルを同時に行う “Pull” アイコン（下向き矢印）をクリックします。

PUSH - 緑色の “Push” アイコン（上向き矢印）をクリックします。Github のユーザー名とパスワードの入力を求められることがあります。最初に尋ねられたときには、2 つの Git コマンドラインを Terminal に入力する必要があるかもしれません。

  • git config –global user.email “” （Github アカウントのメールアドレス）を設定

  • git config –global user.name “Github ユーザー名”

これらのコマンドの入力方法については、以下の Git コマンドのセクションを参照してください。

ヒント： パスワードの入力を頻繁に求められますか？SSH キーを使ってリポジトリに接続するには、このチュートリアルの 10 章と 11 章を参照してください（より複雑です）

Github Desktop の場合

“Fetch origin” ボタンをクリックすると、リモートリポジトリに新しいコミットがあるかどうかを確認できます。

Git がリモートリポジトリで新しいコミットを見つけると、このボタンは “Pull” ボタンに変わります。プッシュとプルに同じボタンが使われるので、事前にプルしておかないと変更をプッシュできません。

“History” タブ（“Changes” タブの近く）に行くと、すべてのコミット（自分のコミットと他の人のコミット）を見ることができます。これは、共同作業者が何をしたかを知るための良い方法です。 コミット・メッセージや説明文がある場合はそれを読み、diffペインを使って 2 つのファイルのコードを比較することができます。

すべてのリモートの変更がプルされ、少なくとも1つのローカルの変更がコミットされたら、同じボタンをクリックしてプッシュすることができます。

Console の場合

なななんと！コマンド名は fetch と pull と push です。

git fetch  # リモートに新しいコミットはあるか?
git pull   # リモートのコミットをローカルブランチに持ってくる
git push   # ローカルへのコミットをリモートにプッシュ

プルしたいがローカルで作業中である

この状況には時々遭遇します。 ローカルリポジトリで変更を加えたのに、リモートリポジトリにはあなたがプルしなかったコミットがあるという状況です。

あなたのローカルの変更が上書きされる可能性があるので、Git はプルを拒否します。自分の変更を維持するための戦略はいくつかあります。Happy Git with Rでよく説明されていますが、その中でも主なものは次の 2 つです。

  • 変更をコミットし、リモートの変更を取得して、それを取り込み、必要に応じて衝突を解決して (後述のセクションを参照ください)、すべてをオンラインにプッシュする
  • 変更を「スタッシュ」し、プルしてスタッシュを解除 (復元) してから、コミットして衝突を解決してプッシュする。

リモートでの変更に関連するファイルとローカルでの変更に関連するファイルが重なっていない場合は、Git は自動的にコンフリクトを解決することができます。

Github Desktop では、この操作をボタンで行うことができます。スタッシュするには、Branch > Stash all changes と進みます。

46.10 ブランチをメインブランチにマージ

変更が完了したら、その変更をメインブランチにマージする作業を始めましょう。状況に応じて、この作業を迅速に行うこともできますし、チームメイトを巻き込んで慎重にレビューや承認の手順を踏むこともできます。

Github Desktop でのローカル作業

Github Desktop を使ってローカルでブランチをマージすることもできます。まず、コミットを受け取る側のブランチ、つまり更新したい側のブランチに移動 (checkout) します。次に、メニューの Branch > Merge into current branch をクリックします。インポート元のブランチを選択するボックスが表示されます。

Console の場合

まず、変更を受け取るブランチに戻ります。これは通常は master ですが、別のブランチになることもあります。次に、作業中のブランチを master にマージします。

git checkout master  # master (あるいは、その他の branch) に戻る
git merge this_fancy_new_branch

このページでは、より高度なブランチ操作の例を示し、裏で何が起こっているかを少し説明しています。

Github でプル・リクエストの提出

2 つのブランチを誰にも知らせずにマージすることも可能ですが、master ブランチに統合する前に、複数の人でマージについて議論したり調査したりすることがあります。このプロセスを支援するために、Github ではマージに関する議論を行うための機能として、プル・リクエスト (pull request, PR) を提供しています。

プル・リクエスト（“PR”）とは、あるブランチを別のブランチにマージするためのリクエストです (「私の作業ブランチを “main” ブランチにプルしてほしい」というリクエストです)。 プル・リクエストには通常、複数のコミットが含まれます。プル・リクエストを受け入れてブランチにマージする前に、議論とレビューのプロセスが始まります。例えば、dplyr パッケージの githubでプル・リクエストの議論を読むことができます。

プル・リクエスト（PR）は、下図のように Web サイトから直接送信することも、Github Desktop から送信することもできます。

  • Github リポジトリ（オンライン）にアクセスします。
  • “Pull Requests” タブを表示し、“New pull request” ボタンをクリックします。
  • ドロップダウンメニューから、自分のブランチを main にマージするものを選択します。
  • プル・リクエストの詳細なコメントを書き、“Create Pull Request” をクリックします。

以下の画像では、“forests” というブランチが “main” にマージされるように選択されています。

これで、プル・リクエストが表示されるようになりました（以下の画像例）。

  • タブの “Files changed” を確認すると、“main” ブランチがマージされた場合にどのように変化するかがわかります。

  • 右側には、Github ID をタグ付けすることで、チームのメンバーにレビューを要求することができます。main にマージするためには承認するレビューが 1 つ必要になるようにリポジトリの設定をすることもできます。

  • プル・リクエストが承認されると、“Merge pull request” のボタンがアクティブになります。これをクリックします。

  • マージが完了したら、以下の手順でブランチを削除します。

コンフリクトの解決

2 人の人間が同じ行を同時に変更すると、マージ・コンフリクトが発生します。Git はどちらのバージョンを残すかの判断はしませんが、コンフリクトが発生している場所を探すのには役立ちます。慌てないでください。 ほとんどの場合は、簡単に解決できます。

例えば、Github の場合

マージでコンフリクトが発生したら、そのファイルをエディターで開いてください。コンフリクトは文字列で示されます。

<<<<<<< HEAD と ======= の間のテキストは、自分のローカルリポジトリから、======= と >>>>>>> の間のテキストはもう一方のブランチ (origin や main などのブランチ) から来ています。

どちらのバージョンのコードがいいかを決めて（あるいは、両方の変更点を含んだ 3 つ目のコードを書いて）、残りの部分を削除し、Git が付けたマーク (<<<<<<< HEAD, =======, >>>>>>> origin/master/your_branch_name) をすべて削除します。

そして、ファイルを保存し、ステージし、コミットします。これが、マージされたバージョンを「公式」にするためのコミットです。その後、プッシュすることを忘れないでください。

あなたと共同作業者の双方がプル＆プッシュを頻繁に行えば行うほど、コンフリクトは小さくなります。

注釈：Console での操作に慣れてきたら、もっと多くの高度な merge オプションがあります（例：空白を無視する、共同作業者に優先権を与えるなど）。

ブランチの削除

ブランチが master にマージされて不要になったら、そのブランチを削除することができます。

46.10.0.1 Github + RStudio

Github のリポジトリに行き、すべてのブランチを表示するボタンをクリックします（ブランチを選択するドロップダウンの横）。自分のブランチを見つけて、その横にあるゴミ箱アイコンをクリックします。ブランチの削除について詳しくはこちらをご覧ください。

必ず、あなたのコンピュータのローカルでブランチを削除してください。これは自動的には行われません。

  • RStudio から、main ブランチにいることを確認します。

  • RStudio の “Terminal”（R コンソールの隣のタブ）で Git コマンドの入力に切り替え、次のように入力します。git branch -d branch_name、ここで “branch_name” は削除するブランチの名前です。

  • Git タブを更新すると、ブランチは消えているはずです。

46.10.0.2 Github Desktop の場合

削除したいブランチをチェックアウトして、メニューの Branch > Delete で削除してください。

Fork

プロジェクトに貢献したいが権利がない場合や、個人的に使用するためにプロジェクトを更新したい場合には、 プロジェクトをフォークすることができます。フォークについての簡単な説明はこちらにあります。

Github で “Fork” ボタンをクリックします。

これでオリジナルのリポジトリがクローンされますが、あなたのプロファイルにもクローンされます。これで、Github 上に 2 つのバージョンのリポジトリが存在することになります。オリジナルのリポジトリは変更できませんが、クローンされたバージョンはあなたのプロファイルにあります。

次に、前述のセクションで説明した方法のいずれかを使って、オンラインリポジトリの自分のプロファイル上のバージョンをローカルコンピュータにクローンします。 その後、新規ブランチを作成し、変更を加えてコミットし、リモートリポジトリにプッシュします。

結果が十分だと判断したら、Github または Github Desktop からプル・リクエスト を作成して、元のリポジトリのオーナーやメンテナと会話を始めることができます。

公式リポジトリの最新のコミットが必要な場合は？

誰かが公式リポジトリに重要な変更を加え、それをあなたのクローンバージョンに含めたいとします。自分のフォークと公式リポジトリを同期させることは可能です。ターミナルを使うことになりますが、それほど複雑ではありません。 ほとんどの場合、次のことを覚えておく必要があります。

  • upstream = 公式リポジトリ、あなたが変更できなかったリポジトリ
  • origin = あなたの Github プロファイルにあるリポジトリのバージョン

このチュートリアル をお読みいただくか、以下の手順で進めてください。

まず、Git ターミナル（あなたのリポジトリ内）で次のように入力します。

git remote -v

upstream のリポジトリをまだ設定していない場合は、origin で始まる 2 行が表示されます。この行は、fetch と push が指すリモートリポジトリを示しています。覚えておいてほしいのは、origin は Github 上にある自分のリポジトリ示しているいうことです。例えば

ここで、新規リモートリポジトリを追加します。

git remote add upstream https://github.com/appliedepi/epiRhandbook_eng.git

ここでのアドレスは、Github がリポジトリをクローンしたときに生成するアドレスです (クローンについてのセクションを参照)。これで、4 つのリモート参照（ポインタ）ができています。

これで設定は完了したので、元の（upstream）リポジトリから変更を取得したいときはいつでも、更新したいブランチに行って（checkout）、以下コマンドを入力すればいいのです。

git fetch upstream # リモートリポジトリから新しいコミットを取得
git checkout the_branch_you_want_to_update
git merge upstream/the_branch_you_want_to_update  # upstream ブランチを自分のブランチにマージ
git push # 自分の remote リポジトリを更新

コンフリクトが発生した場合は、「コンフリクトの解決」で説明しているように、解決しなければなりません。

要約: フォークはクローンすることと同義ですが、Github サーバー側で行います。 残りの作業は、典型的な共同作業の流れに沿った実作業です（クローン、プッシュ、プル、コミット、マージ、プル・リクエストの提出…）。

注釈：フォークは概念であって Git コマンドではありませんが、Bitbucket など他のホストにもあります。

46.11 学んだこと

以下のことを学びました。

  • Git を設定して、自分のフォルダの変更を追跡する。
  • ローカルのリポジトリを、リモートのオンラインリポジトリに接続する。
  • 変更をコミットする。
  • ローカルとリモートのリポジトリを同期させる。

疫学業務担当者としての必要なことは、これだけでほぼ十分でしょう。私たちは通常、ソフトウェア開発者のような高度な使い方はしません。

しかし、もっと高度なことをしたい（あるいはする必要がある）場合、Git にはコミットの履歴を単純化したり、1 つまたは複数のコミットを戻したり、コミットを cherry-pick（訳注：いいとこ取り、cherry-pick はgit のコマンドの一つ）したりといった、より強力な機能があることを知っておいてください。 このようなことをすると、まるで魔法のように聞こえるかもしれませんが、すでに基本的な知識を身につけているので、知識を積み上げるすることが容易になるのです。

RStudio の Git ペインや Github Desktop は、初心者や日々の仕事での使用には適していますが、中級者や上級者向けの Git 機能への GUI は提供していないことに注意してください。 より完成度の高い GUI では、カーソル操作でより多くのことができるようになります（通常は、より複雑なレイアウトを犠牲にして）。

リポジトリの追跡にはどんなツールでも使うことができるので、たまに試してみたいときやあまり一般的ではない複雑な作業をするときには GUI をインストールし、それ以外のときにはシンプルな GUI を使うということも簡単にできるということを覚えておきましょう （たとえば、ほとんどの時間は Github Desktop を使い、特定の作業をするときには SourceTree や Gitbash に切り替えるなど）。

46.12 Git コマンド

おすすめの学習方法

Git のコマンドをインタラクティブなチュートリアルで学ぶには、このウェブサイトを参照してください。

コマンドを入力する場所

Git シェルでコマンドを入力します。

選択肢 1 RStudio で新しく Terminal を開くことができます。このタブは R Console の隣にあります。文字が入力できない場合は、“Terminal” の下のドロップダウンメニューをクリックし、“New terminal” を選択します。ドル記号 “$” の後の点滅しているスペースにコマンドを入力します。

選択肢 2 Git タブ（RStudio Environment ペインの近く）の青い「歯車」アイコンをクリックして、shell（コマンドを入力するターミナル）を開くこともできます。ドロップダウンメニューから “Shell” を選択します。新しいウィンドウが開くので、ドル記号 “$” の後にコマンドを入力します。

選択肢 3 右クリックして “Git Bash here” を開くと、同じようなターミナルが表示されます。Git Bash の見つけ方、必要な bash コマンドなど、初心者向けの情報をご紹介します。

サンプルコマンド

以下では、一般的な git コマンドをいくつか紹介します。これらのコマンドを使う際には、どのブランチがアクティブ (チェックアウト済み) なのかを覚えておきましょう。

以下のコマンドでは、<name> はブランチの名前を表します。 <commit_hash> は、特定のコミットのハッシュIDを表します。<num> は数字を表します。 < と > 記号は入力しないでください。

Git コマンド 内容
git branch <name> 新規にブランチ <name> を作成
git checkout <name> ブランチ <name> に移動
git checkout -b <name> 新規にブランチを作成し移動
git status 変更を見る
git add <file> ファイルをステージ
git commit -m <message> 現在のブランチにステージされた変更をメッセージ付きでコミット
git fetch リモートリポジトリからコミットをフェッチ
git pull 現在のブランチのリモートリポジトリからコミットをプル
git push ローカルのコミットをリモートにプッシュ
git switch git checkout と同じ、今後はこちらに移行
git merge <name> ブランチ <name> を現在のブランチにマージ
git rebase <name> 現在のブランチから <name> へのコミットを修正

46.13 参考資料

この章の多くは、Jenny Bryan 氏によるこの “Happy Git with R”ウェブサイトを参考にしています。このウェブサイトには、Git や R に関連する一般的なエラーのトラブルシューティングに役立つセクションが用意されています。

Github.com documentation and start guideをご覧ください。

RStudio の “IDE” cheatsheet には、RStudio での Git に関するヒントがあります。

https://ohi-science.org/news/github-going-back-in-time

初心者のための Git コマンド

Git コマンドを学ぶためのインタラクティブチュートリアル。

https://www.freecodecamp.org/news/an-introduction-to-git-for-absolute-beginners-86fa1d32ff71/: 自分のコンピュータ上の 1 つのフォルダの変更を追跡するための絶対的な基本を学ぶのに適しています。

ブランチを理解するための良い図解があります。https://speakerdeck.com/alicebartlett/git-for-humans

基本的なことからより高度なことまでをカバーするチュートリアル

https://tutorialzine.com/2016/06/learn-git-in-30-minutes

https://dzone.com/articles/git-tutorial-commands-and-operations-in-git https://swcarpentry.github.io/git-novice/ (ショートコース) https://rsjakob.gitbooks.io/git/content/chapter1.html

Pro Git book は、公式のリファレンスとされています。 いくつかの章は大丈夫でしょうが、おおむね 技術的な内容になっています。Git を少し使ってみて、何が起こっているのか、どうすればいいのかをもう少し正確に知りたいと思ったら、この本はいい資料になるでしょう。