野望

Gitを使えるようになりたいものだと思ってがんばっている。

（vim（emacs）のdotfileをGithubにおいて、履歴を保管しておきたいんだなあ）

いい記事がたくさんあって、なんとかなりそう……なんだけれど、ひとりでこちょこちょやっていて、意外とツラいのが「失敗したときに戻せない」ってこと。

各コマンドが思い通りに動かなかったときに、戻るやり方を調べたので記録しておきます。

git init

$ git init

でローカルリポジトリをつくったけど、やっぱりやめたいとき。
対象ディレクトリに~/.gitをつくっているだけだそうで、.gitを削除すればおわり。

$ git -rf .git

なるほど！

git init取り消し - Qiita

git add

$ git add .

でステージングに追加した後で、やっぱりやめたいとき。
（実際、エラーメッセージがずらずら出て、どうしていいかわからなくて困った）

$ git status

で、何がどうなっているか調べられる。取り消すときは、-rmかreset。

$ git -rm --cached -r <dir>/<files>
$ git reset

-rmは、初回だけということだが、まだよくわかっていない。
たぶん、わけもわからず試しているようなときには、status→reset→statusが良いのだろうと思われる。

git add を取り消す - Qiita

git remote add

$ git remote add origin <url>
$ git push -u origin master

とか本（やウェブサイト）に書いてある通りにやったのは良いけど、なんだかエラーメッセージが出て、そもそも、add originて何やねん、となったとき。remote -vで調べて、名前を探して、rmすると良い。

$ git remote -v
$ git remote rm origin

git remote add を取り消す方法 - Qiita

そのあと

まだcloneしたりpullしたりはしていないので、なんかあったら追記します。

commitとpushしかできない人のためのgithubの使い方まとめ
　が大変勉強になって助かっております。

ターミナルでリモートリポジトリから、クローンを作成する（かなりはまりました笑）

環境
macOS Big Sur(バージョン11.0.1)
git (git version 2.29.2)

エラー内容

ターミナル

ss@saaaMPro Desktop % git clone https://github.com/sakuma-s/git-command.git
Cloning into 'git-command'...
fatal: invalid branch name: init.defaultBranch = 

エラー内容を翻訳すると
fatal: invalid branch name: init.default Branch
致命的：無効なブランチ名：init.defaultブランチ

ここでかなりハマりました、、、

git branchで現在のブランチを確認

ターミナル

ss@saaaMPro Desktop % git branch
* master

と記載されており、リモートリポジトリのbranchを確認するとmainに設定している事を確認！早速変更！

git branch -m main

一応変更されているか確認

ss@saaaMPro Desktop % git branch
* main

再度git cloneを実行

ss@saaaMPro Desktop % git clone https://github.com/sakuma-s/git-command.git gittest05     
Cloning into 'gittest05'...
remote: Enumerating objects: 19, done.
remote: Counting objects: 100% (19/19), done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 19 (delta 6), reused 19 (delta 6), pack-reused 0
Receiving objects: 100% (19/19), done.
Resolving deltas: 100% (6/6), done.

成功！
念の為、ローカルディレクトリも確認！

今回のエラー原因

gitのデフォルトで設定されているbranch(master)と、リモートリポジトリのデフォルトbranch(main)が違ったため、上手くクローンが出来なかったのだと思います。。。
小さな事でもありがたいので、情報不足でしたらコメントからご指摘お願いいたします！

ブランチ名を変更する時に参考にしたサイト
gitのローカルのブランチ名を変更したい

助かりました！感謝いたします。

まず、前提としてGitから説明したいと思います
この記事は個人の独断と偏見によって書かれています

Gitとは

Gitはソースコードやテキストファイル等のバージョン管理システムです。
普段はコマンドベースでコマンドプロンプトなどからコマンドで操作します。
主な流れとしては

1. リモートサーバ等にある中心リポジトリをローカルに複製する (git clone)。
2. ローカルでコンテンツの修正・追加・削除を行い、ローカルリポジトリに変更履歴を記録する (git commit)。必要に応じて過去の状態の閲覧や復元などを行う。場合によってはこのステップを何度か繰り返す。
3. ローカルの変更内容を中心リポジトリに反映させる (git push)。作業者ごとの変更内容が衝突することもある。Gitが自動で解決できる場合もあれば、手動での解決 (git merge）が必要なこともある。
4. 更新された中心リポジトリ（他者の作業内容も統合されている）をローカルの複製にも反映する (git pull)。これによりローカル環境のコードも最新の内容になるので、改めてステップ2の作業を行う。

大まかな流れとしてはこう（Wikipediaより

また、Gitを使うにはGitをインストールする必要があります。
Git公式:
https://git-scm.com/

コマンドベースのチュートリアルの一覧としてはこちらを参考にしていただければ
https://qiita.com/yuyakato/items/41751848add5dfd5289c

使用コマンド一覧
Reference

メリット

メリットとしては
1. コミットの履歴が残る
2. 誰がどこを編集したのかがわかる
3. 複数人で同じファイルを作業した際に上書きされない
4. 前のバージョンに戻したり、一部分の編集をなかったことにできる

デメリット

デメリットとしては
1. 使用する人の環境にGitが入っていることが前提
2. 覚えること（コマンド等）が多い

Branch

Gitでは作業場所を分けて使う事ができる。
複数人で作業する場合は通常、その人数分の作業場所を準備する。
理想的なワークフローはgit-flowが一番理想的ではある。
git-flowに関しては下記に図解されてわかりやすいと思うので時間があるときに読んでもらいたい
git-flow 図解:https://qiita.com/ohnaka0410/items/7c7fa20710dfd72b7d7a

コマンド一覧

clone

リモート上にあるgitをローカルにダウンロードします。

git clone url

とすることでリポジトリのディレクトリが作成されます

init

gitリポジトリを作成します

diff

現在のブランチと変更したファイルの変更点を表示します
また、ブランチとブランチのファイルの変更点も表示できます

git diff ブランチ名..ブランチ名

Pull Requestを送る前に見たいときに使えます

status

gitに関するカレントディレクトリの状態を表示します
git addされ、コミットされていないファイルの一覧や
addされていないファイル、.gitigoreで管理対象外にもされていないファイル一覧
が見ることができます

.gitigoreで管理対象外にもされていないファイルとは
新規で作られて、ファイルの履歴が無いファイルのことを指します

log

gitリポジトリのログ（変更履歴）を表示します
変更履歴で変更されたファイルを一緒に見たい場合は

git log --stat

とコマンド入力することで変更履歴と変更ファイルを見ることができます。

tag

gitの変更場所にタグをつけることができます

git tag タグ名

特定のコミット場所にタグをつけるには

git tag -a タグ名 -m 'タグのコメント' コミット番号

タグの作成後はpushするとリモートにもタグが反映されるようになります

git tag
//または
git tag -l 'パターン'

を入力するとタグの一覧が表示されます
パターンに入力するとマッチした一覧が表示されます

特定のタグを確認するには

git show タグ名

とすることでタグの場所のコミットメッセージや変更者などが見れます。

show

前述した通り、git showを入力するとコミットのメッセージや変更者が見れます。
これはタグだけではなく、コミットのハッシュ値などを入力するとそのコミットの詳細が見れるようになります。
また、ファイルを指定するも可能です。

git show タグ名:file.txt

Add

ファイルの変更点をステージング（一時的にまとめておく）する
ステージングしたファイルをCommitすることでGitへ変更点が適用される

.gitignoreを無視して追加することもできるみたいです。

git add -f <ファイル名>

Commit

ソースコードの変更点をコメント付で保存することができます。

主に英語でコミットするようになっていますが、日本語でも結構です。

ただ、英語と日本語どちらかに合わせるようにしましょう。（英語のほうが何かと便利です
英語で書く場合に参考になると思う記事

https://qiita.com/shikichee/items/a5f922a3ef3aa58a1839

また、英語で書くメリットとしてGitHubでは#番号でIssueやプルリクエスト番号を指定することができます

そのコミットをGitHub上で見るとリンク形式になり、そのリンクが指定されたIssueやプルリクエストに飛ぶことができるの後から見返したときにわかりやすいと思います。

また、commitの頻度はできるだけ細かくしておきましょう。

これは大きな変更を一つのcommitにしてしまうと、その変更点の一つに問題が合った場合はすべての変更が取り消されることになります。

小さな処理の追加でも一つのcommitにするようにしましょう。
メリットとしては下記に記載されています（個人的な考えですが

Git 作業における commit と push の頻度について

Stash

今変更を加えたファイルを避難させておくこと

変更後にリモートで変更があった際に使える
1. 今の変更点をstashする
2. リモートの変更をローカルに取り込む
3. stashにある変更を戻す
4. 変更をcommitする

という手順でするとわざわざコピーしておくことなく変更点を戻せる

変更済みのファイルをAddでもなく、stashをすることによって一時的に保管できます。

取り出したいときはstash popをすることで取り出すことができます。

reset時やrevertをする際には事前にやっておくことで変更中のファイルが元に戻ることを防ぐことができるので

やっておくべきだと思います。

Conflict

ファイル同士の衝突

同じ変更部分があったり、元のファイルと変更したファイルとの差分がおかしくなった場合に発生する

これを解決しない限りそのファイルに変更点を適用できない

Conflictを解決するにはWeb上で解決するか、GitKrakenなどを使って解決する事もできる

Pull

リモートの状態を現在のローカルに適用させます。

リモートの状態とローカルの状態（commit等）が違った場合にConflictが起きるので
なにかをする前にPullをするということをしておきましょう。

Push

ローカルにある変更（commit）をリモートに適用させます

また、リモートに適用させてもリポジトリが共有されているすべてのローカルに適用されるわけでは有りません。

個々にPullをすることで変更点を適用させることになります。

checkout

今現在いるブランチから他のブランチへ移動する際に使われるもの
コマンドでは

git checkout -b ブランチ名

で変更できる

merge

マージ、ブランチの変更点を取り入れる際に使ったりする。

例：debugの変更点をmasterに取り入れる際には

git merge debug

とする

revert

コミットを取り消します。

取り消す際には順番に気をつけなければ変更が残ったままになる場合がありますで注意が必要です。

取り消す順番としては新しいものから順番に取り消しましょう

また、まとめて取り消したい場合はコマンドを入れるほうが安全かもしれません

まとめて消す際には

git revert <対象のコミットID A>..<対象のコミットID B>

を使用してコミットの先頭、末尾を時系列で指定します。

revertされるのは先頭(A)の直後のコミットとなり、先頭(A)自体は含みません。

参考どころか引用：Git revertとresetについて

ちなみにA→B→Cの順番のコミット（Cが最新）を取り消す場合には

C→B→Aの順番で取り消すべきだと考えてます（A→B→Cの順番で取り消した際に変更が残っていたことがあったため

マージをrevertで取り消すことも可能です。

その他revertのコマンドは下記の記事をご覧ください。

Git revertとresetについて

reset

上記のrevertでは変更点を戻すコミットを出しますが、resetではコミット無しで戻すことが可能です。

ただし、リモートへpushしたあとに取り消すことはあまりおすすめできません。

一応下記の記事にリモートへpushした後にコミットを取り消す方法が記載されていますので興味があれば

Gitで誤ってpushしてしまったときのpushの取り消し方法

ローカル内であれば基本的には問題有りません。

ただ、現在変更中のファイル等があればstashしておきましょう

resetの方法は下記記事を参考に

[Git]コミットの取り消し、打ち消し、上書き

git reset --hard HEAD^

cherrypic

他のブランチのコミットを今現在いるブランチへそのコミットだけを取り入れるときに使える。

マージしたいけどいらない部分があったり、ブランチを分けてそのコミットだけを入れてPull Requestをしたりと分けることもできるので覚えておくと便利

rebase

リベース

ブランチ元を変更する

自分が理解できた記事はこちら:
git rebaseを初めて使った際のまとめ

bisect

git bisectによって問題が発生した箇所を特定することができます。

git bisect start 問題のコミット 問題の無いコミット

このコミットの場所にはタグを指定することもできます。

なので、v1.0で問題がなく、v1.5で問題が発生した場合は

git bisect start v1.5 v1.0

と記述します

そしてテストスクリプトの指定をします

git bisect run スクリプトファイル名

とすることで、gitが自動的にテストの実行と中間のバージョンのチェックアウトを繰り返し行い、問題が発生した地点を見つけてくれます。

手動で行う場合は

テスト結果が問題ないなら以下

git bisect good

問題があった場合は以下を実行します

git bisect bad

上記のどちらかを実行すると自動的に中間のバージョンにチェックアウトしてくれます

その後、再び手動でチェックを行い、問題があるかどうかをgit bisectに教えることを繰り返します。

git bisectが現在チェックアウトしているコミットを確認するには

git bisect view

で確認できます

過程を確認するには

git bisect log

元の状態に戻す（git bisectの実行前）

git bisect reset

参考記事:
git bisect で問題箇所を特定する

.gitigoreについて

Gitには特定のフォルダ、ファイルを管理しないように除外設定することができます。

.gitigoreに除外するファイルやディレクトリを設定することでGitで管理しません。

これはC#のbinなど、コードのデバッグで作成されたファイルなどを記載することで管理するファイル容量を抑える事ができます。

このファイルに関しての書き方はコードの言語によってはテンプレートがあったりするので言語に合わせて書いていただきたい。

例：
VisualStudio.gitignore

GitHubとは

GitHubはローカルに置いてあるGitをWeb上で管理できる

Web上で管理することで、ローカル（自分のPC）のソースコードを他のローカル（人のPC）に導入することもでき

他人のPCから変更点をアップしたりすることができる

コマンドベースで触る人は
こちらの記事
も参考に

GitHubのドキュメントはこちら:https://docs.github.com/ja/free-pro-team@latest/github/getting-started-with-github

去年一昨年辺りにMicrosoftの傘下に入り、前まではプライベートリポジトリに3人までしか招待できなかった制限（無料プラン）が解除され、人数に制限がなく、保持できるプライベートリポジトリも3つまでだったのが無制限になった。

コラボレーターを個人リポジトリに招待する

画面

友人のリポジトリですがこのような画面になります。

Code

現在のリポジトリにあるファイルや変更点などが見れます
また、コミットに対してコメントの入力をすることができるのでそのコミットに疑問を持ったりした場合はコメントで質問や提案をすることができます

Issues

現在発生しているバグや機能向上の提案などができます

Issueごとにラベルやコメント、解決してほしいユーザー等の指定ができます、

ラベルに関して：ラベルについて

これがOpenの状態だと未解決、Closeの状態だと解決済みといった具合でひと目でわかるようになります

こちらにもコメントが追加でき、質問や解決に向けての対策などが取れるようになります。

Pull request

各ブランチから他のブランチへ変更点を入れたいときに使います

ここではIssueで建てたバグや機能をfix #1（＃の後はIssueの番号）等で指定してプルリクエストがマージされるとそのIssueは自動的にClose状態になります。

こちらもコメントができますので質問等やレビューができます。

勝手に入れられたくない場合はリポジトリの本人やコラボレーター(設定)のみマージすることや、何人以上がレビューした場合にのみマージボタンが押せる等の設定ができます。

Actions

GitHubが用意しているAction（動作）から選択できます。

主にあるのは、ビルドが正常に通るかどうかなど

このタブは設定より表示、非表示等の設定ができます。

Projects

こちらはプロジェクトタブで、Todoリストや完了したものなどリストで管理することができます

また、Issueも追加することができます。

Security

セキュリティタブではセキュリティに関しての設定ができます。

コードの脆弱性がないかどうかをチェックしてもらうユーザーの追加など

Insights

このタブではリポジトリの状況が見れます。

誰がどのくらいコミットしたか、どのくらいのコードの追加削除を行ったかが見れたり、ブランチのグラフが見れたりします

GitHub Tools

こちらに一覧が乗ってますのでご参考に

https://git-scm.com/download/gui/windows

下記は自分が使ったことのあるツール一覧

GitHub Desktop

https://desktop.github.com/

料金：無料

使い勝手は悪くないがIssueの状況が見えなかったり使い勝手が自分的にはよくなく、あまりつかいませんでした。

ブランチの変更やコードの変更点などは見れます。

プライベートリポジトリなども変更することができます。

SouceTree

料金：無料

GitHub Desktopと同様にIssueの状況等が見えないのであまりおすすめはできません。。。

GitKraken

https://www.gitkraken.com/

料金:無料（一部有料

プライベートリポジトリを開く等は有料になりますが、一番使いやすいと思います。

GitHubと連携し、Issueの一覧やPull Requestの一覧が見れるようになり、Conflict等の衝突の解決も手軽にできます。

価格も年間で5000円弱なのであまり高くは無いと思っています（月々約400円ほど

またこちらにもGitHubと似たようなBoards（GitHubでいうProject）があり、そのBoardに他のGitkrakenユーザーを招待して開発することができます。このBoardにはラベルが付けられたり、日付の追加ができたりと非常に便利で使いやすかったです。

またラベルに対してコメントの追加等ができるのでGitHub Projectよりは使いやすいかと思います。

はじめに

現在、DMM WEBCAMPでプログラミングを学習中の初心者です。
チーム開発のフェーズに入ったことで、GitHubを使用する機会が大幅に増えています。
最初は慣れなかった操作も、段々と回数を重ねていくうちに慣れてきました。
しかし、直感で操作してしまっているケースもあり、今のうちにしっかり勉強しようと思い、この記事を書くことにしました。
それでは参りましょう。

そもそも一般的なブランチの意味って？

英和辞典で調べてみると、branchの意味としては、
(木の)枝、枝状のもの、支流、(山の)支脈、支系、分家、部門、分科
となっていました。

チーム開発の現場に置き換えると、担当するセクションやパートごとに、ブランチを切った上で作業に取り掛かっていたので、枝や支流という和訳はしっくりきますね。

GitHubにおけるブランチの意味とは

念のために、Gitの公式ドキュメントでも確認してみましょうか。

公式情報によると、ブランチの定義はこうなっていました。
Git におけるブランチとは、コミットを指す軽量なポインタに過ぎません。

ん？　ポインタ？

英語のbranchの和訳と、公式情報の定義がコンフリクトしてるみたいに思えてきました笑
もう少し詳しくみてみましょうか。

新しいブランチを作成する

新しい作業に取り組む時や、バグを解決する際など、ブランチを新しく作成する場面は往々にあると思います。
半ば無意識で行っている作業の意味を考えてみましょう。

再度、公式ドキュメントに立ち返りましょう。
ブランチを新しく作成するということは、
単に新たな移動先を指す新しいポインタが作られるだけ
とのこと。
今までずっと、新たな作業用の道が作られるようなイメージでしたが、ここでもあくまでポインタという概念で説明されています。

それならコミットの定義も確認しよう

「急がば回れ」ということわざに倣い、コミットの定義をみてみましょう。

Git にコミットすると、Git はコミットオブジェクトを作成して格納します。
このオブジェクトには、あなたがステージしたスナップショットへのポインタや作者・メッセージのメタデータ、そしてそのコミットの直接の親となるコミットへのポインタが含まれています。

なるほど、分からん。みたいな状態になりますね。
上の文章を読み解くと、コミットとは、git add後のステージングエリア上ファイルの、スナップショットを撮影すること、というイメージになるのでしょう。

以下、公式ドキュメントから画像等をお借りして、もう少し説明していきます。

早速、新しくtestingブランチを作成しましょう。
git branch -b testing

先ほどの公式ドキュメントの説明を思い出しましょう。
新しくブランチを作成したということは、単に新たな移動先を指す新しいポインタが作られただけです。

HEADとは？

もう一度上の図を確認すると、masterブランチの上に、HEADという文字が見えます。
HEADとは、あなたが作業しているローカルブランチへのポインタを指しています。
つまり、今現在、まだローカル環境はmasterブランチであり、先ほどのgit branch -bコマンドは新しくブランチを作成しただけで、ブランチ自体の切り替えはまだ行われていないということです。

ブランチの切り替え

それでは、ここで先ほど作成したtestingブランチに移動しましょう。
コマンドは、
git checkout testing
です。

ローカルブランチが切り替わったことで、HEADも移動していることが分かるでしょうか？

testingブランチにて、何かファイル変更を行い、コミットをしてみましょう。
git commit -m "changed something"
すると、以下のように変更します。

testingブランチは一つ分進んでいますが、masterブランチは一切動いていません。
HEADはコミットが進んだ分に併せて、一つ分移動していますね。

ここで、masterブランチに戻ってみましょう。

もうお分かりですね。
HEADもmasterブランチに移動していることが確認できました。

つまり、HEADはあくまで作業しているローカルブランチのポインタを示しているだけ、という説明通り、ローカルの場所を移動すれば、HEADがそれに付随される、ということですね。

おわりに

今まで、ブランチは線でつながっているイメージが強かったのですが、実際はポインタのような点が連続しているようなもの、という理解になろうかと思います。
GitHubも深掘りすれば、色々と学ぶべきことがたくさんありそうですね。