はじめに

MacにプリインストールされているGitのバージョンが低かったのでアップデートした際のメモです。

Update

まずは現状のバージョンを確認。

$ git --version
git version 2.10.1

（うーん、低かった...）

調べたところ、brewでアップデートおよび管理するのが一番手軽そうだったのでbrewにてインストール。
事前にbrewのインストール済みパッケージを確認したい場合には以下のコマンドを実行。

$ brew ls

では、導入開始。

$ brew install git
 :
 :
Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
Could not symlink bin/git
Target /usr/local/bin/git
already exists. You may want to remove it:
  rm '/usr/local/bin/git'

To force the link and overwrite all conflicting files:
  brew link --overwrite git

To list all files that would be deleted:
  brew link --overwrite --dry-run git
 :
 :
Error: Permission denied @ apply2files - /usr/local/.....

予想に反してやたらとエラーが...
とりあえず、慌てずにバージョンを確認。

$ git --version
git version 2.10.1
$ brew ls | grep git
git
$ brew info git
git: stable 2.25.0 (bottled), HEAD
 :

Gitのバージョンは変わってないが、brewによりバージョン2.25.0のインストールはされている。
エラーメッセージの通り、インストールはできたがシンボリックリンクが作れなかったってことだ。
というわけで、エラーメッセージに記載のコマンドでシンボリックリンクをオーバーライドしてみる。

$ brew link --overwrite git
Linking /usr/local/Cellar/git/2.25.0_1... 208 symlinks created
$ git --version
git version 2.25.0

これで今度こそバージョンアップ完了！

もう一つ出ていたエラー Permission denied @ apply2files はbrewのIssue #45009のコメント が参考になりそう。
あとでトライしてみる。

githubのリポジトリとは何?

リポジトリは、プロジェクトのフォルダーのようなものです。 プロジェクトのリポジトリにはプロジェクトのすべてのファイルが含まれ、各ファイルのリビジョン履歴が保存されます。 プロジェクトの作業をリポジトリ内で議論し、管理することもできます。

参考↓
https://help.github.com/ja/github/creating-cloning-and-archiving-repositories/about-repositories

どういうタイトルをつければいいのか?

基本的に英語でタイトルをつけます。　
自分で見返した際に何を作ったか分かるようなものが良いです。

例) git-practice, python-first-game等

descriptionとは?

タイトルの説明です。
オプションですので必須ではないですが、後に見返した時のために書いておいた方が良いでしょう。
こちらは英語,日本語どちらでも大丈夫です。
ちなみに私は日本語で書いてます。

例) 〇〇会社のlp模写, Javascriptで〇〇作ってみた

リポジトリは、作っている作品ごとに新しくリポジトリを作成していくものです。

どのタイミングでリポジトリを変更すれば良いのか?

リポジトリは作っているものや学習している内容が変わったら変更します。
かなり変更するので、多くなっていくものです。

PublicとPrivate

公開するか非公開にするかの選択ですね。
書いている内容が余程重要なものではない限り、基本的に公開して問題ないです。

プッシュしていくと

プッシュしていくと、中のファイルが更新されていきます。
追加される訳ではないのでご注意下さい。

終わりに

githubはgitの知識も必要になってくるので初心者の方にはかなり難易度の高いものだと思います。
私自身も手間取りましたね。
gitについて初心者におすすめの書籍があるので良かったら参考にしてみて下さい↓
https://www.amazon.co.jp/%E3%82%8F%E3%81%8B%E3%81%B0%E3%81%A1%E3%82%83%E3%82%93%E3%81%A8%E5%AD%A6%E3%81%B6-Git%E4%BD%BF%E3%81%84%E6%96%B9%E5%85%A5%E9%96%80%E3%80%88GitHub%E3%80%81Bitbucket%E3%80%81SourceTree%E3%80%89-%E6%B9%8A%E5%B7%9D-%E3%81%82%E3%81%84/dp/4863542178/ref=asc_df_4863542178/?tag=jpgo-22&linkCode=df0&hvadid=295686767484&hvpos=&hvnetw=g&hvrand=16461701231400126736&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=1009243&hvtargid=pla-526224398321&psc=1&th=1&psc=1

この連載はこんな人に向けて書かれています。

• 小説作家さん
• 編集者さん
• 校正さん
• ライターさん
• 発注者さん

つまり文章を書いたり修正したりする全ての人たちですね！

0. この連載を始めたきっかけ

僕は片倉青一という筆名で小説を書いています。
小説だけではご飯を食べられないので、覆面ライターもやっています。せちがらい。

で、覆面ライターの案件で
「クライアントさん… Git と GitHub 使って仕事したいです…」
って言ったら、使っていいということになりました。やったぜ。
でもクライアントさんは Git と GitHub の使い方をあんまり知らないので、片倉が入門書を書くことになりました。なんてこった。

この連載は、片倉がこれからの仕事で楽をするために始めました。
目標は、クライアントさんに Git と GitHub の使い方をひととおり覚えてもらい、記事の管理と校正・校閲をお任せできるようになるまでです。
手取り足取り、ここまでやるか、というくらいサポートします。

皆さんも、どうせ苦労するなら楽をするための苦労をしましょう。

1. 今回のゴール

1. GitHub アカウントを取得する
2. Sourcetree をインストールする
3. リモートからリポジトリをクローンする

以上です。ここまでできれば、あなたはとてもとてもえらい。

とっとと導入して手を動かしたい人はこちら
3. さあ Git と GitHub の準備をしよう

※ゴールに違和感を覚えた人へ
具体的には「え、初手で git clone なの？」「git init とか git remote add は？」と思ったあなたへ。
Git を操作する入り口として「新しく手元に作る（git init）」と「すでにあるものを持ってくる（git clone）」の2種類があります。
この記事は、既に動いているプロジェクトへ新たに参加するメンバーへの教育を想定しているため、後者を選びました。

2. Git と GitHub って何が便利なの？

メリットがわからないことには使う気になりませんよね。
わかります。今のままでいいんじゃね？という気持ち。とてもわかります。
ですが、一度 Git と GitHub の使い方を覚えてしまうと、これらを手放せなくなる程度にはとても便利です。
（ちなみに Git はツールの名前、GitHub は Web サービスの名前です）

2.1 概観：どんなことができるのか

まずはこちらをご覧ください。

これは、いまあなたが読んでいるこの記事が、どのように変わっていったのか Git で記録し、 Sourcetree というツールで見やすくしたものです。

Git で変更履歴を記録する、というのは、ゲームでいうところのセーブデータを作成するような感じです。
好きなタイミングで作業内容のセーブデータを作ったり、セーブデータをロードできたりします。

2.2. セーブデータの一覧

「セーブデータの一覧」のエリアでは、セーブデータがどのように作られてきたのか、樹形図で閲覧できます。
上が最新で、下に行くほど古くなります。

最新のセーブデータには「修正案を取り入れた」という見出しが付いています。
任意のセーブデータをダブルクリックすると、そのセーブデータに記録されたファイルをロードすることもできます。つまり、好きなタイミングでバックアップを取って、いつでも元に戻せるわけです。
最新版に戻したいときは、最新版のセーブデータをダブルクリックするだけ。簡単でしょう？

2.3. 変更の日時とか

「変更の日時とか」のエリアでは、誰がいつセーブデータを作成したのか、どのセーブデータから内容を変えたのか、といった概要を閲覧できます。

図中に「コミット」とありますね。誰かが好きなタイミングで作ったセーブデータのことを Git では「コミット（commit）」と呼びます。

突然ですが、おめでとうございます！
あなたは Git 用語をひとつ覚えました！えらい！！

そう、コミット（commit）です。
セーブデータを作ることをコミットする（git commit）と言います。また、セーブデータそのものを指してコミット（commit）と言います。

2.4. 具体的な変更内容

「具体的な変更内容」のエリアでは、選択したセーブデータとその直前のセーブデータとで、ファイルがどのように変わっているのか、詳細を閲覧できます。赤いハイライトは古い内容、緑のハイライトは新しい内容です。差分を比較する、あるいは diff を取る、とも言います。

… SouceTree の表示はちょっとわかりにくいですね。画面端で折り返されていませんし、行単位でしか変更箇所がわかりません。
というわけで、同じ部分を GitHub で表示してみましょう。

薄いハイライトは「変更の行」です。
濃いハイライトは「変更箇所」です。
Sourcetree に比べるとかなりわかりやすいですね。
文字単位で変更箇所をピックアップしてくれると最高なのですが、現状は「ある程度の塊」をピックアップしてくれます。

Git と GitHub は本来、ソフトウェアのバージョン管理に使うものです。
英語で書かれたテキストにはめっぽう強いのですが、日本語で書かれたテキストに対する差分比較機能は、ちょっと弱めです。
もちろん、あると無いとでは大違いですけれど。

2.5. GitHub での校正校閲についてもちょっとだけ

さて、ひととおり、原稿を書き終えたとしましょう。
もちろん終わりではありませんね。文章は推敲して完成するものです。
推敲するときは、誰かに査読してもらい、指摘してもらうのが一番です。
そう、校正校閲です。
GitHub を使うと、校正校閲が爆速になります。体感ですが、10倍くらい速くなります。

こんな感じで、原稿の内容を議論します。
（議論相手の acple は片倉に Git を教えてくれた物好きです）

2.6. そろそろまとめて

はい、まとめます。

原稿の執筆段階では、 Git を使って好きなタイミングでバックアップを作成できます。
二人以上で推敲する段階では、 GitHub を使って校正校閲を爆速で進められます。

詳細なメリットを箇条書きにします。

• Git を使うと
  • コミットを積んでいくことで、原稿がどう変わっていったのかわかる。
  • どれが原稿の最新版なのか、ファイル名に日付を入れなくてもハッキリわかる。 <- 超重要！
  • いつでも好きなコミットの状態に戻すことができる。
  • 誰がそのコミットを積んだのかわかる。
  • 結果、バージョン管理がめちゃくちゃ楽になる。

具体的な例を挙げると

Qiita記事1-1_Ver1.2_片倉最新版_Final★これで最後★2月6日acple指摘反映.docx
Qiita記事1-1_Ver1.2片倉最新版_Final★これで最後★2月6日片倉修正.docx
Qiita記事1-1_Ver1.2片倉最新版_Final_2月6日Final Final_23時50分版.docx

みたいな地獄から解放されます。

• さらに GitHub を使うと
  • 変更点に関して、必要に応じた濃さで議論できる。
  • 査読者は片っ端から修正案を挙げて、筆者は片っ端から案を検討できる。
  • 互いの待ち時間が圧倒的に圧縮された結果、校正校閲が爆速になる。
  • 議論の内容が原稿ファイルに書き込まれることはない。

どうでしょう？覚えたら便利だと思いませんか？

2.7. Word とか Google Document じゃダメ？

一人で執筆するだけなら、 Word や Google Document で何も問題はありません。
一太郎も良いエディタです。片倉も一太郎をときどき使います。
ですが、バージョン管理と共同編集作業までこなすとなると、 Word や Google Document だけでは厳しくなります。

もう一度言います。
執筆するだけなら、何を使っても問題ありません。
ただし、バージョン管理や共同編集作業にあたっては、それに適したツールを使いましょう、というお話しをしています。

Word やら Google Document やら一太郎やらをさんざん使い倒してきた片倉が断言します。
テキストファイルのバージョン管理は Git を使いましょう。あなたが楽になります。
テキストファイルの共同編集作業は GitHub を使いましょう。みんなが楽になります。

3. さあ Git と GitHub の準備をしよう

お待たせしました。
いよいよ実際に手を動かして、 Git と GitHub の世界に足を踏み入れましょう。

3.1. GitHub アカウントを取得する

まずは GitHub アカウントを取得するところから始めましょう。
英語サイトだからといって怖がらないでくださいね。
以下の3つがあれば大丈夫です。

• Username（ユーザーネーム）
• Email address（メールアドレス）
• Password（英数字記号を含めた15文字以上のパスワード）

以下のリンクからアカウントを取得してください。
Join GitHub · GitHub

よくあるアカウント取得の手順なので、詳細は割愛します。
画面の指示にしたがって進めてください。
ブラウザの翻訳機能を使ってもいいでしょう。

なお、 GitHub にはいくつか料金プランがあります。
今回はフリープランを選びましょう。

Complete Setup ボタンを押すと、認証用のメールが届きます。
メールに記載された Verify email address リンクを踏むことで、認証が完了します。

「新しくリポジトリを作るかい？」と聞かれますが、今回は作らなくてOKです。

最後に、プロフィールのアイコンだけ設定しておきましょう。

GitHub ページの右上に、自動生成されたアイコンが表示されています。

ユニークなアイコンなのですが、誰なのかちょっとわかりづらいです。

アイコンを選択して、プルダウンメニューから Settings を選びましょう。
こんな画面になるはずです。

画面右に表示されたアイコンの Edit ボタンをクリックして Upload a Photo を選択します。
ご自身だとわかる画像を選択してください。
画像の選択が終わったら、画面のちょっと下のほうにある Update profile ボタンをクリックして終了です。

2要素認証（Two-factor authentication）の設定は、必須ではありませんが、強く推奨します。
設定方法については
2 要素認証を設定する - GitHub ヘルプ
をご覧下さい。

以降、もっと細かい設定が必要になるときは、その都度記載します。

3.2. Sourcetree をインストールする

次は Git を PC にインストールしましょう！
…と言いたいところなのですが、単に Git をインストールして使うとなると、こんな感じの画面とにらめっこすることになります。

Ktkr@KtkrPC MINGW64 ~/Documents/GitLecture4Writer (chapter1_1)
$ git status
On branch chapter1_1
Your branch is ahead of 'origin/chapter1_1' by 1 commit.
  (use "git push" to publish your local commits)

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   Chapter1/Chapter1_1.md

no changes added to commit (use "git add" and/or "git commit -a")

Ktkr@KtkrPC MINGW64 ~/Documents/GitLecture4Writer (chapter1_1)
$ git fetch

Ktkr@KtkrPC MINGW64 ~/Documents/GitLecture4Writer (chapter1_1)
$ git log --oneline --graph --decorate --all
* 6df55bc (origin/chapter1_1) 修正案を取り入れた。インスコ手順は別途。
* d4d566d 最初の1歩を途中まで執筆。
| * 351f258 (origin/overview, overview) 最初に最低限のインストールを書きます
| * c19468a 全体構成の叩き台を作りました
|/
* a195fd3 (origin/master, origin/chapter1, origin/HEAD, master, chapter1) れどめを作成しました
* 95b1576 Initial commit

「ウッ」となりますね。片倉もなりました。
プログラマな人たちが「カタカタッ、ターンッ」ってやるアレです。 CLI（コマンド・ライン・インタフェース）といいます。
普段使っているアプリケーションはだいたい GUI（グラフィカル・ユーザ・インタフェース）です。

GUI に慣れきった人が、いきなり CLI なんて使えるわけがありません。
とっとと GUI で操作できる Git クライアントを導入しましょう。

GUI な Git クライアントは色々ありますが、この連載では Atlassian が提供している Sourcetree を利用していきます。

コレです。
無料で利用でき、 Windows と Mac OS X の両方に対応していて、日本語化もスマートで、見た目も綺麗です。 Git の最新版も内蔵しています。

もちろん、別の Git クライアントを使っても問題ありません。
オススメの GUI な Git クライアントがあったら教えてください。

以下のリンクから Sourcetree のインストーラーをダウンロードしてください。
Sourcetree - 無料の Git & Mercurial クライアント | Atlassian

インストーラーを起動すると、 Bitbucket Server か Bitbucket のどちらかにログインしてください、と言われます。

Bitbucket を選択してください。
ブラウザが起動し、 Atlassian アカウントの取得画面が出てきます。
Sourcetree の利用には Atlassian アカウントが必要です。

画面下部の Sign up for an account から、 Atlassian アカウントを取得してください。
Google アカウントあるいは Microsoft アカウントでログインしてもOKです。

ログインが完了すると、インストーラーの画面がこんな感じになります。

次へ をクリックすると、ツールを選択したり設定したりする画面になります。

- Mercurial は使わないのでチェックを外します。
- 改行の自動処理を設定する（推奨）とあります。これはチェックを入れます（でも LF -> CRLF って…逆だろjk…）。
- Configure Global Ignore もチェックを外します。

次へ をクリックすると、 Git を操作するときの名前とメールアドレスを登録する画面になります。

GitHub に登録している名前・メールアドレスと一致させましょう。
後から変更できますが、ここで一致させておいたほうが面倒が少なくて楽です。

次へ をクリックすると、SSHキーを読みこむかどうか、というよくわからない質問ダイアログが出てきます。

いいえ で問題ありません。
（※SSH 周りは次回解説します）

この画面が出てくれば、 Sourcetree のインストールは完了です。

どうですか？

ほほう、無事にインストールできましたか。

素晴らしい。

実は、ここまでたどり着ける人さえ少数派です。
「うーん…よくわかんない。やーめた。今のままでいいや」
という人は、とてもとても多いのです。
最初はよくわからないでしょう。片倉もよくわかりませんでした。
ですが、大丈夫です。じっくり解説を読んで、手を動かせば、必ず覚えられます。

4. リポジトリをクローンしよう

では最後に、リモートからローカルへ、リポジトリをクローン（git clone）しましょう。
いきなり4つも新しい言葉が出てきましたね。
安心してください。ちゃんと説明します。

まず、リポジトリ（Repository）とは、 Git が管理対象にしているフォルダとファイルのことです。
多くの場合、リポジトリは2箇所にあります。

• ローカルリポジトリ：あなたが編集するファイルとフォルダ
• リモートリポジトリ：ローカルのデータを転送し、複数人で共有できる場所

※ 厳密ではありませんが、理解の促進を優先しています。

※この概念図も厳密ではありませんが、理解の促進を優先しています。

「リモートからローカルへ、リポジトリをクローンする」
というのは、
「共有場所にあるファイルとフォルダを、あなたが作業する場所へ丸ごと複製する」
という作業のことです。

あまり難しいことではありませんね。
だったらどうしてこんな言葉を使うのかというと、 Git の操作そのものがこれらの言葉で表現されるからです。
「結果にコミットする」とか、そんな感じのあいまいな意識高い系レトリックではありません。
Git でコミットする（git commit）と言ったら、作業した内容をセーブデータとして記録する、という具体的な操作を意味します。

では、実際にクローンしましょう。

Sourcetree の clone ボタンをクリックしてください。
こんな画面になります。

元のパス/URL:
という入力欄に、以下のURLをコピペしてください。
https://github.com/ktkraoichi/GitLecture4Writer.git

コピペしたら、入力欄の外側を適当にクリックしてください。
Sourcetree がぐるぐる動き、自動的にリポジトリの種類、保存場所、名前などを判別してくれます。

じきにこんな画面になります。

クローン ボタンを押しましょう。
Sourcetree がリモートからローカルへ、リポジトリをクローンし始めます。

無事にクローンできたら、 Sourcetree にこんな感じの内容が表示されます。

※この画像は連載が進行すると変化します

そう、あなたが読んでいるこの連載のプロジェクトが、あなたの手元にやってきました。
History でコミットログをぽちぽちクリックすると、何がどう変わったのか、右下の差分比較機能で確認できますよ。

どうでしょう。できましたか？

無事にクローンできたなら、とてもとても素晴らしいことです。
ご自分を褒めてあげてください。

さん、はい

「俺、よくやった！」

リピート・アフター・ミー

「俺、よくやった！！」

本当にご自分を褒めてあげてくださいね。
「Git をやってみよう」と思って勉強を始めた物書きさんのうち、おそらく100人中70人くらいは、ここまでで心が折れます（多めに見積もっています）。

この連載は、片倉がクライアントさんに Git と GitHub の使い方を覚えてもらえるまで終われません。
ここまでの解説で分からないことがあったら、コメントや Twitter で@片倉青一に聞いてください。

片倉のクライアントさんは仕事用のチャットツールで連絡してください。

5. 次回予告

次回のゴールは

• GitHub に自分のリモートリポジトリを作ってみる
• 自分のリポジトリをクローン（git clone）してみる
• ローカルでコミット（git commit）してみる
• ローカルの内容をリモートにプッシュ（git push）してみる
  • プッシュするために SSH の設定をする

の4点（5点）です。

焦らず慌てず、ゆっくり勉強していきましょう。

※2020年2月12日追記
継続して勉強したい人はこの記事をストックしておいてください。
次の記事を投稿したら、この記事も「変更通知を送る」で更新します。
通知が届くので便利ですよ。

6. 付録

6.1. コマンドでやりたい人へ

「せっかくだから俺は最初から CLI で Git を操作するぜ！」
というやる気勢のあなた。素晴らしい。感動しました。今後は Sourcetree の操作と同時に CLI のコマンドも併記します。

以下から、ご利用の OS に合わせて Git をインストールしてください。
Git - Git のインストール

Git と GitHub の設定については以下のドキュメントを参考にしてください。
Git のセットアップ - GitHub ヘルプ

あなたなら Git と GitHub の設定までは、上記のドキュメントにしたがって進めていけるでしょう。

設定が終わったら Windows なら Git Bash を起動、 Mac OS X ならターミナルを起動して

cd "ローカルリポジトリの作成先"

と入力してください。
Windows なら cd Documents あたりでいいでしょう。

次に

git clone https://github.com/ktkraoichi/GitLecture4Writer.git

と入力してください。
リポジトリのクローンが始まります。

$ git clone https://github.com/ktkraoichi/GitLecture4Writer.git
Cloning into 'GitLecture4Writer'...
remote: Enumerating objects: 25, done.
remote: Counting objects: 100% (25/25), done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 25 (delta 3), reused 19 (delta 3), pack-reused 0
Unpacking objects: 100% (25/25), done.

このように表示されればクローンは成功です。

念のため、ローカルリポジトリの中身を見てみましょう。
ファイルエクスプローラで目視してもいいのですが、コマンドでも確認してみましょう。

cd GitLecture4Writer
ls -a

と入力してください。

Ktkr@KtkrPC MINGW64 ~/Documents
$ cd GitLecture4Writer/

Ktkr@KtkrPC MINGW64 ~/Documents/GitLecture4Writer (master)
$ ls -a
.  ..  .git  Chapter1  README.md

Ktkr@KtkrPC MINGW64 ~/Documents/GitLecture4Writer (master)
$

ls -a は「現在のディレクトリに存在する全てのファイルとフォルダを表示する」というコマンドです。
少なくとも .git という隠しフォルダ、 Chapter1 というフォルダ、README.md というファイルがあるはずです。
※連載が進むと、主にChapter●●というフォルダが増えていきます。

せっかくなので Chapter1 というフォルダも見てみましょう。

cd Chapter1
ls

と入力してください。

Ktkr@KtkrPC MINGW64 ~/Documents/GitLecture4Writer (master)
$ cd Chapter1/

Ktkr@KtkrPC MINGW64 ~/Documents/GitLecture4Writer/Chapter1 (master)
$ ls
Chapter1_1.md  img

Chapter1_1.md は、いまあなたが読んでいる記事そのものです。
ちょっと不思議な感じがしますね。

どうですか？ありましたか？

素晴らしい！

6.2. Git の操作方法について

この連載では GUI な Git クライアントとして Sourcetree を使うことにしています。
過去に片倉は GitKraken という GUI Git クライアントを使って Git を操作していました。

GitKraken
Free Git GUI Client - Windows, Mac & Linux | GitKraken

UI は全部英語ですが、英語力ほぼゼロの片倉でも直感的に使えたくらいには洗練されています。
Windows, Mac OS X, Linux で動作します。
2019年6月から無償プランではプライベートリポジトリを利用できなくなってしまいました。
ザンネン。

Git への理解を深めたら、折りを見て CLI に移行したほうがいいと思います。
慣れさえすれば、 Git の操作は CLI が最適です。
現在は Visual Studio Code の Source Control を使ったり、ターミナルで GitBash を開いてコマンドを叩いています。

6.3 あれ、 clone するとき GitHub アカウントって…

はい。パブリックリポジトリを clone する場合、 GitHub アカウントの情報は必須ではありません。
ですが、次回の記事ですぐ必要になるため取得してもらいました。
Atlassian アカウントのユーザ名とメールアドレスが一致するようにしてもらったのも、後の作業を楽にするためです。

監修

@acple@github

• C#チョットデキル
• Git完全に理解してる

Gitの操作についてまとめました。
自分用として逆引き辞典みたいに活用したかったので、見出しがコマンドだったり説明だったりしますがご了承ください。
新たな発見があればその都度更新してゆきます。
間違いがあればご指摘いただければ幸いです。

gitの初期設定

Gitのバージョン確認

$git version

githubのユーザー情報を登録する

git config --global user.name"github user name"
$git config --global user.name"github user name"

エディタを登録する

Visual Studio Codeで「command + shift + p」でコマンドパレットを開き下記を実行する。

Shell Command: Install 'Code' command in path

コマンドラインから下記のコマンドを実行する。

git config --global core.editor "code --wait"

これでgit commitした際にVisual Studio Codeが起動すればOKです。

ユーザー情報の確認方法

git config user.name
git config user.email

ユーザー情報を一覧で確認する方法

git config --list

ユーザー情報の場所

cat ~/ .gitconfig

git操作で必須のコマンド

コマンド名	説明
cd	ディレクトリの移動
ls	ディレクトリの内容を表示
ls-a	隠しファイルを含めたディレクトリの内容を表示する
mkdir	ディレクトリを新規に作成
rm	ファイルを削除
cp	ファイルをコピー
mv	ファイルの移動とファイル名の変更
cat	ファイルの中身を表示

Giの基本操作

git init

ローカルリポジトリの新規作成

git init

git add

ステージへの追加

git add <ファイル名>
git add <ディレクトリ名>
git add .

git commit

変更をコミットする

git commit
git commit -m "メッセージ"
git commit -v

• git commitを実行するとVSCodeが立ち上がる。 コメントを入力しファイルを保存し閉じるとコミットが完了する。
• -m でgitエディタを立ち上げる事なくコミットできる。
• -v で変更内容をgitエディタで確認する事ができる。

状態の確認方法

git status

現在の変更状況をファイル単位で確認する

git status

・ワークツリーとステージ
・ステージとリポジトリ
上記のそれぞれで変更されたファイルが表示される。

git diff

現在の変更差分を確認する

# git add する前の変更分
git diff
git diff <ファイル名>

# git add した後の変更分
git diff --staged

git log

変更履歴を確認する

# １行で表示する
git log --oneline

# ファイルの変更差分を表示する
git log -p index.html

# 表示するコミット数を制限する
git log -n <コミット数>

ファイルの移動・削除の記録方法

git rm

ファイルの削除を記録する

# ファイルごと削除
git rm <ファイル名>
git rm -r <ディレクトリ名>

# ファイルを残したい時
git rm --cached <ファイル名>

パスワードファイルなど間違えてコミットしてしまった場合には
--cached オプションを使ってgitの追跡から外す

git mv

ファイルの移動を記録する(ファイル名変更)

git mv <旧ファイル>　<新ファイル>

#　以下のコマンドと同じ
mv <旧ファイル>　<新ファイル>
git rm <旧ファイル>
git add <新ファイル>

変更を取り消す処理

git checkout

ファイルの変更を取り消す

git checkout -- <ファイル名>
git checkout -- <ディレクトリ名>

# 前変更を取り消す
git checkout -- .

ブランチ名とファイル名が同じ場合、区別をつける為に -- をつける。

git reset HEAD

ステージングを取り消す

git reset HEAD <ファイル名> 
git reset HEAD <ディレクトリ名>

# 全変更を取り消す
git reset HEAD .

ステージングは取り消されるが、ファイルの変更は取り消されないので、ファイルの変更まで取り消したい場合は「git checkout」コマンドを使う。

リモート

git add origin

リモートリポジトリを新規登録する

git add origin https:github.com/user/repo.git

• originというショートカットでURLのリモートリポジトリを登録する
• 今後は origin という名前でgithubリポジトリにアップしたり取得したりできる
• gitではメインのリモートリポジトリの事を origin と呼んでいる

git clone

既存のリモートリポジトリをローカルに複製する

git clone リモートリポジトリ名

git push

リモートリポジトリ（Github）へ送信する

git push <リモート名><ブランチ名>
git push origin master

# 次回以降 git push だけでよくなるコマンド
git push -u origin master

git remote

リモートを表示する

git remote

# 対応するURLを表示
git remote -v

git remote show

リモートの詳細情報を表示する

git remote show <リモート名>
git remote show origin

• FetchとPushのURL
• リモートブランチ
• git pullの挙動
• git pushの挙動

git remote rename

リモートを変更・削除する

# リモートを変更する場合
git remote rename <旧リモート名> <新リモート名>
git remote rename tutorial new_tutorial

# リモートを削除する場合
git remote rm <リモート名>
git remote rm new_tutorial

git remote add

リモートリポジトリを新規追加する

git remote add <リモート名> <リモートURL>
git remote add tutorial https://github.com/user/repo.git

# 「origin」で登録した時と同じように次回からは「tutorial」というショートカットでプッシュやプルをする事ができる。

リモートリポジトリを複数登録するのはどんな時か？

・チーム開発とは別に自分でもリモートリポジトリを持っておきたい場合。
・複数のチームで開発する場合。

リモートから情報を取得する

1.フェッチ
2.プル

git fetch

git fetch <リモート名>
git fetch origin

# フェッチした情報は　remotes/リモート/ブランチ　に保存される。

# フェッチした情報をマージコマンドでワークツリーに取り込む
git merge origin/master

フェッチされた情報はローカルリポジトリの
remotes/リモート/ブランチ
に保存される。

この情報をワークツリーに反映させるには
git mergeコマンド
を使う必要がある。

**補足**

# ブランチの中身を全て確認する（-aはallの略）
# 現在いるブランチに「＊」がつく
git branch -a

# ブランチを切り替えてフェッチした内容を確認する
git checkout remotes/origin/master

# 元のマスターブランチに切り替える
git checkout master

git pull

git pull <リモート名> <ブランチ名>
git pull origin master

# 上記コマンドは省略可能
git pull

# git pullは下記コマンドと同じ事をしている
git fetch origin master
git merge origin/master

git pullはリモートリポジトリからローカルリポジトリのワークツリーに反映させるのを一度にやってしまう。便利な反面注意点がある。

プルを実行する際の注意点

プルしてきたブランチは現在いるブランチに統合される為、思わぬブランチに統合されファイルがぐちゃぐちゃになってしまう危険性がある。
そのため慣れないうちはフェッチを使った方が安全。

ブランチ

並行して複数の機能を開発するためにあるのがブランチ

ブランチを新規追加する

git branch <ブランチ名>
git branch feature

# ブランチを作成するだけでブランチの切り替えまでは行わないので注意

ブランチの一覧を表示する

git branch

# 全てのブランチを表示する
# -aはallの略でリモートブランチも表示される
git branch -a

ブランチを切り替える

git checkout <既存ブランチ名>
git checkout feature

# ブランチを新規作成して切り替える
git checkout -b <新ブランチ名>

ブランチを変更・削除する

# 自分が作業しているブランチの名前を変更する
git branch -m <ブランチ名>
git branch -m new_branch

# ブランチを削除する
# masterにマージされていない変更が残っている場合はエラーが出る
git branch -d <ブランチ名>
git branch -d feature

# ブランチを強制削除する
# masterにマージされていない変更が残っていても強制削除される
git branch -D <branch名>

リモートブランチとは

# リモートリポジトリからfetchした情報が保存されるブランチ
git branch -a 
# を実行すると

remotes/origin/master
remotes/origin/feature

# などと表示される。

# このブランチの内容を参照したりマージしたりする場合は
# 頭の remotes/ はつけなくて良い。

git merge origin/master
git status origin/feature

マージ

マージとは他の人の変更内容を取り込む作業のこと
マージには以下の２種類がある。

・Auto Merge
・Fast Forward

Auto Merge:基本的なマージ

masterブランチ の内容が developブランチ を分岐した時より進んでしまっている場合、両方の変更を取り込んだマージコミットが作成される。
マージコミットは２つのperentをもつ。

# 指定したブランチが作業中のブランチにマージされる
git merge <ブランチ名>
git merge <リモート名/ブランチ名>
git merge origin/master

Fast Forward

hotfixブランチの変更をmasterにマージする際に、
masterブランチに変更がなければ、
masterブランチがhotfixブランチに移動するだけで
hotfixブランチの内容を取り込む事ができる。

このようなマージをFast Fowardという。

# Fast Fowardでコミットメッセージを残すには
# 設定でFast Fowardを無効にする

git config --global merge.ff false

コンフリクト

masterブランチとdevelopブランチで
同じファイルの同じ行が編集されていた場合、
マージした際に コンフリクト が起きる。

コンフリクトが起きないようにする為には

・複数人で同じファイルを変更しない
・pullやmergeをする際に変更中の状態をなくしておく（commitやstashをしておく）

プルリクエスト

自分の変更したコードをリポジトリに取り込んでもらえるよう依頼する機能

# プルリクエストの順序

1. ブランチを切る
2. ファイルを編集する
3. ローカルにadd,commitする
4. githubにプッシュする
5. githubで「Pull request」タブの「New pull request」ボタンを選択。
6.「base」と「compare」を選択する。
7.「Create pull request」を選択。
8.タイトルとコメントを入力。
9.「Create pull request」を押す。
10.右側の「reviewers」からレビューしてもらいたい人を選択し通知を送る。


# レビュワーの作業順序

1. githubで「Pull request」タブのレビューするコードを選択。
2. 「File changed」からコードを確認する。
3. コードの修正依頼をする場合は修正するコードをホバーして「➕」を押す。
4. コメントを入力して「Add single comment」を押す
5. コードレビューがリクエストした人に送信される。


# プルリクエストした内容を承認する場合

1.githubで「Pull request」タブの「Review changes」を押す。
2.「Approve」を選択し「Submit review」を押す。


# 承認されたリクエストをマージする方法

1. githubで「Pull request」タブの中の「conversation」タブで「Merge pull request」を選択する。
2.マージメッセージを確認し「Comfirm merge」を押す。
3.「Delete branch」ボタンを押してプルリクエストブランチを削除する。


# マージした内容をローカルにも取り込みプリクエストブランチを削除する。

git checkout master
git pull origin master
git branch -d pull_request

リベース

変更を統合する際に、履歴をきれいに整えるために使うのがリベース
作業が完了したブランチを分岐元のブランチにくっつける時に使う機能の一つです。

git rebase <branch名>

リベースの注意点

githubにプッシュしたコミットをリベースするのはNG。
また git push -f で強制的にプッシュするのもNG。

マージとリベースのどちらが良いか？

マージ	リベース
コンフリクトの解消が比較的簡単	コンフリクトの解消が大変（コミット毎に解消する必要がある）
マージコミットがたくさんあると履歴が複雑化する	履歴をきれいに保つ事ができる

コンフリクトを事前に確認する方法

一度githubにプッシュしてプルリクエストを作成する。
コンフリクトしている場合はアラートが表示される。
アラートが表示された場合はリベースではなくマージを使うと楽。

プルにはマージ型とリベース型がある

# マージ型のプル（通常のプル fetch → mergeと同じ挙動）
git pull <リモート名> <ブランチ名>
git pull origin master

# リベース型のプル（fetch → rebaseと同じ挙動）
git pull --rebase <リモート名> <ブランチ名>
git pull--rebase origin master

リベース型のメリット

マージコミットが残らない
githubの最新の情報を取得したいだけの時リベース型を使うのがおすすめ。

プルをリベース型に設定する

git config --global pull.rebase true

# masterブランチでpullする時のみ設定する場合
git config branch.master.rebase true

コミットの修正

直前のコミットをやりなおす

git commit --amend

複数のコミットをやりなおす

git rebase -i <コミットID>
git rebase -i HEAD~3

# 「i」は「interactive」の略
# 対話的リベースといって、やりとりしながら履歴を変更していく。
# 「HEAD~」とする事でHEADを基点に数値分の親コミットを指定する。
# 「HEAD^」とする事でHEADを基点にマージした場合の２つ目の親を指定できる。

① git rebase -i HEAD~3 を実行するとエディタが立ち上がって
直前のコミットが３つ表示される。
（順番が git log とは逆なので注意）

pick gh21f6d ヘッダー修正
pick 193954d ファイル追加
pick 8agha0d README修正

② やり直したいコミットの「pick」の部分を「edit」に変更する。
③ 保存してエディタを終了する。
④ editのコミットのところまでコミットの適用が止まる。
⑤ ファイルの内容を修正
⑥ ファイルをステージに追加
⑦ git commit --amend コマンドで修正
⑧ git rebase --continue コマンドで次のコミットへいく
⑨ 「pick」だとそのままコミット内容を適用して次へ進む。

指定したコミットを削除する

git rebase -i HEAD~3 

pick hncjk7d タイトルを修正
pick ksn6j4k 画像を追加
pick bgmk73h 背景画像を変更

# 消したいコミットを行毎削除すればOK！

指定したコミットを並び替える

git rebase -i HEAD~3 

pick hncjk7d タイトルを修正
pick ksn6j4k 画像を追加
pick bgmk73h 背景画像を変更

# 並び替えたい行を入れ替えればOK！！

指定したコミットを一つにまとめる

git rebase -i HEAD~3 

pick hncjk7d タイトルを修正
squash ksn6j4k 画像を追加
squash bgmk73h 背景画像を変更

#  pick を squash に変えれば直前のコミットと一つにまとまる。
#  squash の場合はコミットメッセージの入力が求められる。

コミットを分割する

git rebase -i HEAD~3 

pick hncjk7d タイトルを修正
pick ksn6j4k 画像を追加
edit bgmk73h index.html と style.css を変更

①分割したい行の「pick」を「edit」に変更する

git reset HEAD^
git add index.html
git commit -m "index.htmlを修正"
git add style.css
git commit -m "style.cssを修正"
git rebase --continue

# git reset とはコミットを取り消してステージングしていない状態に戻すコマンド。
# HEAD^ は edit に変えたコミットを指す。

タグ

コミットを参照しやすくするために、分かりやすく名前を付けるのがタグ。
よくリリースポイントに使います。

タグの一覧を表示する

git tag

# パターンを指定してタグを表示
git tag -l "201705"
20170501_01
20170502_01
20170502_02

タグには２つの種類がある

・注釈付き版（annotated）
・軽量版（lightweight）

注釈付き版のタグの作成

git tag -a <タグ名> -m "<メッセージ>"
git tag -a 20200203_01 -m "version 20200203_01"

軽量版のタグの作成

git tag <タグ名> 
git tag 20200203_01

昔のコミットにタグを付ける

git tag -a <タグ名> <コミットID> -m "<メッセージ>"
git tag -a 20200203_01 hfk9dsh -m "version 20200203_01"

git tag <タグ名> <コミットID>
git tag 20200203_01 hfk9dsh

タグのデータを表示する

git show <タグ名>
git show 20200203_01

タグをリモートリポジトリに送信する方法

git push <リモート名> <タグ名>
git push origin 20200203_01

# タグを一斉に送信する
git push origin --tags

githubでタグを確認する

Codeタブ → Releaseタブ →　Tags

スタッシュ

作業を一時避難するコマンド
急に別の作業をすることになった場合に、現在のワーキングツリーとステージの内容を避難させる事ができる。

git stash
git stash save

# stashとは「隠す」という意味

スタッシュした内容を確認する

git stash list

# 下記のようにスタッシュした数だけ表示される
stash@{0}
stash@{1}
stash@{2}

スタッシュした作業を復元する

# 最新の作業を復元する
git stash apply

# ステージの状況も復元する
git stash apply --index

# 特定の作業を復元する
git stash apply <スタッシュ名>
git stash apply stash@{1}

スタッシュした作業を削除する

# 最新の作業を削除する
git stash drop

# 特定の作業を削除する
git stash drop <スタッシュ名>
git stash drop stash@{1}

# 全作業を削除する
git stash clear

その他

コマンドにエイリアスをつける

git config --global alias.ci commit
git config --global alias.st status
git config --global alias.br branch
git config --global alias.co 

• エイリアスをつける事で設定が楽になる
• git config は設定を変更するコマンド
• --global をつけるとPC全体の設定を変更するコマンドになる
• --global を付けないと特定のプロジェクトにしか反映されない。
• 今回の省略コマンドは全てのプロジェクトで使用するので--grobalをつける

Gitで管理したくないファイルを外す

• パスワード情報などが記載されているファイル
• windwsやmacで自動生成されるファイル
• キャッシュ
• チーム開発に必要ないファイル

.gitignoreファイルに指定する

"4つの指定方法"

# 指定したファイルを除外
index.html

#ルートディレクトリを指定
/root.html

# ディレクトリ以下を除外
dir/

# /以外の文字列にマッチ「*」
/*/*.css

はじめに

githubで管理されているコードやナレッジを引継き，新しいリポジトリを作ろうとした際にWikiの移行のつまづいたので備忘録です

GitHubのWikiの移行

基本的に新しくWikiを作りWikiのみのリポジトリをgit cloneします．
httpsのバージョンはあったのですがsshのバージョンがなかったので載せときます．

sshにおけるWikiのgit clone

git clone git@github.com:[User or Organizations Name]/[Repository Name].wiki.git

例示

git clone git@github.com:EniwaSentaiToshiking/2020-base.wiki.git

cloneができてからは基本的にgitの使い方と変わらないので割愛します．
よしなにadd，commit，pushしてください

さいごに

Wikiをそもそもsshでcloneできること知らなかった・・・
あと中身は全部MarkDown形式なので他のツールとの相性も良さそうですね！
これで変にWikiの移行でhttpsだからUserNameとPasswordを聞かれてえ！？って迷うことはなくなるでしょう(2敗)

この頃よしなにを多用する癖がついてきた・・・