最近、プログラミングの学習内容を、GitとGitHubを利用して管理しているのですが、、、

専門用語が多すぎません？？？(笑)

と思ったので、アウトプットがてらGitとGitHubで頻出の用語について、簡単に説明していきます！

各種エリア

• リポジトリ(Repository)
  　→変更履歴を記録する場所。箱みたいなもの。


• ワーキングツリー(Working tree)
  　→自身のPC内でGitに監視されているディレクトリとファイル郡。


• ステージングエリア(Staging area)
  　→コミットをする前の控室のようなもの。


• ローカルリポジトリ(Local repository)
  　→ローカル環境(自分のPC)のリポジトリを指す。


• リモートリポジトリ(Remote repository)
  　→外部サーバー(GitHub)のリポジトリを指す。

各種エリアのポイントは、ワーキングツリーからどんどん下に更新していくと言う流れです。僕は最初のうちは「こんなにあってどうするの？」って感じですが、、、笑

簡単なコマンド

• アッド(add)
  　→ワーキングツリーから、ステージングエリアへ残す。


• コミット(commit)
  　→ステージングエリアから、ローカルリポジトリに変更履歴を記録すること。


• プッシュ(push)
  　→ローカルリポジトリを、リモートリポジトリに共有すること。


• プル(pull)
  　→リモートリポジトリから、ローカルリポジトリに、ファイルを同期すること。

こちらのコマンドは、先の各種エリアから移動する際に使用する、最も基本的なコマンドになります。これも上から順番に実行していく流れです。

Gitが使用しているファイル

• .git
  　→Gitを管理するファイル。通常は隠しフォルダとされていて見えない。


• .gitignore
  　→Gitで管理したく無いディレクトリやファイルを記述するファイル。こちらも通常は隠しフォルダとされていて見えない。

隠しファイルの存在は、誰かから教えてもらわない限り、なかなかわからない部分ですが、特に .gitignoreはセキュリティ対策で超重要な部分になりますので、気になる方は是非調べてみてくださいね！

まとめ

ここで紹介した用語は、GitやGitHubで出てくる中で、ほんの一部ですが、これだけでも知っておくとチーム開発などがしやすくなると思いますので、また忘れた頃に見返してみてくださいな！

最後まで読んでくださり、ありがとうございました！

筆者：yuki｜学習10日目で初案件獲得→現在はフルスタックエンジニア転職に向けて学習中
Qiita：https://qiita.com/yuki4839
Twitter：https://twitter.com/yuki35522891

こんにちは、くりぱんです。

この記事で実現できること

• GithubからCloneする
• GithubからLaravelプロジェクトをCloneした後の、開発環境の構築

開発環境

• OS：MacOS
• フレームワーク：Laravel
• バージョン管理ツール：Git
• Github

説明

LaraveのプロジェクトをGithubからCloneしただけだと、vendarディレクトリや.envファイルがなく、php artisan serveしてもエラーが出て、実際に開発できる環境にはありません。
今回は、Laravelのプロジェクトに参画して、GithubからCloneしたけど、どうしたらいいの！っていう人向けに、どうやって開発環境を整えるのかを説明していこうと思います。

実装の流れ

1. GithubからClone
2. composer install
3. .envの作成
4. データベース設定

実装

GithubからClone

まずは、Laravelのプロジェクトをクローンしたい場所にターミナルでcdコマンドを実行して移動しておきましょう！
今回は、/Applications/MAMP/htdocs配下にクローンしていきます。
皆さんは自由な場所にクローンしてくださいね！

$ cd /Applications/MAMP/htdocs/

次に、Githubからのクローンです。ターミナルで下記のコマンドを実行しましょう。

$ git clone LaravelプロジェクトURL

これでLaravelプロジェクトが先程cdコマンドで移動したディレクトリにクローンされています。

composer update or composer install

クローンしてきたLaravelプロジェクトを見てみると、vendarディレクトリが無いことがわかります。
なので、作っちゃいましょ！
まずはcdコマンドでLaravelプロジェクトディレクトリまで移動しましょう。

$ cd Laravelプロジェクトディレクトリ

それが終わったら、vendarディレクトリを作っていきます。

$ composer install

これでphp artisan serveをすると、サーバーは起動します。

.envの作成

次に、.envを作成していきましょう。
これがないと、500エラーなどがでて全くサイトを確認できないですからね！
実は、すでに.envの元となるファイルは存在するので、それをコピーするだけなんです。
なので、以下のコマンドを実行してください！

$ cp .env.example .env

次に、.envの中のAPP_KEYを発行します。

$ php artisan key:generate

このAPP_KEYは、暗号化やパスワードリセット等のセキュリティーでとても大事な役割を担っています。

そして、下記のコマンドで念の為キャッシュをクリアしておきましょう！

$ php artisan config:clear

これで、.envの設定はOKです。
現場などで、他に.envの設定がある場合は設定しましょう！

データベース設定

データベースが必要な場合は、下記のコマンドたちも実行していきましょう！

$ php artisan migrate

seederファイルもある場合は、下記のコマンドを実行してください。

$ php artisan db:seed

ReflectionException : Class 〇〇 does not existやclass 〇〇 not foundなどのエラーが出た場合は、下記のコマンドでオートロードの定義をしましょう。

$ composer dump-autoload

それが終わったら、再マイグレーションとシーダーの実行をしましょう。

$ php artisan migrate:refresh --seed

ブラウザで確認して、問題なければOKです。

最後に

今回は、LaravelプロジェクトをGithubからcloneしたはいいけど、その後がわからない！サーバー立ち上がらないし、変なエラーでる！っていう時の備忘録でした。
当記事を、最後まで見ていただきありがとうございました。！

Twitterもやってます！
プログラミングや金融知識についてやエンジニアの現実についてつぶやいています！
よかったら見てみてくださいね！

https://twitter.com/sakuslife

submodule追加

git submodule add <git url> <path>

submoduleのステータス確認

git submodule status

submodule削除

# .git/configの中身の該当箇所を削除(?)
git submodule deinit <path>
# .gitmodules/modulesの中を削除
rm -rf .gitmodules/modules/<name>
# 実体を削除
rm -rf <path>

submodule更新

git submodule update --remote

参考

• https://qiita.com/k_yamashita/items/040c04f8798d2384806e
• https://qiita.com/BlueSilverCat/items/19bb9b814572cd35b2ae

概要

現在所属中のオンラインサロン「転職クエスト」にて、Railsアプリ共同開発を行っています。

恐れながらファシリテーターを務めさせてもらっているのですが、開発をすすめる上で全員のネックになっていたことがありました。

Git/GitHubの共同開発的な使い方がわからない。。。

なので、開発を進めるファシリテーターとして、Git/GitHubをこうやって使おうぜ！というマニュアルを用意しておこうと考えました。

本記事では共同開発 初心者さんたちに向けたGit/GitHubのフローについて紹介します！

想定読者

1. アプリの個人開発のためにGit/GitHubを使ったことはある
2. コンフリクト解消のやり方を知りたい！
3. コードレビューのやり方を知りたい！

そもそも、どこがわかっていない？

Git/GitHubを使って共同開発をする上で、ネックになる部分はどこか。
考えるために、これまで行ってきたGit/GitHubの使い方を振り返ってみます。

個人開発でのGit/GitHubの使い方

1. ローカルのmasterでブランチ切る
2. ブランチで作業しコミット
3. リモートにブランチをプッシュして、プルリク作成
4. GitHub上でひとりLGTMを出して、ブランチをmasterにマージ
5. リモートのmasterをローカルのmasterにプル
6. 1~5を繰り返す

さて、このフローでしか開発をしてこなかった人が、共同開発でGit/GitHubを使う際に、初めて経験するのはどんなことでしょうか？

僕は、次のことだと考えました。

初めて共同開発をする人がやったことがないこと

1. 他の人のプルリクに対するコードレビュー
2. リモートのmasterの変更分を、ローカルの作業中ブランチにマージ
3. その際に起きるコンフリクト解消

特に2, 3については、最新に更新されたmasterからしかブランチを切ったことがないというのが不安の理由として挙げられます。
共同開発では、ブランチのマージによって常にmasterが更新されていきますので、その更新分を自分の作業中ブランチに反映する必要があります。

ここに焦点を当てて、共同開発でのコンフリクト解消、コードレビューの手順を紹介していきます！

コンフリクト解消の例

場面設定

設定

masterから同じタイミングで2つのブランチを切る
  user1.branch1 : git checkout -b new,createアクションを実装
  user2.branch2 : git checkout -b edit,updateアクションを実装

ちなみに今回は「ルーティングの設定」のみを取り扱っていきますのであしからず。

1. [user1] branch1でnew,createのルーティングを設定

branch1→routes.rb

+ resources :tweets, only: [:new, :create]

2. [user1] ローカルでコミット→リモートにブランチをプッシュ

branch1(new,createアクションを実装)

% git add .
% git commit -m "ルーティングにnew,createを追加"
% git push origin new,createアクションを実装

3. [user1] GitHubでプルリク作成→LGTM→マージ

ここは省略します。

4. [user2] branch2でedit,updateのルーティングを設定

branch2→routes.rb

+ resources :tweets, only: [:edit, :update]

5. [user2] branch2でコミット

branch2(edit,updateアクションを定義)

% git add .
% git commit -m "ルーティングにedit,updateを追加"

※次にmasterブランチに切り替えますが、その前に必ずここでコミットをしてください！

6. [user2] リモートmaster(branch1 merged)→ローカルmasterにプル

# masterブランチに移動
% git checkout master

# リモートのmasterをローカルのmasterに反映
% git pull origin master

【今はこういう状態】

• master → new, createアクション
• branch2 → edit, updateアクション

7. [user2] ⚠コンフリクト ローカルmaster→branch2にマージ

# 作業中ブランチに移動
% git checkout edit,updateアクションを定義

# ローカルのmasterを作業中ブランチにマージ
% git merge master

【コンフリクト発生の様子】

• Head : 現在、作業中のブランチ (branch2)
• master : マージしたローカルのmasterブランチ

8-1. [user2] コンフリクトの解消

masterを基準に修正し、コンフリクト解消したらコミット

# 編集後
% git add .
% git commit
(デフォルト名 : Merge branch 'master' into edit,updateアクションを定義)

基本的に、masterと作業中ブランチのログをどちらも残し、必要な形に変えればそれでOKです。
コミットするとデフォルトでこのブランチがマージされたよ！というコミット名になります。

【※コンフリクト解消後のGitHub Desktopの画面】
▶commit Mergeを押せば、デフォルトのコミット名でコミットされる...はず

8-2. [user2] わからないのでとりあえずmergeを取り消したい！

もし「コンフリクトこわい！ 一旦戻したい！」という方にはこちら。

merge取り消し方法

% git merge --abort

【merge取り消しの様子】
▶コンフリクト状態がリセットされます

9. [user2] branch2をリモートにプッシュ→プルリク

% git push origin edit,updateアクションを定義

小括 : コンフリクト解消

• ローカルの作業中ブランチで最新の変更をコミット
• 誰かがブランチをマージしたリモートのmasterをローカルのmasterにプル
• ブランチを切り替え、masterをマージ
• 落ち着いてコンフリクト解消→修正したらコミット

続いて、コードレビューの仕方についてです。

branch2「edit,updateアクションを定義」のプルリクに対してコードレビューをしましょう！

コードレビューの例

1. [レビュアー] プルリクURL→File changedタブ

ここで、ファイルの変更差分について確認します。

2. [レビュアー] 変更希望箇所をクリック（複数行を選択も可能）

直してほしい部分を選択して、コメントをします。

3. [レビュアー] コメントをする→Start a review

選択した部分についてのコメントを記載して下さい。

4. [レビュアー] 複数ファイルにコメント→Finish your review

そのプルリクで気になった箇所にコメントを残し終えたら、Finish your reviewを押して下さい。

• conversationsに戻るとレビューが反映されています。
• これに従って、プルリク依頼者はローカルで編集 → push → 再レビュー依頼

▶今回、レビュアー側として「showアクションを追加して下さい」とコメントをしてみました。これに沿って「プルリク依頼者側」での対応をしてみましょう。

5. [依頼者側] ローカルで編集してpush

routes.rb

#showを追加
+ resources :tweets, only: [:new, :create, :show, :edit, :update]

local-branch2

% git add .
% git commit -m "showアクションを追加"
% git push origin edit,updateアクションを定義

6.[依頼者側] 修正報告

レビューに対して「showアクションを追加しました！」とコメントしましょう。

7. [レビュアー] LGTM→Resolve conversation(レビュー完了)

• File changedを確認
• OKなら（コメントした後に）Resolve conversation

8. 全部でLGTMならマージ

以上のフローを繰り返し、LGTMをもらえたらマージしましょう！

9.ローカルのmasterにプル

% git checkout master
% git pull origin master

masterの変更分 (mergeした部分) が次のように反映されます。

小括 : コードレビュー

• プルリクのFile Changedで変更差分を確認
• 必要に応じてコメント
• コメントに対してローカルブランチで作業し再レビュー
• LGTMならマージ

以上が、GitHub flowによるコードレビューの基本手順です。

まとめ

• Git/GitHubを共同開発で使うときは、最新masterを作業中ブランチにマージする場面がくる
• 変わった部分を冷静に判断し、コンフリクトを解消
• プルリクに対してはファイルの変更差分を確認し、レビューを行う

個人とは違う部分が多く、例を出して説明するのに苦労しました。
しかし、この機会に学んでみるとGitってすごいな！と改めて思いました。

引き続き、共同開発がスムーズに進むよう、学習を進めていきたいです！

参考

• Udemy | Git： もう怖くないGit！チーム開発で必要なGitを完全マスター
• Qiita | GitHubで共同開発のためのチュートリアル
• Qiita | Gitでやりたいこと、ここで見つかる

ブランチ　マージ

ブランチ
並行して複数機能を開発するための仕組み
大本のブランチ master

HEADは現在作業している所
ブランチを新規作成する

ブランチの切り替えまでは行われない
$git buranch ブランチ名

ブランチの表示
$git buranch

全て表示 リモートブランチも表示
$git buranch -a

ブランチの切り替え
$git checkout 既存のブランチ名


新規作成＋ブランチの切り替え
$git checkout -b ブランチ名

ブランチを変更削除
変更
$git branch -m ブランチ名
削除
$git buranch -d ブランチ名 masterにマージされていない変更は残る

$git buranch -D　ブランチ名 強制的に削除

マージ
統合

$git merge ブランチ名
$git merge リモート名/ブランチ名


    b = masterブランチ
  - b
a
  - c
  c = testブランチ


  マージすると
  - b     d = masterブランチ
a      - d
  - c
  c = testブランチ


----------------------

Fast Foward


master    test
↓         ↓
a  ----   b


        master
        test
↓         ↓
a  ----   b

--------------------

Auto Merge



  b = masterブランチ
  - b
a
  - c
  c = testブランチ


親を2つ持っている b c を持っている
  - b     d = masterブランチ
a      - d
  - c
c = testブランチ


-----------------------------------------
コンフリクト

b c 同じ箇所を修正した場合に起こる

  b = masterブランチ
  - b
a
  - c
  c = testブランチ



複数人で同じファイルを編集しないようにする

変更中の状態をなくす事
  pull mergeを行う前に commit stashをしておくこと

pullを行う際に　ブランチを確認してから行う

実践編

プルリクエスト


ワークツリー
masterブランチを最新にする
ブランチファイルを作成
ファイルを編集変更
変更をコミット

ローカルリポジトリへプッシュ
↓
ローカルリポジトリ
プルリクエスト
コードレビューしてもらう
プルリクエストマージ
ブランチ削除

$git checkout -b pull_request
$git branch
master
*pull_request
$git add.
$git commit -m'pull_request create'
$git push origin pull_request


githubサイトへ


File changesでコードを見ることが出来る
紫でdeletedを押す

$git branch -d pull_request
または-D


github_flow

pull_request
maerge
 繰り返し

rebase

test
- b
a
- c
master
```

$git checkout test
$git rebase master
```

a - c - b`になる
master test

github pushしたコミットをリベースするのはNG

git push -fは使用するべきではない
強制的に行えるがgitがくしゃくしゃになるため行わないようにする

リベースとマージどっちを使用するべき？

マージ
コンフリクト○
マージコミットがたくさんあると複雑

作業履歴を残したいなら

リベース
履歴がきれいに保つ
コンフリクト△

履歴をきれいに使うなら

プッシュ後したあと
コンフリクトしそうならマージを使用

プッシュしていないローカルの変更に対してはリベース

ローカル関係はリベース　それ以外はマージ

コミットをきれいに整えてからの
pushをする場合の履歴の書き換え方
pushしていないコミットのみ

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

$git commit --amend


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



複数のコミッtのやり直し


ステージベース

$git rebase -i commitID
$git rebase -i HEAD~2       /2/3/4/5/5

edit as268da
pick wadfg45s
pick fdhnb513


editに変更すればそこまで戻る

$git commit --amend


$git rebase --continue




$git stash apply


ステージの状態も復元する場合
$git stash apply --index



特定の作業を復元する場合
$git stash applay　スタッシュ名



$git stash drop
$git stash スタッシュ名


全作業削除
$git stash clear
ー＝

すぐ忘れるのでメモ

名前の設定

git config --local user.name "<Name>"

Proxy設定

## リポジトリのみ設定
git config --local http.proxy <URL(ex:http://...)>:<port num>

目的

• Visual Studio Code（以後VScode）の拡張機能GitLensが便利だったので導入方法から紹介する

前提条件

• VScodeが導入されていること。

前提情報

• 筆者はMacにVScodeを入れている。拡張機能なのでOSには左右されないと思うのでWindowsの方も同じ方法でできると思う。

詳細

1. 導入

   1. VScodeを開き、サイドメニューにある拡張機能のアイコンをクリックする。

      

   2. 課長機能の検索部分に「GitLens」と入力し、ヒットしたGitLensの「インストール」をクリックする。

      

2. 確認

   1. Gitでバージョン管理をしているファイルをVScodeで開く。
   2. 既存ソースコードをクリックして入力できるようにする。

   3. 下記のように誰が、どのくらい前に、どんなコミットメッセージでコミットしたかの情報が表示される。

      

mac のシェル環境(zsh)から、マージされたリモートのGitブランチを削除するコマンドです。

コマンド

git branch -v -r --merged origin/develop | grep -v -e master -e develop -e test | sed -e 's/origin\///g' | cut -d' ' -f 3 | xargs git push -d origin 

読みやすく複数行にすると

git branch -v -r --merged origin/develop | \
grep -v -e master -e develop -e test | \
sed -e 's/origin\///g' | cut -d' ' -f 3 | xargs git push -d origin 

コマンドの各パーツ

マージされたブランチを一覧で出力

git branch -v -r --merged origin/develop

ここでは origin/develop にマージされたブランチを出しています。

消してはいけないブランチを除外

grep -v -e master -e develop -e test

master, develop, test を含むブランチを消してはいけないものとして除外しています。

ここまで繋げて実行すると、対象となるブランチを見ることができます。

ブランチ名の変換

sed -e 's/origin\///g'

表示されるブランチに origin が付いていますからその部分を消します。

ブランチ名の抽出

cut -d' ' -f 3 

最終コミットのメッセージが出ていますので、それを除外します。

リモートブランチ削除

xargs git push -d origin 

その他

不要になったブランチは削除しましょう。

作業を終えてcommitする際に、commitメッセージを間違えたり、変更したファイルをaddし忘れたりした時に、

git commit -m 'Aの実装'

git commit -m 'Aの実装: コミット漏れの追加'

みたいなことをするとダサい気がしたし、色々と他人に迷惑がかかる気がしたので、修正方法を調べると --amendというものを発見したので、メモしておく。

git commit --amendでできること

• commitメッセージの修正
• commitの内容を後から追加

git commit --amendでできないこと

• pushする前のcommitにしか利用することができない
• commitに含まれた修正を取り消すことはできない -> resetというものを使わないといけないらしい
• 2つ以上前のcommitを修正する-> rebaseというものを使わないといけないらしい

addしてなかったファイルを追加したい

以下のようにする。

$ git add A
$ git commit -m 'Aを追加'
$ git add B
$ git commit -m --amend 'AとBを追加

--amendに--no-editオプションを付けると、元々のcommitメッセージをそのまま利用することができる。

commitメッセージを変えたい

以下のようにする。

$ git add A
$ git commit -m 'Aを追加'
$ git commit -m --amend '実はBを追加'

まとめ

GIt力を高めたい

ブランチとは

ブランチ(branch)は、1つのプロジェクトから分岐させることにより、プロジェクト本体に影響を与えずに開発を行える機能のことを言います。つまり変更などの履歴を分岐してそれぞれ記録していくということですね！
分岐したブランチはほかのブランチの影響を受けないので、同じレポジトリの中で複数の変更(実装)を同時に進めていくことができます。

このように複数のブランチで開発を行い、それぞれのブランチで異なる機能の実装を行い実装が完了したタイミングなど(チームや作業者で異なります)で、統合(merge)して開発を進めていきます。

ブランチの作成関連

※ブランチを移動する前にはcommitが必要になります。commitせずに移動しようとするとcommitしてください的なerrorが出るのでその際は潔くcommitしてから移動しましょう。
※[ ]は省いて入力してください

#現在いる自分のブランチを確認(出力された中の*がついているブランチが現在のブランチです)
$ git branch

#ローカル間でのブランチの移動
$ git checkout [移動したい先のブランチ名]

#新規ローカルブランチの作成
$ git branch -b [作成したいブランチ名]

#リモートにあるブランチを元に新しくローカルブランチを作成
$ git branch [新しいブランチ名] [元にするブランチ名]

ブランチの削除

1⃣マージ済みのブランチの削除(マージしてないとエラーが出ます、してない場合は2⃣)
$ git branch -d [ブランチ名]

2⃣ローカルブランチを問答無用で削除
$ git branch -D [ブランチ名]

ブランチ名の変更

#ローカルのブランチ名の変更(hogeからfugaなら[hoge] [fuga])
$ git branch -m [現状のブランチ名] [新しいブランチ名]

#現在使用しているブランチ名の変更(fugaにしたければ[fuga])
$ git branch -m [新しいブランチ名]                                

統合ブランチへのプルリク&マージ後のローカルへの反映

#1⃣反映させたいブランチへ移動(統合ブランチがhogeなら[ブランチ名]はhoge)
$ git checkout [ブランチ名]

#2⃣リモートの最新版をローカルにプルする(1⃣に合わせると[ブランチ名]はhoge)
$ git pull origin [ブランチ名]

#3⃣自分の作業ブランチへの反映(1⃣2⃣に合わせると[ブランチ名]はhoge)
$ git checkout [自分の作業ブランチ名]
$ git merge origin/[ブランチ名]

※2⃣でプルした後に新しくブランチを作成したい場合
$ git checkout -b [作成したいブランチ名]

空コミット(筆者は良く忘れるコマンドなのでメモ代わりに、、)

空コミットは新規ファイルや修正ファイルが皆無でもコミットすることができます。
ブランチを確認するときなどに使います。

$ git add -A

$ git commit --allow-empty -m "コミットメッセージ"

#リモートレポジトリにプッシュ
$ git push origin [ブランチ名]

最後に

今回は初心者である筆者による筆者のための備忘録要素がハンパないですが、参考になれば嬉しいです。
他にもよく使うコマンドがあれば追加していきたいと思います。