ローカルブランチ名を変更してリモートに反映する

１　ローカルブランチ名変更

git branch -m <古いブランチ名> <新しいブランチ名>

２　リモートに反映

 git push origin <新しいブランチ名>

特定のブランチをクローンする

git clone  -b ブランチ名　https://github.com/ユーザー名/リポジトリ名.git

何回も調べなおすの面倒なので、どんどん追記していきます。

Gitに初めて触れる方や、事故ってあたふたする方に向けて書きます。
(自分の認識が間違ってないか整理する為にも)

• 自分なりの解釈でざっくりと書きます。
• しっかりと理解したい方や、より詳しく知りたい方には向かないかも知れません。
• Sourcetreeを使用する前提で解説していきます。
• 私も初心者につき、間違っている箇所があるかも知れません。

基本用語･操作

リポジトリ

Gitで管理する対象になっているディレクトリのこと。
このディレクトリ下のファイルに変更があると、差分として表示される。

以降でリモートとかローカルとか言っているのはそれぞれリモートリポジトリとローカルリポジトリのこと。

クローン

全てはここから始まる。(多分)

概ね、リモートリポジトリをローカルにコピーすること。
この操作でローカルにコピーしてきたものをローカルリポジトリと呼ぶ。

ダウンロードだと思って良い(と思う)。

ブランチ

枝。ゲームで言うストーリー分岐(?)みたいなもの。
ゲームと違うのはエンディングが大体ひとつしかない(全部最後はmasterにマージされる)事。
実装する機能毎や作業者ごと等、分ける際の考え方は色々ある。

よく使うブランチ名は以下みたいな感じ。
- master

その名の通り。リリース用のものであることが多く、だいたいプロテクトが掛けられている。そのくらい大切なものなので、触ることがあれば細心の注意を払うこと。
- develop

開発用のブランチ。 developから、各機能や作業事にブランチを切って作業し、終わったらdevelopへマージする。(という運用が多いと思う)

• feature/○○○○
  例えばfeature/add_input_view とか。featureというフォルダに、add_input_viewというブランチがあるイメージ。
  Sourcetreeでは実際にフォルダみたいに表示されるので、単純に見やすい。他にもfix/○○○○(修正)とかも使うかも。この辺はプロジェクトによって大きく変わる。

※詳しくは[日本語訳]A successful Git branching modelとかを見て欲しい。

チェックアウト

ブランチの切り替え。ソースツリーなら何も意識しなくてもやってる。

コミット

ブランチに対して、変更を確定させること。
ゲームで言うセーブ。作業が一段落着いたら行う。
後で戻る事や、変更内容を確認するために
なるべく細かくコミットしておく方が(個人的には)好き。

スタッシュ

変更したものを一時的に退避させて保管できる機能。
めちゃくちゃ使う。
コミットするほど作業してないけどブランチを切り替えたい時とかに。
スタッシュに積むとか言う。

プッシュ

ローカルの状態をリモートへ反映すること。プルの逆。

プル

リモートの状態をローカルへ反映すること。プッシュの逆。

フェッチ

リモートの状態を確認すること。
フェッチを行うとプルする必要のあるリポジトリが分かるので、事故(こういうの)を防ぐことが出来る。

マージ

ブランチ同士を結合すること。そのまま。

コンフリクト

マージされるふたつのブランチの差分がぶつかり合う事。
同じ箇所を複数のブランチで修正すると起こる。
このままではマージできないので、解決する必要がある。
解消方法は大きくわけて3通りある。
- 相手(マージする先)の変更を使う
- 自分の変更を使う
- 手動でいい感じに修正する

コンフリクトしないように、developを作業ブランチにこまめに取り込もう。

リバート

特定のコミットの内容を打ち消す事。
正確には、特定のコミットの逆のコミットをすること。
ミスった時や、特定のコミットが不要になった時に使う。

チェリーピック

特定のコミットを今いるブランチに取り込むこと。
時々つかう。

よくある事故(経験したもの)

※他にいい方法があればお教えいただきたく存じます。

コミットした内容を取り消したい

プッシュしていない場合
→めんどくさいのでローカルブランチを一度消して、
　もう一度リモートからチェックアウトする。

プッシュ済みの場合
→リバートする。

リモートのコミットをプルせずにコミットしてしまった

これはめちゃくちゃやってしまってました。
こうならないように、まずはフェッチしてからコミットする癖をつけましょう。
もうやってしまった場合は↓の手順で解決してます。

こんな表示になってると思うので、この状態でブランチを切る。(例えばHogeとか)
その後、ローカルブランチを削除してもう一度リモートからチェックアウトし、
hogeブランチのコミットをチェリーピックで取り込んで完了。

---

最後までご覧いただきありがとうございました！
Git触りたての方の参考になれば幸いです！

気になるところや間違っているところなどございましたら、お教えいただきたく存じます。

背景

あんまり使わないけど覚えておかないと面倒になるやつ。
調べるのもだるいので覚書しておく。

.gitignore じゃあない。

あ、Windows環境やで

notepad .git/info/exclude

したら .gitignore とおんなじ感じで無視したいファイルを追加する

# git ls-files --others --exclude-from=.git/info/exclude
# Lines that start with '#' are comments.
# For a project mostly in C, the following would be a good set of
# exclude patterns (uncomment them if you want to use them):
# *.[oa]
# *~

# ここらへんにてきとうに

Gitのアレを更新する

あれだよ…ﾎﾗ…ｱﾚ…

git update-index --assume-unchanged <FILE_PATH>

おっけ、消えた。

はじめに

Github初心者がGithubでプロジェクトを管理をする方法を自分用にまとめたものです。
もし、同じような初学者の参考になれば幸いです。

環境(Gitバージョン)

$ git --version
git version 2.21.0 (Apple Git-122)

作業の流れ

この記事で行う作業の流れは、
Githubでリモートリポジトリを作成→ローカルにクローンを作成→Laravelプロジェクト作成→ Github上にプッシュ
となります。

Githubでリポジトリを作成する

「New repository」からリポジトリを作成します。この時、「Initialize this repository with a README」にチェックしましょう。
※ここでチェックし忘れても、githubのリポジトリのページに記載されている下記のようなコマンドを、次の作業で作成するクローンフォルダ内に移動した上で実行することでREADMEファイルを作成することができます。

echo "# プロジェクト名" >> README.md
user-MBP:プロジェクト名 username$ git init
Reinitialized existing Git repository in /Users/username/Desktop/プロジェクト名/.git/
user-MBP:プロジェクト名 iusername$ git add README.md
user-MBP:プロジェクト名 username$ git commit -m "first commit"
//このコマンドは参考用です。そのままターミナルに貼り付けても意味はありません。

ローカルにリポジトリをクローンする

ローカル(自分のPC)にGithubで作成したリモートリポジトリ のクローンを作成します。

クローンはデスクトップ上にworkという作業用フォルダを作成し、その中に作成します。今後、何かしらのプロジェクトをGithubで管理する際はこのworkフォルダ内で作業を行うようにします。

まず、workフォルダを作成します。

$ cd Desktop //userからDesktopディレクトリに移動します。
$ mkdir work //workという名前の空のフォルダがデスクトップ上に作成されます。
$ ls //Desktopディレクトリ上のファイルを一覧できます。workフォルダが作成されたことを確認しましょう。
$ cd work //workフォルダ内に移動します。

次に、GithubのリポジトリのWeb URLをコピーします。URLは上記の画像のように、「Clone or download」をクリックした先に表示されるClone with HTTPSのURLです。このURLを介してローカル上にリポジトリがクローンされます。

$ git clone <リポジトリのURL> //workフォルダ内にリモートリポジトリがクローンされます。
$ ls //クローンされて、ローカルリポジトリが作成されているかを確認しましょう。

Laravelのプロジェクトを作成する

次に作業を行うLaravelプロジェクトを作成します。

$ cd <ローカルリポジトリのフォルダ名> //フォルダを移動します。
$ laravel new <プロジェクト名> //ローカルリポジトリ内にLaravelプロジェクトが作成されます。
$ls //プロジェクトが作成されているか確認しましょう。

基本的にLaravelプロジェクトはクローンフォルダ内で作成したほうが良いようです。もし、すでに作成したLaravelプロジェクトを管理したい場合はフォルダごと全てをクローン内に移しましょう。

addからpushまでの流れ

次にLaravelプロジェクトをgithubで管理します。今回は作成したばかりのLaravelプロジェクトをGithubにpushします。

$ git branch //現在、masterブランチにいることを確認します。

masterブランチにいれば、masterという文字が緑色で表示されます。

特に何も表示されない場合は自分がいるディレクトリの位置を確認する、masterブランチが作成されているか確認するなどの確認をしましょう。
※もしみつからない場合は、先ほどご説明したように、READMEファイルの作成を行ってみてください(READMEを作り忘れた場合)。

$ git add . //ローカルリポジトリ内のファイルをインデックス登録してコミットする準備を行う。
$ git status //コミットの準備がされているファイル一式を確認することができます。

「git add .」はカレントディレクトリ(作業中のディレクトリ)内の変更があった全てのフォルダがaddされるコマンドです。

今回は、初めてLaravelプロジェクトをaddしたので、Laravelプロジェクトのファイルが全てaddされます。今後、Laravelプロジェクト内のファイルやフォルダ情報を変更した場合は、変更したファイルやフォルダのみがaddされます。

初めて「git add .」コマンドを入力すると無反応なので心配になりますが、「git status」コマンドを入力することでgit addが実行されていることを確認できます。このように初めは一つの作業ごとに確認を行ったほうが安心して作業できます。

$ git commit -m "コミットメッセージ" //addしたファイル一式がcommitされます。
$ git log //commit情報を確認できます。
$ git push origin master ////masterブランチにpushします。

以上です。Githubのリモートリポジトリを確認するとpushされたファイル一式が確認できると思います。

最後に

自分用のメモではありますが、初めてのQiitaへの記事投稿となります。
もし、ここ間違えているよ！、ここはこうしたほうがいいよ！という意見がありましたら、教えていただけると勉強になりますのでよろしくお願いします！