20200801のGitに関する記事は11件です。

投稿日：2020-08-01T21:32:11+09:00

「明日からソースはこのGitリポジトリにpushで」と言われた時に慌てない為のまとめ

普段はGitを使ってないのですが、急にGitを使うことになった時の為に、Gitの基本的な使い方を備忘録としてまとめておきます。

対象

Git普段あまり使ってない
リポジトリは作ったりしない。利用するだけ

プロジェクトでGitを利用する時の流れ

ブランチ使ってない時

参加プロジェクトの指定されたリモートリポジトリからクローンする
ローカルでコード編集
ローカルでコミット
リモートリポジトリにプッシュ

コマンド

// 作業ディレクトリに移動
cd git-test
$ ls -la
drwxr-xr-x  4 luck  staff  128  7 31 23:44 .
drwxr-xr-x  4 luck  staff  128  7 31 23:31 ..

// リモートリポジトリからクローン
$ git clone https://<リポジトリアドレス>
Cloning into 'luck-gk-demo01'...
Username for 'https://<URL>': <e-mail>
Password for 'https://<URL>': <password>
warning: You appear to have cloned an empty repository.

$ ls -la
drwxr-xr-x  4 luck  staff  128  7 31 23:44 .
drwxr-xr-x  4 luck  staff  128  7 31 23:31 ..
drwxr-xr-x  3 luck  staff   96  8  1 13:39 luck-gk-demo01

指定されたブランチを利用する時

リモートリポジトリの指定されたブランチをクローンする
ローカルでコード編集
ローカルでコミット
リモートリポジトリの指定ブランチにプッシュ

【管理側の操作】一旦マスターブランチにpush

// ブランチ確認
$ git branch
* master

// リモートブランチ確認
$ git remote -v
origin  https://<リポジトリアドレス> (fetch)
origin  https://<リポジトリアドレス> (push)

// リモートブランチにpush（git push origin master と同じ）
$ git push
Username for 'https://<URL>': <e-mail>
Password for 'https://<URL>': <password>
Counting objects: 3, done.
Writing objects: 100% (3/3), 235 bytes | 235.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://<git URL>
 * [new branch]      master -> master

【管理側の操作】ローカルでブランチ作成してpushしておく

// 現在のローカルブランチ確認
$ git branch
* master

// ローカルで新規ブランチを作って移動
$ git checkout -b development_luck
Switched to a new branch 'development_luck'

// 現在のブランチ確認
$ git branch
* development_luck
  master

$ ls -la
total 8
drwxr-xr-x   4 luck  staff  128  8  1 13:52 .
drwxr-xr-x   5 luck  staff  160  8  1 13:39 ..
drwxr-xr-x  13 luck  staff  416  8  1 14:32 .git
-rw-r--r--   1 luck  staff   16  8  1 13:52 index.md
$ vi index.md
$ git diff
diff --git a/index.md b/index.md
index e26eaf2..84564a7 100644
--- a/index.md
+++ b/index.md
@@ -1,2 +1,3 @@
-Git clone test
+#Git clone test
+リモートリポジトリの特定のブランチからクローンするテスト

// コミットする
$ git status
On branch development_luck
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:   index.md

no changes added to commit (use "git add" and/or "git commit -a")
$ git add .
$ git commit -m "git branch test"
[development_luck f7a2e29] git branch test
 1 file changed, 2 insertions(+), 1 deletion(-)

// リモートにブランチが無い時はそのままだと失敗するので
$ git push
fatal: The current branch development_luck has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin development_luck

// 追加したブランチを指定してpushする
$ git push origin development_luck
Username for 'https://<URL>': <e-mail>
Password for 'https://<URL>': <password>
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 341 bytes | 341.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://<git URL>
 * [new branch]      development_luck -> development_luck

development_luck ブランチが登録された。

【作業者の操作】リモートリポジトリの指定ブランチからクローンする

// ローカルにクローンするディレクトリを作成して移動
$ mkdir git-test01
$ cd git-test01
$ ls -la
total 0
drwxr-xr-x  2 luck  staff   64  8  1 18:36 .
drwxr-xr-x  5 luck  staff  160  8  1 18:36 ..

// リモートリポジトリの特定のブランチを指定してクローン
// git clone -b <ブランチ名> <リモートリポジトリURL>
$ git clone -b development_luck https://<git URL>
Cloning into 'luck-gk-demo01'...
Username for 'https://<URL>': <e-mail>
Password for 'https://<URL>': <password>
remote: Enumerating objects: 6, done.
remote: Counting objects: 100% (6/6), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (6/6), done.

// 指定したブランチがクローンされていることを確認
$ ls -la
total 0
drwxr-xr-x  3 luck  staff   96  8  1 18:38 .
drwxr-xr-x  5 luck  staff  160  8  1 18:36 ..
drwxr-xr-x  4 luck  staff  128  8  1 18:38 luck-gk-demo01
$ cd luck-gk-demo01/
$ ls -la
total 8
drwxr-xr-x   4 luck  staff  128  8  1 18:38 .
drwxr-xr-x   3 luck  staff   96  8  1 18:38 ..
drwxr-xr-x  13 luck  staff  416  8  1 18:38 .git
-rw-r--r--   1 luck  staff  102  8  1 18:38 index.md
$ cat index.md
#Git clone test
リモートリポジトリの特定のブランチからクローンするテスト

// 現在のローカルブランチの確認
$ git branch
* development_luck

【作業者の操作】リモートリポジトリの指定ブランチにpushする

// 現在のローカルブランチ確認
$ git branch
* development_luck

// コードを修正してコミット
$ git status
On branch development_luck
Your branch is up to date with 'origin/development_luck'.

nothing to commit, working tree clean
$ ls -la
total 8
drwxr-xr-x   4 luck  staff  128  8  1 18:38 .
drwxr-xr-x   3 luck  staff   96  8  1 18:38 ..
drwxr-xr-x  13 luck  staff  416  8  1 20:13 .git
-rw-r--r--   1 luck  staff  102  8  1 18:38 index.md
$ vi index.md
$ git diff
diff --git a/index.md b/index.md
index 84564a7..ddc63e7 100644
--- a/index.md
+++ b/index.md
@@ -1,3 +1,4 @@
 #Git clone test
 リモートリポジトリの特定のブランチからクローンするテスト
+リモートリポジトリの特定のブランチにpushするテスト

$ git add .
$ git commit -m "git push test"
[development_luck d0171d2] git push test
 1 file changed, 1 insertion(+)

// リモートリポジトリの確認
$ git remote -v
origin  https://<リポジトリアドレス> (fetch)
origin  https://<リポジトリアドレス> (push)

// リモートリポジトリの指定ブランチにpush
$ git push origin development_luck
Username for 'https://<URL>': <e-mail>
Password for 'https://<URL>': <password>
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 347 bytes | 347.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://luck-gk.backlog.com/git/PROG/luck-gk-demo01.git
   f7a2e29..d0171d2  development_luck -> development_luck

　 Tweet
Qiitaで続きを読む

投稿日：2020-08-01T20:39:47+09:00

Gitで複数アカウントを使い分ける時のリモート接続設定メモ

[備忘] 複数Githubアカウントでssh接続設定(config)を使い分ける手順
git pushする前にアカウント切り替えたい時どうやるんだっけ…？となり、こちらの方の記事を自分用にアレンジした時のメモです。
上記の方が丁寧なので、基本は上記を読んだ方がよいと思います。

事前準備

以下は準備済みの前提で進めます。この記事では説明を省略しています。

gitリポジトリ

GitHubなどのアカウント (必要な数だけ)

ssh鍵の生成およびGitHub等への登録 (必要な数だけ)

globalのgit設定全般

ssh設定

今回は、メインのアカウントは(コマンドコピペ時などにそのまま使えるように）通常通り Host: github.com とし、サブのアカウントを使うときは Host 末尾に .sub と加えることで使い分けるようにします。
~/.ssh/config
Host github.com
  User git
  IdentityFile ~/.ssh/id_rsa_main
  TCPKeepAlive yes
  IdentitiesOnly yes

Host github.com.sub
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_rsa_sub
  TCPKeepAlive yes
  IdentitiesOnly yes
接続確認
$ ssh -T git@github.com
$ ssh -T git@github.com.sub
設定がうまくできていれば、それぞれのレスポンスでアカウント名部分が変わるはずです。
Hi {your-account}! You've successfully authenticated, but GitHub does not provide shell access.
git設定 (subのアカウントの例のみ)

リポジトリ内のアカウント設定

サブのアカウントに切り替えたいリポジトリ配下で以下を実行。最初のcommitをする前にやっておきたい。
git config --local user.name {sub-account}
git config --local user.email {sub-email}
リモートリポジトリURLの登録
$ git remote add origin git@github.com.sub:{your-sub-account}/{repository-name}.git
既に remote.origin.url に何かしらが入っていると fatal: remote origin already exists. と怒られてできないので、その場合は以下コマンドのように add ではなく set-url とする。
$ git remote set-url origin git@github.com.sub:{your-sub-account}/{repository-name}.git
確認
$ git config remote.origin.url
git@github.com.sub:{your-sub-account}/{repository-name}.git
ホスト名部分が github.com.sub など、.ssh/config の Host 部分に書いた値と同じにできていればOK。

これで複数アカウントでのcloneやpushが快適にできるようになりました！

　 Tweet
Qiitaで続きを読む

投稿日：2020-08-01T19:30:24+09:00

開発でよく使うGITコマンド

1. クローンの作成

git clone [クローンしたいリポジトリ]

リポジトリのクローンを作成する。主にリモートリポジトリをローカルにクローンするために利用する。
例：クローンしたいリポジトリが git@github.com:hoge/hoge.git の場合
git clone git@github.com:hoge/hoge.git
2. ブランチの確認

git branch -a

リポジトリの全てのブランチを一覧表示する。リモートブランチを含む。
例：
git branch -a
3. ローカルブランチ作成

git checkout -b [ローカルブランチ名]

現在のブランチから、新しいローカルブランチを作成し、新しいブランチに切り替わる。
例：ローカルブランチ develop を作成する場合
git checkout -b develop
4. リモートブランチ作成

git push origin [リモートブランチ名]

リモートリポジトリ上に新しいブランチを作成する。

git push -u origin [リモートブランチ名]

リモートリポジトリ上に新しいブランチを作成する。
さらに作成した新しいリモートブランチを現在のローカルブランチのupstreamに設定する。
例：リモートブランチ develop を作成する場合
git push origin develop
例：リモートブランチ develop を作成し、ローカルブランチのupstreamに設定する場合
git push -u origin develop
5. リモートブランチと同期

git pull

リモートブランチを取得し、マージする。
例：
git pull
6. コミット

git add .

すべてのディレクトリ、ファイルの変更内容をコミット対象に加える。

git commit -m [コメント]

変更内容をコメントを付けてコミットする。
例：コミットコメントに "バグ修正" を入れる場合
git add .
git commit -m “バグ修正”
7. コミットログの確認

git log

コミットログを一覧表示する。
例：
git log
詳しくは、git log よく使うオプションまとめを参照

8. コミットをまとめる

git rebase -i [派生元コミット]

複数回行ったコミットを１つにまとめる。
例：コミットを4コミット分まとめる場合
git rebase -i HEAD~4
例：派生元コミット 07191f1 を指定し、派生元コミットまでをまとめる場合
git rebase -i 07191f1
詳しくは、rebase -i でコミットをまとめるを参照

9. リモートリポジトリに反映

git push

コミットした内容をリモートリポジトリに反映する。
例：
git push
10. ローカルブランチ削除

git branch -d [ブランチ名]

ローカルブランチを削除する。
例：ローカルブランチ develop を削除する場合
git branch -d develop
11. リモートブランチ削除

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

リモートブランチを削除する。
例：リモートブランチ develop を削除する場合
git push --delete origin develop

　 Tweet
Qiitaで続きを読む

投稿日：2020-08-01T18:13:21+09:00

【チーム開発にて】他メンバーのブランチに移動して、rails sした時のエラー【Rails】

参考対象者

チーム開発初心者

Railsでのアプリ開発にて、データベース関連のエラーで困ってる方

Git初心者

環境
$ rails -v
Rails 6.0.3.1
$ ruby -v
ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [x86_64-darwin19]
$ git --version
git version 2.27.0
$ mysql --version
mysql  Ver 14.14 Distrib 5.7.29, for osx10.15 (x86_64) using  EditLine wrapper
状況

他メンバーのブランチに移動し、レビューするために挙動確認したかったが、サーバーを立ち上げるときにエラーが出た。

どうやら、データベース関連のエラーらしい。

ActiveRecord::PendingMigrationError

https://qiita.com/KONTA2019/items/0444ae3b8c8936a56ee0

上記を参考に、解決する。
ちなみに私は、
$ rails db:migrate
で解決。

でも、その後次のようなエラーが。。。

Multiple migrations have the name ~~~.

結論から言うと、~~~には、マイグレーションファイル名が入ります。

私の場合は、
Multiple migrations have the name CreateUsers.
となって、自分のマイグレーションファイルを確認してみると、
$ rails db:migrate:status

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     20200618162841  Create tweetposts
   up     20200620004226  Change tweetposts to tweets
  down    20200621075518  Create posts
  down    20200623102444  Change posts to chats
  down    20200627042358  Create users
   up     20200627080839  Create users
   up     20200627083356  Add column to users
  down    20200627220915  Change datatype content of chats
   up     20200703201452  ********** NO FILE **********
  down    20200710035709  Add user id to tweets
ありましたね、CreateUsersファイル。

察しの良い方はお分かりだと思いますが、エラー文の内容から「同名のマイグレーションファイルか存在しているから、どちらを参考にデータベース構築をしたら良いかわからないよ」という状況と推測できます。

なので、
down 20200627042358 Create users
こちらのファイルを削除し、
$ rails db:migrate
$ bundle exec rails s
これにて、サーバーを起動することができました！

ちなみに、、、

マイグレーションファイルの、
up 20200703201452 ********** NO FILE **********

気になりますよね？？

これ、ないファイルを参考にデータベースを構築してるという不可思議な現象なので、削除してしまいたいですね。

これの原因は、マイグレーションをdownさせる前に、マイグレーションファイルを削除してしまったため起こるものなのですが、解決方法は下記をどうぞ。

https://qiita.com/beanbeenzou/items/e8886071ab1e1cf7a9c0

　 Tweet
Qiitaで続きを読む

投稿日：2020-08-01T15:30:07+09:00

現場に入るまでに知っておきたいGitHubの使い方

開発の現場に入る上で知っておくべきGitHubの知識をまとめました。
これからGitHubを使ったチーム開発に参画する方に見てもらいたい内容です。

はじめに

開発環境の構築からプルリクエストを出してマージまでの流れをシミュレーション形式で進めていきます。
部分的にはたくさん情報がありますが、ストーリーとしてまとめてみたという感じです。

前提

Gitは学習済
GitHubアカウントがある
※Gitの使い方についてはこちらに記事があります。

鍵を作成

最初にやることは使用するPCとGitHubアカウントとの連携です。
そのためにはPCの公開鍵をGitHubに登録する必要があります。

このコマンドですでに鍵が作成されているか確認できます。
$ ls ~/.ssh
鍵は~/.sshというディレクトリに作るので、lsコマンドで~/.sshのファイル一覧を表示しています。

id_rsaとid_rsa.pubが表示されれば鍵は作成済です。
id_rsaが秘密鍵でid_rsa.pubが公開鍵です。

鍵がなければ作成します。
まず~/.sshに移動します。
$ cd ~/.ssh
もし~/.sshというディレクトリが存在しなければmkdirで作成してください。
$ mkdir ~/.ssh
$ cd ~/.ssh
カレントディレクトリが~/.sshになっている状態で、このコマンドで鍵を作成できます。
$ ssh-keygen -t rsa
何回か質問されますが、そのままEnterを押して問題ありません。

鍵が作成されたはずなので、もう一度lsコマンドを打ってください。
(カレントディレクトリが~/.sshなのでlsだけで十分です)
$ ls
今度はid_rsaとid_rsa.pubが表示されたはずです。

GitHubに公開鍵を登録

続いて公開鍵をGitHubに登録します。

公開鍵はすごく長い文字列で、ターミナルにはcatコマンドで表示できます。
$ cat ~/.ssh/id_rsa.pub
これをそのままコピーしてもいいのですが、コマンドでコピーができるのでこちらの方が便利です。
$ pbcopy < ~/.ssh/id_rsa.pub
※ちなみにこのコマンドはMacの場合です。
Windowsならclip < ~/.ssh/id_rsa.pubでコピーできるようです。
(試してないのでコピーできなかったらすみません)

GitHubへの登録は簡単です。

ログインしてこの画面の「New SSH key」をクリックしてください。
https://github.com/settings/ssh

Titleは自由に決めれます。
Keyにはコピーした公開鍵を貼り付けてください。
「Add SSH key」をクリックすれば完了です。
(おそらくパスワードを求められます)

これで使用するPCとGitHubとのやりとりが可能になります。

リポジトリについて

GitHubでは複数のプロジェクトを管理できます。
リポジトリとは一つ一つのプロジェクトの大元になるディレクトリのようなものです。

プロジェクトへの参画は途中から入ることが多いので、その時にはすでにGitHubにプロジェクトのリポジトリが作られています。

なので現場に入ったらGitHubのソースコードをローカルにコピーする必要があります。
これをリポジトリをクローンすると呼びます。

リポジトリを作成

ここではクローンするリポジトリがないので作成することにします。

作成画面へはURLで遷移するか、画面右上のボタンで遷移できます。
https://github.com/new

リポジトリ名は自由に決めていいので「manga-blog」とします。
Descriptionは記入しなくてもいいです。
公開する必要はないのでprivateを選択します。
Initialize this repository with a READMEのチェックは入れないでください。

これで「Create repository」をクリックすればリポジトリが作成されます。

リポジトリにpush

作成したmanga-blogにソースをpushしていきます。
pushはローカルリポジトリで編集した内容をリモートリポジトリにアップロードする機能です。

適当な場所にmangaディレクトリを作成して移動してください。
$ mkdir manga
$ cd manga
Git管理を開始します。
$ git init
適当にファイルを作リます。
touch ファイル名で作成が可能です。
$ touch UserController.php
$ touch PostController.php
ファイルは何でもいいのでPHPファイルを2つ作りました。
それぞれこのように記載します。
UserController.php
<?php

class UserController
{
    public function create() {}
    public function update() {}
}
PostController.php
<?php

class PostController
{
    public function create() {}
}
これをコミットします。
$ git add .
$ git commit -m "first commit"
これでGitHubにpushする準備が整いました。

pushの前にGitのリポジトリについて補足です。

Gitにはローカルリポジトリとリモートリポジトリという概念があります。
ローカルリポジトリは自分のPCで管理するリポジトリのことで、リモートリポジトリはGitHubのリポジトリのことです。

リモートリポジトリはこのコマンドで確認できます。
$ git remote -v
まだ設定していないので何も出力されません。

設定はgit remote addでできます。
GitHubのmanga-blogのTOP画面にもコマンドが記載されています。
$ git remote add origin git@github.com:{アカウント名}/manga-blog.git
今度はリモートリポジトリが出力されるはずです。
$ git remote -v
origin  git@github.com:{アカウント名}/manga-blog.git (fetch)
origin  git@github.com:{アカウント名}/manga-blog.git (push)
originとはリモートリポジトリの別名です。
pushやpullでoriginが出てきたらGitHubに作ったリポジトリのことだと置き換えてください。

リモートリポジトリが登録できたらpushができます。
$ git push -u origin master
originはリモートリポジトリのことなのでGitHubのmanga-blogを指しています。
manga-blogのmasterブランチにpushするという意味になります。

-uは次回以降のpush先を今回のpushと同じにしてくれるオプションです。
つけなくても問題ありません。
GitHubのリポジトリのTOP画面の説明で-uが付いているので同じにしたかっただけです。

pushできたらGitHubのmanga-blogのTOPに作成したファイルが表示されます。

GitHubの便利機能

pushができたので、ここでGitHubでよく使う便利な機能を2つ紹介します。

permalink

一つ目はpermalinkです。
GitHubにpushしたUserController.phpを開いて、行番号をクリックしてください。
ボタンのようなものが出てくるのでクリックするといくつかメニューが表示されます。
その中から「Copy permalink」を選択すると、そのファイルのその行をハイライトした状態のリンクがコピーできます。

これを使えば別のメンバーと「何々というファイルの何行目について」などとやりとりせず、このリンクを貼り付けるだけで済むようになります。

ファイル検索

もう一つはファイル検索です。
リポジトリのTOPに戻ってtを2回タイプしてみてください。
カーソルが出てくるので、検索したい文字列を打ち込みます。
試しに「user」と入力すると、「user」を含むファイルのみを表示してくれます。

ネストが深いファイルを見つける時にとても便利です。

リポジトリをクローン

リポジトリを作成したので、本来やりたかったリポジトリのクローンを行います。
pushしたディレクトリの一つ上に移動してください。
$ cd ..
クローンはgit clone クローンするリポジトリでできます。
クローンするリポジトリは右上の「Code」ボタンをクリックしてClone with SSHからコピーできます。
$ git clone git@github.com:{アカウント名}/manga-blog.git
これでGitHubのmanga-blogがコピーされて、ローカルにmanga-blogが作成されます。

なお、git cloneではデフォルトでmasterがクローンされます。
ブランチを指定してクローンしたい場合は-b ブランチ名を追加してください。
$ git clone -b ブランチ名 git@github.com:{アカウント名}/manga-blog.git
クローンしたmanga-blogに移動します
$ cd manga-blog
ブランチ指定しなければmasterがコピーされている状態になります。
$ git branch
* master
git branchでローカルブランチの一覧が表示されますが、長く開発しているとブランチがたくさんできます。
この時にカレントブランチを表示するコマンドを知っておくと便利です。
$ git branch --con
conはcontainsのことで、現在のコミットを含むブランチのみを表示してくれます。
大体はカレントブランチのみか最近使用したブランチが数個表示されます。

他にもカレントブランチを表示するオプションはありますが、長いので--conが便利です。

もっといいのはターミナルに常にカレントブランチを表示する方法ですが、これは意外と設定が面倒なので、とりあえずgit branch --conは覚えておいて損はないと思います。

ローカルサーバを立ち上げる

クローンしたらローカルサーバを立ち上げます。
この工程はプロジェクトや採用するツールによって様々なので現場のルールで行うことになります。

ライブラリをインストールしたりDockerを立ち上げるなど諸々行った上で、http://localhost:{ポート}で、プロジェクトのTOP画面が表示されればOKという流れになると思います。

hostsファイル

ローカルホストに http://localhost でアクセスしても良いのですが、味気ないのと何のプロジェクトか分からないことから別名をつけるケースがあります。

その時に使われるのがhostsファイルです。

hostsはmacならこのコマンドで確認できます。
$ cat /etc/hosts
おそらく127.0.0.1 localhostという記載があると思います。
左にIPアドレスで右にホスト名を記入すれば対応関係が作れます。

例えば http://local-manga-blog でローカルホストにアクセスしたいときは
127.0.0.1 local-manga-blog
を追加すればいいことになります。

ポート番号でプロジェクトを分けたいときにも使えます。

追加の仕方はネット上にたくさん記事がありますのでここでは割愛します。

課題

プルリクエストを出す練習をしたいので課題を用意します。
PostController.phpにはupdateがなかったので、それを追加することを課題とします。

クローンしたリポジトリのmanga-blogで作業を行います。

ブランチは課題ごとに作るのが一般的で、ブランチ名の付け方は現場でルールが決まっていると思います。
ここではadd-updateにします。
$ git checkout -b add-update
PostController.phpにupdateを追加します。
PostController.php
<?php

class PostController
{
    public function create() {}
    public function update() {}
}
コミットします。
$ git add .
$ git commit -m "updateを作成"
GitHubにpush

コミットしたらGitHubにpushできますが、その前にoriginのmasterをpullして最新のmasterを取り込みます。
$ git pull origin master
複数人で開発する場合は、ブランチを作ってからpushするまでにmasterが更新されていることがあるので最新を取り込む必要があります。

ここでコンフリクトが起きたら解消しないといけません。
コンフリクトについてはこちらで解説しています。

問題がなければpushします。
pushはgit push origin 同名のブランチ名とすることで、同じ名前のブランチをGitHubに作ってそこにpushできます。
この場合ならgit push origin add-updateになります。

しかしブランチ指定は面倒なのでもっといいコマンドがあります。
$ git push origin HEAD
HEADはカレントブランチとほぼ同じ意味で、このコマンドで代用できます。
これなら毎回、pushのコマンドを変えなくても同名のGitHubのブランチにpushすることができます。

プルリクエストを出す

pushができたらプルリクエストが出せます。

プルリクエストを出す画面に遷移するには色々ルートがあって、その中でも一番多いのはpush直後に上に表示される「Compare & pull request」だと思います。

その他にはブランチを切り替えて右下にある「Pull request」もあります。

プルリクエストはどのブランチからどのブランチに出すのかが肝心です。
「どのブランチから」は作業したadd-updateになります。
「どのブランチに」については現場でルールが決まっています。

下の画像ではmasterになっていますが、stagingやdevelopというブランチがあって、そこに出すことの方が多いかもしれません。

プルリクエストはタイトルやコメント、右側にあるReviewersなど入力する項目はたくさんあります。
ここは現場のフォーマットに従えば問題ないです。
あとは「Create pull request」ボタンでプルリクエストを作成できます。

プルリクエストが作成されたらFiles changedというタブを開いて修正内容を見ることができます。
この画面をもっと見やすくする方法をがあるので紹介します。

下の写真の設定をクリックするとUnifiedとSplitが選べます。
デフォルトはUnifiedになっているので、Splitを選択して「Apply and reload」をクリックしてください。

するとファイルが左右に分割されて、より比較がしやすくなります。

その他にもプルリクエストにはコードにコメントをつけたり、レビューしてプルリクエストを承認するかを決める機能もあります。

レビューからマージ

プルリクエストをマージするにはいったん誰かのチェックが入ると思います。
どこまで厳密にやるかは現場によってまちまちです。

レビュワーをつけて承認(Approve)されないとマージができない設定になっているか、単にコメントで済ませることもあります。
テストが自動で実行されて全て通過してからでないとマージできない場合もあります。

修正の指摘が入ったときはそれに対応して再度pushします。
ここでは例としてPostController.phpにdeleteも追加して欲しいと要望があったとします。

作業を再開するのでカレントブランチを確認します。
$ git branch --con
* add-update
PostController.phpにdeleteを追加します。
PostController.php
<?php

class PostController
{
    public function create() {}
    public function update() {}
    public function delete() {}
}
コミットします。
$ git add .
$ git commit -m "deleteを作成"
pushします。
$ git push origin HEAD
そうすると先ほど出したプルリクエストに反映されます。
プルリクエストが出されているブランチにpushしたときは、自動で反映されますので新たにプルリクエストを出す必要はありません。

これで承認がもらえたことにしてマージします。

緑の「Merge pull request」ボタンが表示されていればマージが可能です。

「Merge pull request」をクリックして「Confirm merge」でマージが完了します。

ここでコンフリクトが発生していると「Merge pull request」が押せないようになっています。
プルリクエストを出したときはコンフリクトが起きていなくても、レビューしてもらっている間にマージ先(ここではmaster)が更新されているケースで起こります。

そういうときは最初にpushする前と同じようにgit pull origin masterでマージ先のブランチをpullしてからコンフリクトを解消する必要があります。
コンフリクトについてはこちらの記事で解説しています。

最後に

現場に入って環境構築からプルリクエストがマージされるまでを簡単な課題も交えて書きました。
ここまでの流れが把握できていれば現場で大きく困ることなはいと思います。
サービスの仕様や課題に集中するためにもGitHubの使い方は事前に理解しておくことをお勧めします。

　 Tweet
Qiitaで続きを読む

投稿日：2020-08-01T15:07:07+09:00

TortoiseGit で GitLab に Merge Request する

GitLab にリモートリポジトリを作成し、TortoiseGit でローカル作業を行う時の操作方法をメモしておきます。

TortoiseGit

環境

Windows10

TortoiseGit 2.10.0.2

GitLab CE 12.8.6（Windows10で仮想サーバー起動）

初回のみ

クローン

GitLab のリポジトリをクローンします。

TortoiseGit の「Git クローン」を選択します。

リポジトリの URL とクローン先のディレクトリを指定します。

ブランチ作成

GitLab の issueごとにブランチを作成して作業します。

masterブランチをプルする

「TortoiseGit」→「プル」を選択します。
リモートに origin を指定します。
リモートブランチに master を指定します。

testブランチを作成する

「TortoiseGit」→「ブランチを作成」を選択します。
ブランチに test（ブランチ名）を指定します。
「新しいブランチに切り替える」にチェックを付けます。

繰り返し作業

testブランチをコミットする

「Git コミット -> "test"」を選択します。
メッセージを入力します。
メッセージに issue番号（例：#4）を入れると GitLab でコミットと issue が紐づきます。
「コミット」をクリックします。

プッシュ

testブランチでorigin/masterをプルする

「TortoiseGit」→「プル」を選択します。
リモートに origin を指定します。
リモートブランチに master を指定します。
「フェッチ後にリベース」にチェックを付けます。
フェッチ後のリベースで競合したら（頑張って）解決します。

testブランチをプッシュする

「TortoiseGit」→「プッシュ」を選択します。
ローカルに test を指定します。

GitLab

Merge Request

「マージリクエストを作成」をクリックします。

タイトルなどを記入します。
「Submit マージリクエスト」をクリックします。

　 Tweet
Qiitaで続きを読む

投稿日：2020-08-01T03:17:15+09:00

yps並走記録　Task3 　SQL：テーブル作成（復習）バッチ作成（復習）～php.ini設定～GitHubにファイルをアップロード～WordPress5.4.2セットアップ

早くも３週目になりました、yps
今回はなるべくリアルタイムで課題をやりながらログを取っていきたいと思います。

まずはSQL周りの復習

MySQLのエンコード設定を直します

エンコード設定をutf8mb4に戻す(mysql cliから日本語扱えるようにutf8にしてた）
sudo vi /etc/my.cnf

最終行に以下を追記
[client]
default-character-set=utf8mb4
編集を保存し、mysqlを再起動
sudo systemctl restart mysql

練習で使うデータをダウンロード

cd /tmp
sudo yum install wget
wget http://tech.pjin.jp/wp-content/uploads/2016/04/worldcup2014.zip
unzip http://worldcup2014.zip

データの確認
ls -la worldcup2014.sql

データベース作成

MySQLにログインして…
mysql -u root -p （パスワードを入力）

データベースを作成
create database worldcup2014db;

使うデータベースにDLしたデータを指定
use worldcup2014db;
source ./worldcup2014.sql;

テーブルを表示して確認
show tables;

確認用バッチ処理とコマンドを作成していきます

参考：バッチ処理とは？

Laravelでモデルを作成（参考：https://blog.codecamp.jp/php_mvc01）
php artisan make:model Models/Player

作成したモデルを確認
ls -la app/Models/Player.php

バッチ記述用のファイルを作成
php artisan make:command TestCommand

作成したファイルを確認
ls -la app/Console/Commands/TestCommand.php

ここからは
1. SSH接続したVS Codeを使って
2. /var/www/html/ypsフォルダ（Laravelのプロジェクトファイル）
で作業していきます

app/console/commandsのCommands.phpファイルに以下を記述
Commands.php
<?php

namespace App\Console\Commands;

use Illuminate\Console\Command;
use App\Models\Player;

class TestCommand extends Command
{
    /**
     * The name and signature of the console command.
     *
     * @var string
     */
    protected $signature = 'test_command';

    /**
     * The console command description.
     *
     * @var string
     */
    protected $description = 'Test Command';

    /**
     * Create a new command instance.
     *
     * @return void
     */
    public function __construct()
    {
        parent::__construct();
    }

    /**
     * Execute the console command.
     *
     * @return int
     */
    public function handle()
    {
        $players = Player::get();
        foreach($players as $player) {
            echo $player->name."\n";
        }
        return 0;
    }
}
保存したらターミナルで以下のコマンドを打って確認

キャッシュをクリア
php artisan config:clear

上記で作成したバッチコマンドを入力
php artisan test_command | head

無事選手名が表示されればＯＫ

MySQL日本語が打てない問題の一先ずの対応　＝　sqlファイルを作成して読み込ませる

どうしてもコマンドを使って行う場合の対応。
≒基本的にLaravelを使ってSQLは操作するので特に問題はなさそう？

一時ファイルに移動
cd /var/tmp
sqlファイルを作成
vi get_players.sql

以下を記述
use worldcup2014db;
select * from players where name = '酒井';
ターミナルで下記を打ってパスワードを入力
mysql -u root -p < ./get_players.sql

酒井選手が２桁表示できればＯＫ
（ファイルに出力したい場合は　mysql -u root -p < ./get_players.sql > ./out.txt）

～MySQLの復習＆バッチ作成ここまで～

php.iniファイルを編集

主にPHPをアプリケーションで使用する際に日本語で文字化けしたりしないような設定をしていくようです。

※事前に sudo yum install colordiff -y で差分を見られるようにしておく

参考リンクを見ながらphp.iniの設定を編集

sudo vi /etc/php.ini

まずはデフォルトのエンコーディングがUTF-8に…

default_charset = "UTF-8"

しかしこれ、あとで調べたら5.2以降のPHPはデフォルトでUTF-8になってるみたい…ということで設定要らんかったのかorz

気を取り直して、mbstringの探しつつ確認をしていきます。
[mbstring]の設定は一番下の方にありました…

mbstring.language = Japanese //コメントアウトを外す
mbstring.encoding_translation = Off //コメントアウトを外してoffにする
mbstring.detect_order = auto //コメントアウト外す

※参考リンクが古いためか、ブログ記事では手動で設定するような記述になっているがautoのままでいいみたいです
（多分ＰＨＰのバージョンの関係）
date.timezone = Asia/Tokyo

PHPのバージョンが表示されてしまわないように変更
expose_php = Off

パフォーマンス関連の設定
memory_limit = 128M これはデフォルトの設定なので確認だけ

ポストリクエストのマックスサイズを128Mに変更
post_max_size = 128M

ファイルをアップロードする際のマックスサイズをPOSTに合わせて128Mに変更
upload_max_filesize = 128M

ついでにエラーログの設定もしておきましょう
error_log= "/var/log/php_errors.log"

全部できてれば…
colordiff -u /etc/php.ini.org /etc/php.iniって打てば
--- /etc/php.ini.org    2020-07-07 18:04:58.000000000 +0900
+++ /etc/php.ini    2020-07-31 23:28:50.392713681 +0900
@@ -373,7 +373,7 @@
 ; threat in any way, but it makes it possible to determine whether you use PHP
 ; on your server or not.
 ; http://php.net/expose-php
-expose_php = On
+expose_php = Off

 ;;;;;;;;;;;;;;;;;;;
--- /etc/php.ini.org    2020-07-07 18:04:58.000000000 +0900
+++ /etc/php.ini    2020-08-01 01:02:55.357913512 +0900
@@ -373,7 +373,7 @@
 ; threat in any way, but it makes it possible to determine whether you use PHP
 ; on your server or not.
 ; http://php.net/expose-php
-expose_php = On
+expose_php = Off

 ;;;;;;;;;;;;;;;;;;;
 ; Resource Limits ;
@@ -584,6 +584,7 @@
 ; http://php.net/error-log
 ; Example:
 ;error_log = php_errors.log
+error_log = "/var/log/php_errors.log"
 ; Log errors to syslog (Event Log on Windows).
 ;error_log = syslog

@@ -690,7 +691,7 @@
 ; Its value may be 0 to disable the limit. It is ignored if POST data reading
 ; is disabled through enable_post_data_reading.
 ; http://php.net/post-max-size
-post_max_size = 8M
+post_max_size = 128M

 ; Automatically add files before PHP document.
 ; http://php.net/auto-prepend-file
@@ -842,7 +843,7 @@

 ; Maximum allowed size for uploaded files.
 ; http://php.net/upload-max-filesize
-upload_max_filesize = 2M
+upload_max_filesize = 128M

 ; Maximum number of files that can be uploaded via a single request
 max_file_uploads = 20
@@ -919,7 +920,7 @@
 [Date]
 ; Defines the default timezone used by the date functions
 ; http://php.net/date.timezone
-;date.timezone =
+date.timezone = Asia/Tokyo

 ; http://php.net/date.default-latitude
 ;date.default_latitude = 31.7667
@@ -1533,7 +1534,7 @@
 ; language for internal character representation.
 ; This affects mb_send_mail() and mbstring.detect_order.
 ; http://php.net/mbstring.language
-;mbstring.language = Japanese
+mbstring.language = Japanese

 ; Use of this INI entry is deprecated, use global internal_encoding instead.
 ; internal/script encoding.
@@ -1571,7 +1572,7 @@
 ; automatic encoding detection order.
 ; "auto" detect order is changed according to mbstring.language
 ; http://php.net/mbstring.detect-order
-;mbstring.detect_order = auto
+mbstring.detect_order = auto

 ; substitute_character used when character cannot be converted
 ; one from another
ってなるはず（らしい）

そしてコンソールに戻ってphpのエラーログファイル作成＆設定を行います
sudo touch /var/log/php_errors.log
sudo chown nginx:nginx /var/log/php_errors.log

ここまでできたら設定反映のためにphp-fpmとnginxを再起動
sudo systemctl restart php-fpm
sudo systemctl restart nginx

～php.iniの設定ここまで～

Gitインスコ＆GitHubとの連携

参考までに予備知識：https://qiita.com/moonbass630/items/383fc8300a83784e4c82

まずはgitをインストール

sudo yum install git -y
ディレクトリをLaravelのプロジェクトに移動して…
cd /var/www/html/yps
gitをinitします（意味が分からない方のための参考リンク：https://26gram.com/git-init）
git init

ブラウザでGitHubを開いて新規リポジトリ作成

Newボタンを押して新規作成

リポジトリをPrivateに

gitignoreにLaravelを追加

create Repositoryを押して

add readme.mdをクリックして完了

リポジトリの画面の右側のCodeボタンをクリックして

Clone with SSHと書かれたところに書いてあるgit@github.comから始まるリポジトリのurlをコピー

※GitHubにはすぐ戻ってくるのでブラウザは開いたままが推奨

Gitの設定ファイルを記述

ターミナルでまたLaravelのプロジェクトファイルへ戻ります
cd /var/www/html/yps/

Gitの設定ファイルを編集
sudo vi .git/config

下記を記述します
[remote "origin"]
    url = "リポジトリのurl" //作成時にコピーしたもの
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
    remote = origin
    merge = refs/heads/master
[user]
    name = 自分のgithubユーザー名
    email = 自分のメアド
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
接続用の秘密鍵を作成

ssh-keygen -t rsa -b 4096 -C "自分のメアド"
enterを押して
パスワードを2回入力

下記コマンドを打って表示される文字列をコピーしておく
cat ~/.ssh/id_rsa.pub

GitHubに文字列を登録

右上のアイコンを押してアカウントメニューを表示

Settings ⇒ SSH and GPG keys

New SSH keyをクリック

Titleは適当なものをつける

Keyと書いてあるところに上記（cat ~/.ssh/id_rsa.pubコマンド）で表示されたキーを張り付け

Add SSH keyを押すと登録完了

GitHubをリモート登録

ターミナルでLaravelプロジェクトフォルダに戻ります
cd /var/www/html/yps/

差分ファイルを全てステージングして、マスターブランチにpush
git add .
git commit -am "initial"
git push origin master
yesを入力してパスワードを入力すればソースコードの登録完了。

develop / feature ブランチを切る

参考リンク：https://qiita.com/Naoki206/items/e5520453f92dcd4274f1

参考リンクを見ながらdevelopブランチとfeatureブランチを切る
$git branch 現在のブランチの確認
$git branch develop developブランチ作成
$git checkout develop developブランチへ移動
$git push origin develop リモートに反映

～git導入＆GitHub連携ここまで～

Masterから分岐させて開発終了後にmergeを使ってmasterブランチへ取り込むことによってgitではバージョン管理をする…
Gitは一応Progateでいじって、Qiitaでも初心者向けの記事読んだりしてたけど、今回色々いじってようやく仕組みが腑に落ちた感あるな～

今回はまとめ作ってたらすんごい時間になってしまったのでこの辺で…
次回はＷＰ導入していじるみたいです。

今まで色々やってきたことの解像度が大分上がってきて楽しくなってきたぞ～（夜中のテンション）

　 Tweet
Qiitaで続きを読む

投稿日：2020-08-01T00:52:40+09:00

merge --no-ffのメリットを年齢のたとえ話で後輩に教えました

git merge --no-ff のメリットを伝えるのに

実案件のログは使いづらいので

年齢の commit graph を作ったら

うまく伝わりました

--no-ff のログです

幼児期おわりはどこですか？

幼児期おわりは ab4ec9c ですね

git merge --no-ff で明示的に commit が発生しているから

戻りやすいです
*   0b5c1f7 Merge branch 'youchien' 小学校入学
|\
| * 97e32e8 (youchien) 6歳
| * 0d14f30 5歳
| * c6e411e 4歳
|/
*   ab4ec9c Merge branch 'youjiki' 幼児期おわり
|\
| * 4c9ea5b (youjiki) 3歳
| * 5cc59f5 2歳
| * f8eeb21 1歳
|/
* cb68c3f 0歳
もし --ff だったら

線が分かれていないので

ちょっと迷いますよね？
* 716457a (HEAD -> master, youchien2) 6歳
* 6d0f305 5歳
* 25960d4 4歳
* becc580 (youjiki2) 3歳
* 39229cf 2歳
* d8cd3cc 1歳
* cb68c3f 0歳
参考

後輩にきちんと教えるために用語は下記を参考にしました。

git merge オプションの --ff, --no-ff, --ff-only の違い

fast-forward とは

non fast-forward とは

説明した状況は？

実は今日、本番公開だったのですが、わずか数分後に元に戻して欲しいと連絡があり、後輩があたふたしていたのでfast-fowardについて話しました。頻繁に巻き戻しが発生する私の用途では--no-ffの見通しのよさにメリットを感じていますと。うまく伝わったみたいで嬉しかったです。

　 Tweet
Qiitaで続きを読む

投稿日：2020-08-01T00:52:40+09:00

Gitで急いで戻したいならmerge --no-ffを使おう

実は今日、本番公開だったのですが、わずか数分後に元に戻して欲しいと連絡がありました。後輩があたふたしていたのでfast-fowardについて話しました。頻繁に巻き戻しが発生する私の用途では--no-ffの見通しのよさにメリットを感じていますと。

彼女はアニメが好きみたいなので、次のような例え話をしました。

ちがう世界線に移動するために

これまでの成長記録を見てみましょう。
今あなたは12歳で、小学校を卒業したところですね。
% git log --oneline --graph
*   9a90c76 (HEAD -> master) Merge branch 'shougakusei' 小学校卒業
|\
| * e7a18f5 (shougakusei) 12歳
| * 5a3cffa 11歳
| * 7695898 10歳
| * 2caab1a 9歳
| * 88b10ad 8歳
| * 62f3fb6 7歳
|/
*   0b5c1f7 Merge branch 'youchien' 小学校入学
|\
| * 97e32e8 (youchien) 6歳
| * 0d14f30 5歳
| * c6e411e 4歳
|/
*   ab4ec9c Merge branch 'youjiki' 幼児期おわり
|\
| * 4c9ea5b (youjiki) 3歳
| * 5cc59f5 2歳
| * f8eeb21 1歳
|/
* cb68c3f 0歳
戻れるなら何歳に戻りたいですか？

私は幼稚園からやり直したいですね。
そんな時のために git merge は --no-ff をお勧めします。

まずは幼児期の終わりです。
% git log --oneline --graph
* 4c9ea5b (HEAD -> youjiki) 3歳
* 5cc59f5 2歳
* f8eeb21 1歳
* cb68c3f (master) 0歳
次は幼稚園に通いますよ。しっかり --no-ff で入園してくださいね。
% git merge --no-ff youjiki
すると、線が２つに分かれました。
これなら幼稚園にいつ入学したのか、後から見ても、ぱっと見て分かります。
そう私が戻りたいのはここですよ。
% git log --oneline --graph
*   ab4ec9c (HEAD -> master) Merge branch 'youjiki' 幼児期おわり
|\
| * 4c9ea5b (youjiki) 3歳
| * 5cc59f5 2歳
| * f8eeb21 1歳
|/
* cb68c3f 0歳
いよいよ戻ります

すこし時が過ぎ６歳になっています。
% git log --oneline --graph
* 97e32e8 (HEAD -> youchien) 6歳
* 0d14f30 5歳
* c6e411e 4歳
*   ab4ec9c (master) Merge branch 'youjiki' 幼児期おわり
|\
| * 4c9ea5b (youjiki) 3歳
| * 5cc59f5 2歳
| * f8eeb21 1歳
|/
* cb68c3f 0歳
では、そろそろ目的の幼稚園入学に戻りましょうか
% git reset --hard ab4ec9c
はい、戻れましたよ。これで幼稚園入園からやり直せます。
--no-ff のおかげでしっかりと３歳の終わりへ戻ることができました。
% git log --oneline --graph
*   ab4ec9c (HEAD -> master) Merge branch 'youjiki' 幼児期おわり
|\
| * 4c9ea5b (youjiki) 3歳
| * 5cc59f5 2歳
| * f8eeb21 1歳
|/
* cb68c3f 0歳
こんどは --ff で成長してみましょう

戻ったところから６歳まで育てておきました。
また卒園と小学校入学です。
% git log --oneline --graph
* 2809494 (HEAD -> youchien2) 6歳
* 9d0399a 5歳
* ba2c75f 4歳
*   ab4ec9c (master) Merge branch 'youjiki' 幼児期おわり
|\
| * 4c9ea5b (youjiki) 3歳
| * 5cc59f5 2歳
| * f8eeb21 1歳
|/
* cb68c3f 0歳
今回は --ff で入学します
% git merge --ff youchien2
Updating ab4ec9c..2809494
Fast-forward
すると、さっきまであった線が消えてしまいました。
区切りがはっきりしなくなるので、--ff よりも --no-ff がオススメです。
% git log --oneline --graph
* 2809494 (HEAD -> master, youchien2) 6歳
* 9d0399a 5歳
* ba2c75f 4歳
*   ab4ec9c Merge branch 'youjiki' 幼児期おわり
|\
| * 4c9ea5b (youjiki) 3歳
| * 5cc59f5 2歳
| * f8eeb21 1歳
|/
* cb68c3f 0歳
けして過去を振り返らないのであれば、余計なコミットが発生しない --ff で問題ありません。
git merge --ff youchien2
そして安心してください。
どちらを選んでもgitで管理されていれば、手間が違うだけで、必ず戻れます。

参考

後輩にきちんと教えるために用語は下記を参考にしました。

git merge オプションの --ff, --no-ff, --ff-only の違い

fast-forward とは

non fast-forward とは

　 Tweet
Qiitaで続きを読む

投稿日：2020-08-01T00:52:40+09:00

Gitで急いで戻したいならmerge --no-ffを使う

git merge --no-ff のメリットを伝えるのに

実案件のログは使いづらいので

年齢の commit graph を作ったら

うまく伝わりました

--no-ff のログです

幼児期おわりはどこですか？

幼児期おわりは ab4ec9c ですね

git merge --no-ff で明示的に commit が発生しているから

戻りやすいです
*   0b5c1f7 Merge branch 'youchien' 小学校入学
|\
| * 97e32e8 (youchien) 6歳
| * 0d14f30 5歳
| * c6e411e 4歳
|/
*   ab4ec9c Merge branch 'youjiki' 幼児期おわり
|\
| * 4c9ea5b (youjiki) 3歳
| * 5cc59f5 2歳
| * f8eeb21 1歳
|/
* cb68c3f 0歳
もし --ff だったら

線が分かれていないので

すっごい迷いますよね？
* 716457a (HEAD -> master, youchien2) 6歳
* 6d0f305 5歳
* 25960d4 4歳
* becc580 (youjiki2) 3歳
* 39229cf 2歳
* d8cd3cc 1歳
* cb68c3f 0歳
どういう状況？

実は今日、本番公開だったのですが、わずか数分後に元に戻して欲しいと連絡があり、後輩があたふたしていたのでfast-fowardについて話しました。頻繁に巻き戻しが発生する私の用途では--no-ffの見通しのよさにメリットを感じていますと。うまく伝わったみたいで嬉しかったです。

参考

後輩にきちんと教えるために用語は下記を参考にしました。

git merge オプションの --ff, --no-ff, --ff-only の違い

fast-forward とは

non fast-forward とは

追記

毎回 commit graph を作成するのが大変だったので、スクリプト化しました。
年齢の commit graph 作成スクリプト（git merge --no-ff の説明用）をご確認ください。

　 Tweet
Qiitaで続きを読む

投稿日：2020-08-01T00:52:40+09:00

後輩に「Gitで急いで戻したいならmerge --no-ffを使おう」と教えました

git merge --no-ff のメリットを伝えるのに

実案件のログは使いづらいので

年齢の commit graph 作ったら

うまくいきましたという話です ## 戻れるなら何歳に戻りたいですか？私は幼稚園入園からやり直したいですね。そんな時のために git merge は --no-ff をお勧めします。

まずは幼児期を終わりましょう。
% git log --oneline --graph
* 4c9ea5b (HEAD -> youjiki) 3歳
* 5cc59f5 2歳
* f8eeb21 1歳
* cb68c3f (master) 0歳
次は幼稚園に通いますよ。しっかり --no-ff で入園してくださいね。
% git merge --no-ff youjiki
すると、線が２つに分かれました。
これなら幼稚園にいつ入学したのか、後から見ても、ぱっと見て分かります。
そう私が戻りたいのはここですよ。
% git log --oneline --graph
*   ab4ec9c (HEAD -> master) Merge branch 'youjiki' 幼児期おわり
|\
| * 4c9ea5b (youjiki) 3歳
| * 5cc59f5 2歳
| * f8eeb21 1歳
|/
* cb68c3f 0歳
いよいよ戻ります

すこし時が過ぎ６歳になっています。
% git log --oneline --graph
* 97e32e8 (HEAD -> youchien) 6歳
* 0d14f30 5歳
* c6e411e 4歳
*   ab4ec9c (master) Merge branch 'youjiki' 幼児期おわり
|\
| * 4c9ea5b (youjiki) 3歳
| * 5cc59f5 2歳
| * f8eeb21 1歳
|/
* cb68c3f 0歳
では、そろそろ目的の幼稚園入学に戻りましょうか
% git reset --hard ab4ec9c
はい、戻れましたよ。これで幼稚園入園からやり直せます。
--no-ff のおかげでしっかりと３歳の終わりへ戻ることができました。
% git log --oneline --graph
*   ab4ec9c (HEAD -> master) Merge branch 'youjiki' 幼児期おわり
|\
| * 4c9ea5b (youjiki) 3歳
| * 5cc59f5 2歳
| * f8eeb21 1歳
|/
* cb68c3f 0歳
こんどは --ff で成長してみましょう

戻ったところから６歳まで育てておきました。
また卒園と小学校入学です。
% git log --oneline --graph
* 2809494 (HEAD -> youchien2) 6歳
* 9d0399a 5歳
* ba2c75f 4歳
*   ab4ec9c (master) Merge branch 'youjiki' 幼児期おわり
|\
| * 4c9ea5b (youjiki) 3歳
| * 5cc59f5 2歳
| * f8eeb21 1歳
|/
* cb68c3f 0歳
今回は --ff で入学します
% git merge --ff youchien2
Updating ab4ec9c..2809494
Fast-forward
すると、さっきまであった線が消えてしまいました。
区切りがはっきりしなくなるので、--ff よりも --no-ff がオススメです。
% git log --oneline --graph
* 2809494 (HEAD -> master, youchien2) 6歳
* 9d0399a 5歳
* ba2c75f 4歳
*   ab4ec9c Merge branch 'youjiki' 幼児期おわり
|\
| * 4c9ea5b (youjiki) 3歳
| * 5cc59f5 2歳
| * f8eeb21 1歳
|/
* cb68c3f 0歳
けして過去を振り返らないのであれば、余計なコミットが発生しない --ff で問題ありません。
git merge --ff youchien2
そして安心してください。
どちらを選んでもgitで管理されていれば、手間が違うだけで、必ず戻れます。

実は今日、本番公開だったのですが、わずか数分後に元に戻して欲しいと連絡がありました。後輩があたふたしていたのでfast-fowardについて話しました。頻繁に巻き戻しが発生する私の用途では--no-ffの見通しのよさにメリットを感じていますと。うまく伝わったみたいで嬉しかったです。

コミットの全体像です

成長記録にしてみました。
% git log --oneline --graph
*   0b5c1f7 Merge branch 'youchien' 小学校入学
|\
| * 97e32e8 (youchien) 6歳
| * 0d14f30 5歳
| * c6e411e 4歳
|/
*   ab4ec9c Merge branch 'youjiki' 幼児期おわり
|\
| * 4c9ea5b (youjiki) 3歳
| * 5cc59f5 2歳
| * f8eeb21 1歳
|/
* cb68c3f 0歳
参考

後輩にきちんと教えるために用語は下記を参考にしました。

git merge オプションの --ff, --no-ff, --ff-only の違い

fast-forward とは

non fast-forward とは

　 Tweet
Qiitaで続きを読む