Gitのブランチについて知ろう

・ブランチを切るって何？
・ブランチ？想像もつかない
少しでも解決るべく、アウトプットしていきたいと思います。

Gitのブランチって？

ブランチは、『作業を枝分かれさせて、プロジェクト本体に影響を与えないようにするため』に使います。
切ったブランチ（分岐したブランチ）は、他のブランチへの干渉をしないため、同じリポジトリ中で複数の変更を同時に進めていくことができます。
ブランチを切らない場合は、masterブランチと言います。
川の流れに例えると、ブランチを切ることで、本流が支流に分岐されるイメージですね。
チームでの開発の場合などにブランチを切ったりするみたいです

ブランチを切るメリットは？

・不具合が起きた場合も対処しやすい
・チーう開発の際に他のメンバーの開発や、本体に影響を与えずに作業を行える

実際のコマンドは？

ブランチを切る→これでブランチを作成します

$ git branch [ブランチ名]

ここでは、sample_branchとしてブランチを切ります

$ git branch sample_branch

⇩ブランチの切り替えを行うコマンドです。

$ git checkout sample_branch

このブランチの切り替えで起こっているのが、上の図で言う所の、『赤い部分』から枝分かれした『白い部分』のことですね

ブランチを切った状態でも、同じようにファイルの変更を行います。そして、masterブランチの時と同様にコミットします。

$ git add .
$ git commit -m 'Add branch'

その後、ブランチをmasterへマージしていきます。
マージとは、masterブランチと切ったブランチ（ここでは、sample_branch）を結合することですね。
これでmasterブランチへ変更を反映させることができます。

$ git checkout master

でmasterブランチへ切り替えます。
そして、

$ git merge sample_branch  

sample_branchで行った変更な内容をmergeして反映させます。

以上、ブランチについてでした。

参考にした記事

https://backlog.com/ja/git-tutorial/stepup/01/
https://www.sejuku.net/blog/71071

前回までのあらすじ

統合環境開発の構築、railsのインストールをやっとの思いで完成させた。
今回はgitについての知識をまとめていきます。
主にrailsチュートリアルの内容に沿っておとなしくやっていくことにします。

gitgitって言われてるけどあんまよくわかってなかったので簡単にまとめると、アプリケーションのバージョン管理システムって感じ？？なんかイメージ的にはドラクエの教会みたいな感じかな？
その他にもチームで開発をするときとか本番サーバへデプロイすることもできんだって！！！

まずgit configで設定する。systemセットアップをするらしい。

$ git config --global user.name"Your Name"
$ git config --global user.email your.email

ここで設定する名前とメールアドレスは一般に公開されるから注意しないといけないみたい。
これ一回登録したらどうなんの？「あああああ。」みたいな名前にしちゃったらきついよね。
つーわけで調べたらちゃんと削除の仕方もあったわ。他にも色々あったので載せときます

git の基本的な使い方

確認

$ git config --list
$ git config キー名

登録・更新

$ git config キー名　設定値　#ローカルリポジトリに設定
$ git config --global キー名　設定値　#全てのローカルリポジトリに設定

削除

$ git config --unset キー名

これでいろいろ面白い名前試したくなっても大丈夫だね。

んで、セットアップしたいと思います。Railsアプリケーションのルートディレクトリへ移動。新しいリポジトリの初期化を行う。ちなみにルートディレクトリってのは階層型ファイル上の最上階のディレクトリのこと。つまりこのアプリケーションの大元ってこと。

$ git init
これが初期化。次にプロジェクトのファイルをリポジトリに追加
$ git add -A

これで現在のディレクトリにあるファイルがすべて追加される。
でもここまでの処理だけだとまだ終わりじゃなくって。。。
追加されたファイルはステージングっていう待機用のリポジトリに置かれてコミットをまつ。
ステージングの状態を知るには

$ git states

んでステージングエリアで控えている変更を本格的にリポジトリに反映（コミット）するには
commitコマンドと使う。

$ git commit -m"Initialize repository"
-mフラグを使うと、コミットメッセージをコマンドラインで直接指定ができる。-mフラグを使わない場合はシステムのデフォルトのエディタが開きそこでコミットメセージを入力する。

gitを使うとなにが便利なのか

についてrailsチュートリアルに書かれてたんだけどなんかコマンド間違って消しちゃっても変更されてるのは現在の作業ツリーだけだからすぐ修正できますよって感じかな！俺みたいなうっかりさんに優しいシステムってことだね！

GitHubとBitbucket

更にgitリポジトリを深めるには上記の２つも知っとかなきゃいかんらしい。どちらもGitリポジトリのホスティングと共同制作を行うことができ、リポジトリの表示や検索を行いやすくしてくれるシステムのことみたい。ホスティングがいまいちよくわかんなかったから調べたんでけどこれは要するにサーバを貸してくれるサービスのことみたい。つまりサーバを貸してくれてそこにリポジトリを置けて、なおかつみんなで使えるよーってことかな。

両者の違いは

GitHub...リポジトリを一般公開する場合は無料、公開しない場合は有料
Bitbucket...共同作業者が一定数以下ならリポジトリを公開しなくても無料、共同作業者が一定数を超えると有料
ってことみたい。俺みたいな一人でちょっといじってみたいくらいだとBitbucketのが良さそうだね。でも主流はGitHubだと思うからある程度慣れてきたらこっちも使っていきたいと思います。

待っって。。。
Railsチュートリアルの文章最後まで読んでみたんだけど

更新予告: 2019年1月からGitHubの非公開型レポジトリが無料になりました。共同作業できるメンバー数は限られているものの、非公開型のリポジトリが利用できるようになったため、本チュートリアルでも現在のBitBucketからGitHubに切り替える可能性があります。

ということみたですね。笑　なので今回は前言撤回してGitHubで登録していきたいと思います。GitHubはprogateにて登録していたのでスムーズに登録できました〜！

Branch

ブランチとは履歴の流れを分岐して記録していくためのもの。基本的にはリポジトリのコピーで、ブランチ上では元のファイルを触らずに新しいコードを書くなど、自由に変更や実験を試すことができます。通常、親リポジトリはmasterブランチと呼ばれ、トピックブランチ (短期間だけ使う一時的なブランチ) とに別れる。

$ git checkout -b modify-README
これがトピックブランチの作成
$ git branch
  master
* modify-README

2つ目のコマンド (git branch) は、すべてのローカルブランチを一覧表示します。「*」はそのブランチが現在使用中であることを表します。1番目のgit checkout -b modify-READMEコマンドで、ブランチの新規作成とそのブランチへの切り替えが同時に行われている。

modify-READMEブランチに「*」が付いていることで、このブランチが現在使用中であることが示されています

ブランチの真価は他の開発者と共同で作業する時に発揮されますが24、本チュートリアルのように一人で作業する時にも非常に有用です。masterブランチはトピックブランチで行った変更に影響されないので、たとえブランチ上のコードがめちゃくちゃになってしまっても、masterブランチをチェックアウトしてトピックブランチを削除すれば、いつでも変更を破棄する事ができます。

Edit (編集)

トピックブランチを作ったら、編集を行う。
viewを編集した内容にいじる。

Commit (コミット)

変更が終わったら、ブランチの状態を確認する。

$ git status
On branch modify-README
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   README.md

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

この時点でgit add -Aを実行することもできますが、git commitには現存するすべてのファイル (git mvで作成したファイルも含む) への変更を一括でコミットする-aフラグがあります。このフラグは非常によく使われる。

$ git commit -a -m "Improve the README file"
[modify-README 9dc4f64] Improve the README file
 1 file changed, 5 insertions(+), 22 deletions(-)

-aフラグは慎重に扱ってください。最後のコミット後に新しいファイルを追加した場合は、まずgit addを実行してバージョン管理下に置く必要があります。

コミットメッセージは現在形かつ命令形で書くようにしましょう (訳注: これは英語で書く場合のルールです。日本語であれば「〜を追加」などの体言止めがよいでしょう)

Merge (マージ)

ファイルの変更が終わったので、masterブランチにこの変更をマージ (merge) します。

$ git checkout master
Switched to branch 'master'
$ git merge modify-README
Updating af72946..9dc4f64
Fast-forward
 README.md | 27 +++++----------------------
 1 file changed, 5 insertions(+), 22 deletions(-)

Gitの出力には34f06b7のような文字列 (ハッシュ) が含まれていることがあります。Gitはこれらをリポジトリの内部処理に使っています。この文字列は環境の違いにより上記のものと少し異なるかもしれませんが、他の部分はほぼ同じはずです。

変更をマージした後は、git branch -dを実行してトピックブランチを削除すれば終わりです。

$ git branch -d modify-README
Deleted branch modify-README (was 9dc4f64).

トピックブランチの削除は必須ではありません。実際、トピックブランチを削除せずにそのままにしておくことはよく行われています。トピックブランチを削除せずに残しておけば、トピックブランチとmasterブランチを交互に行き来して、キリの良い所で変更をマージする事ができます。

上で述べたように、git branch -Dでトピックブランチ上の変更を破棄することもできます。

Push (プッシュ)

READMEファイルの更新が終わったので、Bitbucketに変更をプッシュして結果を見てみましょう。既に1.4.3で一度プッシュを行ったので、大抵のシステムではgit pushを実行するときにorigin masterを省略できます。

$ git push

今日はここまで。

前回までのあらすじ

統合環境開発の構築、railsのインストールをやっとの思いで完成させた。
今回はgitについての知識をまとめていきます。
主にrailsチュートリアルの内容に沿っておとなしくやっていくことにします。

gitgitって言われてるけどあんまよくわかってなかったので簡単にまとめると、アプリケーションのバージョン管理システムって感じ？？なんかイメージ的にはドラクエの教会みたいな感じかな？
その他にもチームで開発をするときとか本番サーバへデプロイすることもできんだって！！！

まずgit configで設定する。systemセットアップをするらしい。

$ git config --global user.name"Your Name"
$ git config --global user.email your.email

ここで設定する名前とメールアドレスは一般に公開されるから注意しないといけないみたい。
これ一回登録したらどうなんの？「あああああ。」みたいな名前にしちゃったらきついよね。
つーわけで調べたらちゃんと削除の仕方もあったわ。他にも色々あったので載せときます

git の基本的な使い方

確認

$ git config --list
$ git config キー名

登録・更新

$ git config キー名　設定値　#ローカルリポジトリに設定
$ git config --global キー名　設定値　#全てのローカルリポジトリに設定

削除

$ git config --unset キー名

これでいろいろ面白い名前試したくなっても大丈夫だね。

んで、セットアップしたいと思います。Railsアプリケーションのルートディレクトリへ移動。新しいリポジトリの初期化を行う。ちなみにルートディレクトリってのは階層型ファイル上の最上階のディレクトリのこと。つまりこのアプリケーションの大元ってこと。

$ git init
これが初期化。次にプロジェクトのファイルをリポジトリに追加
$ git add -A

これで現在のディレクトリにあるファイルがすべて追加される。
でもここまでの処理だけだとまだ終わりじゃなくって。。。
追加されたファイルはステージングっていう待機用のリポジトリに置かれてコミットをまつ。
ステージングの状態を知るには

$ git states

んでステージングエリアで控えている変更を本格的にリポジトリに反映（コミット）するには
commitコマンドと使う。

$ git commit -m"Initialize repository"
-mフラグを使うと、コミットメッセージをコマンドラインで直接指定ができる。-mフラグを使わない場合はシステムのデフォルトのエディタが開きそこでコミットメセージを入力する。

gitを使うとなにが便利なのか

についてrailsチュートリアルに書かれてたんだけどなんかコマンド間違って消しちゃっても変更されてるのは現在の作業ツリーだけだからすぐ修正できますよって感じかな！俺みたいなうっかりさんに優しいシステムってことだね！

GitHubとBitbucket

更にgitリポジトリを深めるには上記の２つも知っとかなきゃいかんらしい。どちらもGitリポジトリのホスティングと共同制作を行うことができ、リポジトリの表示や検索を行いやすくしてくれるシステムのことみたい。ホスティングがいまいちよくわかんなかったから調べたんでけどこれは要するにサーバを貸してくれるサービスのことみたい。つまりサーバを貸してくれてそこにリポジトリを置けて、なおかつみんなで使えるよーってことかな。

両者の違いは

GitHub...リポジトリを一般公開する場合は無料、公開しない場合は有料
Bitbucket...共同作業者が一定数以下ならリポジトリを公開しなくても無料、共同作業者が一定数を超えると有料
ってことみたい。俺みたいな一人でちょっといじってみたいくらいだとBitbucketのが良さそうだね。でも主流はGitHubだと思うからある程度慣れてきたらこっちも使っていきたいと思います。

待っって。。。
Railsチュートリアルの文章最後まで読んでみたんだけど

更新予告: 2019年1月からGitHubの非公開型レポジトリが無料になりました。共同作業できるメンバー数は限られているものの、非公開型のリポジトリが利用できるようになったため、本チュートリアルでも現在のBitBucketからGitHubに切り替える可能性があります。

ということみたですね。笑　なので今回は前言撤回してGitHubで登録していきたいと思います。GitHubはprogateにて登録していたのでスムーズに登録できました〜！

Branch

ブランチとは履歴の流れを分岐して記録していくためのもの。基本的にはリポジトリのコピーで、ブランチ上では元のファイルを触らずに新しいコードを書くなど、自由に変更や実験を試すことができます。通常、親リポジトリはmasterブランチと呼ばれ、トピックブランチ (短期間だけ使う一時的なブランチ) とに別れる。

$ git checkout -b modify-README
これがトピックブランチの作成
$ git branch
  master
* modify-README

2つ目のコマンド (git branch) は、すべてのローカルブランチを一覧表示します。「*」はそのブランチが現在使用中であることを表します。1番目のgit checkout -b modify-READMEコマンドで、ブランチの新規作成とそのブランチへの切り替えが同時に行われている。

modify-READMEブランチに「*」が付いていることで、このブランチが現在使用中であることが示されています

ブランチの真価は他の開発者と共同で作業する時に発揮されますが24、本チュートリアルのように一人で作業する時にも非常に有用です。masterブランチはトピックブランチで行った変更に影響されないので、たとえブランチ上のコードがめちゃくちゃになってしまっても、masterブランチをチェックアウトしてトピックブランチを削除すれば、いつでも変更を破棄する事ができます。

Edit (編集)

トピックブランチを作ったら、編集を行う。
viewを編集した内容にいじる。

Commit (コミット)

変更が終わったら、ブランチの状態を確認する。

$ git status
On branch modify-README
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   README.md

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

この時点でgit add -Aを実行することもできますが、git commitには現存するすべてのファイル (git mvで作成したファイルも含む) への変更を一括でコミットする-aフラグがあります。このフラグは非常によく使われる。

$ git commit -a -m "Improve the README file"
[modify-README 9dc4f64] Improve the README file
 1 file changed, 5 insertions(+), 22 deletions(-)

-aフラグは慎重に扱ってください。最後のコミット後に新しいファイルを追加した場合は、まずgit addを実行してバージョン管理下に置く必要があります。

コミットメッセージは現在形かつ命令形で書くようにしましょう (訳注: これは英語で書く場合のルールです。日本語であれば「〜を追加」などの体言止めがよいでしょう)

Merge (マージ)

ファイルの変更が終わったので、masterブランチにこの変更をマージ (merge) します。

$ git checkout master
Switched to branch 'master'
$ git merge modify-README
Updating af72946..9dc4f64
Fast-forward
 README.md | 27 +++++----------------------
 1 file changed, 5 insertions(+), 22 deletions(-)

Gitの出力には34f06b7のような文字列 (ハッシュ) が含まれていることがあります。Gitはこれらをリポジトリの内部処理に使っています。この文字列は環境の違いにより上記のものと少し異なるかもしれませんが、他の部分はほぼ同じはずです。

変更をマージした後は、git branch -dを実行してトピックブランチを削除すれば終わりです。

$ git branch -d modify-README
Deleted branch modify-README (was 9dc4f64).

トピックブランチの削除は必須ではありません。実際、トピックブランチを削除せずにそのままにしておくことはよく行われています。トピックブランチを削除せずに残しておけば、トピックブランチとmasterブランチを交互に行き来して、キリの良い所で変更をマージする事ができます。

上で述べたように、git branch -Dでトピックブランチ上の変更を破棄することもできます。

Push (プッシュ)

READMEファイルの更新が終わったので、Bitbucketに変更をプッシュして結果を見てみましょう。既に1.4.3で一度プッシュを行ったので、大抵のシステムではgit pushを実行するときにorigin masterを省略できます。

$ git push

今日はここまで。

macOC CatalinaにアップデートしたらGitが動かなくなった

$ git
xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun

以下のコマンドでインストール

$ xcode-select --install
xcode-select: note: install requested for command line developer tools

EUCの開発環境等でよく頻発するのでメモ

$ git commit ← -mをつけないのがポイント

その後vimが立ち上がるので

:set fileencoding=utf-8

と入れて、日本語コメントを入れると文字化けしなくなります。

作業中ブランチにて

git stash (必要に応じて)
git checkout master
git pull
git checkout [ブランチ名]
git merge master

コンフリクトあって解消したあとに

git add [コンフリクトしたファイル]
git stash pop (最初のgit stashをした場合)
git commit
git push origin [ブランチ名]

masterをチェックアウトして

git checkout master
git merge --squash [ブランチ名]

ブランチでの変更を取り込んだ後に

git commit

ログに残したいメッセージ以外を削除してコミット

git push origin master

ブランチを削除

git push --delete origin [ブランチ名]

背景

諸事情によりGitHubなどが使えず、リモートリポジトリを社内LANの共有フォルダなどにおきたい場合の手順について調べましたので、記録しておきます。

環境はWindows10で、Gitはインストール済みという前提です。

まず、Git Bashでの操作を説明するため、テキストファイルを管理対象とする例を説明します。
次に、VisualStudioに備わっているGit操作を使った操作手順について説明します。使用したVisualStudioは2015です。

概要

共有フォルダにおかれた1つのリモートリポジトリを共有し、AさんとBさんの二人が並行して作業する場合を想定します。

大まかな手順としては次のようになります。
1. 今回の説明のために使用する3つのフォルダを準備します
2. AさんのPC上に最初のプロジェクトを作る
3. Aさんのプロジェクトのクローン（ベア）を共有フォルダ上に作る
4. Aさんのプロジェクトにリモートリポジトを設定する
5. 確認としてAさんのローカルリポジトリで変更をコミットしてプッシュする
6. BさんのPCに3.のリモートリポジトリのクローンを作る

手順（Git Bashからの操作）

手順１ 説明用のフォルダを準備する

今回は説明のために下図のように1つのフォルダの下にAさん、Bさんの作業フォルダとリモートリポジトリをおく共有フォルダを作ります。

実際にはこれら3つのフォルダは社内LANなどを介して離れたところに作られます。

手順２ 最初のプロジェクトを作る

AさんのPC上で最初にプロジェクトを作ります。プロジェクトといってもただのテキストファイルを含む下図のようなフォルダです。テキストファイルdoc.txtの中身はブランクです。

このフォルダをGit管理対象にするため、Git Bashから次の操作を行います。

~/prog/A-san/txt

$ git init
$ git add --all
$ git commit -m 最初のコミット

手順３ ベア（リモート）リポジトリを作る

Gitで管理されているAさんのプロジェクトtxtのベアリポジトリを作ります。
Git Bashでリモートリポジトリを作りたいフォルダに移動し、下記の操作を行います。

~/prog/_depot

git clone --bare ../A-san/txt txt.git

作成するベアリポジトリの名前には末尾に.gitをつけておくといいようです。

手順４ Aさんのプロジェクトにリモートリポジトリを設定する

手順３ではgit cloneを使用しましたが、git cloneはクローン元に対しては何も操作を加えないため、この時点ではAさんのローカルリポジトリはベアリポジトリが作られたことを知りません。

Aさんは作業した内容をプッシュする必要がありますので、Aさんのローカルリポジトリにプッシュ/プル先となるリモートリポジトリを設定します。

Git Bashで~/prog/A-san/txtに戻り、下記の操作を行います。

~/prog/A-san/txt

git remote add origin ../../_depot/txt.git
git remote update
git push --set-upstream origin master

3行目は厳密にはプッシュの操作ですが、私の環境ではgit pushでは初回は必ずエラーが出るのでここで一度このコマンドを送信しておきます。

手順５ 確認

現時点でAさんのローカルリポジトリは~prog/_depotにおいたリモートリポジトリとリンクしており、Aさんが行った変更をプッシュできる環境ができ上がっています。

確認のため、~/prog/A-san/txt/doc.txtに下記の1行を追記してコミット、プッシュします

Aさん、1行記入

~/prog/A-san/txt

git add -all
git commit -m Aさん、1行記入
git push

手順６ BさんのPCにリモートリポジトリのクローンを作る

Bさんが作業できるように、Git Bashで~/prog/B-sanに移動して下記の操作を行います。

~/prog/B-san

git clone ../_depot/txt.git

この操作だけで下図のようにBさんのフォルダにプロジェクトが作られています。

このdoc.txtの中身にも手順５で記入した1行目の内容がちゃんと反映されています。
また、このローカルリポジトリはリモートリポジトリをクローンしているので、クローン元がリモートリポジトリとして既に設定されているので、手順４に相当する操作は不要です。

以上でAさん、Bさんが並行して作業する環境ができあがりました。

手順（VisualStudio2015からの操作）

VisualStudioにはGit操作の機能が備わっていて、これを使用するとラクチンです。
手順の流れはGit Bashの場合と同じですが、手順１は完了しているので、手順２から説明をスタートします。

手順２ 最初のプロジェクトを作る

VisualStudioから新規プロジェクトの作成を行います（appという名前の新規プロジェクトを作ります）。
下図のようなフォルダが作られます。

これをGit管理するためにはVisualStudioの右下のGitボタンを押すだけでOKです。
これで.gitignoreも自動的に生成され、最初のコミットをやってくれます。

ボタンを押すと下図のようにGit機能が使えるようになります。
左から、プッシュ待ちの変更数、コミット待ちの変更数、ローカルリポジトリ、ブランチが表示されています。
VisualStudioではこの辺をクリックするとGit操作ができます。

手順３ ベア（リモート）リポジトリを作る

この手順はGit Bashを使います。（VisualStudioでもできるかもしれませんが）

~/prog/_depot

git clone --bare ../A-san/app app.git

手順４ 最初のプロジェクトにリモートリポジトリを設定する

この手順もGit Bashを使います。
VisualStudioの場合、1行目の操作でリモートリポジトリを指定する際、
絶対パスを使わないとプッシュできませんでした。

~/prog/A-san/app

git remote add origin C:/xxx/prog/_depot/app.git
git remote update
git push --set-upstream origin master

3行目の操作によりプッシュがされますので、VisualStudioの表示は下図のようになります。

手順５ 確認

AさんのVisualStudio上で何らかの変更を行います。
たとえばフォームにボタンを追加すると、下図のように3つのコミット待ちの変更が出てきますので、これをコミットし、プッシュしておきます。

手順６ BさんのPCにリモートリポジトリのクローンを作る

この作業もGit Bashを使用します。

~/prog/B-san

git clone ../_depot/app.git

これで下図のようにBさんのフォルダにプロジェクトが作られていて、開いてみると手順５で追加したボタンがちゃんと反映されています。

おまけ

上記はGitはインストール済み、初期設定済みの前提でしたが、メンバーが追加になった時など、新たにGitをインストールした際、Gitに設定する手順もメモしておきます。

GitBash

git config --global user.name yakisobamilk
git config --global user.email yakisoba@milk.com