diff --git a/01-basics.md b/01-basics.md index c7ec16717..8dc65711f 100644 --- a/01-basics.md +++ b/01-basics.md @@ -1,78 +1,118 @@ --- -title: 自動的なバージョン管理 +title: Automated Version Control teaching: 5 exercises: 0 --- ::::::::::::::::::::::::::::::::::::::: objectives -- 自動バージョン管理システムの利点を理解しましょう。 -- 自動バージョン管理システムの仕組みの基本を理解しましょう。 +- Understand the benefits of an automated version control system. +- Understand the basics of how automated version control systems work. :::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::: questions -- バージョン管理とは何で、なぜそれを使うべきなのでしょうか? +- What is version control and why should I use it? :::::::::::::::::::::::::::::::::::::::::::::::::: -それではまず、どのようにしてバージョン管理システムが 「いつ」、「何」を、「誰」が編集したのかを記録・管理しているかを見ていきましょう。 -他の人と共同作業をしていなくても、 以下の状況に陥るより、自動的なバージョン管理を使うほうが大分良いはずです： +We'll start by exploring how version control can be used +to keep track of what one person did and when. +Even if you aren't collaborating with other people, +automated version control is much better than this situation: -![「高く、深く積み上げる」Jorge Cham 作、 https://www.phdcomics.com](fig/phd101212s.png){alt='Comic: a PhD student sends "FINAL.doc" to their supervisor, but after several increasingly intense and frustrating rounds of comments and revisions they end up with a file named "FINAL_rev.22.comments49.corrections.10.#@$%WHYDIDCOMETOGRADSCHOOL????.doc"'} +!["notFinal.doc" by Jorge Cham, ](fig/phd101212s.png){alt='Comic: a PhD student sends "FINAL.doc" to their supervisor, but after several increasingly intense and frustrating rounds of comments and revisions they end up with a file named "FINAL_rev.22.comments49.corrections.10.#@$%WHYDIDCOMETOGRADSCHOOL????.doc"'} -皆さんもこんな経験をされたことがあるはずです。複数の、（それもほとんど 内容が同じの）文書のコピーを保存しておくのは馬鹿げたことです。 文書作成ソフトの中には、例えばMicrosoft Wordの[変更履歴](https://support.office.com/en-us/article/Track-changes-in-Word-197ba630-0f5f-4a8e-9a77-3712475e806a)、Google Docsの[バージョン履歴](https://support.google.com/docs/answer/190843?hl=en)、LibreOfficeの[変更の記録・表示](https://help.libreoffice.org/Common/Recording_and_Displaying_Changes)、こういった状況にある程度うまく対応できるものもあります。 +We've all been in this situation before: it seems unnecessary to have +multiple nearly-identical versions of the same document. Some word +processors let us deal with this a little better, such as Microsoft +Word's +[Track Changes](https://support.office.com/en-us/article/Track-changes-in-Word-197ba630-0f5f-4a8e-9a77-3712475e806a), +Google Docs' [version history](https://support.google.com/docs/answer/190843?hl=en), or +LibreOffice's [Recording and Displaying Changes](https://help.libreoffice.org/Common/Recording_and_Displaying_Changes). -バージョン管理システムは、基礎となるドキュメントを元に、 加えられた全ての変更点を記録していきます。 バージョン管理システムは、基礎となるドキュメントを元に、 -加えられた全ての変更点を記録していきます。ドキュメントの -進歩を記録していると考えてもらって構いません。変更点を最初の状況まで -戻してから、最新版になるまでの変更を一つずつ再現していくことができます。 +Version control systems start with a base version of the document and +then record changes you make each step of the way. You can +think of it as a recording of your progress: you can rewind to start at the base +document and play back each change you made, eventually arriving at your +more recent version. -![](fig/play-changes.svg){alt='変更は連続して保存されます'} +![](fig/play-changes.svg){alt='Changes Are Saved Sequentially'} -「変更点」と「ドキュメント」を別々の物として考えてみると、基礎となるドキュメントに -異なる変更点を「再現」する事によって、結果的に違ったバージョンのドキュメントを -作る事が可能だという事が分かります。 例えば、下の図のように二人のユーザーが同じドキュメントに違った編集を加えた場合です。 +Once you think of changes as separate from the document itself, you +can then think about "playing back" different sets of changes on the base document, ultimately +resulting in different versions of that document. For example, two users can make independent +sets of changes on the same document. -![](fig/versions.svg){alt='異なるバージョンの保存ができます'} +![](fig/versions.svg){alt='Different Versions Can be Saved'} -変更点の衝突（コンフリクト）が無ければ、二つ以上の違った変更点を基礎ドキュメントに加えることさえできます。 +Unless multiple users make changes to the same section of the document - a conflict - you can +incorporate two sets of changes into the same base document. -![](fig/merge.svg){alt='複数のバージョンをマージできます'} +![](fig/merge.svg){alt='Multiple Versions Can be Merged'} -バージョン管理システムは、ユーザーがドキュメントに加えた変更点を記録するツールであり、 結果的にドキュメントの違ったバージョンを作成する事ができます。 このツールを活用 する事によって、次のバージョンに加える変更点（個々の変更点は 「[commit（コミット）](../learners/reference.md#commit)」と呼びます）を決める事ができ、変更点に関するメタデータも一緒に保存する事ができます。 特定のプロジェクトのコミット履歴とそれに関するメタデータを総じて 「[repository（リポジトリ）](\(../learners/reference.md#repository\))」と呼びます。 -リポジトリは 別々のコンピュータと同期させる事が出来るので、他人との共同作業を潤滑に進めることが可能になります。 +A version control system is a tool that keeps track of these changes for us, +effectively creating different versions of our files. It allows us to decide +which changes will be made to the next version (each record of these changes is +called a [commit](../learners/reference.md#commit)), and keeps useful metadata +about them. The complete history of commits for a particular project and their +metadata make up a [repository](../learners/reference.md#repository). +Repositories can be kept in sync across different computers, facilitating +collaboration among different people. ::::::::::::::::::::::::::::::::::::::::: callout -## バージョン管理システムの長い歴史 +## The Long History of Version Control Systems + +Automated version control systems are nothing new. +Tools like [RCS](https://en.wikipedia.org/wiki/Revision_Control_System), [CVS](https://en.wikipedia.org/wiki/Concurrent_Versions_System), or [Subversion](https://en.wikipedia.org/wiki/Apache_Subversion) have been around since the early 1980s and are used by +many large companies. +However, many of these are now considered legacy systems (i.e., outdated) due to various +limitations in their capabilities. +More modern systems, such as Git and [Mercurial](https://swcarpentry.github.io/hg-novice/), +are *distributed*, meaning that they do not need a centralized server to host the repository. +These modern systems also include powerful merging tools that make it possible for +multiple authors to work on +the same files concurrently. -自動化されたバージョン管理システムは最近発明されたものではありません。 -[RCS](https://ja.wikipedia.org/wiki/Revision_Control_System)、[CVS](https://ja.wikipedia.org/wiki/Concurrent_Versions_System)、[Subversion](https://ja.wikipedia.org/wiki/Apache_Subversion)などのツールは1980年前半から存在しており、多くの会社に使われていました。 -しかし、これらのツールでは出来る事に制限があり、多くはもう時代遅れとされています。 -現代使われているシステム、例えばGitや[Mercurial](https://swcarpentry.github.io/hg-novice/)、は _分散_されています。というのは、特定のサーバーを必要とせずにシステムをホストする事が出来るという事です。 -現代のシステムには大変便利で効果的な「merge（マージ）」機能が備われており、同じファイルを 複数人で作業する事が可能になりました。 :::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::: challenge -## 論文を書くにあたって +## Paper Writing -- 例えば、論文のために数百行書いたとします。しばらくして、間違えてその文章を編集してしまいます。 どうしたら以前書いた文章を取り戻すことができるのでしょう？ そもそも、可能なのでしょうか？ +- Imagine you drafted an excellent paragraph for a paper you are writing, but later ruin + it. How would you retrieve the *excellent* version of your conclusion? Is it even possible? -- 五人の共著者がいるとします。 どうやって全員の変更やコメントを管理すれば良いのでしょう？ LibreOffice WriterやMicrosoft Wordの場合、こういった変更やコメントを変更履歴機能で受け入れると どうなるのでしょう？ 変更点は記録されるのでしょうか？ +- Imagine you have 5 co-authors. How would you manage the changes and comments + they make to your paper? If you use LibreOffice Writer or Microsoft Word, what happens if + you accept changes made using the `Track Changes` option? Do you have a + history of those changes? ::::::::::::::: solution -## 解答 - -- 以前書いた数百行の回復は、古いバージョンの論文のコピーを作成した場合にのみ可能です。 前に書いた文章を失う危険性は、このページの上にある漫画に描かれているような問題のあるワークフローになることが多いです。 - -- 従来のワープロを使った共同執筆は面倒です。 - すべての共同作業者が文書に順番に書く（執筆のプロセスを遅らせる）か、一つのバージョンをすべての全員に送り、手作業で彼らのコメントをあなたの文書にマージしなければなりません。 「変更の追跡」または「変更の記録」オプションは、変更をハイライトし、マージを簡略化することができますが、変更を受け入れるとすぐにその履歴が失われます。 そうなると、誰がその変更を提案したのか、なぜそれが提案されたのか、いつ文書にマージされたのか、わからなくなります。 - Google DocsやMicrosoft Office Onlineのようなオンライン・ワープロでさえ、こうした問題を完全に解決することはできません。 +## Solution + +- Recovering the excellent version is only possible if you created a copy + of the old version of the paper. The danger of losing good versions + often leads to the problematic workflow illustrated in the PhD Comics + cartoon at the top of this page. + +- Collaborative writing with traditional word processors is cumbersome. + Either every collaborator has to work on a document sequentially + (slowing down the process of writing), or you have to send out a + version to all collaborators and manually merge their comments into + your document. The 'track changes' or 'record changes' option can + highlight changes for you and simplifies merging, but as soon as you + accept changes you will lose their history. You will then no longer + know who suggested that change, why it was suggested, or when it was + merged into the rest of the document. Even online word processors like + Google Docs or Microsoft Office Online do not fully resolve these + problems. + + ::::::::::::::::::::::::: @@ -80,7 +120,9 @@ exercises: 0 :::::::::::::::::::::::::::::::::::::::: keypoints -- バージョン管理とは、制限無く「元に戻す」ことができる機能。 -- バージョン管理を使えば、複数の人と同時進行で作業をする事ができます。 +- Version control is like an unlimited 'undo'. +- Version control also allows many people to work in parallel. :::::::::::::::::::::::::::::::::::::::::::::::::: + + diff --git a/02-setup.md b/02-setup.md index 928e7be90..cb0b91595 100644 --- a/02-setup.md +++ b/02-setup.md @@ -1,67 +1,82 @@ --- -title: Gitの設定 +title: Setting Up Git teaching: 5 -exercises: Vim の終了の仕方 +exercises: 0 --- ::::::::::::::::::::::::::::::::::::::: objectives -- コンピュータで初めて `git` を使うための設定が出来るようになりましょう。 -- `--global` 設定フラグの意味を理解しましょう。 +- Configure `git` the first time it is used on a computer. +- Understand the meaning of the `--global` configuration flag. :::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::: questions -- Git を使うために必要な設定は何ですか？ +- How do I get set up to use Git? :::::::::::::::::::::::::::::::::::::::::::::::::: -Git を新しいパソコンで初めて使う場合、いくつかの設定を変更しなければなりません。 Git を始めるにあたって、私達が変更する設定をいくつか表記します： +When we use Git on a new computer for the first time, +we need to configure a few things. Below are a few examples +of configurations we will set as we get started with Git: -- 名前とメールアドレス、 -- 使用したいテキストエディタ、 -- 以上の設定をグローバル設定として使う（つまり、全てのプロジェクトに反映させる）。 +- our name and email address, +- what our preferred text editor is, +- and that we want to use these settings globally (i.e. for every project). -コマンドラインでは、Git コマンドは `git <動詞> <オプション>` と入力します。ここでの「動詞」は、Git に何をさせたいのかを表し、「オプション」はその動詞にとって必要とされる追加の情報です。 ドラキュラが新しいユーザーの場合、以下のようにコンピュータを設定します： +On a command line, Git commands are written as `git verb options`, +where `verb` is what we actually want to do and `options` is additional optional information which may be needed for the `verb`. So here is how +Dracula sets up his new laptop: ```bash -Vim の終了の仕方 +$ git config --global user.name "Vlad Dracula" +$ git config --global user.email "vlad@tran.sylvan.ia" ``` -ここでは、ドラキュラの代わりに自分の名前とメールアドレスを使いましょう。 ここで入力した名前とメールアドレスは、これから行う Git での作業に関わってきます。というのも、これからのレッスンで[GitHub](https://github.com/)、[BitBucket](https://bitbucket.org/)、[GitLab](https://gitlab.com/)、またはその他のGit をホストするサーバーに変更箇所を「プシュ」した（送った）際に、これらの情報が使われるからです。 +Please use your own name and email address instead of Dracula's. This user name and email will be associated with your subsequent Git activity, +which means that any changes pushed to +[GitHub](https://github.com/), +[BitBucket](https://bitbucket.org/), +[GitLab](https://gitlab.com/) or +another Git host server +after this lesson will include this information. -これらのレッスンでは、[GitHub](https://github.com/) に接続するので、GitHub アカウントと同じメールアドレスに設定してください。 プライバシーについて気になる方は、[GitHub のメールアドレスをプライベートにするための説明][git-privacy] を参照してください。 +For this lesson, we will be interacting with [GitHub](https://github.com/) and so the email address used should be the same as the one used when setting up your GitHub account. If you are concerned about privacy, please review [GitHub's instructions for keeping your email address private][git-privacy]. ::::::::::::::::::::::::::::::::::::::::: callout -## 電子メールの非公開 +## Keeping your email private + +If you elect to use a private email address with GitHub, then use that same email address for the `user.email` value, e.g. `username@users.noreply.github.com` replacing `username` with your GitHub one. -GitHub でプライベートのメールアドレスを使う場合は、同じメールアドレスを `user.email` の値に設定してください（例：`username@users.noreply.github.com`）。 :::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::::: callout -## 改行コード +## Line Endings -他のキーと同様に、キーボードで Enter または ↵ （またはMacでは Return）を押すと、コンピュータはそれを文字として入力します。 -話が長くなるので詳しい説明は省きますが、行末に使われる文字はオペレーティングシステム（OS）よって違います。 -（行末に使われる文字を「改行コード」と呼びます。） -Git は、改行コードを使ってファイルの違いを確かめるため、違うパソコンでファイルを編集した時に思わぬ問題が起こるかもしれません。 -このレッスンの範囲外ですが、この問題については -[Pro Git book](https://www.git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#_core_autocrlf) を読んでください。 +As with other keys, when you hit Enter or ↵ or on Macs, Return on your keyboard, +your computer encodes this input as a character. +Different operating systems use different character(s) to represent the end of a line. +(You may also hear these referred to as newlines or line breaks.) +Because Git uses these characters to compare files, +it may cause unexpected issues when editing a file on different machines. +Though it is beyond the scope of this lesson, you can read more about this issue +[in the Pro Git book](https://www.git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#_core_autocrlf). -Git がどのように改行コードを理解・変換するかは、 `git config` の `core.autocrlf` コマンドを使って変更できます。 -以下の設定をおすすめします： +You can change the way Git recognizes and encodes line endings +using the `core.autocrlf` command to `git config`. +The following settings are recommended: -macOS および Linux: +On macOS and Linux: ```bash $ git config --global core.autocrlf input ``` -またはWindowsの場合: +And on Windows: ```bash $ git config --global core.autocrlf true @@ -69,38 +84,42 @@ $ git config --global core.autocrlf true :::::::::::::::::::::::::::::::::::::::::::::::::: -以下の表を参考に、ドラキュラはテキストエディタも設定しました： - -| エディタ | 設定コマンド | -| :------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------- | -| 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"` | - -設定したテキストエディタもいつでも変更することができます。 +Dracula also has to set his favorite text editor, following this table: + +| Editor | Configuration command | +| :----------- | :------------------------------ | +| Atom | `$ git config --global core.editor "atom --wait"` | +| nano | `$ git config --global core.editor "nano -w"` | +| BBEdit (Mac, with command line tools) | `$ 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-bit install) | `$ git config --global core.editor "'c:/program files (x86)/sublime text 3/sublime_text.exe' -w"` | +| Sublime Text (Win, 64-bit install) | `$ git config --global core.editor "'c:/program files/sublime text 3/sublime_text.exe' -w"` | +| Notepad (Win) | `$ git config --global core.editor "c:/Windows/System32/notepad.exe"` | +| Notepad++ (Win, 32-bit install) | `$ git config --global core.editor "'c:/program files (x86)/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"` | +| Notepad++ (Win, 64-bit install) | `$ 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"` | + +It is possible to reconfigure the text editor for Git whenever you want to change it. ::::::::::::::::::::::::::::::::::::::::: callout -## Vim の終了の仕方 +## Exiting Vim + +Note that Vim is the default editor for many programs. If you haven't used Vim before and wish to exit a session without saving +your changes, press Esc then type `:q!` and hit Enter or ↵ or on Macs, Return. +If you want to save your changes and quit, press Esc then type `:wq` and hit Enter or ↵ or on Macs, Return. -多くのソフトの初期設定では、Vim がデフォルトのテキストエディタに設定されています。 保存せずに Vim を終了するには、Escを押した後に `:q!` と入力してからEnterまたは↵（Macの場合はReturn）を押してください。 -保存してから終了するには、Escを押してから `:wq` と入力してEnterまたは↵（Mac の場合は Return）を押してください。 :::::::::::::::::::::::::::::::::::::::::::::::::: -Git (2.28以上) では、新しいリポジトリを初期化したときに作成されるブランチの名前を設定できます。 ドラキュラはその機能を使って、最終的に使うクラウドサービスと一致するように`main`に設定することにします。 +Git (2.28+) allows configuration of the name of the branch created when you +initialize any new repository. Dracula decides to use that feature to set it to `main` so +it matches the cloud service he will eventually use. ```bash $ git config --global init.defaultBranch main @@ -108,54 +127,61 @@ $ git config --global init.defaultBranch main ::::::::::::::::::::::::::::::::::::::::: callout -## Gitブランチ名の設定 +## Default Git branch naming -ソースファイルのどんな変更でも、ある「ブランチ」に属しています。 -このレッスンの新しい学習者にとっては、ブランチが存在し、このレッスンでは1つのブランチを使うことを知っていれば十分です。\ -デフォルトでは、`git init` で新しいリポジトリを作成すると、Git が`master` -というブランチを作成します (次のエピソードで説明します)。 この用語は、 -人身売買という人種差別的慣習を想起させ、 -[ソフトウェア開発コミュニティ](https://github.com/github/renaming) は、 -より包括的な言葉を採用するように動いています。 +Source file changes are associated with a "branch." +For new learners in this lesson, it's enough to know that branches exist, and this lesson uses one branch. +By default, Git will create a branch called `master` +when you create a new repository with `git init` (as explained in the next Episode). This term evokes +the racist practice of human slavery and the +[software development community](https://github.com/github/renaming) has moved to adopt +more inclusive language. -2020年には、ほとんどのGit ホスティングサービスは、`main`をデフォルトの -ブランチとして使うように移行しました。 例として、GitHub やGitLab で新規に開いたリポジトリのデフォルトは -`main`です。 しかし、Gitはまだ同じ変更を行っていません。 その結果、ローカル・リポジトリは、ほとんどのクラウド・サービスと同じブランチ名を手動で設定する必要があります。 +In 2020, most Git code hosting services transitioned to using `main` as the default +branch. As an example, any new repository that is opened in GitHub and GitLab default +to `main`. However, Git has not yet made the same change. As a result, local repositories +must be manually configured have the same main branch name as most cloud services. -2.28より前のバージョンのGitでは、個々のリポジトリで変更が可能です。 そのためのコマンドは次回のエピソードで紹介します。 ローカルのGit の設定でこの値が設定されていない場合、`init.defaultBranch` のデフォルト値は `master` になることに注意しましょう。 +For versions of Git prior to 2.28, the change can be made on an individual repository level. The +command for this is in the next episode. Note that if this value is unset in your local Git +configuration, the `init.defaultBranch` value defaults to `master`. :::::::::::::::::::::::::::::::::::::::::::::::::: -上記の5つのコマンドは、一度実行するだけで十分です。`--global` フラグは Git に、 -今使っているパソコン内にある自分のアカウントに関連する全てのプロジェクトに同じ設定をするように指示しています。 +The five commands we just ran above only need to be run once: the flag `--global` tells Git +to use the settings for every project, in your user account, on this computer. -さっそくこれらの設定を確認し、`core.editor`をテストしてみましょう： +Let's review those settings and test our `core.editor` right away: ```bash $ git config --global --edit ``` -追加の変更を加えずにファイルを閉じましょう。 設定ファイルのタイプミスは問題を引き起こすため、以下のように設定を表示する方が安全です。 +Let's close the file without making any additional changes. Remember, since typos in the config file will cause +issues, it's safer to view the configuration with: ```bash $ git config --list ``` -また、必要であれば、同じコマンドを使えば、違うエディタやメールアドレスに変えることができます。 -これは何度でもできます。 +And if necessary, change your configuration using the +same commands to choose another editor or update your email address. +This can be done as many times as you want. ::::::::::::::::::::::::::::::::::::::::: callout -## プロキシ +## Proxy -ネットワーク環境によっては[プロキシ](https://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%AD%E3%82%B7) を使わなければならないかもしれません。 この場合、プロキシの設定が必要です： +In some networks you need to use a +[proxy](https://en.wikipedia.org/wiki/Proxy_server). If this is the case, you +may also need to tell Git about the proxy: ```bash $ git config --global http.proxy proxy-url $ git config --global https.proxy proxy-url ``` -プロキシを無効にするには： +To disable the proxy, use ```bash $ git config --global --unset http.proxy @@ -166,18 +192,20 @@ $ git config --global --unset https.proxy ::::::::::::::::::::::::::::::::::::::::: callout -## Git のヘルプとマニュアル +## Git Help and Manual -`git` のコマンドを忘れた時は、`-h` を使えばコマンドの一覧を、`--help` を使えばマニュアルを見ることができます：ある `git` コマンドのサブコマンドやオプションを忘れてしまった場合は、 `git -h` とタイプすることによって関連するオプションのリストを見るか、`git --help` とタイプすることによって対応する Git マニュアルを見ることができます： +Always remember that if you forget the subcommands or options of a `git` command, you can access the +relevant list of options typing `git -h` or access the corresponding Git manual by typing +`git --help`, e.g.: ```bash $ git config -h $ git config --help ``` -マニュアルを見ている間、`:`はコマンドを待っているプロンプトであり、 Q を押してマニュアルを終了できることを覚えておいてください。 +While viewing the manual, remember the `:` is a prompt waiting for commands and you can press Q to exit the manual. -より一般的には、利用可能な `git` コマンドのリストや、Git マニュアルを入手することができます： +More generally, you can get the list of available `git` commands and further resources of the Git manual typing: ```bash $ git help @@ -187,8 +215,11 @@ $ git help [git-privacy]: https://help.github.com/articles/keeping-your-email-address-private/ + :::::::::::::::::::::::::::::::::::::::: keypoints -- `git config` と `--global` オプションを使い、ユーザー名、メールアドレス、エディタ、その他の設定を行う。 +- Use `git config` with the `--global` option to configure a user name, email address, editor, and other preferences once per machine. :::::::::::::::::::::::::::::::::::::::::::::::::: + + diff --git a/03-create.md b/03-create.md index 227374803..2dfb60f72 100644 --- a/03-create.md +++ b/03-create.md @@ -1,42 +1,43 @@ --- -title: リポジトリの作成 +title: Creating a Repository teaching: 10 exercises: 0 --- ::::::::::::::::::::::::::::::::::::::: objectives -- ローカルのGitリポジトリを作成する。 -- `.git` ディレクトリの目的を説明する。 +- Create a local Git repository. +- Describe the purpose of the `.git` directory. :::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::: questions -- Gitはどこに情報を格納しますか? +- Where does Git store information? :::::::::::::::::::::::::::::::::::::::::::::::::: -Gitの設定ができたら、 -それを使い始めることができます。 +Once Git is configured, +we can start using it. -火星に惑星着陸船を送ることが可能かどうかを調査しているウルフマンとドラキュラの話に戻りましょう。 +We will continue with the story of Wolfman and Dracula who are investigating if it +is possible to send a planetary lander to Mars. ![](fig/motivatingexample.png){alt='motivatingexample'} -[ウルフマン対ドラキュラ](https://www.deviantart.com/b-maze/art/Werewolf-vs-Dracula-124893530) +[Werewolf vs dracula](https://www.deviantart.com/b-maze/art/Werewolf-vs-Dracula-124893530) by [b-maze](https://www.deviantart.com/b-maze) / [Deviant Art](https://www.deviantart.com/). -[火星](https://en.wikipedia.org/wiki/File:OSIRIS_Mars_true_color.jpg) by European Space Agency / +[Mars](https://en.wikipedia.org/wiki/File:OSIRIS_Mars_true_color.jpg) by European Space Agency / [CC-BY-SA 3.0 IGO](https://creativecommons.org/licenses/by/3.0/deed.en). -[冥王星](https://commons.wikimedia.org/wiki/File:PIA19873-Pluto-NewHorizons-FlyingPastImage-20150714-transparent.png) / +[Pluto](https://commons.wikimedia.org/wiki/File:PIA19873-Pluto-NewHorizons-FlyingPastImage-20150714-transparent.png) / Courtesy NASA/JPL-Caltech. -[ミイラ](https://commons.wikimedia.org/wiki/File:Mummy_icon_-_Noun_Project_4070.svg) +[Mummy](https://commons.wikimedia.org/wiki/File:Mummy_icon_-_Noun_Project_4070.svg) © Gilad Fried / [The Noun Project](https://thenounproject.com/) / [CC BY 3.0](https://creativecommons.org/licenses/by/3.0/deed.en). -[月](https://commons.wikimedia.org/wiki/File:Lune_ico.png) +[Moon](https://commons.wikimedia.org/wiki/File:Lune_ico.png) © Luc Viatour / [https://lucnix.be](https://lucnix.be/) / [CC BY-SA 3.0](https://creativecommons.org/licenses/by-sa/3.0/deed.en). -まず、`Desktop`フォルダーに作業用のディレクトリを作成し、そのディレクトリに移動しましょう: +First, let's create a new directory in the `Desktop` folder for our work and then change the current working directory to the newly created one: ```bash $ cd ~/Desktop @@ -44,22 +45,29 @@ $ mkdir planets $ cd planets ``` -次に、Gitに`planets`を[リポジトリ](../learners/reference.md#repository)（Gitがファイルのバージョンを保存できる場所）にするように伝えます。 +Then we tell Git to make `planets` a [repository](../learners/reference.md#repository) +\-- a place where Git can store versions of our files: ```bash $ git init ``` -重要なのは、`git init` はサブディレクトリとそのファイルを含むことができるリポジトリを作成するということです。サブディレクトリが最初から存在する場合でも、後から追加された場合でも、`planets` リポジトリの中に入れ子になった別のリポジトリを作成する必要はありません。 また、 `planets`ディレクトリの作成と、リポジトリとしての初期化はまったく別の処理であることに注意してください。 +It is important to note that `git init` will create a repository that +can include subdirectories and their files---there is no need to create +separate repositories nested within the `planets` repository, whether +subdirectories are present from the beginning or added later. Also, note +that the creation of the `planets` directory and its initialization as a +repository are completely separate processes. -`ls` を使ってディレクトリの内容を表示すると、 -何も変更されていないように見えます: +If we use `ls` to show the directory's contents, +it appears that nothing has changed: ```bash $ ls ``` -ですが `-a` フラグを追加してすべてを表示すると、Git が `.git`という隠しディレクトリを `planets` の中に作ったことがわかります: +But if we add the `-a` flag to show everything, +we can see that Git has created a hidden directory within `planets` called `.git`: ```bash $ ls -a @@ -69,12 +77,15 @@ $ ls -a . .. .git ``` -Git はプロジェクトのディレクトリ内にあるすべてのファイルとサブディレクトリを含む、プロジェクトに関するすべての情報を格納するためにこの特別なサブディレクトリを使用します。 -`.git` サブディレクトリを削除すると、プロジェクトの履歴を失うことになります。 +Git uses this special subdirectory to store all the information about the project, +including the tracked files and sub-directories located within the project's directory. +If we ever delete the `.git` subdirectory, +we will lose the project's history. -次に、デフォルトのブランチを `main` という名前に変更します。 -あなたの設定やgitのバージョンによっては、これが既にデフォルトになっているかもしれません。 -この変更の詳細については、[「セットアップ」](02-setup.md#default-git-branch-naming) を参照してください。 +Next, we will change the default branch to be called `main`. +This might be the default branch depending on your settings and version +of git. +See the [setup episode](02-setup.md#default-git-branch-naming) for more information on this change. ```bash $ git checkout -b main @@ -84,7 +95,8 @@ $ git checkout -b main Switched to a new branch 'main' ``` -プロジェクトのステータスをGitに問うことで、すべてが正しく設定されていることを確認できます: +We can check that everything is set up correctly +by asking Git to tell us the status of our project: ```bash $ git status @@ -98,34 +110,48 @@ No commits yet nothing to commit (create/copy files and use "git add" to track) ``` -使用している`git`のバージョンによって、出力の表現が少し異なるかもしれません。 +If you are using a different version of `git`, the exact +wording of the output might be slightly different. ::::::::::::::::::::::::::::::::::::::: challenge -## Git リポジトリを作る場所 +## Places to Create Git Repositories -`planets` （すでに作成したプロジェクト）についての情報を追跡すると共に、 ドラキュラは moons についての情報も追跡したいと考えています。 -ウルフマンの心配にもかかわらず、ドラキュラは次の一連のコマンドを使って、彼の `planets`プロジェクト内に `moons` プロジェクトを作ります: +Along with tracking information about planets (the project we have already created), +Dracula would also like to track information about moons. +Despite Wolfman's concerns, Dracula creates a `moons` project inside his `planets` +project with the following sequence of commands: ```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リポジトリが作られたと示していることを確認する +$ cd ~/Desktop # return to Desktop directory +$ cd planets # go into planets directory, which is already a Git repository +$ ls -a # ensure the .git subdirectory is still present in the planets directory +$ mkdir moons # make a subdirectory planets/moons +$ cd moons # go into moons subdirectory +$ git init # make the moons subdirectory a Git repository +$ ls -a # ensure the .git subdirectory is present indicating we have created a new Git repository ``` -`git init` コマンドは、`moons` サブディレクトリ内で実行され、`moons` サブディレクトリに保存されているファイルを追跡するために必要でしょうか? +Is the `git init` command, run inside the `moons` subdirectory, required for +tracking files stored in the `moons` subdirectory? ::::::::::::::: solution -## 解答 +## Solution -いいえ。 ドラキュラは `moons` サブディレクトリを Git リポジトリにする必要はありません。`planets` リポジトリは、`planets` ディレクトリの下のすべてのファイル、サブディレクトリ、およびサブディレクトリファイルを追跡するからです。 従って、`moons` についてのすべての情報を追跡するのは、ドラキュラが `moons` サブディレクトリを`planets` ディレクトリに追加するだけで済みます。 +No. Dracula does not need to make the `moons` subdirectory a Git repository +because the `planets` repository can track any files, sub-directories, and +subdirectory files under the `planets` directory. Thus, in order to track +all information about moons, Dracula only needed to add the `moons` subdirectory +to the `planets` directory. -それと、Git リポジトリが「入れ子」にされている場合、Gitリポジトリは互いに干渉する可能性があります：外側のリポジトリは内側のリポジトリのバージョン管理をしようとします。 したがって、新しいGitリポジトリはそれぞれ別のディレクトリに作るのがベストです。 ディレクトリに競合するリポジトリががないことを確認するには、`git status`の出力を確認します。 次のような場合は、上の方で示したように新しいリポジトリを作ることをお勧めします： +Additionally, Git repositories can interfere with each other if they are "nested": +the outer repository will try to version-control +the inner repository. Therefore, it's best to create each new Git +repository in a separate directory. To be sure that there is no conflicting +repository in the directory, check the output of `git status`. If it looks +like the following, you are good to go to create a new repository as shown +above: ```bash $ git status @@ -137,36 +163,45 @@ fatal: Not a git repository (or any of the parent directories): .git ::::::::::::::::::::::::: -## `git init` の間違いを修正する +## Correcting `git init` Mistakes -ウルフマンはドラキュラに、「入れ子」状態になっているリポジトリがいかに冗長で、混乱を引き起こす可能性があるかを説明しました。 説明を聞いて、ドラキュラは「入れ子」状態のリポジトリを削除したいと思いました。 `moons`サブディレクトリの最後の`git init`を、ドラキュラはどうやって、元に戻すことができるのでしょうか？ +Wolfman explains to Dracula how a nested repository is redundant and may cause confusion +down the road. Dracula would like to remove the nested repository. How can Dracula undo +his last `git init` in the `moons` subdirectory? ::::::::::::::: solution -## 解決策 （要注意！） +## Solution -- USE WITH CAUTION! -### 背景 +### Background -Gitリポジトリからのファイルの削除は、慎重に行う必要があります。 しかし、特定のファイルを追跡するようにGitに指示する方法については、まだ学んでいません（次のエピソードで学びます）。 Gitによって追跡されていないファイルは、他の「普通の」ファイルと同じように、次のようにして簡単に削除できます： +Removing files from a Git repository needs to be done with caution. But we have not learned +yet how to tell Git to track a particular file; we will learn this in the next episode. Files +that are not tracked by Git can easily be removed like any other "ordinary" files with ```bash $ rm filename ``` -同様に、`rm -r dirname` または `rm -rf dirname` を使ってディレクトリを削除することができます。 -この方法で削除されるファイルやフォルダがGitによって追跡されているなら、次のエピソードで見られるように、それらの削除が、追跡する必要がある別の変更になります。 +Similarly a directory can be removed using `rm -r dirname` or `rm -rf dirname`. +If the files or folder being removed in this fashion are tracked by Git, then their removal +becomes another change that we will need to track, as we will see in the next episode. -### 解答 +### Solution -Gitはすべてのファイルを`.git`ディレクトリに保存します。 -この小さなミスから立ち直るには、ドラキュラは`planets`ディレクトリの中から次のコマンドを実行して、moonsサブディレクトリの中の`.git`フォルダを削除すれば良い： +Git keeps all of its files in the `.git` directory. +To recover from this little mistake, Dracula can just remove the `.git` +folder in the moons subdirectory by running the following command from inside the `planets` directory: ```bash $ rm -rf moons/.git ``` -しかし、気をつけてください！ 間違ったディレクトリでこのコマンドを実行すると、残しておきたいプロジェクトのGit履歴がすべて削除されてしまいます。 -したがって、常に `pwd` コマンドを使用してカレントディレクトリを確認してください。 +But be careful! Running this command in the wrong directory will remove +the entire Git history of a project you might want to keep. +Therefore, always check your current directory using the command `pwd`. + + ::::::::::::::::::::::::: @@ -174,7 +209,9 @@ $ rm -rf moons/.git :::::::::::::::::::::::::::::::::::::::: keypoints -- `git init` はリポジトリを初期化する。 -- Gitはリポジトリデータのすべてを`.git`ディレクトリに格納する。 +- `git init` initializes a repository. +- Git stores all of its repository data in the `.git` directory. :::::::::::::::::::::::::::::::::::::::::::::::::: + + diff --git a/04-changes.md b/04-changes.md index bd8a64b36..82c5689fa 100644 --- a/04-changes.md +++ b/04-changes.md @@ -1,47 +1,49 @@ --- -title: 変更内容の記録 +title: Tracking Changes teaching: 20 exercises: 0 --- ::::::::::::::::::::::::::::::::::::::: objectives -- 一つ以上のファイルにおいて、「変更・追加・コミット」の作業を行いましょう。 -- 「変更・追加・コミット」を行っている際、情報がどこに保管されているのか説明しましょう。 -- わかりやすいコミットメッセージと、そうでないメッセージの違いを区別できるようになりましょう。 +- Go through the modify-add-commit cycle for one or more files. +- Explain where information is stored at each stage of that cycle. +- Distinguish between descriptive and non-descriptive commit messages. :::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::: questions -- どうやって変更点を Git で記録出来ますか？ -- どうやってリポジトリの状態をチェック出来ますか？ -- 何を変更して、なぜ変えたのかをメモするにはどうすればよいですか？ +- How do I record changes in Git? +- How do I check the status of my version control repository? +- How do I record notes about what changes I made and why? :::::::::::::::::::::::::::::::::::::::::::::::::: -まずはじめに、正しいディレクトリにいるかどうか確かめましょう。 -`planets` ディレクトリに入っているはずです。 +First let's make sure we're still in the right directory. +You should be in the `planets` directory. ```bash $ cd ~/Desktop/planets ``` -赤い惑星（火星）が基地に最適かどうかについてのノートを書くために`mars.txt` というファイルを作成しましょう。 -`nano` （もしくは好きなテキストエディタ）でファイルを編集しましょう。 -以前 `core.editor` で設定したエディタとは別のエディタで編集しても大丈夫です。 ですが、新しくファイルを作成・編集するコマンドはエディタによって違うということを覚えておいてください（`nano` ではないかもしれません）。 テキストエディタについて復習したい方は、[Unix シェル](https://swcarpentry.github.io/shell-novice/) の [どのエディタ？](https://swcarpentry.github.io/shell-novice/03-create/) のレッスンを見てみてください。 +Let's create a file called `mars.txt` that contains some notes +about the Red Planet's suitability as a base. +We'll use `nano` to edit the file; +you can use whatever editor you like. +In particular, this does not have to be the `core.editor` you set globally earlier. But remember, the bash command to create or edit a new file will depend on the editor you choose (it might not be `nano`). For a refresher on text editors, check out ["Which Editor?"](https://swcarpentry.github.io/shell-novice/03-create.html#which-editor) in [The Unix Shell](https://swcarpentry.github.io/shell-novice/) lesson. ```bash $ nano mars.txt ``` -以下の文を `mars.txt` に記入してください： +Type the text below into the `mars.txt` file: ```output Cold and dry, but everything is my favorite color ``` -まず、listコマンド（`ls`）を実行して、ファイルが正しく作成されたことを確認しましょう： +Let's first verify that the file was properly created by running the list command (`ls`): ```bash $ ls @@ -51,7 +53,7 @@ $ ls mars.txt ``` -これで `mars.txt` は一文だけ入ってる状態になりました。確認してみましょう： +`mars.txt` contains a single line, which we can see by running: ```bash $ cat mars.txt @@ -61,8 +63,8 @@ $ cat mars.txt Cold and dry, but everything is my favorite color ``` -プロジェクトの状態をもう一度確認してみると、 -Git は新しいファイルがあることに気づきます： +If we check the status of our project again, +Git tells us that it's noticed the new file: ```bash $ git status @@ -81,16 +83,15 @@ Untracked files: nothing added to commit but untracked files present (use "git add" to track) ``` -"untracked files" （追跡されていないファイル）というメッセージは、 -Git が追跡していないファイルがこのディレクトリに存在していることを意味します。 -`git add` を使って、Git にこのファイルを追跡してもらいましょう： -`git add` を使って、Git にこのファイルを追跡してもらいましょう： +The "untracked files" message means that there's a file in the directory +that Git isn't keeping track of. +We can tell Git to track a file using `git add`: ```bash $ git add mars.txt ``` -そして、正しく動作したか確認してみましょう： +and then check that the right thing happened: ```bash $ git status @@ -108,9 +109,10 @@ Changes to be committed: ``` -これで Git は `mars.txt` を追跡するように設定することができました。 -ですが、まだ変更点をコミットとして記録していません。 -これをするには、もう一つコマンドを使う必要があります： +Git now knows that it's supposed to keep track of `mars.txt`, +but it hasn't recorded these changes as a commit yet. +To get it to do that, +we need to run one more command: ```bash $ git commit -m "Start notes on Mars as a base" @@ -122,20 +124,23 @@ $ git commit -m "Start notes on Mars as a base" create mode 100644 mars.txt ``` -`git commit` を使うと、 -Git は `git add` によって一時的に保存されたデータを -`.git` ディレクトリにコピー、そして永久保存します。 -永久保存されたコピーを [コミット](../learners/reference.md#commit) -（または [リビジョン](../learners/reference.md#revision))）と呼び、`f22b25e` はコミットの省略されたIDです。 あなたのコミットには別のIDが使われているかもしれません。 +When we run `git commit`, +Git takes everything we have told it to save by using `git add` +and stores a copy permanently inside the special `.git` directory. +This permanent copy is called a [commit](../learners/reference.md#commit) +(or [revision](../learners/reference.md#revision)) and its short identifier is `f22b25e`. Your commit may have another identifier. -`-m` フラグ（「メッセージ」の略）を使い、何を変えて、なぜ変えたのかが後からでも分かるように、簡潔で分かりやすいメッセージを書きましょう。 -`-m` を使わずに `git commit` を使った場合、Git は `nano` （または `core.editor` として設定したエディタ）を開き、もっと長いメッセージを書くことができます。 +We use the `-m` flag (for "message") +to record a short, descriptive, and specific comment that will help us remember later on what we did and why. +If we just run `git commit` without the `-m` option, +Git will launch `nano` (or whatever other editor we configured as `core.editor`) +so that we can write a longer message. -[良いコミットメッセージ][commit-messages] は、どのような変更が行われたのかが分かる短い文（50字以下） -で始まります。 大抵のメッセージは、「このコミットを適用すると」という文が完全文になるように書かれます。 -もっと詳しく書きたい場合は、このメッセージの後に改行してからノートを加えましょう。 ここには、なぜこのような変更をしたのか、この変更によって何が影響を受けるかなどといった事を書くといいでしょう。 +[Good commit messages][commit-messages] start with a brief (\<50 characters) statement about the +changes made in the commit. Generally, the message should complete the sentence "If applied, this commit will" . +If you want to go into more detail, add a blank line between the summary line and your additional notes. Use this additional space to explain why you made changes and/or what their impact will be. -今の状態で `git status` を走らせると： +If we run `git status` now: ```bash $ git status @@ -146,8 +151,9 @@ On branch main nothing to commit, working tree clean ``` -といったように、最新の状態であることを教えてくれます。 -つい先程、何をしたのかを見たい場合は `git log` を使って、 Git にプロジェクトの履歴を表示してもらいましょう： +it tells us everything is up to date. +If we want to know what we've done recently, +we can ask Git to show us the project's history using `git log`: ```bash $ git log @@ -161,20 +167,31 @@ Date: Thu Aug 22 09:51:46 2013 -0400 Start notes on Mars as a base ``` -`git log` は、リポジトリに施された全てのコミットを最新のものから順に表示します。 -各コミットには、省略されていないコミットID（以前 `git commit` で表示された省略IDと同じ字列で始まります）、コミットの著者、作成日時、そして、コミットが作られた時につけられたログメッセージが含まれています。 +`git log` lists all commits made to a repository in reverse chronological order. +The listing for each commit includes +the commit's full identifier +(which starts with the same characters as +the short identifier printed by the `git commit` command earlier), +the commit's author, +when it was created, +and the log message Git was given when the commit was created. ::::::::::::::::::::::::::::::::::::::::: callout -## 変更点は何処にあるの？ +## Where Are My Changes? + +If we run `ls` at this point, we will still see just one file called `mars.txt`. +That's because Git saves information about files' history +in the special `.git` directory mentioned earlier +so that our filesystem doesn't become cluttered +(and so that we can't accidentally edit or delete an old version). -ここで `ls` を使用すると、`mars.txt` ファイル一つしかありません。 -なぜかと言うと、Git はファイルの変更履歴を、以前触れた `.git` という特別なディレクトリに保存します。これをする事によって、ファイルシステムが散らからないようにし、うっかり古いバージョンのファイルを変更、または削除できないようにしています。 :::::::::::::::::::::::::::::::::::::::::::::::::: -それでは、ドラキュラがファイルに新しい情報を加えたとしましょう。 -（以前と同様に、`nano` を使い、`cat` でファイルの中身を表示させます。違うエディタを使ってもいいし、`cat` を使わなくても構いません。） +Now suppose Dracula adds more information to the file. +(Again, we'll edit with `nano` and then `cat` the file to show its contents; +you may use a different editor, and don't need to `cat`.) ```bash $ nano mars.txt @@ -186,7 +203,8 @@ Cold and dry, but everything is my favorite color The two moons may be a problem for Wolfman ``` -`git status` を使うと、追跡しているファイルが変更されたことを知らせてくれます： +When we run `git status` now, +it tells us that a file it already knows about has been modified: ```bash $ git status @@ -203,10 +221,16 @@ Changes not staged for commit: 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` を使いましょう。 -これによって、今のファイルの状態と、一つ前までのファイルの状態との違いを確かめることができます： +The last line is the key phrase: +"no changes added to commit". +We have changed this file, +but we haven't told Git we will want to save those changes +(which we do with `git add`) +nor have we saved them (which we do with `git commit`). +So let's do that now. It is good practice to always review +our changes before saving them. We do this using `git diff`. +This shows us the differences between the current state +of the file and the most recently saved version: ```bash $ git diff @@ -222,18 +246,23 @@ index df0654a..315bf3a 100644 +The two moons may be a problem for Wolfman ``` -すると、暗号のようなメッセージが出力されます。 -これらのメッセージは、エディタや `patch` といったプログラムで使われる -一連のコマンドで、ファイルをどうやって再構成するのかが書かれています。 -分かりやすいように、一文ずつ見てみましょう： +The output is cryptic because +it is actually a series of commands for tools like editors and `patch` +telling them how to reconstruct one file given the other. +If we break it down into pieces: -1. 最初の文は、Git が古いバージョンと新しいバージョンのファイルをUnix の`diff`コマンドと同じように、二つのファイルを比べていることを表しています。 -2. 次に、Git が比べているファイルの正確なバージョンを表示しています。`df0654a` と `315bf3a` はコンピュータが作成した、各バージョン"につけられたIDです。 -3. 3・4つ目の文章は、変更されているファイルの名前を表示しています。 -4. 残りの文章が一番重要です。ここに、何が変わり、どの行が変更されたのかが記されています。 - 特に、この`+` マークは、どこに文章が加えられたのかを表しています。 +1. The first line tells us that Git is producing output similar to the Unix `diff` command + comparing the old and new versions of the file. +2. The second line tells exactly which versions of the file + Git is comparing; + `df0654a` and `315bf3a` are unique computer-generated labels for those versions. +3. The third and fourth lines once again show the name of the file being changed. +4. The remaining lines are the most interesting, they show us the actual differences + and the lines on which they occur. + In particular, + the `+` marker in the first column shows where we added a line. -変更点を確認したら、コミットしましょう： +After reviewing our change, it's time to commit it: ```bash $ git commit -m "Add concerns about effects of Mars' moons on Wolfman" @@ -250,9 +279,8 @@ Changes not staged for commit: no changes added to commit (use "git add" and/or "git commit -a") ``` -おっと、 -初めに `git add` を使わなかったので、 Git はコミットさせてくれませんでした。 -直しましょう： +Whoops: +Git won't commit because we didn't use `git add` first. Let's fix that: ```bash @@ -265,28 +293,54 @@ $ git commit -m "Add concerns about effects of Mars' moons on Wolfman" 1 file changed, 1 insertion(+) ``` -Git は変更をコミットする前に、コミットしたいファイルを -追加するように要求してきます。 これによって、変更点をこまめに、そして論理的に分割して保存ができ、大きな変更をひとまとめに保存しなくてもよくなります。 -例えば、論文にいくつか引用源を加えるとします。 -これらの引用源、そして使われた参考文献の目録を、まだ書き終わっていない結論とは_別に_保存したい場合はどうすればいいのでしょう。 +Git insists that we add files to the set we want to commit +before actually committing anything. This allows us to commit our +changes in stages and capture changes in logical portions rather than +only large batches. +For example, +suppose we're adding a few citations to relevant research to our thesis. +We might want to commit those additions, +and the corresponding bibliography entries, +but *not* commit some of our work drafting the conclusion +(which we haven't finished yet). -Git には、まだコミットされていない[changeset](../learners/reference.md#changeset)（一連の変更点）を一時的に保存・把握するために使われる、_staging area_（ステージング・エリア）と呼ばれる特殊な場所が存在します。 +To allow for this, +Git has a special *staging area* +where it keeps track of things that have been added to +the current [changeset](../learners/reference.md#changeset) +but not yet committed. ::::::::::::::::::::::::::::::::::::::::: callout -## ステージングエリア +## Staging Area + +If you think of Git as taking snapshots of changes over the life of a project, +`git add` specifies *what* will go in a snapshot +(putting things in the staging area), +and `git commit` then *actually takes* the snapshot, and +makes a permanent record of it (as a commit). +If you don't have anything staged when you type `git commit`, +Git will prompt you to use `git commit -a` or `git commit --all`, +which is kind of like gathering *everyone* to take a group photo! +However, it's almost always better to +explicitly add things to the staging area, because you might +commit changes you forgot you made. (Going back to the group photo simile, +you might get an extra with incomplete makeup walking on +the stage for the picture because you used `-a`!) +Try to stage things manually, +or you might find yourself searching for "git undo commit" more +than you would like! -仮にGit を、プロジェクトの一生の間に起こった変更内容を「スナップショット」として保存するものとして考えると、`git add` は_何が_スナップショットに含まれる（ステージングエリアに入れる）のかを指定して、`git commit` は_実際にスナップショットを撮り_、コミットとして永久保存します。 -`git commit` と入力した際にステージングエリアに何もなかった場合、Git は`git commit -a` もしくは `git commit --all` を入力するように言ってきます。このコマンドは、写真を撮る時の「全員集合！」のようなもので、全ての変更点を強制的にコミットできます。 -ですが、大抵は、コミットしたい変更点のみをステージングエリアに入れるほうが良いでしょう。これによって、不要な変更点を間違えてコミットすることもありません。 （集合写真の例に例えると、メイクの不完全なエキストラがステージの上を横断しているのを一緒に撮ってしまった、みたいなものです。） -ですので、ステージングエリアにどの変更点を入れるかは自分で管理しましょう。さもないと、必要以上に「git コミットやり直す」で検索をかけることになるでしょう。 :::::::::::::::::::::::::::::::::::::::::::::::::: ![](fig/git-staging-area.svg){alt='The Git Staging Area'} -それでは、ファイルの変更点がエディタからステージングエリア、そして長期保存に移る過程を見てみましょう。 -初めに、新しい文章をファイルに加えましょう： +Let's watch as our changes to a file move from our editor +to the staging area +and into long-term storage. +First, +we'll add another line to the file: ```bash $ nano mars.txt @@ -314,19 +368,23 @@ index 315bf3a..b36abfd 100644 +But the Mummy will appreciate the lack of humidity ``` -いい感じです。 -これでファイルの最後に新しく文章を足すことができました。 -（左にある `+` マークで記されています。） -それでは変更点をステージングエリアに入れて -`git diff` がなにを表示するのかを見てみましょう： +So far, so good: +we've added one line to the end of the file +(shown with a `+` in the first column). +Now let's put that change in the staging area +and see what `git diff` reports: ```bash $ git add mars.txt $ git diff ``` -何も表示されませんでした。Git が見た限りでは、保存したい変更点と今ディレクトリ内にあるファイルには、これといった違いは無いということになります。 -ですが、こう入力すると： +There is no output: +as far as Git can tell, +there's no difference between what it's been asked to save permanently +and what's currently in the directory. +However, +if we do this: ```bash $ git diff --staged @@ -343,8 +401,10 @@ index 315bf3a..b36abfd 100644 +But the Mummy will appreciate the lack of humidity ``` -以前コミットされた状態のファイルとステージングエリアにある変更点の違いが表示されます。 -変更内容を保存しましょう： +it shows us the difference between +the last committed change +and what's in the staging area. +Let's save our changes: ```bash $ git commit -m "Discuss concerns about Mars' climate for Mummy" @@ -355,7 +415,7 @@ $ git commit -m "Discuss concerns about Mars' climate for Mummy" 1 file changed, 1 insertion(+) ``` -状態をチェックしましょう： +check our status: ```bash $ git status @@ -366,7 +426,7 @@ On branch main nothing to commit, working tree clean ``` -そして、今までの変更履歴も見てみましょう： +and look at the history of what we've done so far: ```bash $ git log @@ -394,30 +454,43 @@ Date: Thu Aug 22 09:51:46 2013 -0400 ::::::::::::::::::::::::::::::::::::::::: callout -## 文字ごとの違いを表示する +## Word-based diffing + +Sometimes, e.g. in the case of the text documents a line-wise +diff is too coarse. That is where the `--color-words` option of +`git diff` comes in very useful as it highlights the changed +words using colors. -時折、例えばテキストドキュメントなど、列ごとの違いを表示するのは大雑把すぎる場合があります。 こういう時は、`git diff` の `--color-words` オプションを使えば、色で文字ごとの違いを表示してくれるので、大変便利です。 :::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::::: callout -## ログをめくる +## Paging the Log -`git log` の出力がスクリーンよりも長いと、`git` はスクリーンに収まるようにログを分割して表示するプログラムを使います。 -この "pager" （ページャ）というプログラムが開くと、一番下の列がプロンプトではなく、`:` になります。 +When the output of `git log` is too long to fit in your screen, +`git` uses a program to split it into pages of the size of your screen. +When this "pager" is called, you will notice that the last line in your +screen is a `:`, instead of your usual prompt. -- ページャを閉じるには Q を押してください。 -- 次のページを表示するには Spacebarを押してください。 -- ある `<文字>` を全ページの中から検索する時は、/ を押し、`<文字>` を入力してください。 Nを押すと次の一致場所に行けます。 +- To get out of the pager, press Q. +- To move to the next page, press Spacebar. +- To search for `some_word` in all pages, + press / + and type `some_word`. + Navigate through matches pressing N. + :::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::::: callout -## ログの出力を制限する +## Limit Log Size -`git log` の出力がスクリーン全体を埋めないようにするために、Gitが表示するコミットの数を `-N` で変えることができます。この `N`は、表示したいコミットの数を表しています。 例えば、最新のコミットの情報だけを表示したい場合は、こう入力します： +To avoid having `git log` cover your entire terminal screen, you can limit the +number of commits that Git lists by using `-N`, where `N` is the number of +commits that you want to view. For example, if you only want information from +the last commit you can use: ```bash $ git log -1 @@ -431,7 +504,8 @@ Date: Thu Aug 22 10:14:07 2013 -0400 Discuss concerns about Mars' climate for Mummy ``` -`--oneline` オプションを使うことによって、表示する情報を制限する事ができます： +You can also reduce the quantity of information using the +`--oneline` option: ```bash $ git log --oneline @@ -443,7 +517,11 @@ $ git log --oneline f22b25e Start notes on Mars as a base ``` -`--oneline` オプションを他のオプションと組み合わせることもできます。 便利な組み合わせの一つとして、 `--graph` を追加すると、コミット履歴をテキストベースのグラフとして表示し、どのコミットが現在の `HEAD`、現在のブランチ `main`、あるいは[その他の Git リファレンス][git-references]に関連しているかを示すことができます： +You can also combine the `--oneline` option with others. One useful +combination adds `--graph` to display the commit history as a text-based +graph and to indicate which commits are associated with the +current `HEAD`, the current branch `main`, or +[other Git references][git-references]: ```bash $ git log --oneline --graph @@ -459,54 +537,64 @@ $ git log --oneline --graph ::::::::::::::::::::::::::::::::::::::::: callout -## ディレクトリ - -Git でディレクトリを使用する際は、以下の二点を覚えておきましょう。 - -1. Git はディレクトリ単体を追跡することはなく、ディレクトリ内のファイルのみを追跡します。 - 自分で試してみてください： - -```bash -$ mkdir spaceships -$ git status -$ git add spaceships -$ git status -``` - -注目してほしいのは、新しく作った `directory` ディレクトリは `git add` でリポジトリに追加したにも関わらず、追跡されてないファイルのリストに表示されていません。 たまに `.gitkeep` ファイルが空のディレクトリ内にあるのは、このためです。 `.gitignore`とは違って、このファイルは特別でも何でもなく、空のディレクトリを Git のリポジトリに追加、そして追跡させるためだけに置いてあるだけです。 なので、別の名前のファイルでも同じことができます。 - -2. Git リポジトリ内でディレクトリを作成し、複数のファイルをそのディレクトリに入れたい場合、ディレクトリ内のファイルをひとまとめに追加する事ができます： - -```bash -git add -``` - -自分で試してみてください： - -```bash -$ touch spaceships/apollo-11 spaceships/sputnik-1 -$ git status -$ git add spaceships -$ git status -``` - -次に進む前に、これらの変更をコミットしましょう。 - -```bash -$ git commit -m "Add some initial thoughts on spaceships" -``` +## Directories + +Two important facts you should know about directories in Git. + +1. Git does not track directories on their own, only files within them. + Try it for yourself: + + ```bash + $ mkdir spaceships + $ git status + $ git add spaceships + $ git status + ``` + + Note, our newly created empty directory `spaceships` does not appear in + the list of untracked files even if we explicitly add it (*via* `git add`) to our + repository. This is the reason why you will sometimes see `.gitkeep` files + in otherwise empty directories. Unlike `.gitignore`, these files are not special + and their sole purpose is to populate a directory so that Git adds it to + the repository. In fact, you can name such files anything you like. + +2. If you create a directory in your Git repository and populate it with files, + you can add all files in the directory at once by: + + ```bash + git add + ``` + + Try it for yourself: + + ```bash + $ touch spaceships/apollo-11 spaceships/sputnik-1 + $ git status + $ git add spaceships + $ git status + ``` + + Before moving on, we will commit these changes. + + ```bash + $ git commit -m "Add some initial thoughts on spaceships" + ``` :::::::::::::::::::::::::::::::::::::::::::::::::: -まとめると、変更内容をリポジトリに追加したい時は`git add` で変更点をステージングエリアに移してから、`git commit` でステージングエリアの変更点をリポジトリに保存します： +To recap, when we want to add changes to our repository, +we first need to add the changed files to the staging area +(`git add`) and then commit the staged changes to the +repository (`git commit`): ![](fig/git-committing.svg){alt='The Git Commit Workflow'} ::::::::::::::::::::::::::::::::::::::: challenge -## コミットメッセージを決める +## Choosing a Commit Message -以下のコミットメッセージの内、最後の `mars.txt` のコミットに最適なメッセージはどれでしょう？ +Which of the following commit messages would be most appropriate for the +last commit made to `mars.txt`? 1. "Changes" 2. "Added line 'But the Mummy will appreciate the lack of humidity' to mars.txt" @@ -514,9 +602,13 @@ $ git commit -m "Add some initial thoughts on spaceships" ::::::::::::::: solution -## 解答 +## Solution + +Answer 1 is not descriptive enough, and the purpose of the commit is unclear; +and answer 2 is redundant to using "git diff" to see what changed in this commit; +but answer 3 is good: short, descriptive, and imperative. + -１つ目のメッセージは短すぎてコミットの内容が何なのかわかりにくいです。２つ目は`git diff`で何が変わったのかが分かるので、長い割にはあまり意味がありません。３つ目は、短く、簡潔で、分かりやすいメッセージです。 ::::::::::::::::::::::::: @@ -524,43 +616,36 @@ $ git commit -m "Add some initial thoughts on spaceships" ::::::::::::::::::::::::::::::::::::::: challenge -## Git に変更点をコミットする +## Committing Changes to Git -以下の内、`myfile.txt` を Git リポジトリに保存するためのコマンドはどれでしょう？ +Which command(s) below would save the changes of `myfile.txt` +to my local Git repository? 1. ```bash - ``` - -$ git commit -m "my recent changes" - -```` + $ git commit -m "my recent changes" + ``` 2. ```bash -$ git init myfile.txt -$ git commit -m "my recent changes" -```` - + $ git init myfile.txt + $ git commit -m "my recent changes" + ``` 3. ```bash - ``` - -$ git add myfile.txt -$ git commit -m "my recent changes" - -```` + $ git add myfile.txt + $ git commit -m "my recent changes" + ``` 4. ```bash -$ git commit -m myfile.txt "my recent changes" -```` + $ git commit -m myfile.txt "my recent changes" + ``` ::::::::::::::: solution -## 解答 - -1. ファイルがステージングエリアにない限り、コミットできません。 - -2. 新しくリポジトリを作ろうとします。 +## Solution -3. 正しい回答です。まずファイルをステージングエリアに追加し、それからコミットします。 - -4. "my recent changes" というファイルを myfile.txt というメッセージでコミットしようとします。 +1. Would only create a commit if files have already been staged. +2. Would try to create a new repository. +3. Is correct: first add the file to the staging area, then commit. +4. Would try to commit a file "my recent changes" with the message myfile.txt. + + ::::::::::::::::::::::::: @@ -568,21 +653,26 @@ $ git commit -m myfile.txt "my recent changes" ::::::::::::::::::::::::::::::::::::::: challenge -## 複数のファイルをコミットする +## Committing Multiple Files -一つのコミットに対し、ステージングエリアは複数のファイルの変更点を保持する事ができます。 +The staging area can hold changes from any number of files +that you want to commit as a single snapshot. -1. `mars.txt` に、火星ではなく金星に基地を作ることにしたという文章を加えましょう。 -2. 新しく `venus.txt` というファイルを作り、金星に基地を置く決断についての感想を書きましょう。 -3. 二つのファイルの変更内容をステージングエリアに加えて、コミットしましょう。 +1. Add some text to `mars.txt` noting your decision + to consider Venus as a base +2. Create a new file `venus.txt` with your initial thoughts + about Venus as a base for you and your friends +3. Add changes from both files to the staging area, + and commit those changes. ::::::::::::::: solution -## 解答 +## Solution -以下の`cat mars.txt`の出力は、この課題で追加された内容のみを反映しています。 出力は異なる場合があります。 +The output below from `cat mars.txt` reflects only content added during +this exercise. Your output may vary. -まずは `mars.txt` と `venus.txt` を編集しましょう： +First we make our changes to the `mars.txt` and `venus.txt` files: ```bash $ nano mars.txt @@ -602,20 +692,20 @@ $ cat venus.txt Venus is a nice planet and I definitely should consider it as a base. ``` -これで二つのファイルをステージングエリアに追加することができます。 二つのファイルを一気に追加するには： +Now you can add both files to the staging area. We can do that in one line: ```bash $ git add mars.txt venus.txt ``` -一つずつ追加するには： +Or with multiple commands: ```bash $ git add mars.txt $ git add venus.txt ``` -これでファイルをコミットする準備ができました。 `git status` でチェックしましょう。 コミットをするには： +Now the files are ready to commit. You can check that using `git status`. If you are ready to commit use: ```bash $ git commit -m "Write plans to start a base on Venus" @@ -634,46 +724,49 @@ $ git commit -m "Write plans to start a base on Venus" ::::::::::::::::::::::::::::::::::::::: challenge -## `bio` リポジトリ +## `bio` Repository -- `bio` という Git リポジトリ新しく作りましょう。 -- `me.txt` というファイルに自分について３文書いて、変更点をコミットしてください。 -- すでに書いた文章の内、ひとつだけ編集して、更にもう一文加えてください。 -- 編集した後の状態とその前の違いを表示してください。 +- Create a new Git repository on your computer called `bio`. +- Write a three-line biography for yourself in a file called `me.txt`, + commit your changes +- Modify one line, add a fourth line +- Display the differences + between its updated state and its original state. ::::::::::::::: solution -## 解答 +## Solution -必要であれば、`planets` から出ましょう： +If needed, move out of the `planets` folder: ```bash $ cd .. ``` -新しく `bio` というディレクトリを作り、中に移動しましょう： +Create a new folder called `bio` and 'move' into it: ```bash $ mkdir bio $ cd bio ``` -リポジトリを作りましょう： +Initialise git: ```bash $ git init ``` -`nano` か他のテキストエディタで `me.txt` を作りましょう。 -作ったら、変更点を追加してコミットしてください： +Create your biography file `me.txt` using `nano` or another text editor. +Once in place, add and commit it to the repository: ```bash $ git add me.txt $ git commit -m "Add biography file" ``` -指示通りにファイルを編集してください（一文だけ変えて、もう一文足す）。 -オリジナルと編集後のファイルの違いを表示させるために、`git diff` を使います： +Modify the file as described (modify one line, add a fourth line). +To display the differences +between its updated state and its original state, use `git diff`: ```bash $ git diff me.txt @@ -683,16 +776,20 @@ $ git diff me.txt :::::::::::::::::::::::::::::::::::::::::::::::::: -[commit-messages]: https://chris.beams.io/posts/git-commit/ + +[commit-messages]: https://chris.beams.io/posts/git-commit/ [git-references]: https://git-scm.com/book/en/v2/Git-Internals-Git-References + :::::::::::::::::::::::::::::::::::::::: keypoints -- `git status` はリポジトリの状態を表示する。 -- ファイルはプロジェクトの作業ディレクトリ、ステージング・エリア（次のコミットに含まれる変更点が蓄積される場所）、そしてローカル・リポジトリ（コミットが永久に記録される場所）に保存される。 -- `git add` はファイルをステージング・エリアに移動させる。 -- `git commit` はステージされた内容をローカル・リポジトリに保存する。 -- コミットメッセージは、変更点がわかりやすいように書きましょう。 +- `git status` shows the status of a repository. +- Files can be stored in a project's working directory (which users see), the staging area (where the next commit is being built up) and the local repository (where commits are permanently recorded). +- `git add` puts files in the staging area. +- `git commit` saves the staged content as a new commit in the local repository. +- Write a commit message that accurately describes your changes. :::::::::::::::::::::::::::::::::::::::::::::::::: + + diff --git a/05-history.md b/05-history.md index bf600f9bb..fcfbd1364 100644 --- a/05-history.md +++ b/05-history.md @@ -1,29 +1,33 @@ --- -title: 履歴の探索 +title: Exploring History teaching: 25 exercises: 0 --- ::::::::::::::::::::::::::::::::::::::: objectives -- リポジトリのHEADとは何か、またその使い方を説明出来るようになりましょう。 -- Gitのコミット番号を特定して使ってみましょう。 -- 追跡調査されるファイルのいろいろなバージョンを比較してみましょう。 -- ファイルの古いバージョンを復元してみましょう。 +- Explain what the HEAD of a repository is and how to use it. +- Identify and use Git commit numbers. +- Compare various versions of tracked files. +- Restore old versions of files. :::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::: questions -- ファイルの古いバージョンを復元するにはどうすればよいでしょうか? -- 変更内容を再調査するにはどうすればよいでしょうか? -- ファイルの古いバージョンを復元するにはどうすればよいでしょうか? +- How can I identify old versions of files? +- How do I review my changes? +- How can I recover old versions of files? :::::::::::::::::::::::::::::::::::::::::::::::::: -前のレッスンで見たように、コミットを識別子で参照できます。 識別子 `HEAD` を使うことで作業ディレクトリの _最新のコミット_ を参照できます。 +As we saw in the previous episode, we can refer to commits by their +identifiers. You can refer to the *most recent commit* of the working +directory by using the identifier `HEAD`. -`mars.txt` に一度に1行ずつ追加しているので、進展を見て確認することは簡単です。それでは `HEAD` を使ってそれを行ってみましょう。 始める前に、 `mars.txt` にもう1行加えることで変更を加えてみましょう。 +We've been adding one line at a time to `mars.txt`, so it's easy to track our +progress by looking, so let's do that using our `HEAD`s. Before we start, +let's make a change to `mars.txt`, adding yet another line. ```bash $ nano mars.txt @@ -37,7 +41,7 @@ But the Mummy will appreciate the lack of humidity An ill-considered change ``` -それでは、何が得られるか見てみましょう。 +Now, let's see what we get. ```bash $ git diff HEAD mars.txt @@ -55,13 +59,18 @@ index b36abfd..0848c8d 100644 +An ill-considered change. ``` -これは、 `HEAD` を省略した場合 (試してみてください) に得られるものと同じです。 これの本当の利点は、以前のコミットを参照できることです。 それを行うには、`HEAD` より前のコミットを参照するために `~1` (「\~」は「チルダ」、発音は [**til**-d_uh_]) を追加します。 +which is the same as what you would get if you leave out `HEAD` (try it). The +real goodness in all this is when you can refer to previous commits. We do +that by adding `~1` +(where "~" is "tilde", pronounced [**til**\-d*uh*]) +to refer to the commit one before `HEAD`. ```bash $ git diff HEAD~1 mars.txt ``` -古いコミット間の違いを確認したい場合は、`git diff` を再度使用できますが、`HEAD~1`、`HEAD~2` などの表記を使用して、それらを参照するには下記を行います: +If we want to see the differences between older commits we can use `git diff` +again, but with the notation `HEAD~1`, `HEAD~2`, and so on, to refer to them: ```bash $ git diff HEAD~3 mars.txt @@ -79,7 +88,9 @@ index df0654a..b36abfd 100644 +An ill-considered change ``` -`git diff` を使用して表示されるコミットと作業ディレクトリの _違い_ ではなく、古いコミットで行った変更だけでなくコミットメッセージも表示する `git show`を使用することもできます。 +We could also use `git show` which shows us what changes we made at an older commit as +well as the commit message, rather than the *differences* between a commit and our +working directory that we see by using `git diff`. ```bash $ git show HEAD~3 mars.txt @@ -101,12 +112,24 @@ index 0000000..df0654a +Cold and dry, but everything is my favorite color ``` -このようにして、コミットのチェーンを構築できます。 -チェーンの最新の終わりは `HEAD` と呼ばれます; `~` 表記を使用して以前のコミットを参照できるため、`HEAD~1` は「以前のコミット」を意味し、`HEAD~123` は現在の場所から123個前のコミットに戻ります。 - -`git log` が表示する、数字と文字の長い文字列を使用してコミットを参照することもできます。 -これらは一個一個の変更に対するユニークなIDであり、「ユニーク」は本当に唯一であることを意味します: どのコンピューターのどのファイルの変更の組み合わせに対しても、ユニークな40文字の ID があります。 -最初のコミットにはID `f22b25e3233b4645dabd0d81e651fe074bd8e73b` が与えられたので、これを試してみましょう: +In this way, +we can build up a chain of commits. +The most recent end of the chain is referred to as `HEAD`; +we can refer to previous commits using the `~` notation, +so `HEAD~1` +means "the previous commit", +while `HEAD~123` goes back 123 commits from where we are now. + +We can also refer to commits using +those long strings of digits and letters +that `git log` displays. +These are unique IDs for the changes, +and "unique" really does mean unique: +every change to any set of files on any computer +has a unique 40-character identifier. +Our first commit was given the ID +`f22b25e3233b4645dabd0d81e651fe074bd8e73b`, +so let's try this: ```bash $ git diff f22b25e3233b4645dabd0d81e651fe074bd8e73b mars.txt @@ -124,7 +147,9 @@ index df0654a..93a3e13 100644 +An ill-considered change ``` -これは正しい答えですが、ランダムな40文字の文字列を入力するのは面倒なので、Gitは最初の数文字だけを使えばよいようにしてくれています: +That's the right answer, +but typing out random 40-character strings is annoying, +so Git lets us use just the first few characters (typically seven for normal size projects): ```bash $ git diff f22b25e mars.txt @@ -142,10 +167,14 @@ index df0654a..93a3e13 100644 +An ill-considered change ``` -やりました! こんなわけで ファイルへの変更を保存して、何が変更されたかを確認できます。 では、どうすれば古いバージョンのものを復元できるでしょうか? -`mars.txt`への最後の更新（「熟考を欠いた変更」）について気が変わったとしましょう。 +All right! So +we can save changes to files and see what we've changed. Now, how +can we restore older versions of things? +Let's suppose we change our mind about the last update to +`mars.txt` (the "ill-considered change"). -`git status` は、ファイルが変更されたことを示しますが、それらの変更はステージングされていません: +`git status` now tells us that the file has been changed, +but those changes haven't been staged: ```bash $ git status @@ -162,7 +191,8 @@ Changes not staged for commit: no changes added to commit (use "git add" and/or "git commit -a") ``` -`git checkout`を使うと、元の状態に戻すことができます: +We can put things back the way they were +by using `git checkout`: ```bash $ git checkout HEAD mars.txt @@ -175,9 +205,13 @@ The two moons may be a problem for Wolfman But the Mummy will appreciate the lack of humidity ``` -その名前から推測できるように、`git checkout` はファイルの古いバージョンをチェックアウト (つまり、復元) します。 -この場合、最後に保存されたコミットである `HEAD` に記録されたファイルのバージョン を復元することをGitに伝えています。 -さらに戻りたい場合は、代わりにコミット Id を使うことができます: +As you might guess from its name, +`git checkout` checks out (i.e., restores) an old version of a file. +In this case, +we're telling Git that we want to recover the version of the file recorded in `HEAD`, +which is the last saved commit. +If we want to go back even further, +we can use a commit identifier instead: ```bash $ git checkout f22b25e mars.txt @@ -204,8 +238,9 @@ Changes to be committed: ``` -変更はステージング領域にあることに注意してください。 -繰り返しますが、`git checkout` を使うと、元の状態に戻すことができます: +Notice that the changes are currently in the staging area. +Again, we can put things back the way they were +by using `git checkout`: ```bash $ git checkout HEAD mars.txt @@ -213,16 +248,18 @@ $ git checkout HEAD mars.txt ::::::::::::::::::::::::::::::::::::::::: callout -## HEAD を見失わないようにしましょう +## Don't Lose Your HEAD -上記では下記を使いました +Above we used ```bash $ git checkout f22b25e mars.txt ``` -`mars.txt` をコミット `f22b25e` 後の状態に戻すためにです。 しかし、気をつけてください！ -コマンド `checkout` には他の重要な機能があり、入力が正確でない場合、Gitはあなたの意図を誤解する可能性があります。 たとえば、前のコマンドで `mars.txt` を忘れた場合です。 +to revert `mars.txt` to its state after the commit `f22b25e`. But be careful! +The command `checkout` has other important functionalities and Git will misunderstand +your intentions if you are not accurate with the typing. For example, +if you forget `mars.txt` in the previous command. ```bash $ git checkout f22b25e @@ -243,50 +280,69 @@ do so (now or later) by using -b with the checkout command again. Example: HEAD is now at f22b25e Start notes on Mars as a base ``` -ここでの「HEADが切り離された」状態は「見れるが触ってはいけない」ようなものなので、この状態で変更を加えないでください。 -リポジトリの過去の状態を調査した後、`git checkout main` で `HEAD`を再接続してください。 +The "detached HEAD" is like "look, but don't touch" here, +so you shouldn't make any changes in this state. +After investigating your repo's past state, reattach your `HEAD` with `git checkout main`. + :::::::::::::::::::::::::::::::::::::::::::::::::: -取り消したい変更の一個**前**のコミット番号を使う必要があることを覚えておくことが重要です。 -よくある間違いは、破棄しようとしている変更を行ったコミットの番号を使用することです。 -以下の例では、最新のコミットの前 (`HEAD~1`) 、すなわち`f22b25e`から状態を取得したいと考えています: +It's important to remember that +we must use the commit number that identifies the state of the repository +*before* the change we're trying to undo. +A common mistake is to use the number of +the commit in which we made the change we're trying to discard. +In the example below, we want to retrieve the state from before the most +recent commit (`HEAD~1`), which is commit `f22b25e`: ![](fig/git-checkout.svg){alt='Git Checkout'} -つまり、すべてをまとめると、Gitがどのように機能するかは次の漫画のようになります: +So, to put it all together, +here's how Git works in cartoon form: -![https://figshare.com/articles/How\_Git\_works\_a\_cartoon/1328266](fig/git_staging.svg) +![https://figshare.com/articles/How_Git_works_a_cartoon/1328266](fig/git_staging.svg) ::::::::::::::::::::::::::::::::::::::::: callout -## よくあるケースの簡単化 +## Simplifying the Common Case -`git status` の出力を注意深く読むと、次のヒントを含んでいることが分かります: +If you read the output of `git status` carefully, +you'll see that it includes this hint: ```output (use "git checkout -- ..." to discard changes in working directory) ``` -それが言っているように、バージョン識別子のない `git checkout` はファイルを`HEAD`に保存された状態に復元します。 -二重のダッシュ `--`はコマンドから復元されるファイルの名前を区別するために必要です：それがないと、Git はファイルの名前をコミット Id として使用しようとします。 +As it says, +`git checkout` without a version identifier restores files to the state saved in `HEAD`. +The double dash `--` is needed to separate the names of the files being recovered +from the command itself: +without it, +Git would try to use the name of the file as the commit identifier. + :::::::::::::::::::::::::::::::::::::::::::::::::: -ファイルを1つずつ元に戻すことができるという事実は -人々が研究を整理する方法を変えることがあります。 -すべての変更が1つの大きなドキュメントに含まれている場合、 -後で結論に加えられた変更を元に戻さずに、 -序論への変更を元に戻すことは困難です(不可能ではありませんが)。 -一方、序論と結論を別々のファイルに保存すると、時間を前後に移動するのがはるかに簡単になります。 +The fact that files can be reverted one by one +tends to change the way people organize their work. +If everything is in one large document, +it's hard (but not impossible) to undo changes to the introduction +without also undoing changes made later to the conclusion. +If the introduction and conclusion are stored in separate files, +on the other hand, +moving backward and forward in time becomes much easier. ::::::::::::::::::::::::::::::::::::::: challenge -## ファイルの古いバージョンの復元 +## Recovering Older Versions of a File -ジェニファーは、数週間取り組んできたPythonスクリプトに変更を加えました。そして今朝行った変更により、スクリプトが "壊れ"、動作しなくなりました。 彼女はそれを修正しようとして約1時間費やしましたが、うまく機能しません... +Jennifer has made changes to the Python script that she has been working on for weeks, and the +modifications she made this morning "broke" the script and it no longer runs. She has spent +\~ 1hr trying to fix it, with no luck... -幸い、彼女はGitを使用してプロジェクトのバージョンを追跡していました! 以下のどのコマンドで、`data_cruncher.py` と呼ばれるPythonスクリプトの最後にコミットされたバージョンを復元できるでしょうか？ +Luckily, she has been keeping track of her project's versions using Git! Which commands below will +let her recover the last committed version of her Python script called +`data_cruncher.py`? 1. `$ git checkout HEAD` @@ -300,24 +356,26 @@ HEAD is now at f22b25e Start notes on Mars as a base ::::::::::::::: solution -## 解答 +## Solution -答えは (5) - 2 と 4 の両方です。 +The answer is (5)-Both 2 and 4. The `checkout` command restores files from the repository, overwriting the files in your working -directory. Answers 2 and 4 both restore the _latest_ version _in the repository_ of the file -`data_cruncher.py`. Answer 2 uses `HEAD` to indicate the _latest_, whereas answer 4 uses the +directory. Answers 2 and 4 both restore the *latest* version *in the repository* of the file +`data_cruncher.py`. Answer 2 uses `HEAD` to indicate the *latest*, whereas answer 4 uses the unique ID of the last commit, which is what `HEAD` means. -Answer 3 gets the version of `data_cruncher.py` from the commit _before_ `HEAD`, which is NOT +Answer 3 gets the version of `data_cruncher.py` from the commit *before* `HEAD`, which is NOT what we wanted. Answer 1 can be dangerous! Without a filename, `git checkout` will restore **all files** in the current directory (and all directories below it) to their state at the commit specified. This command will restore `data_cruncher.py` to the latest commit version, but it will also -restore _any other files that are changed_ to that version, erasing any changes you may +restore *any other files that are changed* to that version, erasing any changes you may have made to those files! -As discussed above, you are left in a _detached_ `HEAD` state, and you don't want to be there. +As discussed above, you are left in a *detached* `HEAD` state, and you don't want to be there. + + ::::::::::::::::::::::::: @@ -325,27 +383,35 @@ As discussed above, you are left in a _detached_ `HEAD` state, and you don't wan ::::::::::::::::::::::::::::::::::::::: challenge -## コミットを戻すことについて +## Reverting a Commit -ジェニファーは同僚とPythonスクリプトで共同作業を行っており、グループのリポジトリへの彼女の最新のコミットが間違っていることに気付き、それを元に戻したいと思っています。 ジェニファーは、グループリポジトリのみんなが正しい変更を取得できるように、正しく元に戻す必要があります。 ジェニファーは、グループリポジトリのみんなが正しい変更を取得できるように、正しく元に戻す必要があります。 `git revert [wrong commit ID]` は、ジェニファーの誤ったコミットを元に戻す新しいコミットを作ります。 +Jennifer is collaborating with colleagues on her Python script. She +realizes her last commit to the project's repository contained an error, and +wants to undo it. Jennifer wants to undo correctly so everyone in the project's +repository gets the correct change. The command `git revert [erroneous commit ID]` will create a +new commit that reverses the erroneous commit. -従って`git revert`は`git checkout [commit ID]`とは異なります。なぜなら `checkout` はグループのリポジトリにはコミットされていないローカルの変更用のコマンドだからです。 +The command `git revert` is +different from `git checkout [commit ID]` because `git checkout` returns the +files not yet committed within the local repository to a previous state, whereas `git revert` +reverses changes committed to the local and project repositories. -以下は、ジェニファーが`git revert`を使用するための正しい手順と説明ですが、不足しているコマンドは何でしょうか？ +Below are the right steps and explanations for Jennifer to use `git revert`, +what is the missing command? -1. `________ # コミットIDを見つけるために、プロジェクトのgitの 履歴を見ます` +1. `________ # Look at the git history of the project to find the commit ID` -2. そのIDをコピーします (IDの最初の数文字は例えば 0b1d055)。 +2. Copy the ID (the first few characters of the ID, e.g. 0b1d055). 3. `git revert [commit ID]` -4. 新しいコミットメッセージを入力します。 +4. Type in the new commit message. -5. 保存して閉じます。 +5. Save and close ::::::::::::::: solution -## 解答 +## Solution The command `git log` lists project history with commit IDs. @@ -353,15 +419,17 @@ The command `git show HEAD` shows changes made at the latest commit, and lists the commit ID; however, Jennifer should double-check it is the correct commit, and no one else has committed changes to the repository. + + ::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::: challenge -## ワークフローと履歴の理解 +## Understanding Workflow and History -最後のコマンドの出力は何でしょうか？ +What is the output of the last command in ```bash $ cd planets @@ -374,31 +442,24 @@ $ cat venus.txt #this will print the contents of venus.txt to the screen ``` 1. ```output - ``` - -Venus is too hot to be suitable as a base - -```` + 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 + ``` 3. ```output - ``` - -Venus is beautiful and full of love -Venus is too hot to be suitable as a base - -```` + 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 -```` + Error because you have changed venus.txt without committing the changes + ``` ::::::::::::::: solution -## 解答 +## Solution -答えは2です。 +The answer is 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, @@ -424,24 +485,30 @@ Venus is beautiful and full of love. ::::::::::::::::::::::::::::::::::::::: challenge -## `git diff` の理解のチェック +## Checking Understanding of `git diff` -このコマンドをよく考えてみてください: `git diff HEAD~9 mars.txt`。 このコマンドを実行したらどうなるだろうと予測しますか? 実行すると何が起こっていますか? またそれはなぜでしょうか? +Consider this command: `git diff HEAD~9 mars.txt`. What do you predict this command +will do if you execute it? What happens when you do execute it? Why? + +Try another command, `git diff [ID] mars.txt`, where [ID] is replaced with +the unique identifier for your most recent commit. What do you think will happen, +and what does happen? -別のコマンド `git diff [ID] mars.txt` を試しましょう、ここでの [ID] は最新のコミットのユニークな ID で置き換えられます。 あなたは何が起こるだろうと思いますか? :::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::: challenge -## ステージされた変更の除去 +## Getting Rid of Staged Changes -`git checkout` は、ステージされていない変更があったときに 以前のコミットを復元するために使用できます。しかしそれはステージされているがコミットされていない変更に対しても機能するでしょうか? -`mars.txt` に変更を用意し、その変更を加え（`git add`を使い）、`git checkout` を使い変更を取り除くことができるかどうか確かめましょう。 +`git checkout` can be used to restore a previous commit when unstaged changes have +been made, but will it also work for changes that have been staged but not committed? +Make a change to `mars.txt`, add that change using `git add`, +then use `git checkout` to see if you can remove your change. ::::::::::::::: solution -## 解答 +## Solution After adding a change, `git checkout` can not be used directly. Let's look at the output of `git status`: @@ -457,7 +524,7 @@ Changes to be committed: Note that if you don't have the same output you may either have forgotten to change the file, -or you have added it _and_ committed it. +or you have added it *and* committed it. Using the command `git checkout -- mars.txt` now does not give an error, but it does not restore the file either. @@ -509,16 +576,18 @@ nothing to commit, working tree clean ::::::::::::::::::::::::::::::::::::::: challenge -## 履歴を探索し、要約する +## Explore and Summarize Histories -履歴の探索はgitの重要な要素であり、特にそのコミットが数ヶ月前のものである場合は、適切なコミットIDを見つけるのが難しいことがよくあります。 +Exploring history is an important part of Git, and often it is a challenge to find +the right commit ID, especially if the commit is from several months ago. -`planets` プロジェクトに50を超えるファイルがあると考えてください。 -あなたは `mars.txt` 中の特定のテキストが変更されたコミットを見つけたいとします。 -`git log` と入力すると、非常に長いリストが表示されました。 -どうやって探す範囲を限定しますか? +Imagine the `planets` project has more than 50 files. +You would like to find a commit that modifies some specific text in `mars.txt`. +When you type `git log`, a very long list appeared. +How can you narrow down the search? -`git diff` コマンドを使用すると、1つの特定のファイルを探索できることを思い出してください、 例えば、`git diff mars.txt` 。 ここでも同様のアイデアを適用できます。 +Recall that the `git diff` command allows us to explore one specific file, +e.g., `git diff mars.txt`. We can apply a similar idea here. ```bash $ git log mars.txt @@ -548,7 +617,9 @@ $ git log --patch HEAD~9 *.txt :::::::::::::::::::::::::::::::::::::::: keypoints -- `git diff` は、コミット間の違いを表示します。 -- `git checkout` は、ファイルの古いバージョンを復元します。 +- `git diff` displays differences between commits. +- `git checkout` recovers old versions of files. :::::::::::::::::::::::::::::::::::::::::::::::::: + + diff --git a/06-ignore.md b/06-ignore.md index 902c80c9d..0bdd8f5d0 100644 --- a/06-ignore.md +++ b/06-ignore.md @@ -1,31 +1,33 @@ --- -title: ファイルを無視する +title: Ignoring Things teaching: 5 exercises: 0 --- ::::::::::::::::::::::::::::::::::::::: objectives -- Git で追跡したくないファイルを指定しましょう -- ファイルを無視する利点を理解しましょう +- Configure Git to ignore specific files. +- Explain why ignoring files can be useful. :::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::: questions -- Git で追跡したくないファイルを指定するにはどうすればよいですか？ +- How can I tell Git to ignore files I don't want to track? :::::::::::::::::::::::::::::::::::::::::::::::::: -Git に追跡して欲しくないファイル、例えばエディタが作成したバックアップファイルやデータ解析中に作られた中間ファイルなどは、どう対処すればいいのでしょう？ -例として、いくつかファイルを作ってみましょう： +What if we have files that we do not want Git to track for us, +like backup files created by our editor +or intermediate files created during data analysis? +Let's create a few dummy files: ```bash $ mkdir results $ touch a.csv b.csv c.csv results/a.out results/b.out ``` -そして Git が何と言うか見てみましょう： +and see what Git says: ```bash $ git status @@ -44,11 +46,12 @@ Untracked files: nothing added to commit but untracked files present (use "git add" to track) ``` -これらのファイルをバージョンコントロールで保存するのはディスク容量の無駄になります。 -さらに、これら全てが表示されると、本当に必要な変更点に集中できなくなってしまうかもしれないので、 -Git にこれらのファイルを無視してもらいましょう。 +Putting these files under version control would be a waste of disk space. +What's worse, +having them all listed could distract us from changes that actually matter, +so let's tell Git to ignore them. -これをするには、`.gitignore` というファイルをルートディレクトリに作ります： +We do this by creating a file in the root directory of our project called `.gitignore`: ```bash $ nano .gitignore @@ -60,10 +63,13 @@ $ cat .gitignore results/ ``` -入力したパターンは、 Git に `.dat` で終わるファイル名と`results` ディレクトリ内にあるファイルを無視するように指示しています。 -（Git がすでに追跡しているファイルは、引き続き追跡されます。） +These patterns tell Git to ignore any file whose name ends in `.csv` +and everything in the `results` directory. +(If any of these files were already being tracked, +Git would continue to track them.) -このファイルを作った後`git status` の出力を見てみると、大分綺麗になっています： +Once we have created this file, +the output of `git status` is much cleaner: ```bash $ git status @@ -79,9 +85,11 @@ Untracked files: nothing added to commit but untracked files present (use "git add" to track) ``` -Git は新しく作られた `.gitignore` ファイルしか表示していません。 -このファイルは追跡しなくても良いかと思うでしょうが、リポジトリを共有する際に、他の人達も私達が無視したものを同じように無視したいでしょう。 -なので、`.gitignore` を追加してコミットしましょう： +The only thing Git notices now is the newly-created `.gitignore` file. +You might think we wouldn't want to track it, +but everyone we're sharing our repository with will probably want to ignore +the same things that we're ignoring. +Let's add and commit `.gitignore`: ```bash $ git add .gitignore @@ -94,7 +102,7 @@ On branch main nothing to commit, working tree clean ``` -`.gitignore` を作った事によって、間違えて不要なファイルをリポジトリに追加する事を防ぐことができます： +As a bonus, using `.gitignore` helps us avoid accidentally adding files to the repository that we don't want to track: ```bash $ git add a.csv @@ -106,8 +114,10 @@ a.csv Use -f if you really want to add them. ``` -この設定を強制的に無視してファイルを追加するには、`git add -f` を使います。 例えば、`git add -f a.csv` と入力します。 -もちろん、無視されたファイルの状況はいつでも見ることができます： +If we really want to override our ignore settings, +we can use `git add -f` to force Git to add something. For example, +`git add -f a.csv`. +We can also always see the status of ignored files if we want: ```bash $ git status --ignored @@ -128,33 +138,42 @@ nothing to commit, working tree clean ::::::::::::::::::::::::::::::::::::::: challenge -## 埋もれた（ネストされた）ファイルを無視する +## Ignoring Nested Files -以下のようなディレクトリ構造があるとします： +Given a directory structure that looks like: ```bash results/data results/plots ``` -`results/data` ではなく、`results/plots` のみを無視するにはどうすればいいのでしょう？ +How would you ignore only `results/plots` and not `results/data`? ::::::::::::::: solution -## 解答 +## Solution -`results/plots` 内のファイルのみを無視するのであれば、`.gitignore` に `/plots/` サブフォルダを無視するように.gitignore に以下の文を加えれば解決できます： +If you only want to ignore the contents of +`results/plots`, you can change your `.gitignore` to ignore +only the `/plots/` subfolder by adding the following line to +your .gitignore: ```output results/plots/ ``` -この行によって、`results/plots`の内容だけが無視され、`results/data`の内容は無視されません。 +This line will ensure only the contents of `results/plots` is ignored, and +not the contents of `results/data`. -様々なプログラミングの問題と同様に、この無視ルールが守られるようにする回答方法はいくつかありま。 -「ネストされたファイルを無視する：バリエーション」の演習は、わずかに異なるディレクトリ構造を持っており、別の解決策を提示しています。「ネストされたファイルを無視する：バリエーション」の演習は、わずかに異なるディレクトリ構造を持っており、別の解決策を提示しています。 +As with most programming issues, there +are a few alternative ways that one may ensure this ignore rule is followed. +The "Ignoring Nested Files: Variation" exercise has a slightly +different directory structure +that presents an alternative solution. Further, the discussion page has more detail on ignore rules. + + ::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::: @@ -163,25 +182,29 @@ Further, the discussion page has more detail on ignore rules. ## Including Specific Files -`final.csv`以外の、ルートディレクトリ内にある他の `.data` ファイルを全て無視したい場合はどうすればいいのでしょう？ -ヒント： `!` （感嘆符）が何をするのか調べてみましょう。 +How would you ignore all `.csv` files in your root directory except for +`final.csv`? +Hint: Find out what `!` (the exclamation point operator) does ::::::::::::::: solution -## 解答 +## Solution -以下二文を .gitignore に加えましょう： +You would add the following two lines to your .gitignore: ```output -*.data # 全ての data ファイルを無視する -!final.data # final.data は対象から除外する +*.csv # ignore all data files +!final.csv # except final.csv ``` -感嘆符は、無視してあったファイルを対象から外します。 +The exclamation point operator will include a previously excluded entry. -このレッスンで`.csv`ファイルをコミットしたことがあるので、この新しいルールでは無視されません。 Only future additions +Note also that because you've previously committed `.csv` files in this +lesson they will not be ignored with this new rule. Only future additions of `.csv` files added to the root directory will be ignored. + + ::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::: @@ -207,7 +230,7 @@ before. ::::::::::::::: solution -## 解答 +## Solution If you want to ignore the contents of `results/` but not those of `results/data/`, you can change your `.gitignore` to ignore @@ -225,9 +248,9 @@ results/* # ignore everything in results folder ::::::::::::::::::::::::::::::::::::::: challenge -## ディレクトリ内の全てのデータファイルを無視する +## Ignoring all data Files in a Directory -空の.gitignoreファイルがあり、以下のようなディレクトリ構造があるとします： +Assuming you have an empty .gitignore file, and given a directory structure that looks like: ```bash results/data/position/gps/a.csv @@ -237,14 +260,18 @@ results/data/position/gps/info.txt results/plots ``` -`result/data/position/gps` 内にある全ての `.data` ファイルを無視する一番短い`.gitignore`ルールは何でしょう？ `info.txt` ファイルは無視しないでください。 +What's the shortest `.gitignore` rule you could write to ignore all `.csv` +files in `result/data/position/gps`? Do not ignore the `info.txt`. ::::::::::::::: solution -## 解答 +## Solution + +Appending `results/data/position/gps/*.csv` will match every file in `results/data/position/gps` +that ends with `.csv`. +The file `results/data/position/gps/info.txt` will not be ignored. + -`results/data/position/gps/*.data` を使えば `results/data/position/gps` 内にある全ての `.data` ファイルを無視できます。 -`results/data/position/gps/info.txt` ファイルは無視されません。 ::::::::::::::::::::::::: @@ -268,7 +295,7 @@ How do you ignore all the `.csv` files, without explicitly listing the names of ::::::::::::::: solution -## 解答 +## Solution In the `.gitignore` file, write: @@ -279,29 +306,32 @@ In the `.gitignore` file, write: This 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. + + ::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::: challenge -## ルールの順番 +## The Order of Rules -以下の内容の `.gitignore` ファイルがあるとします： +Given a `.gitignore` file with the following contents: ```bash *.csv !*.csv ``` -結果的に何が無視されるのでしょうか？ +What will be the result? ::::::::::::::: solution -## 解答 +## Solution -感嘆符 `!` は無視してあったファイルを対象から除外する効果があります。 -`!*.csv` は、その前に入力されている `.csv` ファイルを対象から外すので、全ての `.csv` ファイルは引き続き追跡されることになります。 +The `!` modifier will negate an entry from a previously defined ignore pattern. +Because the `!*.csv` entry negates all of the previous `.csv` files in the `.gitignore`, +none of them will be ignored, and all `.csv` files will be tracked. ::::::::::::::::::::::::: @@ -309,26 +339,27 @@ You can still include some specific exception with the exclamation point operato ::::::::::::::::::::::::::::::::::::::: challenge -## ログファイル +## Log Files -仮に `log_01`、 `log_02`、 `log_03`、というように、中間的にログファイルを作成するスクリプトを書いたとします。 -これらのログファイルは取っておきたいのですが、`git` で追跡したくありません。 +You wrote a script that creates many intermediate log-files of the form `log_01`, `log_02`, `log_03`, etc. +You want to keep them but you do not want to track them through `git`. -1. `log_01`、 `log_02`、などのファイルを無視するためのルールを**一つだけ** `.gitignore` に入力してください。 +1. Write **one** `.gitignore` entry that excludes files of the form `log_01`, `log_02`, etc. -2. 入力したパターン正常に動作しているか確認するために `log_01` などのファイルを作成してください。 +2. Test your "ignore pattern" by creating some dummy files of the form `log_01`, etc. -3. 最終的に `log_01` ファイルがものすごく重要であることが分かりました。`.gitignore` を編集せずに、このファイルを追跡しているファイルに加えてください。 +3. You find that the file `log_01` is very important after all, add it to the tracked files without changing the `.gitignore` again. -4. 隣の人と、追跡したくないファイルは他にどのようなものがあるのか、そして`.gitignore` に何を入力すればこれらのファイルを無視できるのかを話し合ってください。 +4. Discuss with your neighbor what other types of files could reside in your directory that you do not want to track and thus would exclude via `.gitignore`. ::::::::::::::: solution -## 解答 - -1. `log_*` もしくは `log*` を .gitignore に加えます。 +## Solution -2. `git add -f log_01` を使って `log_01` を追跡しましょう。 +1. append either `log_*` or `log*` as a new entry in your .gitignore +2. track `log_01` using `git add -f log_01` + + ::::::::::::::::::::::::: @@ -336,6 +367,8 @@ You can still include some specific exception with the exclamation point operato :::::::::::::::::::::::::::::::::::::::: keypoints -- `.gitignore` で無視するファイルを指定する +- The `.gitignore` file tells Git what files to ignore. :::::::::::::::::::::::::::::::::::::::::::::::::: + + diff --git a/07-github.md b/07-github.md index 5d205384b..eb7287669 100644 --- a/07-github.md +++ b/07-github.md @@ -1,48 +1,58 @@ --- -title: GitHub におけるリモート +title: Remotes in GitHub teaching: 45 exercises: 0 --- ::::::::::::::::::::::::::::::::::::::: objectives -- リモートリポジトリとは何なのか、そしてなぜそれが役立つのかを説明します。 -- リモートリポジトリへのプッシュまたはリモートリポジトリからのプル。 +- Explain what remote repositories are and why they are useful. +- Push to or pull from a remote repository. :::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::: questions -- 自分の変更をウェブ上で他の人と共有するにはどうすればよいですか？ +- How do I share my changes with others on the web? :::::::::::::::::::::::::::::::::::::::::::::::::: -バージョン管理が真価を発揮するのは、他の人々と共同作業を始めるときです。 これを行うために必要な機構のほとんどはすでに揃っています。 -唯一欠けているのは、あるリポジトリから別のリポジトリに変更をコピーすることです。 +Version control really comes into its own when we begin to collaborate with +other people. We already have most of the machinery we need to do this; the +only thing missing is to copy changes from one repository to another. -Git のようなシステムを使用すると、任意の 2 つのリポジトリ間で作業結果を動かすことができます。 ただし、実際には、1 つのコピーを中央ハブとして使用し、それを誰かのラップトップではなくウェブ上に -保管するのが最も簡単です。 ほとんどのプログラマーは、[GitHub](https://github.com) や [Bitbucket](https://bitbucket.org)、あるいは [GitLab](https://gitlab.com/) のようなホスティングサービス -に、これらのメインコピーを保持しています。この長所と短所については、[後のエピソード](13-hosting.md) で探ります。 +Systems like Git allow us to move work between any two repositories. In +practice, though, it's easiest to use one copy as a central hub, and to keep it +on the web rather than on someone's laptop. Most programmers use hosting +services like [GitHub](https://github.com), [Bitbucket](https://bitbucket.org) or +[GitLab](https://gitlab.com/) to hold those main copies; we'll explore the pros +and cons of this in a [later episode](13-hosting.md). -まずは、現在のプロジェクトに加えた変更を世界と共有することから始めましょう。 この目的のために、_ローカル_ リポジトリにリンクされる _リモート_ リポジトリを作成します。 +Let's start by sharing the changes we've made to our current project with the +world. To this end we are going to create a *remote* repository that will be linked to our *local* repository. -## 1. リモートリポジトリを作成する。 +## 1\. Create a remote repository -[GitHub](https://github.com) にログインし、右上隅のアイコンをクリックして `planets` という名前の新しいリポジトリを作成してみましょう： +Log in to [GitHub](https://github.com), then click on the icon in the top right corner to +create a new repository called `planets`: ![](fig/github-create-repo-01.png){alt='Creating a Repository on GitHub (Step 1)'} -リポジトリに「planets」という名前を付けて、「Create Repository」をクリックします。 +Name your repository "planets" and then click "Create Repository". -注: このリポジトリはローカルのリポジトリに接続されるため、空にしておく必要があります。 「Initialize this repository with a README」のチェックを外したままにし、「Add .gitignore」と「Add a license.」の両方のオプションを「None」のままにします。 リポジトリを空にしておく必要がある理由の完全な説明については、以下の「GitHub ライセンスと README ファイル」の演習を参照してください。 +Note: Since this repository will be connected to a local repository, it needs to be empty. Leave +"Initialize this repository with a README" unchecked, and keep "None" as options for both "Add +.gitignore" and "Add a license." See the "GitHub License and README files" exercise below for a full +explanation of why the repository needs to be empty. ![](fig/github-create-repo-02.png){alt='Creating a Repository on GitHub (Step 2)'} -リポジトリが作成されるとすぐに、GitHub には ある URL と、ローカルのリポジトリの構成方法に関する情報が記載されたページが表示されます。 +As soon as the repository is created, GitHub displays a page with a URL and some +information on how to configure your local repository: ![](fig/github-create-repo-03.png){alt='Creating a Repository on GitHub (Step 3)'} -これにより、GitHub のサーバー上で次のことが効果的に行われます。 +This effectively does the following on GitHub's servers: ```bash $ mkdir planets @@ -50,8 +60,9 @@ $ cd planets $ git init ``` -もしあなたが以前の [エピソード](04-changes.md) を覚えていれば、私達は `mars.txt` に以前の作業を追加してコミットしました。 -ローカルリポジトリのダイアグラムは次のようになります： +If you remember back to the earlier [episode](04-changes.md) where we added and +committed our earlier work on `mars.txt`, we had a diagram of the local repository +which looked like this: ![](fig/git-staging-area.svg){alt='The Local Repository with Git Staging Area'} @@ -62,7 +73,7 @@ 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 +## 2\. Connect local to remote repository Now we connect the two repositories. We do this by making the GitHub repository a [remote](../learners/reference.md#remote) for the local repository. @@ -79,7 +90,8 @@ Click on the 'SSH' link to change the [protocol](../learners/reference.md#protoc 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. +minimum level for GitHub. + :::::::::::::::::::::::::::::::::::::::::::::::::: @@ -113,7 +125,7 @@ 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 +## 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. @@ -131,6 +143,7 @@ What we will do now is the minimum required to set up the SSH keys and add the p 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. @@ -143,6 +156,7 @@ You shouldn't really forget about your SSH keys, since they keep your account se 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. @@ -159,10 +173,10 @@ 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 directory ``` -If 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.\ +If 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 +### 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): @@ -228,7 +242,7 @@ drwxr-xr-x 1 Vlad Dracula 197121 0 Jul 16 14:48 ../ -rw-r--r-- 1 Vlad Dracula 197121 106 Jul 16 14:48 id_ed25519.pub ``` -### 3.2 Copy the public key to GitHub +### 3\.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. @@ -275,7 +289,7 @@ Hi Vlad! You've successfully authenticated, but GitHub does not provide shell ac 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 +## 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: @@ -336,14 +350,16 @@ type: $ unset SSH_ASKPASS ``` -in the terminal, before you run `git push`. Despite the name, Git uses -, so +in the terminal, before you run `git push`. Despite the name, [Git uses +`SSH_ASKPASS` for all credential +entry](https://git-scm.com/docs/gitcredentials#_requesting_credentials), 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: @@ -360,6 +376,7 @@ 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: @@ -390,7 +407,7 @@ How would you get that same information in the shell? ::::::::::::::: solution -## 解答 +## Solution 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 @@ -408,6 +425,8 @@ We can do this with `git checkout ID` where ID is the identifier of the commit w look at. If we do this, we need to remember to put the repository back to the right state afterwards! + + ::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::: @@ -422,6 +441,7 @@ 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](https://help.github.com/articles/adding-a-file-to-a-repository/). + :::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::: challenge @@ -436,12 +456,14 @@ record times, and why? ::::::::::::::: solution -## 解答 +## Solution 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. + + ::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::: @@ -455,12 +477,14 @@ How is "git push" different from "git commit"? ::::::::::::::: solution -## 解答 +## Solution 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. + + ::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::: @@ -475,7 +499,7 @@ would have happened when you tried to link your local and remote repositories? ::::::::::::::: solution -## 解答 +## Solution 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 @@ -527,3 +551,5 @@ create mode 100644 README.md - `git pull` copies changes from a remote repository to a local repository. :::::::::::::::::::::::::::::::::::::::::::::::::: + + diff --git a/08-collab.md b/08-collab.md index 085189b8a..c67f9f098 100644 --- a/08-collab.md +++ b/08-collab.md @@ -32,6 +32,7 @@ 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" @@ -89,7 +90,7 @@ $ git commit -m "Add notes about Pluto" create mode 100644 pluto.txt ``` -Then push the change to the _Owner's repository_ on GitHub: +Then push the change to the *Owner's repository* on GitHub: ```bash $ git push origin main @@ -146,6 +147,7 @@ associated with a repository. Here are some of the most useful ones: 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 change `upstream` to `fred`. + :::::::::::::::::::::::::::::::::::::::::::::::::: @@ -191,6 +193,7 @@ 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. + :::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::: challenge @@ -199,6 +202,7 @@ read and review. Switch roles and repeat the whole process. + :::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::: challenge @@ -211,7 +215,7 @@ command line? And on GitHub? ::::::::::::::: solution -## 解答 +## Solution On the command line, the Collaborator can use `git fetch origin main` to get the remote changes into the local repository, but without merging @@ -221,6 +225,8 @@ 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. + + ::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::: @@ -237,6 +243,7 @@ code to comment, a blue comment icon appears to open a comment window. The Collaborator posts her comments and suggestions using the GitHub interface. + :::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::: challenge @@ -247,6 +254,7 @@ 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? + :::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::: keypoints @@ -254,3 +262,5 @@ What are some of the benefits of using version control, Git and GitHub? - `git clone` copies a remote repository to create a local repository with a remote called `origin` automatically set up. :::::::::::::::::::::::::::::::::::::::::::::::::: + + diff --git a/09-conflict.md b/09-conflict.md index 953b7170e..b1e9e0b3d 100644 --- a/09-conflict.md +++ b/09-conflict.md @@ -82,7 +82,7 @@ To https://github.com/vlad/planets.git Now let's have the owner make a different change to their copy -_without_ updating from GitHub: +*without* updating from GitHub: ```bash $ nano mars.txt @@ -313,6 +313,7 @@ When asked by your instructor, pull her changes from the repository to create a conflict, then resolve it. + :::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::: challenge @@ -359,7 +360,7 @@ $ git commit -m "Add picture of Martian surface" ``` Suppose 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`. +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: ```bash @@ -440,9 +441,9 @@ $ git commit -m "Use image of sky instead of surface" [main da21b34] Use image of sky instead of surface ``` -We can also keep _both_ images. The catch is that we cannot keep them +We 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 +and *rename* it, then add the renamed versions. First, check out each image and rename it: ```bash @@ -471,6 +472,8 @@ $ git commit -m "Use two images: surface and sky" Now both images of Mars are checked into the repository, and `mars.jpg` no longer exists. + + ::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::: @@ -483,40 +486,40 @@ 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 `100` to a text file `numbers.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 +- *Make changes* by appending the number `100` to a text file `numbers.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 +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 +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! | `AFK` | +| order | action . . . . . . . . . . | command . . . . . . . . . . | +| ----- | -------------------------- | --------------------------------------------- | +| 1 | | | +| 2 | | `echo 100 >> numbers.txt` | +| 3 | | | +| 4 | | | +| 5 | | | +| 6 | Celebrate! | `AFK` | ::::::::::::::: solution ## Solution -| 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! | `AFK` | +| 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! | `AFK` | ::::::::::::::::::::::::: @@ -528,3 +531,5 @@ started. - The version control system does not allow people to overwrite each other's changes blindly, but highlights conflicts so that they can be resolved. :::::::::::::::::::::::::::::::::::::::::::::::::: + + diff --git a/10-open.md b/10-open.md index 23c67d876..1fe72edc7 100644 --- a/10-open.md +++ b/10-open.md @@ -1,88 +1,138 @@ --- -title: オープン サイエンス +title: Open Science teaching: 5 exercises: 5 --- ::::::::::::::::::::::::::::::::::::::: objectives -- バージョン管理システムを計算実験用の電子実験ノートとしてどのように活用できるか説明しましょう。 +- Explain how a version control system can be leveraged as an electronic lab notebook for computational work. :::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::: questions -- バージョン管理は、私の研究をよりオープンにするのにどのように役立ちますか? +- How can version control help me make my work more open? :::::::::::::::::::::::::::::::::::::::::::::::::: -> "open" の反対は "closed" ではありません。 -> "open" の反対は "broken" です。 -> +> The opposite of "open" isn't "closed". +> The opposite of "open" is "broken". +> > \--- John Wilbanks -科学では情報を自由に共有することが理想的かもしれませんが、現実はもっと複雑なことがよくあります。 -最近のよくあるやり方は次のようになります。 - -- 科学者は何らかのデータを収集し、それを自分の部門によって時折バックアップされるマシンに保存します。 -- 次に、科学者はそのデータを分析するために、いくつかの小さなプログラム（これもその科学者のマシンにあります）を作成または変更します。 -- 結果が出たら、それを書き留めて論文を提出します。 - 科学者は自分のデータを含めるかもしれません -- ますます多くのジャーナルがこれを必要としています -- しかし科学者はおそらく自分のコードを含めていません。 -- 時間が経過します。 -- ジャーナルは、科学者の分野の他の少数の人々によって匿名で書かれたレビューを科学者に送信します。 - 科学者はレビューした人を納得させるために自分の論文を改訂し、その間に科学者は以前に書いたスクリプトを修正し、論文を再提出するかもしれません。 -- さらに時間が経過します。 -- ついに論文が出版されます。 - 科学者のデータのオンラインコピーへのリンクが含まれている可能性がありますが、論文自体はペイウォールの背後にあるでしょう：個人的または組織的なアクセス権を持つ人だけがそれを読むことができるでしょう。 - -しかし、ますます多くの科学者にとって、そのプロセスは次のようになります: - -- [figshare](https://figshare.com/)や[Zenodo](https://zenodo.org)などのオープンアクセスリポジトリに保存され、独自の[デジタルオブジェクト識別子](https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E8%AD%98%E5%88%A5%E5%AD%90) (DOI) が与えられます。 - または、データはすでに公開されており、[Dryad](https://datadryad.org/) に保存されています。 -- 科学者は、自分の研究を保持するためにGitHubに新しいリポジトリを作成します。 -- 科学者は分析を行うときに、スクリプト (場合によってはいくつかの出力ファイルも) への変更をそのリポジトリにプッシュします。 - 科学者はまた、自分の論文用にそのリポジトリを使用します；そしてそのリポジトリは、同僚とのコラボレーションのハブになります。 -- 論文の状態に満足したら、[arXiv](https://arxiv.org/)またはその他のプレプリントサーバーに版を投稿し、仲間からのフィードバックを求めます。 -- そのフィードバックに基づいて、科学者は最終的に論文をジャーナルに投稿する前に、いくつかの改訂を投稿する可能性があります。 -- 公開された論文には、科学者のプレプリントとコードそしてデータリポジトリへのリンクが含まれているため、他の科学者が論文の研究を自分の研究の出発点として使用するのがはるかに簡単になります。 - -このオープンモデルは発見を加速します：研究結果がオープンになっていればなっているほど、 -[広く引用され、再利用されます](https://doi.org/10.1371/journal.pone.0000308)。 -ただし、このように作業したい人は、正確に "オープン" が何を意味し、それをどのように行うかについて、いくつかの決定を下す必要があります。 [この本](https://link.springer.com/book/10.1007/978-3-319-00026-8)では、オープンサイエンスのさまざまな側面について詳しく知ることができます。 - -これは、バージョン管理を教える (多くの) 理由の1つです。 -コツコツと使うと、計算作業のための共有可能な電子ラボノートとして機能することによって、 -バージョン管理は "どのように" の質問に答えてくれます： - -- 誰がいつ何をしたかなど、作業の概念的な段階が文書化されています。 すべてのステップには、（ほとんどの場合）固有の識別子 (コミットID) がスタンプされています。 -- 理論的根拠、アイデア、およびその他の知的作業の文書化を、それらから生じる変化に直接結び付けることができます。 -- 独自の回復可能な方法で計算結果を取得するために、研究で使用したものを参照できるようになります。 -- Gitなどのバージョン管理システムを使用すると、リポジトリの履歴全体を簡単にアーカイブして永続化できます。 +Free sharing of information might be the ideal in science, +but the reality is often more complicated. +Normal practice today looks something like this: + +- A scientist collects some data and stores it on a machine + that is occasionally backed up by their department. +- They then write or modify a few small programs + (which also reside on the machine) + to analyze that data. +- Once they have some results, + they write them up and submit a paper. + The scientist might include their data -- a growing number of journals require this -- but + they probably don't include the code. +- Time passes. +- The journal sends the scientist reviews written anonymously by a handful of other people in their field. + The scientist revises the paper to satisfy the reviewers, + during which time they might also modify the scripts they wrote earlier, + and resubmits. +- More time passes. +- The paper is eventually published. + It might include a link to an online copy of the data, + but the paper itself will be behind a paywall: + only people who have personal or institutional access + will be able to read it. + +For a growing number of scientists, +though, +the process looks like this: + +- The data that the scientist collects is stored in an open access repository + like [figshare](https://figshare.com/) or + [Zenodo](https://zenodo.org), possibly as soon as it's collected, + and given its own + [Digital Object Identifier](https://en.wikipedia.org/wiki/Digital_object_identifier) (DOI). + Or the data was already published and is stored in + [Dryad](https://datadryad.org/). +- The scientist creates a new repository on GitHub to hold their work. +- During analysis, + they push changes to their scripts + (and possibly some output files) + to that repository. + The scientist also uses the repository for their paper; + that repository is then the hub for collaboration with colleagues. +- When they are happy with the state of the paper, + the scientist posts a version to [arXiv](https://arxiv.org/) + or some other preprint server + to invite feedback from peers. +- Based on that feedback, + they may post several revisions + before finally submitting the paper to a journal. +- The published paper includes links to the preprint + and to the code and data repositories, + which makes it much easier for other scientists + to use their work as starting point for their own research. + +This open model accelerates discovery: +the more open work is, +[the more widely it is cited and re-used](https://doi.org/10.1371/journal.pone.0000308). +However, +people who want to work this way need to make some decisions +about what exactly "open" means and how to do it. You can find more on the different aspects of Open Science in [this book](https://link.springer.com/book/10.1007/978-3-319-00026-8). + +This is one of the (many) reasons we teach version control. +When used diligently, +it answers the "how" question +by acting as a shareable electronic lab notebook for computational work: + +- The conceptual stages of your work are documented, including who did + what and when. Every step is stamped with an identifier (the commit ID) + that is for most intents and purposes unique. +- You can tie documentation of rationale, ideas, and other + intellectual work directly to the changes that spring from them. +- You can refer to what you used in your research to obtain your + computational results in a way that is unique and recoverable. +- With a version control system such as Git, + the entire history of the repository is easy to archive for perpetuity. ::::::::::::::::::::::::::::::::::::::::: callout -## コードを引用可能にすること +## Making Code Citable + +Anything that is hosted in a version control repository (data, code, papers, +etc.) can be turned into a citable object. You'll learn how to do this in +[the later episode on Citation](12-citation.md). -バージョン管理リポジトリでホストされているもの（データ、コード、論文など）はすべて、 引用可能なオブジェクトに変換できます。これを行う方法は、 これを行う方法は、[レッスン 12: 引用](12-citation.md)で学習します。 :::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::: challenge -## 私の仕事はどれくらい再現可能ですか？ +## How Reproducible Is My Work? + +Ask one of your labmates to reproduce a result you recently obtained +using only what they can find in your papers or on the web. +Try to do the same for one of their results, +then try to do it for a result from a lab you work with. -ラボメイトの1人に、あなたの論文やウェブで見つけることができるものだけを使用して、あなたが最近得た結果を再現するように依頼してみましょう。 -ラボメイトの結果の1つに対して同じことを行ってみてから、あなたの研究室由来の結果にそれを行ってみてください。 :::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::: challenge -## 適切なデータリポジトリを見つける方法は? +## How to Find an Appropriate Data Repository? + +Surf the internet for a couple of minutes and check out the data repositories +mentioned above: [Figshare](https://figshare.com/), [Zenodo](https://zenodo.org), +[Dryad](https://datadryad.org/). Depending on your field of research, you might +find community-recognized repositories that are well-known in your field. +You might also find useful [these data repositories recommended by Nature](https://www.nature.com/sdata/data-policies/repositories). +Discuss with your neighbor which data repository you might want to +approach for your current project and explain why. -数分間インターネットサーフィンして、次のデータリポジトリをチェックしてみましょう：[Figshare](https://figshare.com/), [Zenodo](https://zenodo.org)、[Dryad](https://datadryad.org/)。 研究分野によっては、その分野でよく知られたコミュニティで認められたリポジトリが見つかるかもしれません。 -[Natureが推奨するこれらのデータリポジトリ](https://www.nature.com/sdata/data-policies/repositories)も便利かもしれません。 -現在のプロジェクト用にどのデータリポジトリにアプローチしたいかを隣人と議論し、その理由を説明してみましょう。 :::::::::::::::::::::::::::::::::::::::::::::::::: @@ -97,12 +147,15 @@ a remote server and replaces the file with a text pointer within the github repo 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. +repository and describe what they see when they access that large file. + :::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::: keypoints -- オープンな科学的研究は、クローズドよりも有用であり、引用数が多い。 +- Open scientific work is more useful and more highly cited than closed. :::::::::::::::::::::::::::::::::::::::::::::::::: + + diff --git a/11-licensing.md b/11-licensing.md index 501063361..038e548d9 100644 --- a/11-licensing.md +++ b/11-licensing.md @@ -44,9 +44,9 @@ considerations include: 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 +jargon to decide if they're ok with it. The [Open Source +Initiative](https://opensource.org/licenses) and [Free Software +Foundation](https://www.gnu.org/licenses/license-list.html) both maintain lists of licenses which are good choices. [This article][software-licensing] provides an excellent overview of @@ -69,6 +69,7 @@ Can you do this unilaterally, or do you need permission from someone in your institution? If so, who? + :::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::: challenge @@ -85,11 +86,13 @@ the licenses discussed in this session? How is it different? - [CPython](https://github.com/python/cpython), the standard implementation of the Python language - [Jupyter](https://github.com/jupyter), the project behind the web-based Python notebooks we'll be using - [EtherPad](https://github.com/ether/etherpad-lite), a real-time collaborative editor + :::::::::::::::::::::::::::::::::::::::::::::::::: [software-licensing]: https://doi.org/10.1371/journal.pcbi.1002598 + :::::::::::::::::::::::::::::::::::::::: keypoints - The `LICENSE`, `LICENSE.md`, or `LICENSE.txt` file is often used in a repository to indicate how the contents of the repo may be used by others. @@ -98,3 +101,5 @@ the licenses discussed in this session? How is it different? - People who are not lawyers should not try to write licenses from scratch. :::::::::::::::::::::::::::::::::::::::::::::::::: + + diff --git a/12-citation.md b/12-citation.md index 21f9f70b7..f46f92a83 100644 --- a/12-citation.md +++ b/12-citation.md @@ -18,8 +18,8 @@ exercises: 0 You may want to include a file called `CITATION` or `CITATION.txt` that describes how to reference your project; -the one for Software -Carpentry +the [one for Software +Carpentry](https://github.com/swcarpentry/website/blob/gh-pages/CITATION) states: ```source @@ -69,3 +69,5 @@ make citable. - Add a CITATION file to a repository to explain how you want your work cited. :::::::::::::::::::::::::::::::::::::::::::::::::: + + diff --git a/13-hosting.md b/13-hosting.md index de50504fc..f17d34f55 100644 --- a/13-hosting.md +++ b/13-hosting.md @@ -6,36 +6,50 @@ exercises: 0 ::::::::::::::::::::::::::::::::::::::: objectives -- 科学研究のホスティングのためのさまざまなオプションについて説明します。 +- Explain different options for hosting scientific work. :::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::: questions -- バージョン管理リポジトリはどこでホストすればよいでしょうか? +- Where should I host my version control repositories? :::::::::::::::::::::::::::::::::::::::::::::::::: -自分たちの仕事をオープンにしたいグループにとって次に大きな問題は、コードとデータをどこにホストするかです。 1 つのオプションは、研究室、学部、または大学がサーバーを提供し、アカウントやバックアップなどを管理することです。 これの主な利点は、誰が何を所有しているかを明確にすることです。 -それは、題材が機密性の高いもの (すなわち、ヒトを対象とする実験に関するもの、または特許出願に使用される可能性のあるもの) である場合に特に重要です。 主な欠点は、サービスの提供コストとその存続期間です。データ収集に 10 年を費やした科学者は、10 年後もデータが利用できることを確認したいと考えますが、それは学術インフラに資金提供されるほとんど助成金の存続期間をはるかに超えています。 - -もう 1 つのオプションは、ドメインを購入し、それをホストするためにインターネット サービス プロバイダー (ISP) に料金を支払うことです。 これにより、個人またはグループによる制御が強化され、ある機関から別の機関に移動するときに発生する可能性のある問題を回避できます。 -ただし、上記のオプションまたは下記のオプションよりもセットアップに多くの時間と労力が必要です。 - -3 番目のオプションは、 -[GitHub](https://github.com)、 [GitLab](https://gitlab.com)、または -[BitBucket](https://bitbucket.org) のようなパブリック ホスティング サービスを使用することです。 -これらの各サービスは、コードリポジトリを作成、閲覧、編集できる Web インターフェイスを提供します。 これらのサービスは、イシュートラッキング、Wiki ページ、メール通知、コードレビューなどのコミュニケーションやプロジェクト管理ツールも提供します。 These services benefit from economies of +The second big question for groups that want to open up their work is where to +host their code and data. One option is for the lab, the department, or the +university to provide a server, manage accounts and backups, and so on. The +main benefit of this is that it clarifies who owns what, which is particularly +important if any of the material is sensitive (i.e., relates to experiments +involving human subjects or may be used in a patent application). The main +drawbacks are the cost of providing the service and its longevity: a scientist +who has spent ten years collecting data would like to be sure that data will +still be available ten years from now, but that's well beyond the lifespan of +most of the grants that fund academic infrastructure. + +Another option is to purchase a domain and pay an Internet service provider +(ISP) to host it. This gives the individual or group more control, and +sidesteps problems that can arise when moving from one institution to another, +but requires more time and effort to set up than either the option above or the +option below. + +The third option is to use a public hosting service like +[GitHub](https://github.com), [GitLab](https://gitlab.com), or +[BitBucket](https://bitbucket.org). +Each of these services provides a web interface that enables people to create, +view, and edit their code repositories. These services also provide +communication and project management tools including issue tracking, wiki pages, +email notifications, and code reviews. 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](https://github.com/swcarpentry/) where you can find the source for this -page. Anyone with a GitHub account can suggest changes to this text. +As an example, Software Carpentry [is on GitHub](https://github.com/swcarpentry/) where you can find the [source for this +page](https://github.com/swcarpentry/git-novice/blob/main/episodes/13-hosting.md). 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, +GitHub repositories can also be assigned DOIs, [by connecting its releases to +Zenodo](https://guides.github.com/activities/citable-code/). For example, [`10.5281/zenodo.7908089`](https://zenodo.org/record/7908089) is the DOI that has been "minted" for this introduction to Git. @@ -61,6 +75,7 @@ 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. + :::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::: challenge @@ -72,6 +87,7 @@ Can you do this unilaterally, or do you need permission from someone in your institution? If so, who? + :::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::: challenge @@ -82,6 +98,7 @@ Does your institution have a repository or repositories that you can use to share your papers, data and software? How do institutional repositories differ from services like [arXiV](https://arxiv.org/), [figshare](https://figshare.com/), [GitHub](https://github.com/) or [GitLab](https://about.gitlab.com/)? + :::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::: keypoints @@ -90,3 +107,5 @@ differ from services like [arXiV](https://arxiv.org/), [figshare](https://figsha - Rules regarding intellectual property and storage of sensitive information apply no matter where code and data are hosted. :::::::::::::::::::::::::::::::::::::::::::::::::: + + diff --git a/14-supplemental-rstudio.md b/14-supplemental-rstudio.md index 3c7bbc3b5..c1f5d72ab 100644 --- a/14-supplemental-rstudio.md +++ b/14-supplemental-rstudio.md @@ -1,5 +1,5 @@ --- -title: "Supplemental: Using Git from RStudio" +title: 'Supplemental: Using Git from RStudio' teaching: 10 exercises: 0 --- @@ -76,6 +76,7 @@ RStudio. Note: Even if you have Git installed, you may need to accept the Xcode license if you are using macOS. + :::::::::::::::::::::::::::::::::::::::::::::::::: Next, RStudio will ask which existing directory we want to use. Click @@ -124,6 +125,7 @@ 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` @@ -145,6 +147,7 @@ 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. + :::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::: challenge @@ -167,6 +170,8 @@ 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. + + ::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::: @@ -175,11 +180,13 @@ There are many more features in the RStudio Git menu, but these should be enough to get you started! [rstudio]: https://www.rstudio.com/ - [rstudio-projects]: https://support.rstudio.com/hc/en-us/articles/200526207-Using-Projects + :::::::::::::::::::::::::::::::::::::::: keypoints - Using RStudio's Git integration allows you to version control a project over time. :::::::::::::::::::::::::::::::::::::::::::::::::: + + diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index 11895988e..f19b80495 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -1,5 +1,5 @@ --- -title: Contributor Code of Conduct +title: "Contributor Code of Conduct" --- As contributors and maintainers of this project, @@ -8,6 +8,6 @@ we pledge to follow the [The Carpentries Code of Conduct][coc]. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by following our [reporting guidelines][coc-reporting]. -[coc-reporting]: https://docs.carpentries.org/topic_folders/policies/incident-reporting.html +[coc-reporting]: https://docs.carpentries.org/topic_folders/policies/incident-reporting.html [coc]: https://docs.carpentries.org/topic_folders/policies/code-of-conduct.html diff --git a/LICENSE.md b/LICENSE.md index b96171fa0..7632871ff 100644 --- a/LICENSE.md +++ b/LICENSE.md @@ -1,5 +1,5 @@ --- -title: Licenses +title: "Licenses" --- ## Instructional Material @@ -24,7 +24,7 @@ Under the following terms: - **Attribution**---You must give appropriate credit (mentioning that your work is derived from work that is Copyright (c) The Carpentries and, where - practical, linking to https\://carpentries.org/), provide a [link to the + practical, linking to ), provide a [link to the license][cc-by-human], and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. @@ -35,10 +35,10 @@ Under the following terms: Notices: -- You do not have to comply with the license for elements of the material in +* You do not have to comply with the license for elements of the material in the public domain or where your use is permitted by an applicable exception or limitation. -- No warranties are given. The license may not give you all of the permissions +* No warranties are given. The license may not give you all of the permissions necessary for your intended use. For example, other rights such as publicity, privacy, or moral rights may limit how you use the material. @@ -73,11 +73,7 @@ Carpentry" and their respective logos are registered trademarks of [Community Initiatives][ci]. [cc-by-human]: https://creativecommons.org/licenses/by/4.0/ - [cc-by-legal]: https://creativecommons.org/licenses/by/4.0/legalcode - [mit-license]: https://opensource.org/licenses/mit-license.html - [ci]: https://communityin.org/ - [osi]: https://opensource.org diff --git a/config.yaml b/config.yaml index a8b09d6f8..c3626edcf 100644 --- a/config.yaml +++ b/config.yaml @@ -1,70 +1,94 @@ #------------------------------------------------------------ -#Values for this lesson. +# Values for this lesson. #------------------------------------------------------------ -#Which carpentry is this (swc, dc, lc, or cp)? -#swc: Software Carpentry -#dc: Data Carpentry -#lc: Library Carpentry -#cp: Carpentries (to use for instructor training for instance) -#incubator: The Carpentries Incubator + +# Which carpentry is this (swc, dc, lc, or cp)? +# swc: Software Carpentry +# dc: Data Carpentry +# lc: Library Carpentry +# cp: Carpentries (to use for instructor training for instance) +# incubator: The Carpentries Incubator carpentry: 'swc' -#Overall title for pages. -title: 'Gitによるバージョン管理' -#Date the lesson was created (YYYY-MM-DD, this is empty by default) + +# Overall title for pages. +title: 'Version Control with Git' + +# Date the lesson was created (YYYY-MM-DD, this is empty by default) created: '2014-12-04' -#Comma-separated list of keywords for the lesson -keywords: 'ソフトウェア, データ, レッスン, カーペントリーズ' -#Life cycle stage of the lesson -#possible values: pre-alpha, alpha, beta, stable + +# Comma-separated list of keywords for the lesson +keywords: 'software, data, lesson, The Carpentries' + +# Life cycle stage of the lesson +# possible values: pre-alpha, alpha, beta, stable life_cycle: 'stable' -#License of the lesson materials (recommended CC-BY 4.0) + +# License of the lesson materials (recommended CC-BY 4.0) license: 'CC-BY 4.0' -#Link to the source repository for this lesson -source: 'https://github.com/swcarpentry-ja/git-novice' -#Default branch of your lesson + +# Link to the source repository for this lesson +source: 'https://github.com/swcarpentry/git-novice' + +# Default branch of your lesson branch: 'main' -#Who to contact if there are any issues + +# Who to contact if there are any issues contact: 'team@carpentries.org' -#Navigation ------------------------------------------------ -#Use the following menu items to specify the order of -#individual pages in each dropdown section. Leave blank to -#include all pages in the folder. -#Example ------------- -#episodes: -#- introduction.md -#- first-steps.md -#learners: -#- setup.md -#instructors: -#- instructor-notes.md -#profiles: -#- one-learner.md -#- another-learner.md -#Order of episodes in your lesson -episodes: - - 01-basics.md - - 02-setup.md - - 03-create.md - - 04-changes.md - - 05-history.md - - 06-ignore.md - - 07-github.md - - 08-collab.md - - 09-conflict.md - - 10-open.md - - 11-licensing.md - - 12-citation.md - - 13-hosting.md - - 14-supplemental-rstudio.md -#Information for Learners -learners: -#Information for Instructors -instructors: -#Learner Profiles -profiles: -#Customisation --------------------------------------------- -#This space below is where custom yaml items (e.g. pinning -#sandpaper and varnish versions) should live + +# Navigation ------------------------------------------------ +# +# Use the following menu items to specify the order of +# individual pages in each dropdown section. Leave blank to +# include all pages in the folder. +# +# Example ------------- +# +# episodes: +# - introduction.md +# - first-steps.md +# +# learners: +# - setup.md +# +# instructors: +# - instructor-notes.md +# +# profiles: +# - one-learner.md +# - another-learner.md + +# Order of episodes in your lesson +episodes: +- 01-basics.md +- 02-setup.md +- 03-create.md +- 04-changes.md +- 05-history.md +- 06-ignore.md +- 07-github.md +- 08-collab.md +- 09-conflict.md +- 10-open.md +- 11-licensing.md +- 12-citation.md +- 13-hosting.md +- 14-supplemental-rstudio.md + +# Information for Learners +learners: + +# Information for Instructors +instructors: + +# Learner Profiles +profiles: + +# Customisation --------------------------------------------- +# +# This space below is where custom yaml items (e.g. pinning +# sandpaper and varnish versions) should live + + url: 'https://swcarpentry.github.io/git-novice' analytics: carpentries -lang: ja +lang: en diff --git a/discuss.md b/discuss.md index 6320d345c..def35b113 100644 --- a/discuss.md +++ b/discuss.md @@ -105,6 +105,7 @@ Sort them by the number of stars and have a look at the top few. If you find some you like, please check that they're covered by an open source license before you clone them. + :::::::::::::::::::::::::::::::::::::::::::::::::: ## Non-text Files @@ -119,7 +120,7 @@ We will now revisit this in more detail. Many people want to version control non-text files, such as images, PDFs and Microsoft Office or LibreOffice documents. It is true that Git can handle these filetypes (which fall under the banner of "binary" file types). -However, just because it _can_ be done doesn't mean it _should_ be done. +However, just because it *can* be done doesn't mean it *should* be done. Much of Git's magic comes from being able to do line-by-line comparisons ("diffs") between files. This is generally easy for programming source code and marked up text. @@ -194,7 +195,7 @@ You can see exactly which lines changed and what the changes were. An uninformative `git diff` is not the only consequence of using Git on binary files. However, most of the other problems boil down to whether or not a good diff is possible. -This isn't to say you should _never_ use Git on binary files. +This isn't to say you should *never* use Git on binary files. A rule of thumb is that it's OK if the binary file won't change very often, and if it does change, you don't care about merging in small differences between versions. @@ -457,7 +458,7 @@ files, but ignore the rest of `results/`? ::::::::::::::: solution -## 解答 +## Solution To do this, your .gitignore would look like this: @@ -471,3 +472,5 @@ results/* # ignore the files in the results directory ::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::: + + diff --git a/index.md b/index.md index 36d7e0fc9..424022b28 100644 --- a/index.md +++ b/index.md @@ -3,31 +3,56 @@ permalink: index.html site: sandpaper::sandpaper_site --- -ウルフマンとドラキュラはユニバーサル・ミッションズ（ユーフォリック州立大学からスピンオフした宇宙 -サービス）に雇われ、次の惑星着陸船を火星に送ることが可能かどうかを調査しています。 彼らはそれぞれ同時に計画を立てたいのですが、前にもこのような仕事をしようとしたら困ったことがありました。 交代制にすれば、各自がもう片方が終わるのを待つのに多くの時間を費やすことになります。しかし、それぞれ自分のコピーを編集して、メールで添付ファイルを送ったりすると情報の喪失や上書き、複製などといった問題が起こります。 +Wolfman and Dracula have been hired by Universal Missions (a space +services spinoff from Euphoric State University) to investigate if it +is possible to send their next planetary lander to Mars. They want to +be able to work on the plans at the same time, but they have run into +problems doing this in the past. If they take turns, each one will +spend a lot of time waiting for the other to finish, but if they work +on their own copies and email changes back and forth things will be +lost, overwritten, or duplicated. + +A colleague suggests using [version control](learners/reference.md#version-control) to +manage their work. Version control is better than mailing files back and forth: + +- Nothing that is committed to version control is ever lost, unless + you work really, really hard at it. Since all old versions of + files are saved, it's always possible to go back in time to see + exactly who wrote what on a particular day, or what version of a + program was used to generate a particular set of results. + +- As we have this record of who made what changes when, we know who to ask + if we have questions later on, and, if needed, revert to a previous + version, much like the "undo" feature in an editor. + +- When several people collaborate in the same project, it's possible to + accidentally overlook or overwrite someone's changes. The version control + system automatically notifies users whenever there's a conflict between one + person's work and another's. + +Teams are not the only ones to benefit from version control: lone +researchers can benefit immensely. Keeping a record of what was +changed, when, and why is extremely useful for all researchers if they +ever need to come back to the project later on (e.g., a year later, +when memory has faded). + +Version control is the lab notebook of the digital world: it's what +professionals use to keep track of what they've done and to +collaborate with other people. Every large software development +project relies on it, and most programmers use it for their small jobs +as well. And it isn't just for software: books, +papers, small data sets, and anything that changes over time or needs +to be shared can and should be stored in a version control system. -同僚が[バーション管理](learners/reference.md#version-control)を使って作業を管理することを勧めました。 バージョン管理はファイルを送り返すよりも優れています： - -- 本当に消そうとしない限り、バージョン管理に入れらた（「コミットされた」）ものが失われることはありません。 古いバージョンのファイルはすべて保存されているため、特定の日に誰が何を書き込んだのか、特定の結果を生成するためにどのバージョンのプログラムが使用されたのかなど、正確に確認することが可能です。 - -- 誰が何をいつ変更したのかという記録があるため、後に問題が生じた場合、連絡するべき人が分かる上に必要に応じて「元に戻す」機能のように、以前のバージョンに戻すことができます。 +:::::::::::::::::::::::::::::::::::::::::: prereq -- 同じプロジェクトで複数の人が協力し合う場合、間違って誰かの変更を見落としたり上書きしたりする可能性があります。 バージョン管理システムは、二つの変更点の間に不一致があった場合、自動的にユーザーに知らせてくれます。 +## Prerequisites -バージョン管理を使うことによって得をするのはチームだけではありません: 個人で作業をしている研究者にもメリットがあります。 何が、いつ、何故変わったのかを記録しておくことは、後で昔のプロジェクトを見返すことになった場合などに（例えば、1年後、プロジェクトの詳細を忘れてしまった時などに）、非常に便利です。 +In this lesson we use Git from the Unix Shell. +Some previous experience with the shell is expected, +*but isn't mandatory*. -バージョン管理は、デジタル世界における実験ノートです。 -専門家が、自分が行ったことを記録し、 -他の人々と共同作業を行うために使用するものです。 大規模なソフトウェア開発 -プロジェクトはすべてGit に依存しており、ほとんどのプログラマーは小さな仕事 -でも使用しています。 書籍、論文、小規模なデータセット、時間の経過とともに変化するもの、 -共有する必要があるものは、バージョン管理システムに保存することができるし、そう**すべき**です。 -:::::::::::::::::::::::::::::::::::::::::: prereq - -## 予備知識 +:::::::::::::::::::::::::::::::::::::::::::::::::: -このレッスンでは、UnixシェルからGitを使います。 -シェルの使用経験があることが望ましいですが、_必須ではありません_。 -:::::::::::::::::::::::::::::::::::::::::::::::::: diff --git a/instructor-notes.md b/instructor-notes.md index 4d17d74ae..4d8812e2f 100644 --- a/instructor-notes.md +++ b/instructor-notes.md @@ -11,8 +11,8 @@ lets you focus on the more interesting/innovative aspects of your project. - A few easy-to-remember commands are all you need for most day-to-day version control tasks - The [GitHub][github] hosting service provides a web-based collaboration service - Two main concepts - - _commit_: a recorded set of changes in your project's files - - _repository_: the history of all your project's commits + - *commit*: a recorded set of changes in your project's files + - *repository*: the history of all your project's commits - Why use GitHub? - No need for a server: easy to set up - GitHub's strong community: your colleagues are probably already there @@ -38,7 +38,7 @@ working in teams or not, because it is - You can "split" your shell so that recent commands remain in view using [this](https://github.com/rgaiacs/swc-shell-split-window) script. -- Make sure the network is working _before_ starting this lesson. +- Make sure the network is working *before* starting this lesson. - Drawings are particularly useful in this lesson: if you have a whiteboard, [use it][drawings]! @@ -77,7 +77,7 @@ working in teams or not, because it is widely used in the sciences right now. - Further resources: - + - [git-it] is a self-paced command-line Git demo, with [git-it-electron] its GitHub Desktop successor. - [Code School][code-school] has a free interactive course, [Try Git][try-git]. @@ -102,11 +102,11 @@ working in teams or not, because it is - We suggest instructors and students use `nano` as the text editor for this lessons because - + - it runs in all three major operating systems, - it runs inside the shell (switching windows can be confusing to students), and - it has shortcut help at the bottom of the window. - + Please point out to students during setup that they can and should use another text editor if they're already familiar with it. @@ -128,15 +128,15 @@ working in teams or not, because it is that the `.git` folder contains the whole Git repo and deleting this folder undoes a `git init`. It also gives the learner the way to fix the common mistake of putting unwanted folders (like `Desktop`) under version control. - + Instead of removing the `.git` folder directly, you can choose to move it first to a safer directory and remove it from there: - + ```bash $ mv .git temp_git $ rm -rf temp_git ``` - + The challenge suggests that it is a bad idea to create a Git repo inside another repo. For more discussion on this topic, please see [this issue][repos-in-repos]. @@ -216,7 +216,7 @@ particular set of files in `.gitignore`. - If you're the only instructor, the best way to create is clone the two repos in your Desktop, but under different names, e.g., pretend one is your computer at work: - + ```bash $ git clone https://github.com/vlad/planets.git planets-at-work ``` @@ -224,7 +224,7 @@ particular set of files in `.gitignore`. - It's very common that learners mistype the remote alias or the remote URL when adding a remote, so they cannot `push`. You can diagnose this with `git remote -v` and checking carefully for typos. - + - To fix a wrong alias, you can do `git remote rename `. - To fix a wrong URL, you can do `git remote set-url `. @@ -233,7 +233,7 @@ particular set of files in `.gitignore`. - If both repos are in the `Desktop`, have them to clone their collaborator repo under a given directory using a second argument: - + ```bash $ git clone https://github.com/vlad/planets.git vlad-planet ``` @@ -249,11 +249,11 @@ particular set of files in `.gitignore`. ## [Conflicts](../episodes/09-conflict.md) -- Expect the learners to make mistakes. Expect _yourself_ to make mistakes. +- Expect the learners to make mistakes. Expect *yourself* to make mistakes. This happens because it is late in the lesson and everyone is tired. - If you're the only instructor, the best way to create a conflict is: - + - Clone your repo in a different directory, pretending is your computer at work: `git clone https://github.com/vlad/planets.git planets-at-work`. - At the office, you make a change, commit and push. @@ -265,10 +265,10 @@ particular set of files in `.gitignore`. just (try to) commit. You can diagnose this with `git status`. - Remember that you can discard one of the two parents of the merge: - + - discard the remote file, `git checkout --ours conflicted_file.txt` - discard the local file, `git checkout --theirs conflicted_file.txt` - + You still have to `git add` and `git commit` after this. This is particularly useful when working with binary files. @@ -299,29 +299,19 @@ only choice. It's always interesting to mention the options to have web-hosted private repositories. [github]: https://github.com/ - [drawings]: https://marklodato.github.io/visual-git-guide/index-en.html - [github-privacy]: https://help.github.com/articles/keeping-your-email-address-private/ - [github-line-endings]: https://docs.github.com/en/github/using-git/configuring-git-to-handle-line-endings - [github-line-endings-refresh]: https://docs.github.com/en/github/using-git/configuring-git-to-handle-line-endings#refreshing-a-repository-after-changing-line-endings - [github-gui]: https://git-scm.com/downloads/guis - [diffmerge]: https://sourcegear.com/diffmerge/ - [git-it]: https://github.com/jlord/git-it - [git-it-electron]: https://github.com/jlord/git-it-electron - [code-school]: https://www.codeschool.com/ - [try-git]: https://try.github.io - [git-parable]: https://tom.preston-werner.com/2009/05/19/the-git-parable.html - [repos-in-repos]: https://github.com/swcarpentry/git-novice/issues/272 - [cc-faq-software]: https://creativecommons.org/faq/#can-i-apply-a-creative-commons-license-to-software + + + diff --git a/learner-profiles.md b/learner-profiles.md index 75b2c5cad..434e335aa 100644 --- a/learner-profiles.md +++ b/learner-profiles.md @@ -2,4 +2,4 @@ title: FIXME --- -This is a placeholder file. Please add content here. +This is a placeholder file. Please add content here. diff --git a/md5sum.txt b/md5sum.txt index 28073c21b..a627aae1b 100644 --- a/md5sum.txt +++ b/md5sum.txt @@ -1,25 +1,24 @@ "file" "checksum" "built" "date" -"CODE_OF_CONDUCT.md" "aa54988020ee279c8375831ccd9c229f" "site/built/CODE_OF_CONDUCT.md" "2024-01-13" -"LICENSE.md" "a28efe88838e3073f3f6db11bc125754" "site/built/LICENSE.md" "2024-01-13" -"config.yaml" "b6d9ed3e5970de3643d8c1edf24aae9a" "site/built/config.yaml" "2024-01-13" -"index.md" "5fba22f4ccdf526028f9782ee580cd59" "site/built/index.md" "2024-01-13" -"episodes/01-basics.md" "ba8ce76f1cf8f30c8ceb1a90f89da70e" "site/built/01-basics.md" "2024-01-13" -"episodes/02-setup.md" "4d7bccfd1c241430c9b8e608a6374cdf" "site/built/02-setup.md" "2024-01-13" -"episodes/03-create.md" "09681c18482b4646736c2dd4ea66f24f" "site/built/03-create.md" "2024-01-13" -"episodes/04-changes.md" "1cc85f9469dda0136ead536519420445" "site/built/04-changes.md" "2024-01-13" -"episodes/05-history.md" "3d444b023a9c9baaad5b084fc41b54b1" "site/built/05-history.md" "2024-01-13" -"episodes/06-ignore.md" "d69793160176e870ed240283ab49f0b8" "site/built/06-ignore.md" "2024-02-23" -"episodes/07-github.md" "1373b42fdf770a8f69547bd61cd0cde6" "site/built/07-github.md" "2024-02-23" -"episodes/08-collab.md" "8c601198b5ef4c241e98ae425e8ffb09" "site/built/08-collab.md" "2024-02-23" -"episodes/09-conflict.md" "c94cdba9552057b189a625c98ea23dde" "site/built/09-conflict.md" "2023-11-21" -"episodes/10-open.md" "82c019e04706ed92bf0586d09aa274dc" "site/built/10-open.md" "2024-01-13" -"episodes/11-licensing.md" "f1ae69063f4103a7a32456e9757d9075" "site/built/11-licensing.md" "2023-11-21" -"episodes/12-citation.md" "798f2ada566d42e901b37d3129e47518" "site/built/12-citation.md" "2024-01-13" -"episodes/13-hosting.md" "47486b207801b83534734ca1d0d68ab2" "site/built/13-hosting.md" "2024-02-23" -"episodes/14-supplemental-rstudio.md" "b762f04d5306dfa51dce0d10342f802b" "site/built/14-supplemental-rstudio.md" "2024-01-13" -"instructors/instructor-notes.md" "595ad8f08c4edeed0e0fea6d99f3c6ae" "site/built/instructor-notes.md" "2024-01-13" -"learners/discuss.md" "ecedb12d5d5c004b1f80bb919568a992" "site/built/discuss.md" "2024-02-23" -"learners/reference.md" "3f205209ed4d5580b7efbe7a676f0df2" "site/built/reference.md" "2024-01-13" -"learners/setup.md" "d550d9a13563fa02c6065493450dc24b" "site/built/setup.md" "2024-01-13" -"profiles/learner-profiles.md" "5fe5bf7537072422b91ed393ada03f9a" "site/built/learner-profiles.md" "2024-01-13" -"renv/profiles/lesson-requirements/renv.lock" NA "site/built/renv.lock" "2024-02-23" +"CODE_OF_CONDUCT.md" "c93c83c630db2fe2462240bf72552548" "site/built/CODE_OF_CONDUCT.md" "2024-02-23" +"LICENSE.md" "b24ebbb41b14ca25cf6b8216dda83e5f" "site/built/LICENSE.md" "2024-02-23" +"config.yaml" "69e678021a92f74f922e53d180d05f47" "site/built/config.yaml" "2024-02-23" +"index.md" "a0bf9198af03d79145509a9fd132ab8d" "site/built/index.md" "2024-02-23" +"episodes/01-basics.md" "31f60f1f17daa4cb4d919d0902ffbc7f" "site/built/01-basics.md" "2024-02-23" +"episodes/02-setup.md" "5afa0e80062ab1477afe913a22923306" "site/built/02-setup.md" "2024-02-23" +"episodes/03-create.md" "b7ad40f47369cac2251a357ba5b76011" "site/built/03-create.md" "2024-02-23" +"episodes/04-changes.md" "b1ba204b17c9a74adcf2cd8bc81d7a4c" "site/built/04-changes.md" "2024-02-23" +"episodes/05-history.md" "6a6581cc3a5e0d0824b3baca10421b32" "site/built/05-history.md" "2024-02-23" +"episodes/06-ignore.md" "0683eb66e0a84b5297827704a1010c7b" "site/built/06-ignore.md" "2024-02-23" +"episodes/07-github.md" "76be3c6641d45b04e5ea3bfcf3214880" "site/built/07-github.md" "2024-02-23" +"episodes/08-collab.md" "2c7c53835e365abd47dcc5a41a654c66" "site/built/08-collab.md" "2024-02-23" +"episodes/09-conflict.md" "4b0fefa340bdf583efad05b8343113f1" "site/built/09-conflict.md" "2024-02-23" +"episodes/10-open.md" "6504a09be66b6c32dc3bc929da9ae50e" "site/built/10-open.md" "2024-02-23" +"episodes/11-licensing.md" "760c89ee6411c89378229180997a4388" "site/built/11-licensing.md" "2024-02-23" +"episodes/12-citation.md" "9a98ff6d0d30143af1cf0f4c83804486" "site/built/12-citation.md" "2024-02-23" +"episodes/13-hosting.md" "5de90c2a18e9d00c0dba4d9cd0bf2bf8" "site/built/13-hosting.md" "2024-02-23" +"episodes/14-supplemental-rstudio.md" "752afc0bacceff6e2a6c19f415753292" "site/built/14-supplemental-rstudio.md" "2024-02-23" +"instructors/instructor-notes.md" "8711174c9d3e1f433cdcf9b30cd571d9" "site/built/instructor-notes.md" "2024-02-23" +"learners/discuss.md" "8893316c5cf0dee6a42dd818f6e21122" "site/built/discuss.md" "2024-02-23" +"learners/reference.md" "d976a57639fa49361d9c8431850cde6a" "site/built/reference.md" "2024-02-23" +"learners/setup.md" "19ccf15a75716fe39f1116abf68a380d" "site/built/setup.md" "2024-02-23" +"profiles/learner-profiles.md" "60b93493cf1da06dfd63255d73854461" "site/built/learner-profiles.md" "2024-02-23" diff --git a/reference.md b/reference.md index 61694fddc..88b7f3069 100644 --- a/reference.md +++ b/reference.md @@ -1,5 +1,5 @@ --- -title: Git Cheatsheets for Quick Reference +title: 'Git Cheatsheets for Quick Reference' --- ## Git Cheatsheets for Quick Reference @@ -77,3 +77,5 @@ small. Each set of changes creates a new [commit](#commit) of the files; the version control system allows users to recover old commits reliably, and helps manage conflicting changes made by different users. + + diff --git a/setup.md b/setup.md index 38d6a9f0e..fc90de677 100644 --- a/setup.md +++ b/setup.md @@ -1,47 +1,54 @@ --- -title: セットアップ +title: Setup --- -## Gitのインストール +## Installing Git -いくつかのCarpentriesのレッスンはGitに依存しているので、 -[ワークショップテンプレートのこのセクション][workshop-setup] を参照してください。 -様々なオペレーティングシステムにGitをインストールする手順があります。 +Since several Carpentries lessons rely on Git, please see +[this section of the workshop template][workshop-setup] for +instructions on installing Git for various operating systems. -- [Windows でのGit のインストール][workshop-setup] -- [MacOS でのGit のインストール][workshop-setup] -- [Linux でのGit のインストール][workshop-setup] +- [Git installation on Windows][workshop-setup] +- [Git installation on MacOS][workshop-setup] +- [Git installation on Linux][workshop-setup] -## GitHub アカウントの作成 +## Creating a GitHub Account -このレッスンのエピソード7と8には、 [GitHub](https://github.com)のアカウントが必要です。 +You will need an account for [GitHub](https://github.com) to follow episodes 7 & 8 in this lesson. -1. https\://github.com にアクセスし、ウィンドウの右上にある「Sign Up」のリンクに従ってください。 -2. 指示に従ってアカウントを作成してください。 -3. GitHub でメールアドレスを確認する。 -4. 多要素認証を設定する（下記参照）。 +1. Go to and follow the "Sign up" link at the top-right of the window. +2. Follow the instructions to create an account. +3. Verify your email address with GitHub. +4. Configure multifactor authentication (see below). -### 多要素認証 +### Multi-factor Authentication -2023年にGitHubは 、セキュリティを強化するためすべてのアカウントに [多要素認証(2FA)](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/about-two-factor-authentication)の設定を行うという要件を導入した。 -2FAを設定するためにいくつかのオプションがあります。 +In 2023, GitHub introduced a requirement for +all accounts to have +[multi-factor authentication (2FA)](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/about-two-factor-authentication) +configured for extra security. +Several options exist for setting up 2FA, which are summarised here: -1. [Google Authenticator](https://support.google.com/accounts/answer/1066447?hl=en\&co=GENIE.Platform%3DiOS\&oco=0)や [Duo Mobile](https://duo.com/product/multi-factor-authentication-mfa/duo-mobile-app) のような認証アプリを既に使っている場合は、 [そのアプリにGitHub を追加](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication#configuring-two-factor-authentication-using-a-totp-mobile-app) してください。 -2. スマートフォンにアクセスできるが、まだ認証アプリを使っていない場合は、認証アプリをインストールし、 [アプリにGitHubを追加](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication#configuring-two-factor-authentication-using-a-totp-mobile-app)してください。 -3. スマートフォンにアクセスできない場合、または認証アプリをインストールしたくない場合は、2つの選択肢があります： - 1. [テキストメッセージによる2FAの設定](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication#configuring-two-factor-authentication-using-text-messages) - ([SMSによる認証がサポートされている国のリスト](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/countries-where-sms-authentication-is-supported))、または - 2. [ハードウェアセキュリティキーを使用する](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication#configuring-two-factor-authentication-using-a-security-key) - [YubiKey](https://www.yubico.com/products/yubikey-5-overview/) - のように、または[Google Titanキー](https://store.google.com/us/product/titan_security_key?hl=en-US\&pli=1)を使用してください。 +1. If you already use an authenticator app, + like [Google Authenticator](https://support.google.com/accounts/answer/1066447?hl=en&co=GENIE.Platform%3DiOS&oco=0) + or [Duo Mobile](https://duo.com/product/multi-factor-authentication-mfa/duo-mobile-app) on your smartphone for example, + [add GitHub to that app](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication#configuring-two-factor-authentication-using-a-totp-mobile-app). +2. If you have access to a smartphone but do not already use an authenticator app, install one and + [add GitHub to the app](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication#configuring-two-factor-authentication-using-a-totp-mobile-app). +3. If you do not have access to a smartphone or do not want to install an authenticator app, you have two options: + 1. [set up 2FA via text message](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication#configuring-two-factor-authentication-using-text-messages) + ([list of countries where authentication by SMS is supported](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/countries-where-sms-authentication-is-supported)), or + 2. [use a hardware security key](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication#configuring-two-factor-authentication-using-a-security-key) + like [YubiKey](https://www.yubico.com/products/yubikey-5-overview/) + or the [Google Titan key](https://store.google.com/us/product/titan_security_key?hl=en-US&pli=1). -GitHubのドキュメンテーションに[2FAの設定に関する詳細](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication)があります。 +The GitHub documentation provides [more details about configuring 2FA](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication). -*** +---------------- -## 作業ディレクトリの準備 +## Preparing Your Working Directory -`Desktop`フォルダーで作業を行うので、作業ディレクトリーを`Desktop`フォルダーに変更してください： +We'll do our work in the `Desktop` folder so make sure you change your working directory to it with: ```bash $ cd @@ -49,3 +56,4 @@ $ cd Desktop ``` [workshop-setup]: https://carpentries.github.io/workshop-template/install_instructions/#git +