Content from 自動的なバージョン管理
最終更新日：2024-09-30 | ページの編集
所要時間： 5分
概要
質問
- バージョン管理とは何で、なぜそれを使うべきなのでしょうか?
目的
- 自動バージョン管理システムの利点を理解しましょう。
- 自動バージョン管理システムの仕組みの基本を理解しましょう。
それではまず、どのようにしてバージョン管理システムが 「いつ」、「何」を、「誰」が編集したのかを記録・管理しているかを見ていきましょう。 他の人と共同作業をしていなくても、 以下の状況に陥るより、自動的なバージョン管理を使うほうが大分良いはずです：
皆さんもこんな経験をされたことがあるはずです。複数の、（それもほとんど 内容が同じの）文書のコピーを保存しておくのは馬鹿げたことです。 文書作成ソフトの中には、例えばMicrosoft Wordの変更履歴、Google Docsのバージョン履歴、LibreOfficeの変更の記録・表示、こういった状況にある程度うまく対応できるものもあります。
バージョン管理システムは、基礎となるドキュメントを元に、 加えられた全ての変更点を記録していきます。 バージョン管理システムは、基礎となるドキュメントを元に、 加えられた全ての変更点を記録していきます。ドキュメントの 進歩を記録していると考えてもらって構いません。変更点を最初の状況まで 戻してから、最新版になるまでの変更を一つずつ再現していくことができます。
「変更点」と「ドキュメント」を別々の物として考えてみると、基礎となるドキュメントに 異なる変更点を「再現」する事によって、結果的に違ったバージョンのドキュメントを 作る事が可能だという事が分かります。 例えば、下の図のように二人のユーザーが同じドキュメントに違った編集を加えた場合です。
変更点の衝突（コンフリクト）が無ければ、二つ以上の違った変更点を基礎ドキュメントに加えることさえできます。
バージョン管理システムは、ユーザーがドキュメントに加えた変更点を記録するツールであり、 結果的にドキュメントの違ったバージョンを作成する事ができます。 このツールを活用 する事によって、次のバージョンに加える変更点（個々の変更点は 「commit（コミット）」と呼びます）を決める事ができ、変更点に関するメタデータも一緒に保存する事ができます。 特定のプロジェクトのコミット履歴とそれに関するメタデータを総じて 「repository（リポジトリ）」と呼びます。 リポジトリは 別々のコンピュータと同期させる事が出来るので、他人との共同作業を潤滑に進めることが可能になります。
バージョン管理システムの長い歴史
自動化されたバージョン管理システムは最近発明されたものではありません。 RCS、CVS、Subversionなどのツールは1980年前半から存在しており、多くの会社に使われていました。 しかし、これらのツールでは出来る事に制限があり、多くはもう時代遅れとされています。 現代使われているシステム、例えばGitやMercurial、は _分散_されています。というのは、特定のサーバーを必要とせずにシステムをホストする事が出来るという事です。 現代のシステムには大変便利で効果的な「merge（マージ）」機能が備われており、同じファイルを 複数人で作業する事が可能になりました。
論文を書くにあたって
例えば、論文のために数百行書いたとします。しばらくして、間違えてその文章を編集してしまいます。 どうしたら以前書いた文章を取り戻すことができるのでしょう？ そもそも、可能なのでしょうか？
五人の共著者がいるとします。 どうやって全員の変更やコメントを管理すれば良いのでしょう？ LibreOffice WriterやMicrosoft Wordの場合、こういった変更やコメントを変更履歴機能で受け入れると どうなるのでしょう？ 変更点は記録されるのでしょうか？
以前書いた数百行の回復は、古いバージョンの論文のコピーを作成した場合にのみ可能です。 前に書いた文章を失う危険性は、このページの上にある漫画に描かれているような問題のあるワークフローになることが多いです。
従来のワープロを使った共同執筆は面倒です。 すべての共同作業者が文書に順番に書く（執筆のプロセスを遅らせる）か、一つのバージョンをすべての全員に送り、手作業で彼らのコメントをあなたの文書にマージしなければなりません。 「変更の追跡」または「変更の記録」オプションは、変更をハイライトし、マージを簡略化することができますが、変更を受け入れるとすぐにその履歴が失われます。 そうなると、誰がその変更を提案したのか、なぜそれが提案されたのか、いつ文書にマージされたのか、わからなくなります。 Google DocsやMicrosoft Office Onlineのようなオンライン・ワープロでさえ、こうした問題を完全に解決することはできません。
まとめ
- バージョン管理とは、制限無く「元に戻す」ことができる機能。
- バージョン管理を使えば、複数の人と同時進行で作業をする事ができます。
Content from Gitの設定
最終更新日：2024-06-06 | ページの編集
所要時間： 5分
概要
質問
- Git を使うために必要な設定は何ですか？
目的
- コンピュータで初めて
gitを使うための設定が出来るようになりましょう。 -
--global設定フラグの意味を理解しましょう。
Git を新しいパソコンで初めて使う場合、いくつかの設定を変更しなければなりません。 Git を始めるにあたって、私達が変更する設定をいくつか表記します：
- 名前とメールアドレス、
- 使用したいテキストエディタ、
- 以上の設定をグローバル設定として使う（つまり、全てのプロジェクトに反映させる）。
コマンドラインでは、Git コマンドは
git <動詞> <オプション>
と入力します。ここでの「動詞」は、Git
に何をさせたいのかを表し、「オプション」はその動詞にとって必要とされる追加の情報です。
ドラキュラが新しいユーザーの場合、以下のようにコンピュータを設定します：
BASH
$ git config --global user.name "Vlad Dracula"
$ git config --global user.email "vlad@tran.sylvan.ia"ここでは、ドラキュラの代わりに自分の名前とメールアドレスを使いましょう。 ここで入力した名前とメールアドレスは、これから行う Git での作業に関わってきます。というのも、これからのレッスンでGitHub、BitBucket、GitLab、またはその他のGit をホストするサーバーに変更箇所を「プシュ」した（送った）際に、これらの情報が使われるからです。
これらのレッスンでは、GitHub に接続するので、GitHub アカウントと同じメールアドレスに設定してください。 プライバシーについて気になる方は、GitHub のメールアドレスをプライベートにするための説明 を参照してください。
電子メールの非公開
GitHubでプライベートメールアドレスを使用する場合は、GitHubのno-replyメールアドレスをuser.emailの値として使用してください。
それは、ID+username@users.noreply.github.comの形式になります。
自分のアドレスはGitHubのメール設定で確認できます。
改行コード
他のキーと同様に、キーボードで Enter または ↵ （またはMacでは Return）を押すと、コンピュータはそれを文字として入力します。 話が長くなるので詳しい説明は省きますが、行末に使われる文字はオペレーティングシステム（OS）よって違います。 （行末に使われる文字を「改行コード」と呼びます。） Git は、改行コードを使ってファイルの違いを確かめるため、違うパソコンでファイルを編集した時に思わぬ問題が起こるかもしれません。 このレッスンの範囲外ですが、この問題については Pro Git book を読んでください。
Git がどのように改行コードを理解・変換するかは、
git config の core.autocrlf
コマンドを使って変更できます。 以下の設定をおすすめします：
macOS および Linux:
またはWindowsの場合:
以下の表を参考に、ドラキュラはテキストエディタも設定しました：
| エディタ | 設定コマンド |
|---|---|
| Atom | $ git config --global core.editor "atom --wait" |
| nano | $ git config --global core.editor "nano -w" |
| BBEdit（Mac、コマンドラインツール付き） | $ git config --global core.editor "bbedit -w" |
| Sublime Text (Mac) | $ git config --global core.editor "/Applications/Sublime\ Text.app/Contents/SharedSupport/bin/subl -n -w" |
| Sublime Text (Win、32ビットインストール) | $ git config --global core.editor "'c:/program files (x86)/sublime text 3/sublime_text.exe' -w" |
| Sublime Text (Win、64ビットインストール) | $ git config --global core.editor "'c:/program files/sublime text 3/sublime_text.exe' -w" |
| メモ帳（Win） | $ git config --global core.editor "c:/Windows/System32/notepad.exe" |
| Notepad++ (Win、 32 ビットインストール) | $ git config --global core.editor "'c:/program files (x86)/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin" |
| Notepad++ (Win、 64 ビットインストール) | $ git config --global core.editor "'c:/program files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin" |
| Kate (Linux) | $ git config --global core.editor "kate" |
| Gedit (Linux) | $ git config --global core.editor "gedit --wait --new-window" |
| Scratch (Linux) | $ git config --global core.editor "scratch-text-editor" |
| Emacs | $ git config --global core.editor "emacs" |
| Vim | $ git config --global core.editor "vim" |
| VS Code | $ git config --global core.editor "code --wait" |
設定したテキストエディタもいつでも変更することができます。
Vim の終了の仕方
多くのソフトの初期設定では、Vim
がデフォルトのテキストエディタに設定されています。 保存せずに Vim
を終了するには、Escを押した後に :q!
と入力してからEnterまたは↵（Macの場合はReturn）を押してください。
保存してから終了するには、Escを押してから :wq
と入力してEnterまたは↵（Mac の場合は
Return）を押してください。
Git (2.28以上)
では、新しいリポジトリを初期化したときに作成されるブランチの名前を設定できます。
ドラキュラはその機能を使って、最終的に使うクラウドサービスと一致するようにmainに設定することにします。
Gitブランチ名の設定
ソースファイルのどんな変更でも、ある「ブランチ」に属しています。
このレッスンの新しい学習者にとっては、ブランチが存在し、このレッスンでは1つのブランチを使うことを知っていれば十分です。
デフォルトでは、git init
で新しいリポジトリを作成すると、Git がmaster
というブランチを作成します (次のエピソードで説明します)。 この用語は、
人身売買という人種差別的慣習を想起させ、 ソフトウェア開発コミュニティ
は、 より包括的な言葉を採用するように動いています。
2020年には、ほとんどのGit
ホスティングサービスは、mainをデフォルトの
ブランチとして使うように移行しました。 例として、GitHub やGitLab
で新規に開いたリポジトリのデフォルトは mainです。
しかし、Gitはまだ同じ変更を行っていません。
その結果、ローカル・リポジトリは、ほとんどのクラウド・サービスと同じブランチ名を手動で設定する必要があります。
2.28より前のバージョンのGitでは、個々のリポジトリで変更が可能です。
そのためのコマンドは次回のエピソードで紹介します。 ローカルのGit
の設定でこの値が設定されていない場合、init.defaultBranch
のデフォルト値は master になることに注意しましょう。
上記の5つのコマンドは、一度実行するだけで十分です。--global
フラグは Git に、
今使っているパソコン内にある自分のアカウントに関連する全てのプロジェクトに同じ設定をするように指示しています。
さっそくこれらの設定を確認し、core.editorをテストしてみましょう：
追加の変更を加えずにファイルを閉じましょう。 設定ファイルのタイプミスは問題を引き起こすため、以下のように設定を表示する方が安全です。
また、必要であれば、同じコマンドを使えば、違うエディタやメールアドレスに変えることができます。 これは何度でもできます。
プロキシ
ネットワーク環境によってはプロキシ を使わなければならないかもしれません。 この場合、プロキシの設定が必要です：
プロキシを無効にするには：
Git のヘルプとマニュアル
git のコマンドを忘れた時は、-h
を使えばコマンドの一覧を、--help
を使えばマニュアルを見ることができます：ある git
コマンドのサブコマンドやオプションを忘れてしまった場合は、
git <command> -h
とタイプすることによって関連するオプションのリストを見るか、git <command> --help
とタイプすることによって対応する Git
マニュアルを見ることができます：
マニュアルを見ている間、:はコマンドを待っているプロンプトであり、
Q
を押してマニュアルを終了できることを覚えておいてください。
より一般的には、利用可能な git コマンドのリストや、Git
マニュアルを入手することができます：
まとめ
-
git configと--globalオプションを使い、ユーザー名、メールアドレス、エディタ、その他の設定を行う。
Content from リポジトリの作成
最終更新日：2024-09-30 | ページの編集
所要時間： 10分
概要
質問
- Gitはどこに情報を格納しますか?
目的
- ローカルのGitリポジトリを作成する。
-
.gitディレクトリの目的を説明する。
Gitの設定ができたら、 それを使い始めることができます。
火星に惑星着陸船を送ることが可能かどうかを調査しているウルフマンとドラキュラの話に戻りましょう。
Werewolf
vs dracula by b-maze
/ Deviant Art. 火星
by European Space Agency / CC-BY-SA 3.0
IGO. 冥王星
/ Courtesy NASA/JPL-Caltech. ミイラ
© Gilad Fried / The Noun
Project / CC BY
3.0. 月 © Luc
Viatour / https://lucnix.be / CC BY-SA
3.0.
まず、Desktopフォルダーに作業用のディレクトリを作成し、そのディレクトリに移動しましょう:
次に、Gitにplanetsをリポジトリ（Gitがファイルのバージョンを保存できる場所）にするように伝えます。
重要なのは、git init
はサブディレクトリとそのファイルを含むことができるリポジトリを作成するということです。サブディレクトリが最初から存在する場合でも、後から追加された場合でも、planets
リポジトリの中に入れ子になった別のリポジトリを作成する必要はありません。
また、
planetsディレクトリの作成と、リポジトリとしての初期化はまったく別の処理であることに注意してください。
ls を使ってディレクトリの内容を表示すると、
何も変更されていないように見えます:
ですが -a フラグを追加してすべてを表示すると、Git が
.gitという隠しディレクトリを planets
の中に作ったことがわかります:
出力
. .. .gitGit
はプロジェクトのディレクトリ内にあるすべてのファイルとサブディレクトリを含む、プロジェクトに関するすべての情報を格納するためにこの特別なサブディレクトリを使用します。
.git
サブディレクトリを削除すると、プロジェクトの履歴を失うことになります。
次に、デフォルトのブランチを main
という名前に変更します。
あなたの設定やgitのバージョンによっては、これが既にデフォルトになっているかもしれません。
この変更の詳細については、「セットアップ」
を参照してください。
出力
Switched to a new branch 'main'We can now start using one of the most important git commands, which
is particularly helpful to beginners. git status tells us
the status of our project, and better, a list of changes in the project
and options on what to do with those changes. We can use it as often as
we want, whenever we want to understand what is going on.
出力
On branch main
No commits yet
nothing to commit (create/copy files and use "git add" to track)使用しているgitのバージョンによって、出力の表現が少し異なるかもしれません。
Git リポジトリを作る場所
planets
（すでに作成したプロジェクト）についての情報を追跡すると共に、
ドラキュラは moons についての情報も追跡したいと考えています。
ウルフマンの心配にもかかわらず、ドラキュラは次の一連のコマンドを使って、彼の
planetsプロジェクト内に moons
プロジェクトを作ります:
BASH
$ cd ~/Desktop # Desktop ディレクトリに戻る
$ cd planets # すでに Git リポジトリである planets ディレクトリに移動する
$ ls -a # .git サブディレクトリがまだ planets ディレクトリに存在することを確認する
$ mkdir moons # サブディレクトリ planets/moons を作る
$ cd moons # moons サブディレクトリに移動する
$ git init # moons サブディレクトリをGitリポジトリにする
$ ls -a # .git サブディレクトリが存在し新しいGitリポジトリが作られたと示していることを確認するgit init コマンドは、moons
サブディレクトリ内で実行され、moons
サブディレクトリに保存されているファイルを追跡するために必要でしょうか?
いいえ。 ドラキュラは moons サブディレクトリを Git
リポジトリにする必要はありません。planets
リポジトリは、planets
ディレクトリの下のすべてのファイル、サブディレクトリ、およびサブディレクトリファイルを追跡するからです。
従って、moons
についてのすべての情報を追跡するのは、ドラキュラが moons
サブディレクトリをplanets
ディレクトリに追加するだけで済みます。
それと、Git
リポジトリが「入れ子」にされている場合、Gitリポジトリは互いに干渉する可能性があります：外側のリポジトリは内側のリポジトリのバージョン管理をしようとします。
したがって、新しいGitリポジトリはそれぞれ別のディレクトリに作るのがベストです。
ディレクトリに競合するリポジトリががないことを確認するには、git statusの出力を確認します。
次のような場合は、上の方で示したように新しいリポジトリを作ることをお勧めします：
出力
fatal: Not a git repository (or any of the parent directories): .git
git init の間違いを修正する
ウルフマンはドラキュラに、「入れ子」状態になっているリポジトリがいかに冗長で、混乱を引き起こす可能性があるかを説明しました。
Dracula would like to go back to a single git repository.
moonsサブディレクトリの最後のgit initを、ドラキュラはどうやって、元に戻すことができるのでしょうか？
背景
Gitリポジトリからのファイルの削除は、慎重に行う必要があります。 しかし、特定のファイルを追跡するようにGitに指示する方法については、まだ学んでいません（次のエピソードで学びます）。 Gitによって追跡されていないファイルは、他の「普通の」ファイルと同じように、次のようにして簡単に削除できます：
Similarly a directory can be removed using
rm -r dirname.
この方法で削除されるファイルやフォルダがGitによって追跡されているなら、次のエピソードで見られるように、それらの削除が、追跡する必要がある別の変更になります。
解答
Gitはすべてのファイルを.gitディレクトリに保存します。 To
recover from this little mistake, Dracula can remove the
.git folder in the moons subdirectory by running the
following command from inside the planets directory:
しかし、気をつけてください！
間違ったディレクトリでこのコマンドを実行すると、残しておきたいプロジェクトのGit履歴がすべて削除されてしまいます。
In general, deleting files and directories using rm from
the command line cannot be reversed. したがって、常に pwd
コマンドを使用してカレントディレクトリを確認してください。
まとめ
-
git initはリポジトリを初期化する。 - Gitはリポジトリデータのすべてを
.gitディレクトリに格納する。
Content from 変更内容の記録
最終更新日：2024-09-30 | ページの編集
所要時間： 20分
概要
質問
- どうやって変更点を Git で記録出来ますか？
- どうやってリポジトリの状態をチェック出来ますか？
- 何を変更して、なぜ変えたのかをメモするにはどうすればよいですか？
目的
- 一つ以上のファイルにおいて、「変更・追加・コミット」の作業を行いましょう。
- 「変更・追加・コミット」を行っている際、情報がどこに保管されているのか説明しましょう。
- わかりやすいコミットメッセージと、そうでないメッセージの違いを区別できるようになりましょう。
まずはじめに、正しいディレクトリにいるかどうか確かめましょう。
planets ディレクトリに入っているはずです。
赤い惑星（火星）が基地に最適かどうかについてのノートを書くためにmars.txt
というファイルを作成しましょう。 nano
（もしくは好きなテキストエディタ）でファイルを編集しましょう。 以前
core.editor
で設定したエディタとは別のエディタで編集しても大丈夫です。
ですが、新しくファイルを作成・編集するコマンドはエディタによって違うということを覚えておいてください（nano
ではないかもしれません）。 テキストエディタについて復習したい方は、Unix シェル の どのエディタ？
のレッスンを見てみてください。
以下の文を mars.txt に記入してください：
出力
Cold and dry, but everything is my favorite colorまず、listコマンド（ls）を実行して、ファイルが正しく作成されたことを確認しましょう：
出力
mars.txtこれで mars.txt
は一文だけ入ってる状態になりました。確認してみましょう：
出力
Cold and dry, but everything is my favorite colorプロジェクトの状態をもう一度確認してみると、 Git は新しいファイルがあることに気づきます：
出力
On branch main
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
mars.txt
nothing added to commit but untracked files present (use "git add" to track)“untracked files” （追跡されていないファイル）というメッセージは、
Git
が追跡していないファイルがこのディレクトリに存在していることを意味します。
git add を使って、Git
にこのファイルを追跡してもらいましょう： git add
を使って、Git にこのファイルを追跡してもらいましょう：
そして、正しく動作したか確認してみましょう：
出力
On branch main
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: mars.txt
これで Git は mars.txt
を追跡するように設定することができました。
ですが、まだ変更点をコミットとして記録していません。
これをするには、もう一つコマンドを使う必要があります：
出力
[main (root-commit) f22b25e] Start notes on Mars as a base
1 file changed, 1 insertion(+)
create mode 100644 mars.txtgit commit を使うと、 Git は git add
によって一時的に保存されたデータを .git
ディレクトリにコピー、そして永久保存します。 永久保存されたコピーを コミット （または リビジョン)）と呼び、f22b25e
はコミットの省略されたIDです。
あなたのコミットには別のIDが使われているかもしれません。
-m
フラグ（「メッセージ」の略）を使い、何を変えて、なぜ変えたのかが後からでも分かるように、簡潔で分かりやすいメッセージを書きましょう。
-m を使わずに git commit を使った場合、Git は
nano （または core.editor
として設定したエディタ）を開き、もっと長いメッセージを書くことができます。
良いコミットメッセージ
は、どのような変更が行われたのかが分かる短い文（50字以下）
で始まります。
大抵のメッセージは、「このコミットを適用すると・・
今の状態で git status を走らせると：
出力
On branch main
nothing to commit, working tree cleanといったように、最新の状態であることを教えてくれます。
つい先程、何をしたのかを見たい場合は git log を使って、 Git
にプロジェクトの履歴を表示してもらいましょう：
出力
commit f22b25e3233b4645dabd0d81e651fe074bd8e73b
Author: Vlad Dracula <vlad@tran.sylvan.ia>
Date: Thu Aug 22 09:51:46 2013 -0400
Start notes on Mars as a basegit log
は、リポジトリに施された全てのコミットを最新のものから順に表示します。
各コミットには、省略されていないコミットID（以前 git commit
で表示された省略IDと同じ字列で始まります）、コミットの著者、作成日時、そして、コミットが作られた時につけられたログメッセージが含まれています。
変更点は何処にあるの？
ここで ls を使用すると、mars.txt
ファイル一つしかありません。 なぜかと言うと、Git
はファイルの変更履歴を、以前触れた .git
という特別なディレクトリに保存します。これをする事によって、ファイルシステムが散らからないようにし、うっかり古いバージョンのファイルを変更、または削除できないようにしています。
それでは、ドラキュラがファイルに新しい情報を加えたとしましょう。
（以前と同様に、nano を使い、cat
でファイルの中身を表示させます。違うエディタを使ってもいいし、cat
を使わなくても構いません。）
出力
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfmangit status
を使うと、追跡しているファイルが変更されたことを知らせてくれます：
出力
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: mars.txt
no changes added to commit (use "git add" and/or "git commit -a")最後に表示された文が一番重要です：“no changes added to commit”
（「変更点はコミットに追加されていません」）。
私達はファイルを編集したのですが、まだ Git
にこの変更点を保存したいということを（git add
で）伝えていないし、それを（git commit
で）保存もしていません。 というわけで、これらをやってみましょう。
変更点を保存する前に見直すのは、習慣づけると良いでしょう。 見直すには
git diff を使いましょう。
これによって、今のファイルの状態と、一つ前までのファイルの状態との違いを確かめることができます：
出力
diff --git a/mars.txt b/mars.txt
index df0654a..315bf3a 100644
--- a/mars.txt
+++ b/mars.txt
@@ -1 +1,2 @@
Cold and dry, but everything is my favorite color
+The two moons may be a problem for Wolfmanすると、暗号のようなメッセージが出力されます。
これらのメッセージは、エディタや patch
といったプログラムで使われる
一連のコマンドで、ファイルをどうやって再構成するのかが書かれています。
分かりやすいように、一文ずつ見てみましょう：
- 最初の文は、Git が古いバージョンと新しいバージョンのファイルをUnix
の
diffコマンドと同じように、二つのファイルを比べていることを表しています。 - 次に、Git
が比べているファイルの正確なバージョンを表示しています。
df0654aと315bf3aはコンピュータが作成した、各バージョン”につけられたIDです。 - 3・4つ目の文章は、変更されているファイルの名前を表示しています。
- 残りの文章が一番重要です。ここに、何が変わり、どの行が変更されたのかが記されています。
特に、この
+マークは、どこに文章が加えられたのかを表しています。
変更点を確認したら、コミットしましょう：
出力
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: mars.txt
no changes added to commit (use "git add" and/or "git commit -a")おっと、 初めに git add を使わなかったので、 Git
はコミットさせてくれませんでした。 直しましょう：
出力
[main 34961b1] Add concerns about effects of Mars' moons on Wolfman
1 file changed, 1 insertion(+)Git は変更をコミットする前に、コミットしたいファイルを 追加するように要求してきます。 これによって、変更点をこまめに、そして論理的に分割して保存ができ、大きな変更をひとまとめに保存しなくてもよくなります。 例えば、論文にいくつか引用源を加えるとします。 これらの引用源、そして使われた参考文献の目録を、まだ書き終わっていない結論とは_別に_保存したい場合はどうすればいいのでしょう。
Git には、まだコミットされていないchangeset（一連の変更点）を一時的に保存・把握するために使われる、staging area（ステージング・エリア）と呼ばれる特殊な場所が存在します。
ステージングエリア
仮にGit
を、プロジェクトの一生の間に起こった変更内容を「スナップショット」として保存するものとして考えると、git add
は_何が_スナップショットに含まれる（ステージングエリアに入れる）のかを指定して、git commit
は_実際にスナップショットを撮り_、コミットとして永久保存します。
git commit
と入力した際にステージングエリアに何もなかった場合、Git
はgit commit -a もしくは git commit --all
を入力するように言ってきます。このコマンドは、写真を撮る時の「全員集合！」のようなもので、全ての変更点を強制的にコミットできます。
ですが、大抵は、コミットしたい変更点のみをステージングエリアに入れるほうが良いでしょう。これによって、不要な変更点を間違えてコミットすることもありません。
（集合写真の例に例えると、メイクの不完全なエキストラがステージの上を横断しているのを一緒に撮ってしまった、みたいなものです。）
ですので、ステージングエリアにどの変更点を入れるかは自分で管理しましょう。さもないと、必要以上に「git
コミットやり直す」で検索をかけることになるでしょう。
それでは、ファイルの変更点がエディタからステージングエリア、そして長期保存に移る過程を見てみましょう。 初めに、新しい文章をファイルに加えましょう：
出力
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
But the Mummy will appreciate the lack of humidity出力
diff --git a/mars.txt b/mars.txt
index 315bf3a..b36abfd 100644
--- a/mars.txt
+++ b/mars.txt
@@ -1,2 +1,3 @@
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
+But the Mummy will appreciate the lack of humidityいい感じです。
これでファイルの最後に新しく文章を足すことができました。 （左にある
+ マークで記されています。）
それでは変更点をステージングエリアに入れて git diff
がなにを表示するのかを見てみましょう：
何も表示されませんでした。Git が見た限りでは、保存したい変更点と今ディレクトリ内にあるファイルには、これといった違いは無いということになります。 ですが、こう入力すると：
出力
diff --git a/mars.txt b/mars.txt
index 315bf3a..b36abfd 100644
--- a/mars.txt
+++ b/mars.txt
@@ -1,2 +1,3 @@
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
+But the Mummy will appreciate the lack of humidity以前コミットされた状態のファイルとステージングエリアにある変更点の違いが表示されます。 変更内容を保存しましょう：
出力
[main 005937f] Discuss concerns about Mars' climate for Mummy
1 file changed, 1 insertion(+)状態をチェックしましょう：
出力
On branch main
nothing to commit, working tree cleanそして、今までの変更履歴も見てみましょう：
出力
commit 005937fbe2a98fb83f0ade869025dc2636b4dad5 (HEAD -> main)
Author: Vlad Dracula <vlad@tran.sylvan.ia>
Date: Thu Aug 22 10:14:07 2013 -0400
Discuss concerns about Mars' climate for Mummy
commit 34961b159c27df3b475cfe4415d94a6d1fcd064d
Author: Vlad Dracula <vlad@tran.sylvan.ia>
Date: Thu Aug 22 10:07:21 2013 -0400
Add concerns about effects of Mars' moons on Wolfman
commit f22b25e3233b4645dabd0d81e651fe074bd8e73b
Author: Vlad Dracula <vlad@tran.sylvan.ia>
Date: Thu Aug 22 09:51:46 2013 -0400
Start notes on Mars as a base文字ごとの違いを表示する
時折、例えばテキストドキュメントなど、列ごとの違いを表示するのは大雑把すぎる場合があります。
こういう時は、git diff の --color-words
オプションを使えば、色で文字ごとの違いを表示してくれるので、大変便利です。
ログをめくる
git log の出力がスクリーンよりも長いと、git
はスクリーンに収まるようにログを分割して表示するプログラムを使います。
この “pager”
（ページャ）というプログラムが開くと、一番下の列がプロンプトではなく、:
になります。
- ページャを閉じるには Q を押してください。
- 次のページを表示するには Spacebarを押してください。
- ある
<文字>を全ページの中から検索する時は、/ を押し、<文字>を入力してください。 Nを押すと次の一致場所に行けます。
ログの出力を制限する
git log
の出力がスクリーン全体を埋めないようにするために、Gitが表示するコミットの数を
-N で変えることができます。この
Nは、表示したいコミットの数を表しています。
例えば、最新のコミットの情報だけを表示したい場合は、こう入力します：
出力
commit 005937fbe2a98fb83f0ade869025dc2636b4dad5 (HEAD -> main)
Author: Vlad Dracula <vlad@tran.sylvan.ia>
Date: Thu Aug 22 10:14:07 2013 -0400
Discuss concerns about Mars' climate for Mummy--oneline
オプションを使うことによって、表示する情報を制限する事ができます：
出力
005937f (HEAD -> main) Discuss concerns about Mars' climate for Mummy
34961b1 Add concerns about effects of Mars' moons on Wolfman
f22b25e Start notes on Mars as a base--oneline
オプションを他のオプションと組み合わせることもできます。
便利な組み合わせの一つとして、 --graph
を追加すると、コミット履歴をテキストベースのグラフとして表示し、どのコミットが現在の
HEAD、現在のブランチ main、あるいはその他の
Git リファレンスに関連しているかを示すことができます：
出力
* 005937f (HEAD -> main) Discuss concerns about Mars' climate for Mummy
* 34961b1 Add concerns about effects of Mars' moons on Wolfman
* f22b25e Start notes on Mars as a baseディレクトリ
Git でディレクトリを使用する際は、以下の二点を覚えておきましょう。
- Git はディレクトリ単体を追跡することはなく、ディレクトリ内のファイルのみを追跡します。 自分で試してみてください：
注目してほしいのは、新しく作った directory
ディレクトリは git add
でリポジトリに追加したにも関わらず、追跡されてないファイルのリストに表示されていません。
たまに .gitkeep
ファイルが空のディレクトリ内にあるのは、このためです。
.gitignoreとは違って、このファイルは特別でも何でもなく、空のディレクトリを
Git のリポジトリに追加、そして追跡させるためだけに置いてあるだけです。
なので、別の名前のファイルでも同じことができます。
- Git リポジトリ内でディレクトリを作成し、複数のファイルをそのディレクトリに入れたい場合、ディレクトリ内のファイルをひとまとめに追加する事ができます：
自分で試してみてください：
BASH
$ touch spaceships/apollo-11 spaceships/sputnik-1
$ git status
$ git add spaceships
$ git status次に進む前に、これらの変更をコミットしましょう。
まとめると、変更内容をリポジトリに追加したい時はgit add
で変更点をステージングエリアに移してから、git commit
でステージングエリアの変更点をリポジトリに保存します：
コミットメッセージを決める
以下のコミットメッセージの内、最後の mars.txt
のコミットに最適なメッセージはどれでしょう？
- “Changes”
- “Added line ‘But the Mummy will appreciate the lack of humidity’ to mars.txt”
- “Discuss effects of Mars’ climate on the Mummy”
１つ目のメッセージは短すぎてコミットの内容が何なのかわかりにくいです。２つ目はgit diffで何が変わったのかが分かるので、長い割にはあまり意味がありません。３つ目は、短く、簡潔で、分かりやすいメッセージです。
ファイルがステージングエリアにない限り、コミットできません。
新しくリポジトリを作ろうとします。
正しい回答です。まずファイルをステージングエリアに追加し、それからコミットします。
“my recent changes” というファイルを myfile.txt というメッセージでコミットしようとします。
複数のファイルをコミットする
一つのコミットに対し、ステージングエリアは複数のファイルの変更点を保持する事ができます。
- Add some text to
mars.txtnoting your decision to consider Venus as a base - Create a new file
venus.txtwith your initial thoughts about Venus as a base for you and your friends - Add changes from both files to the staging area, and commit those changes.
以下のcat mars.txtの出力は、この課題で追加された内容のみを反映しています。
出力は異なる場合があります。
まずは mars.txt と venus.txt
を編集しましょう：
出力
Maybe I should start with a base on Venus.出力
Venus is a nice planet and I definitely should consider it as a base.これで二つのファイルをステージングエリアに追加することができます。 二つのファイルを一気に追加するには：
一つずつ追加するには：
これでファイルをコミットする準備ができました。
git status でチェックしましょう。 コミットをするには：
出力
[main cc127c2]
Write plans to start a base on Venus
2 files changed, 2 insertions(+)
create mode 100644 venus.txt
bio リポジトリ
-
bioという Git リポジトリ新しく作りましょう。 -
me.txtというファイルに自分について３文書いて、変更点をコミットしてください。 - すでに書いた文章の内、ひとつだけ編集して、更にもう一文加えてください。
- 編集した後の状態とその前の違いを表示してください。
必要であれば、planets から出ましょう：
新しく bio
というディレクトリを作り、中に移動しましょう：
リポジトリを作りましょう：
nano か他のテキストエディタで me.txt
を作りましょう。 作ったら、変更点を追加してコミットしてください：
指示通りにファイルを編集してください（一文だけ変えて、もう一文足す）。
オリジナルと編集後のファイルの違いを表示させるために、git diff
を使います：
まとめ
-
git statusはリポジトリの状態を表示する。 - ファイルはプロジェクトの作業ディレクトリ、ステージング・エリア（次のコミットに含まれる変更点が蓄積される場所）、そしてローカル・リポジトリ（コミットが永久に記録される場所）に保存される。
-
git addはファイルをステージング・エリアに移動させる。 -
git commitはステージされた内容をローカル・リポジトリに保存する。 - コミットメッセージは、変更点がわかりやすいように書きましょう。
Content from 履歴の探索
最終更新日：2024-09-30 | ページの編集
所要時間： 25分
概要
質問
- ファイルの古いバージョンを復元するにはどうすればよいでしょうか?
- 変更内容を再調査するにはどうすればよいでしょうか?
- ファイルの古いバージョンを復元するにはどうすればよいでしょうか?
目的
- リポジトリのHEADとは何か、またその使い方を説明出来るようになりましょう。
- Gitのコミット番号を特定して使ってみましょう。
- 追跡調査されるファイルのいろいろなバージョンを比較してみましょう。
- ファイルの古いバージョンを復元してみましょう。
前のレッスンで見たように、コミットを識別子で参照できます。 識別子
HEAD を使うことで作業ディレクトリの 最新のコミット
を参照できます。
mars.txt
に一度に1行ずつ追加しているので、進展を見て確認することは簡単です。それでは
HEAD を使ってそれを行ってみましょう。 始める前に、
mars.txt にもう1行加えることで変更を加えてみましょう。
出力
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
But the Mummy will appreciate the lack of humidity
An ill-considered changeそれでは、何が得られるか見てみましょう。
出力
diff --git a/mars.txt b/mars.txt
index b36abfd..0848c8d 100644
--- a/mars.txt
+++ b/mars.txt
@@ -1,3 +1,4 @@
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
But the Mummy will appreciate the lack of humidity
+An ill-considered change.これは、 HEAD を省略した場合 (試してみてください)
に得られるものと同じです。
これの本当の利点は、以前のコミットを参照できることです。
それを行うには、HEAD より前のコミットを参照するために
~1 (「~」は「チルダ」、発音は [til-d_uh_])
を追加します。
古いコミット間の違いを確認したい場合は、git diff
を再度使用できますが、HEAD~1、HEAD~2
などの表記を使用して、それらを参照するには下記を行います:
出力
diff --git a/mars.txt b/mars.txt
index df0654a..b36abfd 100644
--- a/mars.txt
+++ b/mars.txt
@@ -1 +1,4 @@
Cold and dry, but everything is my favorite color
+The two moons may be a problem for Wolfman
+But the Mummy will appreciate the lack of humidity
+An ill-considered changegit diff
を使用して表示されるコミットと作業ディレクトリの 違い
ではなく、古いコミットで行った変更だけでなくコミットメッセージも表示する
git showを使用することもできます。
出力
commit f22b25e3233b4645dabd0d81e651fe074bd8e73b
Author: Vlad Dracula <vlad@tran.sylvan.ia>
Date: Thu Aug 22 09:51:46 2013 -0400
Start notes on Mars as a base
diff --git a/mars.txt b/mars.txt
new file mode 100644
index 0000000..df0654a
--- /dev/null
+++ b/mars.txt
@@ -0,0 +1 @@
+Cold and dry, but everything is my favorite colorこのようにして、コミットのチェーンを構築できます。
チェーンの最新の終わりは HEAD と呼ばれます; ~
表記を使用して以前のコミットを参照できるため、HEAD~1
は「以前のコミット」を意味し、HEAD~123
は現在の場所から123個前のコミットに戻ります。
git log および git show
が表示する、数字と文字の長い文字列を使用してコミットを参照することもできます。
これらは一個一個の変更に対するユニークなIDであり、「ユニーク」は本当に唯一であることを意味します:
どのコンピューターのどのファイルの変更の組み合わせに対しても、ユニークな40文字の
ID があります。 最初のコミットにはID
f22b25e3233b4645dabd0d81e651fe074bd8e73b
が与えられたので、これを試してみましょう:
出力
diff --git a/mars.txt b/mars.txt
index df0654a..93a3e13 100644
--- a/mars.txt
+++ b/mars.txt
@@ -1 +1,4 @@
Cold and dry, but everything is my favorite color
+The two moons may be a problem for Wolfman
+But the Mummy will appreciate the lack of humidity
+An ill-considered changeこれは正しい答えですが、ランダムな40文字の文字列を入力するのは面倒なので、Gitは最初の数文字だけを使えばよいようにしてくれています:
出力
diff --git a/mars.txt b/mars.txt
index df0654a..93a3e13 100644
--- a/mars.txt
+++ b/mars.txt
@@ -1 +1,4 @@
Cold and dry, but everything is my favorite color
+The two moons may be a problem for Wolfman
+But the Mummy will appreciate the lack of humidity
+An ill-considered changeやりました! こんなわけで
ファイルへの変更を保存して、何が変更されたかを確認できます。
では、どうすれば古いバージョンのものを復元できるでしょうか?
mars.txtへの最後の更新（「熟考を欠いた変更」）について気が変わったとしましょう。
git status
は、ファイルが変更されたことを示しますが、それらの変更はステージングされていません:
出力
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: mars.txt
no changes added to commit (use "git add" and/or "git commit -a")git restoreを使うと、元の状態に戻すことができます:
出力
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
But the Mummy will appreciate the lack of humidityその名前から推測できるように、git restore
はファイルの古いバージョンを復元します。
この場合、最後に保存されたコミットである HEAD
に記録されたファイルのバージョンを復元することをGitに伝えています。
さらに遡りたい場合は、-sオプションとコミット Id
を使うことができます:
出力
Cold and dry, but everything is my favorite color出力
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: mars.txt
no changes added to commit (use "git add" and/or "git commit -a")
変更はステージング領域にあることに注意してください。
繰り返しますが、git restore
を使うと、元の状態に戻すことができます:
出力
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
But the Mummy will appreciate the lack of humidity取り消したい変更の一個前のコミット番号を使う必要があることを覚えておくことが重要です。
よくある間違いは、破棄しようとしている変更を行ったコミットの番号を使用することです。
以下の例では、最新のコミットの前 (HEAD~1)
、すなわちf22b25eから状態を取得したいと考えています:
このとき、.
を使用することで、全てのファイルを対象にします。
つまり、すべてをまとめると、Gitがどのように機能するかは次の漫画のようになります:
ファイルを1つずつ元に戻すことができるという事実は 人々が研究を整理する方法を変えることがあります。 すべての変更が1つの大きなドキュメントに含まれている場合、 後で結論に加えられた変更を元に戻さずに、 序論への変更を元に戻すことは困難です(不可能ではありませんが)。 一方、序論と結論を別々のファイルに保存すると、時間を前後に移動するのがはるかに簡単になります。
ファイルの古いバージョンの復元
ジェニファーは、数週間取り組んできたPythonスクリプトに変更を加えました。そして今朝行った変更により、スクリプトが “壊れ”、動作しなくなりました。 彼女はそれを修正しようとして約1時間費やしましたが、うまく機能しません…
幸い、彼女はGitを使用してプロジェクトのバージョンを追跡していました!
以下のどのコマンドで、data_cruncher.py
と呼ばれるPythonスクリプトの最後にコミットされたバージョンを復元できるでしょうか？
$ git restore$ git restore data_cruncher.py$ git restore -s HEAD~1 data_cruncher.py$ git restore -s <unique ID of last commit> data_cruncher.py2番と4番の両方
答えは (5) - 2 と 4 の両方です。
restore
コマンドはリポジトリからファイルを復元し、作業ディレクトリのファイルを上書きします。
2番と4番のコマンドはどちらもリ_ポジトリにある_
data_cruncher.py の_最新バージョン_を復元します。 2番は
HEAD を使って_最新バージョン_を指定し、4番は
HEAD と同じ意味の最後のコミットIDを使います。
3番のコマンドは、data_cruncher.py の HEAD
_より前_のコミットから復元するため、今回の目的とは異なります。
1番はエラーになります。 復元するファイルを指定する必要があります。
すべてのファイルを復元したい場合は、git restore .
を使用するべきです。
コミットを戻すことについて
ジェニファーは同僚とPythonスクリプトで共同作業を行っており、グループのリポジトリへの彼女の最新のコミットが間違っていることに気付き、それを元に戻したいと思っています。
ジェニファーは、グループリポジトリのみんなが正しい変更を取得できるように、正しく元に戻す必要があります。
ジェニファーは、グループリポジトリのみんなが正しい変更を取得できるように、正しく元に戻す必要があります。
git revert [wrong commit ID]
は、ジェニファーの誤ったコミットを元に戻す新しいコミットを作ります。
git revert は git restore -s [commit ID] .
とは異なります。git restore
は、ローカルリポジトリ内でまだコミットされていないファイルを以前の状態に戻すために使用されるのに対して、git revert
はローカルリポジトリおよびプロジェクトリポジトリにコミットされた変更を取り消すために使用されます。
以下は、ジェニファーがgit revertを使用するための正しい手順と説明ですが、不足しているコマンドは何でしょうか？
________ # コミットIDを見つけるために、プロジェクトのgitの 履歴を見ますそのIDをコピーします (IDの最初の数文字は例えば 0b1d055)。
git revert [commit ID]新しいコミットメッセージを入力します。
保存して閉じます。
git log
コマンドは、コミットIDを含むプロジェクトの履歴を一覧表示します。
git show HEAD
は、最新のコミットで行われた変更を表示し、コミットIDも確認できます。ただし、ジェニファーはこれが正しいコミットであることを再確認し、他の人がリポジトリに変更をコミットしていないか確認する必要があります。
ワークフローと履歴の理解
最後のコマンドの出力は何でしょうか？
BASH
$ cd planets
$ echo "Venus is beautiful and full of love" > venus.txt
$ git add venus.txt
$ echo "Venus is too hot to be suitable as a base" >> venus.txt
$ git commit -m "Comment on Venus as an unsuitable base"
$ git restore venus.txt
$ cat venus.txt #this will print the contents of venus.txt to the screen出力
Venus is too hot to be suitable as a base
2. ```output
Venus is beautiful and full of love出力
Venus is beautiful and full of love Venus is too hot to be suitable as a base
4. ```output
Error because you have changed venus.txt without committing the changes答えは2です。
The command git add venus.txt places the current version
of venus.txt into the staging area. The changes to the file
from the second echo command are only applied to the
working copy, not the version in the staging area.
So, when
git commit -m "Comment on Venus as an unsuitable base" is
executed, the version of venus.txt committed to the
repository is the one from the staging area and has only one line.
At this time, the working copy still has the second line (and
git status will show that the file is modified). However,
git restore venus.txt replaces the working copy with the
most recently committed version of venus.txt.
So, cat venus.txt will output
出力
Venus is beautiful and full of love.
git diff の理解のチェック
このコマンドをよく考えてみてください:
git diff HEAD~9 mars.txt。
このコマンドを実行したらどうなるだろうと予測しますか?
実行すると何が起こっていますか? またそれはなぜでしょうか?
別のコマンド git diff [ID] mars.txt
を試しましょう、ここでの [ID] は最新のコミットのユニークな ID
で置き換えられます。 あなたは何が起こるだろうと思いますか?
ステージされた変更の除去
git restore は、ステージされていない変更があったときに
以前のコミットを復元するために使用できます。しかしそれはステージされているがコミットされていない変更に対しても機能するでしょうか?
mars.txt
に変更を用意し、その変更を加え（git addを使い）、git restore
を使い変更を取り除くことができるかどうか確かめましょう。
変更を追加した後、git restore は直接使用できません。
次に、git status の出力を確認してみましょう。
出力
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: mars.txt
この出力が表示されない場合、ファイルの変更を忘れているか、すでにファイルを追加してコミットした可能性があります。
この時点で、git restore mars.txt
コマンドを実行してもエラーは発生しませんが、ファイルは元に戻りません。
Gitは、まず git restore --staged
を使用してステージングエリアからファイルを戻す必要があることを教えてくれます。
次に、git status の出力を確認します。
出力
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git git restore <file>..." to discard changes in working directory)
modified: mars.txt
no changes added to commit (use "git add" and/or "git commit -a")ここで、git restore
コマンドを使ってファイルを前のコミットの状態に戻すことができます。
出力
On branch main
nothing to commit, working tree clean履歴を探索し、要約する
履歴の探索はgitの重要な要素であり、特にそのコミットが数ヶ月前のものである場合は、適切なコミットIDを見つけるのが難しいことがよくあります。
planets
プロジェクトに50を超えるファイルがあると考えてください。 あなたは
mars.txt
中の特定のテキストが変更されたコミットを見つけたいとします。
git log と入力すると、非常に長いリストが表示されました。
どうやって探す範囲を限定しますか?
git diff
コマンドを使用すると、1つの特定のファイルを探索できることを思い出してください、
例えば、git diff mars.txt 。
ここでも同様のアイデアを適用できます。
残念ながら、一部のコミットメッセージは
update files（「ファイルを更新する」）などのように非常に曖昧です。
これらのファイルをどうやって調べたら良いでしょうか？
git diff と git log
はどちらも非常に便利で、それぞれリポジトリの異なる部分の履歴を要約してくれます。
これらを組み合わせることは可能でしょうか？
次のコマンドを試してみましょう：
長い出力が表示され、各コミットメッセージと、そのコミット間での違い（差分）が確認できるはずです。
質問: 次のコマンドは何をしますか？
まとめ
-
git diffは、コミット間の違いを表示します。 -
git checkoutは、ファイルの古いバージョンを復元します。
Content from ファイルを無視する
最終更新日：2024-06-06 | ページの編集
所要時間： 5分
概要
質問
- Git で追跡したくないファイルを指定するにはどうすればよいですか？
目的
- Git で追跡したくないファイルを指定しましょう
- ファイルを無視する利点を理解しましょう
Git に追跡して欲しくないファイル、例えばエディタが作成したバックアップファイルやデータ解析中に作られた中間ファイルなどは、どう対処すればいいのでしょう？ 例として、いくつかファイルを作ってみましょう：
そして Git が何と言うか見てみましょう：
出力
On branch main
Untracked files:
(use "git add <file>..." to include in what will be committed)
a.csv
b.csv
c.csv
results/
nothing added to commit but untracked files present (use "git add" to track)これらのファイルをバージョンコントロールで保存するのはディスク容量の無駄になります。 さらに、これら全てが表示されると、本当に必要な変更点に集中できなくなってしまうかもしれないので、 Git にこれらのファイルを無視してもらいましょう。
これをするには、.gitignore
というファイルをルートディレクトリに作ります：
出力
*.csv
results/入力したパターンは、 Git に .dat
で終わるファイル名とresults
ディレクトリ内にあるファイルを無視するように指示しています。 （Git
がすでに追跡しているファイルは、引き続き追跡されます。）
このファイルを作った後git status
の出力を見てみると、大分綺麗になっています：
出力
On branch main
Untracked files:
(use "git add <file>..." to include in what will be committed)
.gitignore
nothing added to commit but untracked files present (use "git add" to track)Git は新しく作られた .gitignore
ファイルしか表示していません。
このファイルは追跡しなくても良いかと思うでしょうが、リポジトリを共有する際に、他の人達も私達が無視したものを同じように無視したいでしょう。
なので、.gitignore を追加してコミットしましょう：
出力
On branch main
nothing to commit, working tree clean.gitignore
を作った事によって、間違えて不要なファイルをリポジトリに追加する事を防ぐことができます：
出力
The following paths are ignored by one of your .gitignore files:
a.csv
Use -f if you really want to add them.この設定を強制的に無視してファイルを追加するには、git add -f
を使います。 例えば、git add -f a.csv と入力します。
もちろん、無視されたファイルの状況はいつでも見ることができます：
出力
On branch main
Ignored files:
(use "git add -f <file>..." to include in what will be committed)
a.csv
b.csv
c.csv
results/
nothing to commit, working tree cleanresults/plots
内のファイルのみを無視するのであれば、.gitignore に
/plots/ サブフォルダを無視するように.gitignore
に以下の文を加えれば解決できます：
出力
results/plots/この行によって、results/plotsの内容だけが無視され、results/dataの内容は無視されません。
様々なプログラミングの問題と同様に、この無視ルールが守られるようにする回答方法はいくつかありま。 「ネストされたファイルを無視する：バリエーション」の演習は、わずかに異なるディレクトリ構造を持っており、別の解決策を提示しています。「ネストされたファイルを無視する：バリエーション」の演習は、わずかに異なるディレクトリ構造を持っており、別の解決策を提示しています。 Further, the discussion page has more detail on ignore rules.
無視の対象に特定のファイルを含める
final.csv以外の、ルートディレクトリ内にある他の
.data
ファイルを全て無視したい場合はどうすればいいのでしょう？ ヒント：
! （感嘆符）が何をするのか調べてみましょう。
以下二文を .gitignore に加えましょう：
出力
*.data # 全ての data ファイルを無視する
!final.data # final.data は対象から除外する感嘆符は、無視してあったファイルを対象から外します。
このレッスンで.csvファイルをコミットしたことがあるので、この新しいルールでは無視されません。
ルートディレクトリに追加された .csv
ファイルの以後の追記のみが無視されます。
results/ のコンテンツは無視したいが、
results/data/ のコンテンツは無視したくない場合、
.gitignore を変更して、 results
フォルダの内容は無視する、しかし results/data
サブフォルダのコンテンツは例外として設定することができます。 あなたの
.gitignore は次のようになるでしょう：
出力
results/* # ignore everything in results folder
!results/data/ # do not ignore results/data/ contentsディレクトリ内の全てのデータファイルを無視する
results/data/position/gps/*.data を使えば
results/data/position/gps 内にある全ての .data
ファイルを無視できます。 results/data/position/gps/info.txt
ファイルは無視されません。
Ignoring all data Files in the repository
Let us assume you have many .csv files in different
subdirectories of your repository. For example, you might have:
BASH
results/a.csv
data/experiment_1/b.csv
data/experiment_2/c.csv
data/experiment_2/variation_1/d.csvHow do you ignore all the .csv files, without explicitly
listing the names of the corresponding folders?
In the .gitignore file, write:
出力
**/*.csvThis will ignore all the .csv files, regardless of their
position in the directory tree. You can still include some specific
exception with the exclamation point operator.
感嘆符 !
は無視してあったファイルを対象から除外する効果があります。
!*.csv は、その前に入力されている .csv
ファイルを対象から外すので、全ての .csv
ファイルは引き続き追跡されることになります。
ログファイル
仮に log_01、 log_02、
log_03、というように、中間的にログファイルを作成するスクリプトを書いたとします。
これらのログファイルは取っておきたいのですが、git
で追跡したくありません。
log_01、log_02、などのファイルを無視するためのルールを一つだけ.gitignoreに入力してください。入力したパターン正常に動作しているか確認するために
log_01などのファイルを作成してください。最終的に
log_01ファイルがものすごく重要であることが分かりました。.gitignoreを編集せずに、このファイルを追跡しているファイルに加えてください。隣の人と、追跡したくないファイルは他にどのようなものがあるのか、そして
.gitignoreに何を入力すればこれらのファイルを無視できるのかを話し合ってください。
log_*もしくはlog*を .gitignore に加えます。git add -f log_01を使ってlog_01を追跡しましょう。
まとめ
-
.gitignoreで無視するファイルを指定する
Content from GitHub におけるリモート
最終更新日：2024-09-30 | ページの編集
所要時間： 45分
概要
質問
- 自分の変更をウェブ上で他の人と共有するにはどうすればよいですか？
目的
- リモートリポジトリとは何なのか、そしてなぜそれが役立つのかを説明します。
- リモートリポジトリへのプッシュまたはリモートリポジトリからのプル。
バージョン管理が真価を発揮するのは、他の人々と共同作業を始めるときです。 これを行うために必要な機構のほとんどはすでに揃っています。 唯一欠けているのは、あるリポジトリから別のリポジトリに変更をコピーすることです。
Git のようなシステムを使用すると、任意の 2 つのリポジトリ間で作業結果を動かすことができます。 ただし、実際には、1 つのコピーを中央ハブとして使用し、それを誰かのラップトップではなくウェブ上に 保管するのが最も簡単です。 ほとんどのプログラマーは、GitHub や Bitbucket、あるいは GitLab のようなホスティングサービス に、これらのメインコピーを保持しています。この長所と短所については、後のエピソード で探ります。
まずは、現在のプロジェクトに加えた変更を世界と共有することから始めましょう。 この目的のために、ローカル リポジトリにリンクされる リモート リポジトリを作成します。
1. リモートリポジトリを作成する。
GitHub
にログインし、右上隅のアイコンをクリックして planets
という名前の新しいリポジトリを作成してみましょう：
リポジトリに「planets」という名前を付けて、「Create Repository」をクリックします。
注: このリポジトリはローカルのリポジトリに接続されるため、空にしておく必要があります。 「Initialize this repository with a README」のチェックを外したままにし、「Add .gitignore」と「Add a license.」の両方のオプションを「None」のままにします。 リポジトリを空にしておく必要がある理由の完全な説明については、以下の「GitHub ライセンスと README ファイル」の演習を参照してください。
リポジトリが作成されるとすぐに、GitHub には ある URL と、ローカルのリポジトリの構成方法に関する情報が記載されたページが表示されます。
これにより、GitHub のサーバー上で次のことが効果的に行われます。
もしあなたが以前の エピソード
を覚えていれば、私達は mars.txt
に以前の作業を追加してコミットしました。
ローカルリポジトリのダイアグラムは次のようになります：
Now that we have two repositories, we need a diagram like this:
Note that our local repository still contains our earlier work on
mars.txt, but the remote repository on GitHub appears empty
as it doesn’t contain any files yet.
2. Connect local to remote repository
Now we connect the two repositories. We do this by making the GitHub repository a remote for the local repository. The home page of the repository on GitHub includes the URL string we need to identify it:
Click on the ‘SSH’ link to change the protocol from HTTPS to SSH.
HTTPS vs. SSH
We use SSH here because, while it requires some additional configuration, it is a security protocol widely used by many applications. The steps below describe SSH at a minimum level for GitHub.
Copy that URL from the browser, go into the local
planets repository, and run this command:
Make sure to use the URL for your repository rather than Vlad’s: the
only difference should be your username instead of
vlad.
origin is a local name used to refer to the remote
repository. It could be called anything, but origin is a
convention that is often used by default in git and GitHub, so it’s
helpful to stick with this unless there’s a reason not to.
We can check that the command has worked by running
git remote -v:
出力
origin git@github.com:vlad/planets.git (fetch)
origin git@github.com:vlad/planets.git (push)We’ll discuss remotes in more detail in the next episode, while talking about how they might be used for collaboration.
3. SSH Background and Setup
Before Dracula can connect to a remote repository, he needs to set up a way for his computer to authenticate with GitHub so it knows it’s him trying to connect to his remote repository.
We are going to set up the method that is commonly used by many different services to authenticate access on the command line. This method is called Secure Shell Protocol (SSH). SSH is a cryptographic network protocol that allows secure communication between computers using an otherwise insecure network.
SSH uses what is called a key pair. This is two keys that work together to validate access. One key is publicly known and called the public key, and the other key called the private key is kept private. Very descriptive names.
You can think of the public key as a padlock, and only you have the key (the private key) to open it. You use the public key where you want a secure method of communication, such as your GitHub account. You give this padlock, or public key, to GitHub and say “lock the communications to my account with this so that only computers that have my private key can unlock communications and send git commands as my GitHub account.”
What we will do now is the minimum required to set up the SSH keys and add the public key to a GitHub account.
Advanced SSH
A supplemental episode in this lesson discusses SSH and key pairs in more depth and detail.
The first thing we are going to do is check if this has already been done on the computer you’re on. Because generally speaking, this setup only needs to happen once and then you can forget about it.
Keeping your keys secure
You shouldn’t really forget about your SSH keys, since they keep your account secure. It’s good practice to audit your secure shell keys every so often. Especially if you are using multiple computers to access your account.
We will run the list command to check what key pairs already exist on your computer.
Your output is going to look a little different depending on whether or not SSH has ever been set up on the computer you are using.
Dracula has not set up SSH on his computer, so his output is
出力
ls: cannot access '/c/Users/Vlad Dracula/.ssh': No such file or directoryIf SSH has been set up on the computer you’re using, the public and
private key pairs will be listed. The file names are either
id_ed25519/id_ed25519.pub or
id_rsa/id_rsa.pub depending on how the key
pairs were set up.
Since they don’t exist on Dracula’s computer, he uses this command to
create them.
3.1 Create an SSH key pair
To create an SSH key pair Vlad uses this command, where the
-t option specifies which type of algorithm to use and
-C attaches a comment to the key (here, Vlad’s email):
If you are using a legacy system that doesn’t support the Ed25519
algorithm, use:
$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
出力
Generating public/private ed25519 key pair.
Enter file in which to save the key (/c/Users/Vlad Dracula/.ssh/id_ed25519):We want to use the default file, so just press Enter.
出力
Created directory '/c/Users/Vlad Dracula/.ssh'.
Enter passphrase (empty for no passphrase):Now, it is prompting Dracula for a passphrase. Since he is using his lab’s laptop that other people sometimes have access to, he wants to create a passphrase. Be sure to use something memorable or save your passphrase somewhere, as there is no “reset my password” option. Note that, when typing a passphrase on a terminal, there won’t be any visual feedback of your typing. This is normal: your passphrase will be recorded even if you see nothing changing on your screen.
出力
Enter same passphrase again:After entering the same passphrase a second time, we receive the confirmation
出力
Your identification has been saved in /c/Users/Vlad Dracula/.ssh/id_ed25519
Your public key has been saved in /c/Users/Vlad Dracula/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:SMSPIStNyA00KPxuYu94KpZgRAYjgt9g4BA4kFy3g1o vlad@tran.sylvan.ia
The key's randomart image is:
+--[ED25519 256]--+
|^B== o. |
|%*=.*.+ |
|+=.E =.+ |
| .=.+.o.. |
|.... . S |
|.+ o |
|+ = |
|.o.o |
|oo+. |
+----[SHA256]-----+The “identification” is actually the private key. You should never share it. The public key is appropriately named. The “key fingerprint” is a shorter version of a public key.
Now that we have generated the SSH keys, we will find the SSH files when we check.
出力
drwxr-xr-x 1 Vlad Dracula 197121 0 Jul 16 14:48 ./
drwxr-xr-x 1 Vlad Dracula 197121 0 Jul 16 14:48 ../
-rw-r--r-- 1 Vlad Dracula 197121 419 Jul 16 14:48 id_ed25519
-rw-r--r-- 1 Vlad Dracula 197121 106 Jul 16 14:48 id_ed25519.pub3.2 Copy the public key to GitHub
Now we have a SSH key pair and we can run this command to check if GitHub can read our authentication.
出力
The authenticity of host 'github.com (192.30.255.112)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? y
Please type 'yes', 'no' or the fingerprint: yes
Warning: Permanently added 'github.com' (RSA) to the list of known hosts.
git@github.com: Permission denied (publickey).Right, we forgot that we need to give GitHub our public key!
First, we need to copy the public key. Be sure to include the
.pub at the end, otherwise you’re looking at the private
key.
出力
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDmRA3d51X0uu9wXek559gfn6UFNF69yZjChyBIU2qKI vlad@tran.sylvan.iaNow, going to GitHub.com, click on your profile icon in the top right corner to get the drop-down menu. Click “Settings,” then on the settings page, click “SSH and GPG keys,” on the left side “Account settings” menu. Click the “New SSH key” button on the right side. Now, you can add the title (Dracula uses the title “Vlad’s Lab Laptop” so he can remember where the original key pair files are located), paste your SSH key into the field, and click the “Add SSH key” to complete the setup.
Now that we’ve set that up, let’s check our authentication again from the command line.
出力
Hi Vlad! You've successfully authenticated, but GitHub does not provide shell access.Good! This output confirms that the SSH key works as intended. We are now ready to push our work to the remote repository.
4. Push local changes to a remote
Now that authentication is setup, we can return to the remote. This command will push the changes from our local repository to the repository on GitHub:
Since Dracula set up a passphrase, it will prompt him for it. If you completed advanced settings for your authentication, it will not prompt for a passphrase.
出力
Enumerating objects: 16, done.
Counting objects: 100% (16/16), done.
Delta compression using up to 8 threads.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (16/16), 1.45 KiB | 372.00 KiB/s, done.
Total 16 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), done.
To https://github.com/vlad/planets.git
* [new branch] main -> mainプロキシ
If the network you are connected to uses a proxy, there is a chance that your last command failed with “Could not resolve hostname” as the error message. To solve this issue, you need to tell Git about the proxy:
BASH
$ git config --global http.proxy http://user:password@proxy.url
$ git config --global https.proxy https://user:password@proxy.urlWhen you connect to another network that doesn’t use a proxy, you will need to tell Git to disable the proxy using:
Password Managers
If your operating system has a password manager configured,
git push will try to use it when it needs your username and
password. For example, this is the default behavior for Git Bash on
Windows. If you want to type your username and password at the terminal
instead of using a password manager, type:
in the terminal, before you run git push. Despite the
name, Git uses , so you may want to unset SSH_ASKPASS
whether you are using Git via SSH or https.
You may also want to add unset SSH_ASKPASS at the end of
your ~/.bashrc to make Git default to using the terminal
for usernames and passwords.
Our local and remote repositories are now in this state:
The ‘-u’ Flag
You may see a -u option used with git push
in some documentation. This option is synonymous with the
--set-upstream-to option for the git branch
command, and is used to associate the current branch with a remote
branch so that the git pull command can be used without any
arguments. To do this, simply use git push -u origin main
once the remote has been set up.
We can pull changes from the remote repository to the local one as well:
出力
From https://github.com/vlad/planets
* branch main -> FETCH_HEAD
Already up-to-date.Pulling has no effect in this case because the two repositories are already synchronized. If someone else had pushed some changes to the repository on GitHub, though, this command would download them to our local repository.
GitHub GUI
Browse to your planets repository on GitHub. Underneath
the Code button, find and click on the text that says “XX commits”
(where “XX” is some number). Hover over, and click on, the three buttons
to the right of each commit. What information can you gather/explore
from these buttons? How would you get that same information in the
shell?
The left-most button (with the picture of a clipboard) copies the
full identifier of the commit to the clipboard. In the shell,
git log will show you the full commit identifier for each
commit.
When you click on the middle button, you’ll see all of the changes
that were made in that particular commit. Green shaded lines indicate
additions and red ones removals. In the shell we can do the same thing
with git diff. In particular,
git diff ID1..ID2 where ID1 and ID2 are commit identifiers
(e.g. git diff a3bf1e5..041e637) will show the differences
between those two commits.
The right-most button lets you view all of the files in the
repository at the time of that commit. To do this in the shell, we’d
need to checkout the repository at that particular time. We can do this
with git checkout ID where ID is the identifier of the
commit we want to look at. If we do this, we need to remember to put the
repository back to the right state afterwards!
Uploading files directly in GitHub browser
Github also allows you to skip the command line and upload files directly to your repository without having to leave the browser. There are two options. First you can click the “Upload files” button in the toolbar at the top of the file tree. Or, you can drag and drop files from your desktop onto the file tree. You can read more about this on this GitHub page.
GitHub Timestamp
Create a remote repository on GitHub. Push the contents of your local repository to the remote. Make changes to your local repository and push these changes. Go to the repo you just created on GitHub and check the timestamps of the files. How does GitHub record times, and why?
GitHub displays timestamps in a human readable relative format (i.e. “22 hours ago” or “three weeks ago”). However, if you hover over the timestamp, you can see the exact time at which the last change to the file occurred.
Push vs. Commit
In this episode, we introduced the “git push” command. How is “git push” different from “git commit”?
When we push changes, we’re interacting with a remote repository to update it with the changes we’ve made locally (often this corresponds to sharing the changes we’ve made with others). Commit only updates your local repository.
GitHub License and README files
In this episode we learned about creating a remote repository on GitHub, but when you initialized your GitHub repo, you didn’t add a README.md or a license file. If you had, what do you think would have happened when you tried to link your local and remote repositories?
In this case, we’d see a merge conflict due to unrelated histories. When GitHub creates a README.md file, it performs a commit in the remote repository. When you try to pull the remote repository to your local repository, Git detects that they have histories that do not share a common origin and refuses to merge.
出力
warning: no common commits
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From https://github.com/vlad/planets
* branch main -> FETCH_HEAD
* [new branch] main -> origin/main
fatal: refusing to merge unrelated historiesYou can force git to merge the two repositories with the option
--allow-unrelated-histories. Be careful when you use this
option and carefully examine the contents of local and remote
repositories before merging.
出力
From https://github.com/vlad/planets
* branch main -> FETCH_HEAD
Merge made by the 'recursive' strategy.
README.md | 1 +
1 file changed, 1 insertion(+)
create mode 100644 README.mdまとめ
- A local Git repository can be connected to one or more remote repositories.
- Use the SSH protocol to connect to remote repositories.
-
git pushcopies changes from a local repository to a remote repository. -
git pullcopies changes from a remote repository to a local repository.
Content from Collaborating
最終更新日：2024-09-30 | ページの編集
所要時間： 25分
概要
質問
- How can I use version control to collaborate with other people?
目的
- Clone a remote repository.
- Collaborate by pushing to a common repository.
- Describe the basic collaborative workflow.
For the next step, get into pairs. One person will be the “Owner” and the other will be the “Collaborator”. The goal is that the Collaborator add changes into the Owner’s repository. We will switch roles at the end, so both persons will play Owner and Collaborator.
Practicing By Yourself
If you’re working through this lesson on your own, you can carry on by opening a second terminal window. This window will represent your partner, working on another computer. You won’t need to give anyone access on GitHub, because both ‘partners’ are you.
The Owner needs to give the Collaborator access. In your repository page on GitHub, click the “Settings” button on the right, select “Collaborators”, click “Add people”, and then enter your partner’s username.
To accept access to the Owner’s repo, the Collaborator needs to go to https://github.com/notifications or check for email notification. Once there she can accept access to the Owner’s repo.
Next, the Collaborator needs to download a copy of the Owner’s repository to her machine. This is called “cloning a repo”.
The Collaborator doesn’t want to overwrite her own version of
planets.git, so needs to clone the Owner’s repository to a
different location than her own repository with the same name.
To clone the Owner’s repo into her Desktop folder, the
Collaborator enters:
Replace ‘vlad’ with the Owner’s username.
If you choose to clone without the clone path
(~/Desktop/vlad-planets) specified at the end, you will
clone inside your own planets folder! Make sure to navigate to the
Desktop folder first.
The Collaborator can now make a change in her clone of the Owner’s repository, exactly the same way as we’ve been doing before:
出力
It is so a planet!出力
1 file changed, 1 insertion(+)
create mode 100644 pluto.txtThen push the change to the Owner’s repository on GitHub:
出力
Enumerating objects: 4, done.
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 306 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/vlad/planets.git
9272da5..29aba7c main -> mainNote that we didn’t have to create a remote called
origin: Git uses this name by default when we clone a
repository. (This is why origin was a sensible choice
earlier when we were setting up remotes by hand.)
Take a look at the Owner’s repository on GitHub again, and you should be able to see the new commit made by the Collaborator. You may need to refresh your browser to see the new commit.
Some more about remotes
In this episode and the previous one, our local repository has had a
single “remote”, called origin. A remote is a copy of the
repository that is hosted somewhere else, that we can push to and pull
from, and there’s no reason that you have to work with only one. For
example, on some large projects you might have your own copy in your own
GitHub account (you’d probably call this origin) and also
the main “upstream” project repository (let’s call this
upstream for the sake of examples). You would pull from
upstream from time to time to get the latest updates that
other people have committed.
Remember that the name you give to a remote only exists locally. It’s
an alias that you choose - whether origin, or
upstream, or fred - and not something
intrinstic to the remote repository.
The git remote family of commands is used to set up and
alter the remotes associated with a repository. Here are some of the
most useful ones:
-
git remote -vlists all the remotes that are configured (we already used this in the last episode) -
git remote add [name] [url]is used to add a new remote -
git remote remove [name]removes a remote. Note that it doesn’t affect the remote repository at all - it just removes the link to it from the local repo. -
git remote set-url [name] [newurl]changes the URL that is associated with the remote. This is useful if it has moved, e.g. to a different GitHub account, or from GitHub to a different hosting service. Or, if we made a typo when adding it! -
git remote rename [oldname] [newname]changes the local alias by which a remote is known - its name. For example, one could use this to changeupstreamtofred.
To download the Collaborator’s changes from GitHub, the Owner now enters:
出力
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From https://github.com/vlad/planets
* branch main -> FETCH_HEAD
9272da5..29aba7c main -> origin/main
Updating 9272da5..29aba7c
Fast-forward
pluto.txt | 1 +
1 file changed, 1 insertion(+)
create mode 100644 pluto.txtNow the three repositories (Owner’s local, Collaborator’s local, and Owner’s on GitHub) are back in sync.
A Basic Collaborative Workflow
In practice, it is good to be sure that you have an updated version
of the repository you are collaborating on, so you should
git pull before making our changes. The basic collaborative
workflow would be:
- update your local repo with
git pull origin main, - make your changes and stage them with
git add, - commit your changes with
git commit -m, and - upload the changes to GitHub with
git push origin main
It is better to make many commits with smaller changes rather than of one commit with massive changes: small commits are easier to read and review.
Switch Roles and Repeat
Switch roles and repeat the whole process.
Review Changes
The Owner pushed commits to the repository without giving any information to the Collaborator. How can the Collaborator find out what has changed with command line? And on GitHub?
On the command line, the Collaborator can use
git fetch origin main to get the remote changes into the
local repository, but without merging them. Then by running
git diff main origin/main the Collaborator will see the
changes output in the terminal.
On GitHub, the Collaborator can go to the repository and click on “commits” to view the most recent commits pushed to the repository.
Version History, Backup, and Version Control
Some backup software can keep a history of the versions of your files. They also allows you to recover specific versions. How is this functionality different from version control? What are some of the benefits of using version control, Git and GitHub?
まとめ
-
git clonecopies a remote repository to create a local repository with a remote calledoriginautomatically set up.
Content from Conflicts
最終更新日：2024-09-30 | ページの編集
所要時間： 15分
概要
質問
- What do I do when my changes conflict with someone else’s?
目的
- Explain what conflicts are and when they can occur.
- Resolve conflicts resulting from a merge.
As soon as people can work in parallel, they’ll likely step on each other’s toes. This will even happen with a single person: if we are working on a piece of software on both our laptop and a server in the lab, we could make different changes to each copy. Version control helps us manage these conflicts by giving us tools to resolve overlapping changes.
To see how we can resolve conflicts, we must first create one. The
file mars.txt currently looks like this in both partners’
copies of our planets repository:
出力
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
But the Mummy will appreciate the lack of humidityLet’s add a line to the collaborator’s copy only:
出力
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
But the Mummy will appreciate the lack of humidity
This line added to Wolfman's copyand then push the change to GitHub:
出力
[main 5ae9631] Add a line in our home copy
1 file changed, 1 insertion(+)出力
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 331 bytes | 331.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
To https://github.com/vlad/planets.git
29aba7c..dabb4c8 main -> mainNow let’s have the owner make a different change to their copy without updating from GitHub:
出力
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
But the Mummy will appreciate the lack of humidity
We added a different line in the other copyWe can commit the change locally:
出力
[main 07ebc69] Add a line in my copy
1 file changed, 1 insertion(+)but Git won’t let us push it to GitHub:
出力
To https://github.com/vlad/planets.git
! [rejected] main -> main (fetch first)
error: failed to push some refs to 'https://github.com/vlad/planets.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
Git rejects the push because it detects that the remote repository has new updates that have not been incorporated into the local branch. What we have to do is pull the changes from GitHub, merge them into the copy we’re currently working in, and then push that. Let’s start by pulling:
出力
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (1/1), done.
remote: Total 3 (delta 2), reused 3 (delta 2), pack-reused 0
Unpacking objects: 100% (3/3), done.
From https://github.com/vlad/planets
* branch main -> FETCH_HEAD
29aba7c..dabb4c8 main -> origin/main
Auto-merging mars.txt
CONFLICT (content): Merge conflict in mars.txt
Automatic merge failed; fix conflicts and then commit the result.The git pull command updates the local repository to
include those changes already included in the remote repository. After
the changes from remote branch have been fetched, Git detects that
changes made to the local copy overlap with those made to the remote
repository, and therefore refuses to merge the two versions to stop us
from trampling on our previous work. The conflict is marked in in the
affected file:
出力
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
But the Mummy will appreciate the lack of humidity
<<<<<<< HEAD
We added a different line in the other copy
=======
This line added to Wolfman's copy
>>>>>>> dabb4c8c450e8475aee9b14b4383acc99f42af1dOur change is preceded by
<<<<<<< HEAD. Git has then inserted
======= as a separator between the conflicting changes and
marked the end of the content downloaded from GitHub with
>>>>>>>. (The string of letters and
digits after that marker identifies the commit we’ve just
downloaded.)
It is now up to us to edit this file to remove these markers and reconcile the changes. We can do anything we want: keep the change made in the local repository, keep the change made in the remote repository, write something new to replace both, or get rid of the change entirely. Let’s replace both so that the file looks like this:
出力
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
But the Mummy will appreciate the lack of humidity
We removed the conflict on this lineTo finish merging, we add mars.txt to the changes being
made by the merge and then commit:
出力
On branch main
All conflicts fixed but you are still merging.
(use "git commit" to conclude merge)
Changes to be committed:
modified: mars.txt
出力
[main 2abf2b1] Merge changes from GitHubNow we can push our changes to GitHub:
出力
Enumerating objects: 10, done.
Counting objects: 100% (10/10), done.
Delta compression using up to 8 threads
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 645 bytes | 645.00 KiB/s, done.
Total 6 (delta 4), reused 0 (delta 0)
remote: Resolving deltas: 100% (4/4), completed with 2 local objects.
To https://github.com/vlad/planets.git
dabb4c8..2abf2b1 main -> mainGit keeps track of what we’ve merged with what, so we don’t have to fix things by hand again when the collaborator who made the first change pulls again:
出力
remote: Enumerating objects: 10, done.
remote: Counting objects: 100% (10/10), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 6 (delta 4), reused 6 (delta 4), pack-reused 0
Unpacking objects: 100% (6/6), done.
From https://github.com/vlad/planets
* branch main -> FETCH_HEAD
dabb4c8..2abf2b1 main -> origin/main
Updating dabb4c8..2abf2b1
Fast-forward
mars.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)We get the merged file:
出力
Cold and dry, but everything is my favorite color
The two moons may be a problem for Wolfman
But the Mummy will appreciate the lack of humidity
We removed the conflict on this lineWe don’t need to merge again because Git knows someone has already done that.
Git’s ability to resolve conflicts is very useful, but conflict resolution costs time and effort, and can introduce errors if conflicts are not resolved correctly. If you find yourself resolving a lot of conflicts in a project, consider these technical approaches to reducing them:
- Pull from upstream more frequently, especially before starting new work
- Use topic branches to segregate work, merging to main when complete
- Make smaller more atomic commits
- Push your work when it is done and encourage your team to do the same to reduce work in progress and, by extension, the chance of having conflicts
- Where logically appropriate, break large files into smaller ones so that it is less likely that two authors will alter the same file simultaneously
Conflicts can also be minimized with project management strategies:
- Clarify who is responsible for what areas with your collaborators
- Discuss what order tasks should be carried out in with your collaborators so that tasks expected to change the same lines won’t be worked on simultaneously
- If the conflicts are stylistic churn (e.g. tabs vs. spaces),
establish a project convention that is governing and use code style
tools (e.g.
htmltidy,perltidy,rubocop, etc.) to enforce, if necessary
Solving Conflicts that You Create
Clone the repository created by your instructor. Add a new file to it, and modify an existing file (your instructor will tell you which one). When asked by your instructor, pull her changes from the repository to create a conflict, then resolve it.
Conflicts on Non-textual files
What does Git do when there is a conflict in an image or some other non-textual file that is stored in version control?
Let’s try it. Suppose Dracula takes a picture of Martian surface and
calls it mars.jpg.
If you do not have an image file of Mars available, you can create a dummy binary file like this:
出力
-rw-r--r-- 1 vlad 57095 1.0K Mar 8 20:24 mars.jpgls shows us that this created a 1-kilobyte file. It is
full of random bytes read from the special file,
/dev/urandom.
Now, suppose Dracula adds mars.jpg to his
repository:
出力
[main 8e4115c] Add picture of Martian surface
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 mars.jpgSuppose that Wolfman has added a similar picture in the meantime. His
is a picture of the Martian sky, but it is also called
mars.jpg. When Dracula tries to push, he gets a familiar
message:
出力
To https://github.com/vlad/planets.git
! [rejected] main -> main (fetch first)
error: failed to push some refs to 'https://github.com/vlad/planets.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.We’ve learned that we must pull first and resolve any conflicts:
When there is a conflict on an image or other binary file, git prints a message like this:
出力
$ git pull origin main
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From https://github.com/vlad/planets.git
* branch main -> FETCH_HEAD
6a67967..439dc8c main -> origin/main
warning: Cannot merge binary files: mars.jpg (HEAD vs. 439dc8c08869c342438f6dc4a2b615b05b93c76e)
Auto-merging mars.jpg
CONFLICT (add/add): Merge conflict in mars.jpg
Automatic merge failed; fix conflicts and then commit the result.The conflict message here is mostly the same as it was for
mars.txt, but there is one key additional line:
出力
warning: Cannot merge binary files: mars.jpg (HEAD vs. 439dc8c08869c342438f6dc4a2b615b05b93c76e)Git cannot automatically insert conflict markers into an image as it does for text files. So, instead of editing the image file, we must check out the version we want to keep. Then we can add and commit this version.
On the key line above, Git has conveniently given us commit
identifiers for the two versions of mars.jpg. Our version
is HEAD, and Wolfman’s version is 439dc8c0....
If we want to use our version, we can use git checkout:
BASH
$ git checkout HEAD mars.jpg
$ git add mars.jpg
$ git commit -m "Use image of surface instead of sky"出力
[main 21032c3] Use image of surface instead of skyIf instead we want to use Wolfman’s version, we can use
git checkout with Wolfman’s commit identifier,
439dc8c0:
BASH
$ git checkout 439dc8c0 mars.jpg
$ git add mars.jpg
$ git commit -m "Use image of sky instead of surface"出力
[main da21b34] Use image of sky instead of surfaceWe can also keep both images. The catch is that we cannot keep them under the same name. But, we can check out each version in succession and rename it, then add the renamed versions. First, check out each image and rename it:
BASH
$ git checkout HEAD mars.jpg
$ git mv mars.jpg mars-surface.jpg
$ git checkout 439dc8c0 mars.jpg
$ mv mars.jpg mars-sky.jpgThen, remove the old mars.jpg and add the two new
files:
BASH
$ git rm mars.jpg
$ git add mars-surface.jpg
$ git add mars-sky.jpg
$ git commit -m "Use two images: surface and sky"出力
[main 94ae08c] Use two images: surface and sky
2 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 mars-sky.jpg
rename mars.jpg => mars-surface.jpg (100%)Now both images of Mars are checked into the repository, and
mars.jpg no longer exists.
A Typical Work Session
You sit down at your computer to work on a shared project that is tracked in a remote Git repository. During your work session, you take the following actions, but not in this order:
-
Make changes by appending the number
100to a text filenumbers.txt - Update remote repository to match the local repository
- Celebrate your success with some fancy beverage(s)
- Update local repository to match the remote repository
- Stage changes to be committed
- Commit changes to the local repository
In what order should you perform these actions to minimize the chances of conflicts? Put the commands above in order in the action column of the table below. When you have the order right, see if you can write the corresponding commands in the command column. A few steps are populated to get you started.
| order | action . . . . . . . . . . | command . . . . . . . . . . |
|---|---|---|
| 1 | ||
| 2 | echo 100 >> numbers.txt |
|
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | Celebrate! |
| order | action . . . . . . | command . . . . . . . . . . . . . . . . . . . |
|---|---|---|
| 1 | Update local | git pull origin main |
| 2 | Make changes | echo 100 >> numbers.txt |
| 3 | Stage changes | git add numbers.txt |
| 4 | Commit changes | git commit -m "Add 100 to numbers.txt" |
| 5 | Update remote | git push origin main |
| 6 | Celebrate! |
まとめ
- Conflicts occur when two or more people change the same lines of the same file.
- The version control system does not allow people to overwrite each other’s changes blindly, but highlights conflicts so that they can be resolved.
Content from オープン サイエンス
最終更新日：2024-06-06 | ページの編集
所要時間： 10分
概要
質問
- バージョン管理は、私の研究をよりオープンにするのにどのように役立ちますか?
目的
- バージョン管理システムを計算実験用の電子実験ノートとしてどのように活用できるか説明しましょう。
“open” の反対は “closed” ではありません。 “open” の反対は “broken” です。
-– John Wilbanks
科学では情報を自由に共有することが理想的かもしれませんが、現実はもっと複雑なことがよくあります。 最近のよくあるやり方は次のようになります。
- 科学者は何らかのデータを収集し、それを自分の部門によって時折バックアップされるマシンに保存します。
- 次に、科学者はそのデータを分析するために、いくつかの小さなプログラム（これもその科学者のマシンにあります）を作成または変更します。
- 結果が出たら、それを書き留めて論文を提出します。 科学者は自分のデータを含めるかもしれません – ますます多くのジャーナルがこれを必要としています – しかし科学者はおそらく自分のコードを含めていません。
- 時間が経過します。
- ジャーナルは、科学者の分野の他の少数の人々によって匿名で書かれたレビューを科学者に送信します。 科学者はレビューした人を納得させるために自分の論文を改訂し、その間に科学者は以前に書いたスクリプトを修正し、論文を再提出するかもしれません。
- さらに時間が経過します。
- ついに論文が出版されます。 科学者のデータのオンラインコピーへのリンクが含まれている可能性がありますが、論文自体はペイウォールの背後にあるでしょう：個人的または組織的なアクセス権を持つ人だけがそれを読むことができるでしょう。
しかし、ますます多くの科学者にとって、そのプロセスは次のようになります:
- figshareやZenodoなどのオープンアクセスリポジトリに保存され、独自のデジタルオブジェクト識別子 (DOI) が与えられます。 または、データはすでに公開されており、Dryad に保存されています。
- 科学者は、自分の研究を保持するためにGitHubに新しいリポジトリを作成します。
- 科学者は分析を行うときに、スクリプト (場合によってはいくつかの出力ファイルも) への変更をそのリポジトリにプッシュします。 科学者はまた、自分の論文用にそのリポジトリを使用します；そしてそのリポジトリは、同僚とのコラボレーションのハブになります。
- 論文の状態に満足したら、arXivまたはその他のプレプリントサーバーに版を投稿し、仲間からのフィードバックを求めます。
- そのフィードバックに基づいて、科学者は最終的に論文をジャーナルに投稿する前に、いくつかの改訂を投稿する可能性があります。
- 公開された論文には、科学者のプレプリントとコードそしてデータリポジトリへのリンクが含まれているため、他の科学者が論文の研究を自分の研究の出発点として使用するのがはるかに簡単になります。
このオープンモデルは発見を加速します：研究結果がオープンになっていればなっているほど、 広く引用され、再利用されます。 ただし、このように作業したい人は、正確に “オープン” が何を意味し、それをどのように行うかについて、いくつかの決定を下す必要があります。 この本では、オープンサイエンスのさまざまな側面について詳しく知ることができます。
これは、バージョン管理を教える (多くの) 理由の1つです。 コツコツと使うと、計算作業のための共有可能な電子ラボノートとして機能することによって、 バージョン管理は “どのように” の質問に答えてくれます：
- 誰がいつ何をしたかなど、作業の概念的な段階が文書化されています。 すべてのステップには、（ほとんどの場合）固有の識別子 (コミットID) がスタンプされています。
- 理論的根拠、アイデア、およびその他の知的作業の文書化を、それらから生じる変化に直接結び付けることができます。
- 独自の回復可能な方法で計算結果を取得するために、研究で使用したものを参照できるようになります。
- Gitなどのバージョン管理システムを使用すると、リポジトリの履歴全体を簡単にアーカイブして永続化できます。
コードを引用可能にすること
バージョン管理リポジトリでホストされているもの（データ、コード、論文など）はすべて、 引用可能なオブジェクトに変換できます。これを行う方法は、 これを行う方法は、レッスン 12: 引用で学習します。
私の仕事はどれくらい再現可能ですか？
ラボメイトの1人に、あなたの論文やウェブで見つけることができるものだけを使用して、あなたが最近得た結果を再現するように依頼してみましょう。 ラボメイトの結果の1つに対して同じことを行ってみてから、あなたの研究室由来の結果にそれを行ってみてください。
適切なデータリポジトリを見つける方法は?
数分間インターネットサーフィンして、次のデータリポジトリをチェックしてみましょう：Figshare, Zenodo、Dryad。 研究分野によっては、その分野でよく知られたコミュニティで認められたリポジトリが見つかるかもしれません。 Natureが推奨するこれらのデータリポジトリも便利かもしれません。 現在のプロジェクト用にどのデータリポジトリにアプローチしたいかを隣人と議論し、その理由を説明してみましょう。
How to Track Large Data or Image Files using Git?
Large data or image files such as .md5 or
.psd file types can be tracked within a github repository
using the Git Large File
Storage open source extension tool. This tool automatically uploads
large file contents to a remote server and replaces the file with a text
pointer within the github repository.
Try downloading and installing the Git Large File Storage extension tool, then add tracking of a large file to your github repository. Ask a colleague to clone your repository and describe what they see when they access that large file.
まとめ
- オープンな科学的研究は、クローズドよりも有用であり、引用数が多い。
Content from Licensing
最終更新日：2024-06-06 | ページの編集
所要時間： 5分
概要
質問
- What licensing information should I include with my work?
目的
- Explain why adding licensing information to a repository is important.
- Choose a proper license.
- Explain differences in licensing and social expectations.
When a repository with source code, a manuscript or other creative
works becomes public, it should include a file LICENSE or
LICENSE.txt in the base directory of the repository that
clearly states under which license the content is being made available.
This is because creative works are automatically eligible for
intellectual property (and thus copyright) protection. Reusing creative
works without a license is dangerous, because the copyright holders
could sue you for copyright infringement.
A license solves this problem by granting rights to others (the licensees) that they would otherwise not have. What rights are being granted under which conditions differs, often only slightly, from one license to another. In practice, a few licenses are by far the most popular, and choosealicense.com will help you find a common license that suits your needs. Important considerations include:
- Whether you want to address patent rights.
- Whether you require people distributing derivative works to also distribute their source code.
- Whether the content you are licensing is source code.
- Whether you want to license the code at all.
Choosing a license that is in common use makes life easier for contributors and users, because they are more likely to already be familiar with the license and don’t have to wade through a bunch of jargon to decide if they’re ok with it. The Open Source Initiative and Free Software Foundation both maintain lists of licenses which are good choices.
This article provides an excellent overview of licensing and licensing options from the perspective of scientists who also write code.
At the end of the day what matters is that there is a clear statement as to what the license is. Also, the license is best chosen from the get-go, even if for a repository that is not public. Pushing off the decision only makes it more complicated later, because each time a new collaborator starts contributing, they, too, hold copyright and will thus need to be asked for approval once a license is chosen.
Can I Use Open License?
Find out whether you are allowed to apply an open license to your software. Can you do this unilaterally, or do you need permission from someone in your institution? If so, who?
What licenses have I already accepted?
Many of the software tools we use on a daily basis (including in this
workshop) are released as open-source software. Pick a project on GitHub
from the list below, or one of your own choosing. Find its license
(usually in a file called LICENSE or COPYING)
and talk about how it restricts your use of the software. Is it one of
the licenses discussed in this session? How is it different?
まとめ
- The
LICENSE,LICENSE.md, orLICENSE.txtfile is often used in a repository to indicate how the contents of the repo may be used by others. - People who incorporate General Public License (GPL’d) software into their own software must make their software also open under the GPL license; most other open licenses do not require this.
- The Creative Commons family of licenses allow people to mix and match requirements and restrictions on attribution, creation of derivative works, further sharing, and commercialization.
- People who are not lawyers should not try to write licenses from scratch.
Content from Citation
最終更新日：2024-09-30 | ページの編集
所要時間： 2分
概要
質問
- How can I make my work easier to cite?
目的
- Make your work easy to cite
You may want to include a file called CITATION or
CITATION.txt that describes how to reference your project;
the one for Software Carpentry states:
To reference Software Carpentry in publications, please cite:
Greg Wilson: "Software Carpentry: Lessons Learned". F1000Research,
2016, 3:62 (doi: 10.12688/f1000research.3-62.v2).
@online{wilson-software-carpentry-2016,
author = {Greg Wilson},
title = {Software Carpentry: Lessons Learned},
version = {2},
date = {2016-01-28},
url = {http://f1000research.com/articles/3-62/v2},
doi = {10.12688/f1000research.3-62.v2}
}More detailed advice, and other ways to make your code citable can be found at the Software Sustainability Institute blog and in:
Smith AM, Katz DS, Niemeyer KE, FORCE11 Software Citation Working Group. (2016) Software citation
principles. [PeerJ Computer Science 2:e86](https://peerj.com/articles/cs-86/)
https://doi.org/10.7717/peerj-cs.8There is also an @software{...
BibTeX entry type in case
no “umbrella” citation like a paper or book exists for the project you
want to make citable.
まとめ
- Add a CITATION file to a repository to explain how you want your work cited.
Content from Hosting
最終更新日：2024-09-30 | ページの編集
所要時間： 10分
概要
質問
- バージョン管理リポジトリはどこでホストすればよいでしょうか?
目的
- 科学研究のホスティングのためのさまざまなオプションについて説明します。
After choosing a license, another big question for groups that want to open up their work is where to host their code and data. 1 つのオプションは、研究室、学部、または大学がサーバーを提供し、アカウントやバックアップなどを管理することです。 これの主な利点は、誰が何を所有しているかを明確にすることです。 それは、題材が機密性の高いもの (すなわち、ヒトを対象とする実験に関するもの、または特許出願に使用される可能性のあるもの) である場合に特に重要です。 主な欠点は、サービスの提供コストとその存続期間です。データ収集に 10 年を費やした科学者は、10 年後もデータが利用できることを確認したいと考えますが、それは学術インフラに資金提供されるほとんど助成金の存続期間をはるかに超えています。
もう 1 つのオプションは、ドメインを購入し、それをホストするためにインターネット サービス プロバイダー (ISP) に料金を支払うことです。 これにより、個人またはグループによる制御が強化され、ある機関から別の機関に移動するときに発生する可能性のある問題を回避できます。 ただし、上記のオプションまたは下記のオプションよりもセットアップに多くの時間と労力が必要です。
3 番目のオプションは、 GitHub、 GitLab、または BitBucket のようなパブリック ホスティング サービスを使用することです。 これらの各サービスは、コードリポジトリを作成、閲覧、編集できる Web インターフェイスを提供します。 これらのサービスは、イシュートラッキング、Wiki ページ、メール通知、コードレビューなどのコミュニケーションやプロジェクト管理ツールも提供します。 These services benefit from economies of scale and network effects: it’s easier to run one large service well than to run many smaller services to the same standard. It’s also easier for people to collaborate. Using a popular service can help connect your project with communities already using the same service.
As an example, Software Carpentry is on GitHub where you can find the source for this page. Anyone with a GitHub account can suggest changes to this text.
GitHub repositories can also be assigned DOIs, by connecting its
releases to Zenodo. For example, 10.5281/zenodo.7908089
is the DOI that has been “minted” for this introduction to Git.
Using large, well-established services can also help you quickly take advantage of powerful tools. One such tool, continuous integration (CI), can automatically run software builds and tests whenever code is committed or pull requests are submitted. Direct integration of CI with an online hosting service means this information is present in any pull request, and helps maintain code integrity and quality standards. While CI is still available in self-hosted situations, there is much less setup and maintenance involved with using an online service. Furthermore, such tools are often provided free of charge to open source projects, and are also available for private repositories for a fee.
Institutional Barriers
Sharing is the ideal for science, but many institutions place restrictions on sharing, for example to protect potentially patentable intellectual property. If you encounter such restrictions, it can be productive to inquire about the underlying motivations and either to request an exception for a specific project or domain, or to push more broadly for institutional reform to support more open science.
Can My Work Be Public?
Find out whether you are allowed to host your work openly in a public repository. Can you do this unilaterally, or do you need permission from someone in your institution? If so, who?
まとめ
- Projects can be hosted on university servers, on personal domains, or on a public hosting service.
- Rules regarding intellectual property and storage of sensitive information apply no matter where code and data are hosted.
Content from Supplemental: Using Git from RStudio
最終更新日：2024-09-30 | ページの編集
所要時間： 10分
概要
質問
- How can I use Git with RStudio?
目的
- Understand how to use Git from RStudio.
Version control can be very useful when developing data analysis scripts. For that reason, the popular development environment RStudio for the R programming language has built-in integration with Git. While some advanced Git features still require the command-line, RStudio has a nice interface for many common Git operations.
RStudio allows us to create a project associated with a given directory to keep track of various related files. To be able to track the development of the project over time, to be able to revert to previous versions, and to collaborate with others, we version control the Rstudio project with Git. To get started using Git in RStudio, we create a new project:
This opens a dialog asking us how we want to create the project. We have some options here. Let’s say that we want to use RStudio with the planets repository that we already made. Since that repository lives in a directory on our computer, we choose the option “Existing Directory”:
Do You See a “Version Control” Option?
Although we’re not going to use it here, there should be a “version control” option on this menu. That is what you would click on if you wanted to create a project on your computer by cloning a repository from GitHub. If that option is not present, it probably means that RStudio doesn’t know where your Git executable is, and you won’t be able to progress further in this lesson until you tell RStudio where it is.
Find your Git Executable
First let’s make sure that Git is installed on your computer. Open your shell on Mac or Linux, or on Windows open the command prompt and then type:
-
which git(macOS, Linux) -
where git(Windows)
If there is no version of Git on your computer, please follow the Git
installation instructions in the setup of this lesson to install Git
now. Next open your shell or command prompt and type
which git (macOS, Linux), or where git
(Windows). Copy the path to the git executable.
On one Windows computer which had GitHub Desktop installed on it, the
path was:
C:/Users/UserName/AppData/Local/GitHubDesktop/app-1.1.1/resources/app/git/cmd/git.exe
NOTE: The path on your computer will be somewhat different.
Next, RStudio will ask which existing directory we want to use. Click “Browse…” and navigate to the correct directory, then click “Create Project”:
Ta-da! We have created a new project in RStudio within the existing planets repository. Notice the vertical “Git” menu in the menu bar. RStudio has recognized that the current directory is a Git repository, and gives us a number of tools to use Git:
To edit the existing files in the repository, we can click on them in the “Files” panel on the lower right. Now let’s add some additional information about Pluto:
Once we have saved our edited files, we can use RStudio to commit the changes by clicking on “Commit…” in the Git menu:
This will open a dialogue where we can select which files to commit
(by checking the appropriate boxes in the “Staged” column), and enter a
commit message (in the upper right panel). The icons in the “Status”
column indicate the current status of each file. Clicking on a file
shows information about changes in the lower panel (using output of
git diff). Once everything is the way we want it, we click
“Commit”:
The changes can be pushed by selecting “Push Branch” from the Git menu. There are also options to pull from the remote repository, and to view the commit history:
Are the Push/Pull Commands Grayed Out?
Grayed out Push/Pull commands generally mean that RStudio doesn’t
know the location of your remote repository (e.g. on GitHub). To fix
this, open a terminal to the repository and enter the command:
git push -u origin main. Then restart RStudio.
If we click on “History”, we can see a graphical version of what
git log would tell us:
RStudio creates a number of files that it uses to keep track of a
project. We often don’t want to track these, in which case we add them
to our .gitignore file:
Tip: versioning disposable output
Generally you do not want to version control disposable output (or
read-only data). You should modify the .gitignore file to
tell Git to ignore these files and directories.
チャレンジ
- Create a new directory within your project called
graphs. - Modify the
.gitignoreso that thegraphsdirectory is not version controlled.
This can be done in Rstudio:
R
dir.create("./graphs")
Then open up the .gitignore file from the right-hand
panel of Rstudio and add graphs/ to the list of files to
ignore.
There are many more features in the RStudio Git menu, but these should be enough to get you started!
まとめ
- Using RStudio’s Git integration allows you to version control a project over time.
Comment Changes in GitHub
The Collaborator has some questions about one line change made by the Owner and has some suggestions to propose.
With GitHub, it is possible to comment on the diff of a commit. Over the line of code to comment, a blue comment icon appears to open a comment window.
The Collaborator posts her comments and suggestions using the GitHub interface.