はじめに

ここで言うskeletonリポジトリとは、何かのプロジェクトを始めるときに、定型的に必要なディレクトリやスクリプト、テンプレートの類いを格納したリポジトリです。GitHub上でもskeletonで検索するとたくさん見つかります。

こういったリポジトリを使う際は、最初にcloneしてoriginを自分のリポジトリに書き換えたり、あるいは単にファイルコピーしたりすると思いますが、元のskeletonリポジトリの更新に追従するのは結構厄介な問題です。
gitの機能を使うならpull先を変えたりcherry-pickで変更を取り込むことは可能ですが、簡単にできるという感じでもありません。

そこで外部のskeletonリポジトリを簡単に取り込めるgitのサブコマンドを作りました。
実装言語はRustです。

https://github.com/dalance/git-skel/

インストール

Linux/macOS/Windows向けのバイナリはReleasesからダウンロードするか、
Rustがインストール済みでcargoコマンドが使える方は以下でインストールできます。

$ cargo install git-skel

使い方

ディレクトリ作成、gitリポジトリ作成、skeleton適用して最後に適用前に状態の戻すまでの流れをデモ画像にしてみました。

基本的なフロー

skeletonリポジトリ(http://example.com/skeleton.git)をプロジェクトリポジトリ(http://example.com/project.git)に適用する場合を例に説明します。

初回は適用したいリポジトリにてgit skel initを実行します。

$ git clone http://example.com/project.git
$ cd project
$ git skel init http://example.com/skeleton.git

すると、skeletonリポジトリの内容がプロジェクトリポジトリのリポジトリルートに展開されます。
また、そのURLとその時のリビジョンを.gitskel.tomlに書き込みます。
展開結果に問題なければ展開されたファイルを追加してコミットしてください。

skeletonリポジトリに更新があった場合は

$ cd project
$ git skel update

で取り込めます。
これもgit diffなどで確認して問題なければコミットです。

このようにgit-skelはファイル操作しかしないので、実際にコミットする、しないはユーザー判断になっています。
また、ファイル操作の結果、何かが失われる可能性がある場合はデフォルトではなにもしません。
例えば、あるファイルが変更されて未コミットのとき、そのファイルをgit-skelコマンドが上書きしそうなら、上書きせずに中断します。オプション（--force）で強制も可能です。

.gitskelignore

このコマンドの対象にしたくないファイルは.gitskelignoreで指定することができます。フォーマットは.gitignoreと同じです。

このファイルはskeletonリポジトリとプロジェクトリポジトリの両方に置くことができます。
skeletonリポジトリに置く場合は、例えばREADME.mdやLICENSEなどskeletonリポジトリそのものについてのファイルや、説明用のサンプルファイルなどを指定するといいと思います。
プロジェクトリポジトリに置く場合は、そのプロジェクト用にカスタマイズしたファイルを指定することで、更新による上書きを防ぐことができます。

branch/tag

skeletonリポジトリの特定のブランチやタグに追従するよう設定することもできます。

$ cd project
$ git skel branch branch1
$ git skel tag tag1

git skel branchやgit skel tagコマンドを実行すると、そのブランチ・タグの内容を取り込んで.gitskel.tomlを更新します。

また、それ以降git skel updateを実行した場合、追従するよう設定したブランチ・タグの最新に追従します。

クリーンアップ

プロジェクトリポジトリからskeletonリポジトリの内容を取り除きたい場合はgit skel cleanが使えます。

$ cd project
$ git skel clean

これでプロジェクトリポジトリに展開されたskeletonリポジトリの内容を全て削除したうえで.gitskel.tomlも削除します。

.bash_profile

環境変数を書くところ
export AWS_SECRET_ACCESS_KEY='ここにCSVファイルに乗っている値をコピー'

seacrets.yml

環境変数、つまり.bash_profileとかに書いたものを読み込む記述を書く
aws_access_key_id: <%= ENV["AWS_ACCESS_KEY_ID"] %>

.gitignore

github等のリモートリポジトリに送りたくないファイルを書く

APIキー等の秘匿情報をcredentials.ymlで管理する方法

githubにpushしたくない情報はcredentials.yml.encで管理する。
参考：https://qiita.com/NaokiIshimura/items/2a179f2ab910992c4d39

1.cledentials.ymlを編集する

#エディタ設定済みの場合
$rails credentials:edit
#エディタ未設定の場合
$EDITOR="vi" bin/rails credentials:edit

※.bash_profileなどに環境変数：EDITORを指定しておけば、EDITOR="xxx"の指定は不要になります。

2.master_keyを設定する。
.master_keyとは、credentials.yml.encを復号化するためのもの。
.master_keyを知っている人じゃないとcredentials.ymlの内容が読めない仕組み。

デフォルトのmaster keyの値はconfig/master.keyに記載されている。
/config/master.keyが存在しない状態でrails credentials:editコマンドを実行した場合、/config/master.keyが生成される。

ローカル環境ではconfig/.master_keyに存在。

自分のローカル環境以外,例えば本番環境やgitリポジトリからpullしたcredentials.ymlを復号するには?

~/.bash_profileに定義する。

#.bash_profile
RAILS_MASTER_KEY="*********************"

gitの勉強していて一番面倒というかつまづいたのがコンフリクト処理だったのでメモをここに

2019/04/18
すみません少しミスがありました．
最初ブランチ作ってマスターと同じものを作った後に
マスター側でファイルの中身を変更し，その後ブランチ側を変更しました．
それでコンフリクトさせることができます

もともとあるマスターからtest2というブランチを作ります

↓マスター

test.py

#coding:utf-8
print "hello"

####at branch2---->change at master####

ブランチを作る

$ git branch test2

$ git checkout test2

test2のファイルを編集します

test2↓の"change at master"の部分を"change at test2"に変更

test.py

#coding:utf-8
print "hello"

####at branch2---->change at test2####

$ git add .

$ git commit -m "first"

masterをtest2へマージします

$ git merge master

Auto-merging test.py
CONFLICT (content): Merge conflict in test.py
Automatic merge failed; fix conflicts and then commit the result.

同じ箇所を編集しているのでこのようににコンフリクトが生じます

とりあえずどこが変わったのかみてみましょう

$ git diff

@@@ -1,4 -1,4 +1,8 @@@
  #coding:utf-8
  print "hello"

++<<<<<<< HEAD
 +####at branch2----->change at test2###
++=======
+ ####at branch2---->change at master###
++>>>>>>> master

change at master なのか　change at test2 なのかgit（機械)には判断し兼ねるので
そこを人間がみてどうするべきなのか判断する必要があるわけです

test2におけるtest.pyを開いてみます

$ vi test.py

開くと

++<<<<<<< HEAD
 +####at branch2----->change at test2###
++=======
+ ####at branch2---->change at master###
++>>>>>>> master

のような場所があるのでそこを自分で判断して編集します

今回は

####at branch2---->change at master###change at test2###

としてみました

編集したら

$ git add .

$ git commit -m "merged"

[test2 e4859ef] merged

コミットした瞬間，マージされたと応答がありました

ちなみに本当にマージされたかみてみましょう

$ git merge master

Already up to date.

よかった！すでに最新状態（マージ済み）だとのことです！

こんなかんじでコンフリクトを解決できます

何が言いたいかっていうと，
多人数で行う開発の場合，ほとんどがこのようなマニュアルによるマージ
になると思います

dev.toで凄く人気があった記事、英語の練習(日本語も)も重ねて翻訳しました。
自分のGitの再勉強にもなりました。
「嫁」という登場人物は翻訳する際に、脳内の声をそのまま書いたものです。

[元の記事]
Zaisteさん
https://dev.to/zaiste/15-git-commands-you-may-not-know-4a8j

本文＆訳文

Using Git may be intimidating at times. There are so many commands and details to learn. The documentation, however, while being immense, is still greatly accessible. Once you overcome the initial feeling of being overwhelmed, the things will start to fall into place.

Gitは大量のコマンドと内容があり、初心者にとって凄く戸惑いますね。
(嫁： 日本のCM風の欧米人の喋り方か)
莫大なドキュメンテーションがありますが、また見やすいほうです。
あなたが圧倒されているという初期の感覚を克服すると、やっと落ち着いて開始できるね。
(嫁： Google翻訳か？)

Here is a list of 15 Git commands that you may not know yet, but hopefully they will help you out on a journey to master this tool.

このリストにある15個Gitのコマンド、あなたがまた知らないかもしれない。
あなたがGitをマスターするの道に、お力になれるといい
(嫁： この翻訳ほんとうに雑！)

1. 直近のコミットを修正

git commit --amend

—-amend allows to append staged changes (e.g. to add a forgotten file) to the previous commit. Adding —-no-edit on top of that will amend the last commit without changing its commit message. If there are no changes, -—amend will allow you to reword the last commit message.

--amendを使うと、stageにあるファイルを前回のコミットに追加できる(例：追加漏れのファイル)。
さらに、--no-editを追記すると、メッセージを変更しないまま、そのままコミットを上書きできます。
もし特に変更点がなければ、--amendを使うと前回のメッセージを編集できます。
(嫁： ほぼお前の自分の言葉やん！)

2. 会話型 部分選択式 変更追加

git add -p

-p (or —patch) allows to interactively select parts of each tracked file to commit. This way each commit contains only related changes.

-pを付けると、会話式でファイルの中の一部選択しながら、コミットすることができます。
これを使うと、関連があるのものだけ一つのコミットにまとめることができます。
(嫁： ふ〜ん)

3. 会話型 部分選択式 変更Stash

git stash -p

Similar to git-add , you can use --patch option to interactively select parts of each tracked file to stash.

上のgit addに似ているが、 --patchオプション(役者注：--patchを略すと-pになる)を付けると、会話式でファイルの中の一部選択しながら、stashすることができます。
(嫁： 自分の注釈勝手に追加するな！)

4. untrackedファイルをstashする (嫁： ほぼ翻訳しないやいやんかい！)

git stash -u

By default, when stashing, the untracked files are not included. In order to change that behaviour and include those files as well you need to use -u parameter. There is also -a (—all) which stashes both untracked and ignored files altogether, which is probably something you usually won’t need.

stashする際に、デフォルトは追跡しなていないファイル(新規作成したファイル)は含まれていないです。
これら新規ファイル変更するを含むために、 -uオプションを付けないといけないです。
または-a (-all)を付けると、全てのファイル（新規作成したファイルやignoredしたファイル）を含むことになります。
必要がないファイルも含めてしまう可能性があります。

5. 会話型 部分選択式 Checkout

git checkout -p

--patch can be also used to selectively discard parts of each tracked file. I aliased this command as git discard

--patchオプションは会話型部分選択式Checkoutに使うこともできます、私はgit discardのaliasは上記のコマンドを設定しました。
（嫁：会話型 部分選択式 なんとかをやめてくれへん？）

6. 前回のブランチに切り替える

git checkout -

This command allows you to quickly switch to the previously checked out branch. On a general note - is an alias for the previous branch. It can be used with other commands as well. I aliased checkout to co so, it becomes just git co -

このコマンドを使うと、素早に前回のブランチに切り替えることができます。
公式のノートによる、「-」は前回のブランチのaliasなので、ほかのコマンドと組み合わせもできます。私は「checkout」を「co」にaliasにしました、つまり、「git co -」　
（嫁： 前回のブランチにチェックアウトはこれだけ git co -,　簡単♪）

7. 現在の全ての変更を取り消し

git checkout .

If you are sure that all of your local changes can be discarded, you can use . to do it at once. It is, however, a good practice to always use checkout --patch.

もし現在のローカル変更点は全てが要らないを確認したら、「.」を使って一気に取り消しできる。
でも、やっぱりcheckout --patchを使っていい習慣を身に付けましょう。
(嫁：checkoutしたら、変更が消えるから慎重に！！！！！！)

8. 変更点の表示

git diff --staged

This command shows all staged changes (those added to the index) in contrast to just git diff which only shows changes in the working directory (without those in the index).

このコマンドはstagedに上がっている全ての変更をdiff表示できます。git diffだけの場合はworking directoryのファイルのみdiff表示と区別できますね。
(嫁：staged -> git add のあとのファイルのこと、 working directory -> 変更したファイルのこと)

9. ローカルブランチ名変更

git branch -m old-name new-name

If you want to rename the currently checked out branch, you can shorten this command to the following form:

もし現在のブランチ名を変更したいなら、コマンドを省略して使えます。
(嫁：old-nameを入力しなくていいよね)

git branch -m new-name

10. リモートブランチ名変更

git push origin :old-name
git push origin new-name

In order to rename a branch remotely, once you renamed your branch locally, you need to first remove that branch remotely and then push the renamed branch again.

リモートのブランチを変更するときの順番があります。まずローカルのブランチ名を変更し、その後、リモートのブランチを削除し、最後、名前を変更したブランチ再度pushする。
(嫁：「、」が多すぎない？)

11. すべてのコンフォートファイルを開ける

git diff --name-only --diff-filter=U | uniq  | xargs $EDITOR

Rebasing may lead to conflicts, the following command will open all files which need your help to resolve these conflicts.

Rebaseする際にはコンフォートが発生しますね、このコマンドは全てのコンフォートファイルを修正する際に使うといい。

12. あれ？なにを変更したっけ？

git whatchanged --since='2 weeks ago' 

This command will show a log with changes introduced by each commit from the last two weeks.

2週間前の変更した内容を教えてくれる。

13.前回のコミットからファイルを取り消し

git rm —-cached <file-to-remove>
git commit —-amend

Let's say you committed a file by mistake. You can quickly remove that file from the last commit by combining rm and commit --amend commands:

間違いたファイルをコミットしたとき、この二つコマンドを組み合わせると、該当ファイルを前回のコミットから取り除くことができます。

14.ブランチ検索

git branch --contains <commit>

This command will show all branches that contain a particular commit.

指定したコミットを含めるブランチの一覧を表示できる。

15. ローカルリポジトリ軽量化

git gc --prune=now --aggressive

嫁：このコマンドについての説明は特にないね、調べたらちょっと危ないコマンドですね。
リポジトリが壊れるかもしれない...あんまり初心者にはおすすめしないです。
https://qiita.com/kaneshin/items/0d19fc1cd86f931dc855

Bonus

Although I like CLI a lot, I highly recommend checking Magit to further step up your Git game. It is one of best pieces of software I used.
There is, also, a fantastic overview of recommended Git workflows available via help command. Be sure to read it thoroughly!

私はcliは好きだが、Magitを使うと強くおすすめします。今まで使った一番いいソフトウェアです。
最後に、とても素敵なhelpコマンドGit workflowsについての説明もあります。ぜひ読んでみてください。

git help workflows

dev.toで凄く人気があった記事、英語の練習(日本語も)も重ねて翻訳しました。
自分のGitの再勉強にもなりました。
「嫁」という登場人物は翻訳する際に、脳内の声をそのまま書いたものです。

[元の記事]
https://dev.to/zaiste/15-git-commands-you-may-not-know-4a8j

本文＆訳文

Using Git may be intimidating at times. There are so many commands and details to learn. The documentation, however, while being immense, is still greatly accessible. Once you overcome the initial feeling of being overwhelmed, the things will start to fall into place.

Gitは大量のコマンドと内容があり、初心者にとって凄く戸惑いますね。
(嫁： 日本のCM風の欧米人の喋り方か)
莫大なドキュメンテーションがありますが、また見やすいほうです。
あなたが圧倒されているという初期の感覚を克服すると、やっと落ち着いて開始できるね。
(嫁： Google翻訳か？)

Here is a list of 15 Git commands that you may not know yet, but hopefully they will help you out on a journey to master this tool.

このリストにある15個Gitのコマンド、あなたがまた知らないかもしれない。
あなたがGitをマスターするの道に、お力になれるといい
(嫁： この翻訳ほんとうに雑！)

1. 直近のコミットを修正

git commit --amend

—-amend allows to append staged changes (e.g. to add a forgotten file) to the previous commit. Adding —-no-edit on top of that will amend the last commit without changing its commit message. If there are no changes, -—amend will allow you to reword the last commit message.

--amendを使うと、stageにあるファイルを前回のコミットに追加できる(例：追加漏れのファイル)。
さらに、--no-editを追記すると、メッセージを変更しないまま、そのままコミットを上書きできます。
もし特に変更点がなければ、--amendを使うと前回のメッセージを編集できます。
(嫁： ほぼお前の自分の言葉やん！)

2. 会話型 部分選択式 変更追加

git add -p

-p (or —patch) allows to interactively select parts of each tracked file to commit. This way each commit contains only related changes.

-pを付けると、会話式でファイルの中の一部選択しながら、コミットすることができます。
これを使うと、関連があるのものだけ一つのコミットにまとめることができます。
(嫁： ふ〜ん)

3. 会話型 部分選択式 変更Stash

git stash -p

Similar to git-add , you can use --patch option to interactively select parts of each tracked file to stash.

上のgit addに似ているが、 --patchオプション(役者注：--patchを略すと-pになる)を付けると、会話式でファイルの中の一部選択しながら、stashすることができます。
(嫁： 自分の注釈勝手に追加するな！)

4. untrackedファイルをstashする (嫁： ほぼ翻訳しないやいやんかい！)

git stash -u

By default, when stashing, the untracked files are not included. In order to change that behaviour and include those files as well you need to use -u parameter. There is also -a (—all) which stashes both untracked and ignored files altogether, which is probably something you usually won’t need.

stashする際に、デフォルトは追跡しなていないファイル(新規作成したファイル)は含まれていないです。
これら新規ファイル変更するを含むために、 -uオプションを付けないといけないです。
または-a (-all)を付けると、全てのファイル（新規作成したファイルやignoredしたファイル）を含むことになります。
必要がないファイルも含めてしまう可能性があります。

5. 会話型 部分選択式 Checkout

git checkout -p

--patch can be also used to selectively discard parts of each tracked file. I aliased this command as git discard

--patchオプションは会話型部分選択式Checkoutに使うこともできます、私はgit discardのaliasは上記のコマンドを設定しました。
（嫁：会話型 部分選択式 なんとかをやめてくれへん？）

6. 前回のブランチに切り替える

git checkout -

This command allows you to quickly switch to the previously checked out branch. On a general note - is an alias for the previous branch. It can be used with other commands as well. I aliased checkout to co so, it becomes just git co -

このコマンドを使うと、素早に前回のブランチに切り替えることができます。
公式のノートによる、「-」は前回のブランチのaliasなので、ほかのコマンドと組み合わせもできます。私は「checkout」を「co」にaliasにしました、つまり、「git co -」　
（嫁： 前回のブランチにチェックアウトはこれだけ git co -,　簡単♪）

7. 現在の全ての変更を取り消し

git checkout .

If you are sure that all of your local changes can be discarded, you can use . to do it at once. It is, however, a good practice to always use checkout --patch.

もし現在のローカル変更点は全てが要らないを確認したら、「.」を使って一気に取り消しできる。
でも、やっぱりcheckout --patchを使っていい習慣を身に付けましょう。
(嫁：checkoutしたら、変更が消えるから慎重に！！！！！！)

8. 変更点の表示

git diff --staged

This command shows all staged changes (those added to the index) in contrast to just git diff which only shows changes in the working directory (without those in the index).

このコマンドはstagedに上がっている全ての変更をdiff表示できます。git diffだけの場合はworking directoryのファイルのみdiff表示と区別できますね。
(嫁：staged -> git add のあとのファイルのこと、 working directory -> 変更したファイルのこと)

9. ローカルブランチ名変更

git branch -m old-name new-name

If you want to rename the currently checked out branch, you can shorten this command to the following form:

もし現在のブランチ名を変更したいなら、コマンドを省略して使えます。
(嫁：old-nameを入力しなくていいよね)

git branch -m new-name

10. リモートブランチ名変更

git push origin :old-name
git push origin new-name

In order to rename a branch remotely, once you renamed your branch locally, you need to first remove that branch remotely and then push the renamed branch again.

リモートのブランチを変更するときの順番があります。まずローカルのブランチ名を変更し、その後、リモートのブランチを削除し、最後、名前を変更したブランチ再度pushする。
(嫁：「、」が多すぎない？)

11. すべてのコンフォートファイルを開ける

git diff --name-only --diff-filter=U | uniq  | xargs $EDITOR

Rebasing may lead to conflicts, the following command will open all files which need your help to resolve these conflicts.

Rebaseする際にはコンフォートが発生しますね、このコマンドは全てのコンフォートファイルを修正する際に使うといい。

12. あれ？なにを変更したっけ？

git whatchanged --since='2 weeks ago' 

This command will show a log with changes introduced by each commit from the last two weeks.

2週間前の変更した内容を教えてくれる。

13.前回のコミットからファイルを取り消し

git rm —-cached <file-to-remove>
git commit —-amend

Let's say you committed a file by mistake. You can quickly remove that file from the last commit by combining rm and commit --amend commands:

間違いたファイルをコミットしたとき、この二つコマンドを組み合わせると、該当ファイルを前回のコミットから取り除くことができます。

14.ブランチ検索

git branch --contains <commit>

This command will show all branches that contain a particular commit.

指定したコミットを含めるブランチの一覧を表示できる。

15. ローカルリポジトリ軽量化

git gc --prune=now --aggressive

嫁：このコマンドについての説明は特にないね、調べたらちょっと危ないコマンドですね。
リポジトリが壊れるかもしれない...あんまり初心者にはおすすめしないです。
https://qiita.com/kaneshin/items/0d19fc1cd86f931dc855

最後に

Although I like CLI a lot, I highly recommend checking Magit to further step up your Git game. It is one of best pieces of software I used.
There is, also, a fantastic overview of recommended Git workflows available via help command. Be sure to read it thoroughly!

私はcliは好きだが、Magitを使うと強くおすすめします。今まで使った一番いいソフトウェアです。
最後に、とても素敵なhelpコマンドGit workflowsについての説明もあります。ぜひ読んでみてください。

git help workflows

コミット一覧を表示

git ls-remote origin

一覧の番号やハッシュから内容を確認
https://git.dmm.com/{アカウント名}/{アプリ名}/pull/{番号}
https://git.dmm.com/{アカウント名}/{アプリ名}/commit/{ハッシュ}
コミット内容を見ながら
どのコミットに戻すか決める

戻し

git reset --hard xxxxx

push

git push origin master

エラーになる

error: failed to push some refs to 'xxxxxxx'
hint: Updates were rejected because the tip of your current branch is behind

マージされてないコミットがあるよエラーなのでpullしてマージしてからpushすればOK

自分用メモ

/app/build.gradle

//commit hash 取得
def getCommitHasH() {
    def process = "git rev-parse --short HEAD".execute()
    process.waitFor()
    (process.exitValue() == 0) ? process.text.trim() : ""
}

android {
    defaultConfig {
        // BuildConfig へ埋め込み
        buildConfigField("String", "COMMIT_HASH", "\"" + getCommitHasH() + "\"")
    }
}

kotlinで表示制御する場合
HogeActivity.kt

//debugビルドなら表示する
if(BuildConfig.DEBUG){
  commitHashText.text = BuildConfig.COMMIT_HASH
  commitHashText.visibility = View.VISIBLE
}else{
  commitHashText.visibility = View.GONE
}

layoutxmlで表示制御する場合

<!-- import BuildConfig -->
<data>
    <import type="com.hoge.BuildConfig"/>
</data>

<!-- Data binding -->
<TextView
    tools:text="@{BuildConfig.COMMIT_HASH}"
    android:visibility="@{BuildConfig.DEBUG ? View.VISIBLE : View.GONE}"
/>

ref
- https://gist.github.com/kappa-lab/fd8650dfcc2f780055255fa982e82473
- https://qiita.com/kawachi/items/d97c448b013c37f2f198

git conflictに向けて事前に準備しよう

gitの同じブランチ上で複数人が同じ箇所を同時に編集してしまいcommitした際に起きるconflict
ちなみにgitに慣れてないと自分自身でconflictを起こす場合もあります

ちなみにボクは全然やってました

初心者だとconflictが起きると３時間とか5時間とか平気でかかっちゃうので早めに対策だけでも控えとくといいかもしれないですね

ちなみにボクは1回のconflictで5時間以上平気でかかってましたwww

開発現場でやると本当に笑えないですはいw

conflictが起きたら次の順番で解決していきます

▼直前のcommitの打ち消し

$ git reset -- soft HEAD^

▼addの打ち消し

$ git reset ファイル名

▼自分の書いたコードを異次元に保存

$ git stash save

▼最終的にpushしたいコードを保存したので、branchを強制的に切り替える

$ git checkout -f master   //branch => master

▼pullする

$ git pull origin master  //master

▼さっきのbranchに戻る

$ git checkout branch     //master => branch

▼最新masterのコードをbranchにrebase

$ git rebase master

▼保存しておいたコードを反映させる

$ git stash pop

▼add

$ git add -u         //変更ファイルのみadd

▼commit

$ git commit -m "任意のコメント"

▼push

$ git push origin ブランチ名

最後に

webエンジニアだとconflictは避けては通れない道です
はじめのうちはどれだけconflictを起こさないか
ではなくいかにconflictに強くなるかを意識して勉強、または開発する事をおすすめします

ファイト！！！