プログラミング勉強日記

　2020年5月27日　Progate Lv.54

Gitでaddしようとするときのエラー処理

$ git add stylesheet.css
warning: LF will be replaced by CRLF in page3/stylesheet.css.
The file will have its original line endings in your working directory

　Gitでファイルを共有するためにaddすると、上記のよううな警告がでてきた。これを無視してもGithubで登録することはできるが、コードの中に変な文字列が挿入されてしまう。これはGitの設定で改行コードを変更しようとしている。

$ git config --global core.autoCRLF false

　上記のような処理を行うことで改行コードの変更が行われず、変な文字列も挿入されない。

作ったもの

下記にソース置いてます。
https://github.com/ktkn304/githooks

できること

全てのgitリポジトリに共通のgit hooksを提供する。
リポジトリ個別のgit hooksも実行する(huskyにて作られたgit hookも実行できる)。
※ これらの動作を実現するためにグローバルなgitの設定(core.hooksPath)を書き換えているので注意

使い方

# 任意のディレクトリにcloneする
$ git clone https://github.com/ktkn304/githooks.git

$ cd githooks

# インストールスクリプトを実行する
# これにより、以下が実行される
# 1. 下記のディレクトリ・ファイル作成
# ./hooks/pre-commit # 各フックスクリプトを呼び出すシェルスクリプトが作成される
# ./custom-hooks/pre-commit/ # グローバルに適用したいフックスクリプトを配置するディレクトリ
# 2. gitの設定変更(core.hooksPathにリポジトリのhooksディレクトリを指定)
$ ./setup/install

あとは、全体に適用したいフックスクリプトは./custom-hooks/pre-commit/ディレクトリへ配置すればよい。
また、リポジトリ毎のフックスクリプトはリポジトリの.git/hooksディレクトリへ通常通り配置する(huskyもこちらへ配置してくれるので、特に気にしなくてもよい。lefthookはわからない・・・)。

pre-commit以外のフックについて

デフォルトではpre-commitのフックスクリプトしか実行しないようになっている。
./setup/hook-typesを編集し、./setup/installを実行することで任意のフックに対応できる。

例: commit-msgを有効にした場合

./setup/hook-types

# applypatch-msg
commit-msg
# fsmonitor-watchman
# post-update
# pre-applypatch
pre-commit
# pre-merge-commit
# prepare-commit-msg
# pre-push
# pre-rebase
# pre-receive
# update

上記のように変更後、./setup/installを実行する

はじめに

この記事では
バージョン管理システムのGitを
職場で使うことを想定して
Gitの使い方についてまとめた記事です。

ベストプラクティスや間違いがあれば
それなりに良い方法で書き直していきます。

---

ベテランでもGitが扱えるとは限らないらしい

とある人に聞いたところによると
デキる技術者でも案外、
変更履歴のステージングやアド、コミットができないということらしい。
筆者は去年ぐらいからGitをプライベートで使い始めた一般の誤家庭の人

今度、新人君が配属されるということなので
彼にはちゃんと基本コマンドを覚えてもらいたいというオモイと
ちゃんとコードレビューできる体制と育てる環境を確立するという目標がある。

そうしたオモイや目標を実現させるためにGitの基本コマンドについてまとめてみました。
実際に職場に導入してもいないので
いざ使ってみるとこれもあれも必要となるかもしれないけど
とりあえず基本はおさえようというスタンス。

---

想定される環境

客先常駐
リモートリポジトリ環境なし
GitHub使用不可
Windows10 Pro 64bit
Git 2.26.2.windows.1

---

想定される利用者

研修中のエンジニア（例えば、業務未経験者など）
初学者を教えるベテラン、中堅エンジニア

何を管理するか

ソースコード
たとえば
・TeraTermLanguage
・HTML
・JavaScript
・PHP

---

初期設定(git config)

GitHubは使わない（使えない）けど
これがないと誰が何をしたかわからないので
最初に確認しておく。
user.nameは
PCの端末名と自分の名前をローマ字で入れておけばOK

mailaddressは会社のメールアドレスか
個人あてのメールアドレスがないなら
所属しているグループのアドレスがいいだろう。

$ git config --global user.name [username]
$ git config --global [mailaddress]

---

最初に教えるべきコマンド

最初からブランチ切るのは難易度高いと思うので
手堅いところから教えていく

$ git init
$ git add -a
$ git status
$ git commit -am "命令系のコメント"

リポジトリの初期化は知っておかないと何事も始まらないだろう。

git add については -a と .(ドット)の違いについて
聞かれるかもしれないのであらかじめ考えておく

変更したかどうか知りたいこともあるだろう
そういうときのために
git statusコマンドを新人に叩き込んでおく

「先輩！どれ変更したかわかりません」と言われて対応するのは
正直なところ大変だ。
初回ならば何の問題もないかもしれないがことあるごとに
やられたら死ぬ。間違いなく死ぬ。

そして、最後にcommit
これもオプションについて聞かれるかもしれない。
ツッコミ用のアンサーを用意しておこう。

ここで大事なのがコメント付きのcommitかどうかである。
もちろん、commitからのリカバリー方法も大事だが
コメントが付いていないと
リカバリするときにいつまでのcommitに戻れば
いいかわからなくなる可能性がある。

---

最低限教えたら次にブランチをやらせてみよう

$ git checkout -b ブランチ名
$ git branch

ここもオプションについてry
-b オプションは新規にブランチを作成して切り替えるという意味
すでに作成されているブランチがある場合はエラーになる。

checkoutでブランチを切り替えたと錯覚して
作業を続けてしまうというポカ防止のために
必ず、git branchコマンドを叩いて
現在、自分が参照しているブランチを意識させよう。

ここまできたらあとは運用方法である。

---

新しくリポジトリをつくる場合

新人君に
リポジトリを作って
初期化して
アドして
コミットさせたい。
そして、ブランチの活用までやらせたい。
そう思っていろいろ考えましたが
Railsポートフォリオにある運用方法を踏襲させていただくことにしました。

最初のコミットメッセージは
なにが良いんだろうかと考えましたが
無難に「initial repository」として
２回目以降からは案件の管理番号というのが職場にあるので
それを入れてもらった形で体言止めで入力してもらう。

例えば、～機能の改修-XXXX みたいな感じ
ここは実際に使ってみて具体的に決めたほうが良さそう。

デデデ
masterブランチの修正は基本的に行わないものとして
新しくブランチを切ってから修正を加えて
チームかリーダーのレビュー後マージする形をとる。

レビューはどのようにして行うか
そのあたりのノウハウを集めないときつそうな感じがする。
おいおい、集めることとする（続

---

出力メッセージの英語翻訳

あと、英語読めない人が圧倒的に多いはずなので
これらも職場のどこかに貼っておいて覚えてもらおう。

単語	日本語
On branch master	親ブランチを参照しています
No commits yet	まだコミットされていません
Changes to be committed	コミットされる変更
Changes not staged for commit	変更がステージングされていません
nothing to commit, working tree clean	作業ツリーにコミットするものは何もありません
discard changes in working directory	作業ディレクトリの変更を無視する

---

他

初期化といってgitの設定ファイル丸ごと削除されたどうしようとか
思っていますが
実際に使い始めてから考えることとする（続

---

まとめ

結論言うと、まずはこれらを新人君には覚えてもらおう。

$ git config --global user.name [username]
$ git config --global [mailaddress]

$ git init
$ git add -a
$ git status
$ git commit -am "initial repository"

$ git checkout -b ブランチ名
$ git branch
$ git checkout master
$ git branch

---

おわり

ネットで検索しても中々見つけられなかったので、
git rebaseのコマンドフローを書き記しておきます
GUI使わずコマンドでgitを扱う方は参考になるかもしれないです

ちなみに環境ですが、
mac & VSCodeでターミナルを開いて行っています

その前に

変な空白が入ってたりすると、
Whitespace云々でgit rebase中に怒られてしまうので、
VSCodeをお使いの方はsettings.jsonに下記設定を追加しておいてください！

"files.trimTrailingWhitespace": true

Here We Go !!

ではここから作業フローになります。
開発ブランチ名 : develop
自分の作業ブランチ名 : feature-branch
の場合を想定して進めていきます

$はbashで進めた時を想定してつけているので、各々の環境で適宜脳内変換してください〜！

// 作業をコミットしておく
$ git add [作業ファイル]
$ git commit -m "作業メッセージ"

// 開発ブランチへ移動
$ git checkout develop

// 最新のもの必ずとってきてください！
$ git pull origin develop

// 自分の作業ブランチに戻ってから開発ブランチをrebase
$ git checkout feature-branch
$ git rebase develop

// ⭐️rebase中にconflictしなかった場合
// おめでとうございます? pushしてしまいましょう
// 一回でもpushした場合
$ git push --force-with-lease origin feature-branch
//もしくは
//※今回が最初のpushだったら--forceはなくてもいけると思います
$ git push origin feature-branch

// ⭐️rebase中にconflictしてしまった場合
// とりあえず確認してファイルを治しましょう
$ git status
// commitはせず、add のみ
$ git add [conflictしてるファイル名]
// 次のcommitに行きます。そこでもconflictしたら↑と同じことしてください
$ git rebase --continue

全て終わったら、[⭐️rebase中にconflictしなかった場合]に飛んでください

ちなみにrebase自体やり直したいときは、自分の作業ブランチで

$ git rebase --abort

rebase後に間違って自分の作業ブランチをpullしてしまった場合は

$ git merge --abort 

でなかったことにできるので安心してくださいね

Gitでの開発の中で、「rebaseコマンド」によって
現在のブランチを最新のマスターから切らせる時の手順について。

1. ローカルのmasterを最新にする

Github Desktopにて ⬇︎

ターミナルで行う場合 ⬇︎

ターミナル

% git checkout master
% git pull origin master

2. rebaseコマンドの実行

ターミナル

% git checkout 【作業中ブランチ名】
% git rebase master

これでコンフリクトが起きなければ、作業ブランチに最新のマスターを持ってこれている。

3. コンフリクトを解消する

コンフリクトが発生した場合、該当ファイルを修正し
【まとめてadd】 → 【git rebase --continue】を実行する

ターミナル

git add　【修正したファイル名】
git add　【修正したファイル名2】
git rebase --continue

---

rebaseをキャンセルする場合、「 git rebase --abort 」を実行するみたい。
以上で終了です。

はじめに

こんにちはばーんです！

今回は案件をこなすうちにレビュー(指摘)頂いた内容をまとめました。
1人で学習していると気付きにくい事が多くあるなぁ…と感じました。

• 実務に携わっていない方
• 実務経験はあるけど、チーム開発など他者と組んで仕事していない方

は見ていただけると気付きがあるのかなと思います。

結論

最初に書きますw

1. 独学だけでやりきらない方が良い
メンターでなくとも、コミュニティなどで他者と交わりながら進めた方が絶対いいです。
独学だけだと知り得ない情報が沢山あるなぁと今回気づきました。

2. Gitはお金払ってもいいので覚える
神ツールなので。これも独学でやり切るのは厳しいかも…

GitHub

PR(プルリクエスト)のお作法

• できる限りわかりやすく

これはなにもIT業界だけに限った話ではありません。上司に資料を見せる時、お客様に見せる時なるべくわかりやすい説明を心がけませんか？事前に練習したり、他の人に見てもらって修正の意見聞いたり等。
レビュワーも人間なので30Pのびっしり書かれた資料を渡されても厳しいものがあります。
以下が実際に指摘を受けた内容です。

1. 該当箇所をスクショ(新しく改善した場所を明示する)
TOPPAGEのsearch欄を変更しました。
と書くより写真で載せて印をつけて送った方が丁寧ですね。

2. 事実と仮説を分ける
エラーなどが特にそうなのですが、「何をして何が起きたのか(事実)」と「だからどのように考えるのか(仮説)」は分別して記載すべきです。
分かりにくいですし、この記載がないとレビュワーも同じ方法を試して2度手間になるかもしれません。

3. 粒度を適切にする
これはそのチームでの運用方法があればそちらに則る。なければ項目ごとに分けるのが良いかと思います。
例えばWebのサイト制作であればセクション毎、ページ毎など。

• マークダウンを正しく書く

QiitaやREADME.mdなどで積極的に書いて慣れることをオススメします。綺麗に書かれたマークダウンはとても見やすいです。

見やすい　＝　伝わりやすいとそれだけコミュニケーションコストも下がり全員が幸せになります＾＾

GitHubの使い方

• Resolve conversation

コメントを書いてもらっている左下にあるボタンです。これを押すとコメントが閉じられます。
「対応終わったよ！」ってことですね。

• files changed(差分確認)

PRをあげると前回との変更点（差分）が見れます！便利！
僕はこの存在を知るまでは人力で確認してました＾＾

• commit suggestion

「こここっちの方が良くない？」「こっちに変えといたからcommitしといて〜」
とレビュワーが修正してくれたものを反映できるボタンです。神。
commit suggestionのボタンを押してpullするとローカルで反映できます。神。

Git

• GitFlowを理解する

GitやGitHubの運用方法をチーム開発であれば決める事が多いかな〜と思います。
代表的なものが↓
https://qiita.com/hatt0519/items/23ef0866f4abacce7296

• コミットのお作法
  • 関心毎にコミットする。まとめない
  • コミットはなるべく分かりやすく書く(第3者が見ても何の変更がなぜ？どのように行われたか分かるように書く)
  • [fix][add]のように、このコミットが何をしたのか？を最初に記す(下記の記事とか分かり易いです)

メールの最初に【共有】とか、【依頼】とつける事あると思いますがそれと似てます。
https://qiita.com/shikichee/items/a5f922a3ef3aa58a1839

コミットは総じて分かりやすく書く事が大事ですね＾＾

自分1人で試してみる

これらGitやGitHubの使い方ですが、自分1人でも試せます。

1. GitとGitHubを使いテキトーなディレクトリを管理する
2. masterとは別のBranchを切ってpushする
3. GitHub上に Compare & pull request　という表記が出るのでそれを押す

これで自分自身でコメントしたり、ファイルの差分を確認したりできます＾＾

CSS(scss)

scssのお作法

• コンパイルについて

scssのコンパイルですが、相手がどういったコンパイル方法かは相手次第です。
ですので納品時にはこちらからコンパイル方法まで明記すると丁寧ですよね＾＾というお話です。
僕はEasySass（VSのプラグイン）で楽してたのですが、コンパイルするのに楽してたんだな…と痛感しました。したことないって方は是非してみてください。

https://qiita.com/baan_nasebanaru/items/1974467f834bc6640ee6

また、納品も.min.cssなのか、通常の.cssなのかでコマンドの書き方やignoreする対象も変わります。
.min.cssの場合無駄なスペースがないのでより軽いファイルをデプロイできますし、第三者から読み取りにくい状態です。.cssの場合は納品後も修正ができます。

• mixinやinclude以外の使い方

実はmixinってincludeする以外の使い道ないと思ってましたw

https://qiita.com/nekoneko-wanwan/items/c8498a21ae0e2b2198be
この記事が分かりやすいのでオススメです＾＾

• 色やフォントの管理は変数で

フォントも色も使う種類は3種類程度とされています。なので最初にフォントや色を変数で宣言します。
その宣言を元にスタイルを当てる事で、統一感が出る ＋ 修正時の管理が容易になります。

https://francfranc.io/
こちらはfrancfrancのデザインガイドです。ご参考までに

• 完全な白と黒は使わない

#ffffff や #000000 は使わないという事です。
自然界にない色で目立ちすぎる為。使う場合は微妙にずらしましょう。

クラス名について

絶対にタグにスタイル当てない
これそう聞いていても最初はやっちゃうと思います。BEMを知った後でも「BEMで詳細度上げた後のタグだからいっか」みたいな感覚でつけた事あります…
ダメです。全部にクラスつけます。スタイルもクラスに対して当てます(htmlに対してのfontなどは除く)

具体的な名前をつけない
これはcssだけに限った話ではありませんが。
例えば海の写真をヒーローイメージに起用する時に ocean　みたいなクラス名はダメです。
なぜなら写真の内容が変わった時にクラス名も変える必要がでてくるので。
これは逆も然りで、ファイル名に heroImage　みたいなファイル名もダメです。
heroImageを別の写真にした時に修正が必要なので。

ファイルパスの指定を絶対パス（相対ルートパス）でする場合

絶対パスのすすめ
http://osumituki.com/hack/internet/4684.html

サーバーの立て方（ローカル）
https://sterfield.co.jp/designer/%E3%83%AB%E3%83%BC%E3%83%88%E7%9B%B8%E5%AF%BE%E3%83%91%E3%82%B9%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%9Fhtml%E3%81%AE%E5%88%B6%E4%BD%9C%E3%83%BB%E7%A2%BA%E8%AA%8D%E3%82%92node-js%E3%81%AE%E3%83%AD%E3%83%BC/

絶対パスと相対ルートパスで意味合いが微妙に違いますがしたいことは同じです。
納品者から指定されて相対ルートパスで納品した場合などに参照してください。
要するにローカルで作成している場合、ルートディレクトリがわからないので相対ルートパスだとスタイル当たらないというお話と、相対ルートパスでのスタイルの当てた時の確認の仕方が書いてます。

その他

• (JS)アンチパターン

アンチパターンってなによ？って話ですが、要はやっちゃいけないこと。
自分が指摘されたのはevalの使用や、gotoについてです。

eval
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/eval

goto
https://marycore.jp/coding/why-goto-statement-is-bad/

言語名　アンチパターンで調べると沢山出てくるのでおすすめです。
（というか厳密にいうと自分が書いたコードが細かくどういう動きをするのか把握しろって話なんですが…）

• コメントは基本的にWhyを書く（なぜ？以外は書かない）

これはリーダブルコードでも明記されてましたね…
ただ、どーしても不安で書いてしまう。なぜ？以外を書いても良いとは思いますが書かなくて済む努力は必要ですね

• コードは常にきれいに

これは複数名から言われたので真理だと思いますw
一時的にコメントで消すのはOKですが、必要ないと判断したら消しましょう。そして、それに慣れましょう。

さいごに

自分自身も↑に書いた事でまだできてない事沢山ありますが、それを知っておくことは大切かなと思います。

最後まで読んでいただきありがとうございましたm_ _m

1. 独学だけでやりきらない方が良い
2. Gitはお金払ってもいいので覚える

一応結論をもう一回載せて締めにさせていただきます。ありがとうございましたm_ _m

＜問題提起＞
GitというものとGitHubって出てきたけど
【Git（ギット）】と【GitHub（ギットハブ）】て同じなの？

＜結論＞
「Git（ギット）」と「GitHub（ギットハブ）」ですが、この2つは同じものではありません。
「Gitを使ってエンジニアを支援するWebサービスがGitHub」です。

そのため、まずはGitが何かについてからご紹介をしたいと思います。

※GitとGitHubの違い

・Gitとは
・Githubとは
・実際の開発の流れ参考
・初心者向けおすすめサイト

■Gitとは

□【Git】
「ソースコードのバージョンを管理するツール」の名前。システム開発では複数の開発者によってソースコードが書き換わります。いつ誰がどこを変えたのか？ 最新のバージョンはどれか？ など、ソースコードのバージョンを把握する必要があります。このバージョン管理をするツールの1つが「Git」です。

Gitに
１、何を足したのか
 ２、どこを削除したのか ３、どんな手を加えたのか
見ていてもらいたいリポジトリ（これから作業する今自分のいる場所）で、
git initをすると、Gitさんが呼び出せてGitコマンドが使えるようになります。
これを忘れてしまうと、後で大変な目にあいます。

□Gitが広まった理由
ソースコードのバージョンを管理するGit、正確には「分散バージョン管理システム」と呼ばれています。実はGit以前にも、CVSやSubversionなどバージョン管理に用いられたツールがありました。これらを差し置いて、近年Gitが広く受け入れられている理由が「分散」にあります。
バージョン管理システムでは、ソースコードの履歴を「リポジトリ」と呼ばれる場所で管理しています。ソースコードを変更したら、開発者はリポジトリに履歴を記録します。全ての変更が記録されるため、過去のある時点にソースコードを戻す、ということも可能になります。
これまでのバージョン管理システムは、リポジトリは全体で1つだけでした。そのため、開発者が増えるとそれぞれの変更箇所がぶつかるなど、リポジトリに不整合が起こることもありました。
2005年に開発されたGitは、リポジトリを「分散」するようにしました。全体を統括する「リモートリポジトリ」の他に、開発者ごとに「ローカルリポジトリ」を持つ仕組みになっています。
Gitでは、自分のマシンの中にあるローカルリポジトリに変更を記録し、しかるべきタイミングでリモートリポジトリに変更履歴をアップします。これにより、ネットワークが繋がらない環境でもバージョン管理ができ、全体の整合性を保ちやすくなったのです。

■Githubとは

□【Git hub】
「Gitを利用した、開発者を支援するWebサービス」です。GitHubは、クラウド上でGitを用いたバージョン管理をすることができ、さらにGitには無い、開発者に便利な機能を追加しています。いまやユーザ数は2400万人を超え、世界中のソフトウェア開発に利用されているサービスです。
Gitはツールの名前で、GitHubはWebサービスの名前。この2つの関係は「メールとGmail」の関係に似ています。Gmailはメールを利用するためのWebサービスですし、メールのWebサービスはGmail以外にもYahoo!メールなどがありますよね。

■実際の開発の流れ

□ソースコードの基本的な流れの説明
1.リポジトリを作成する
2.ソースコードの作成、編集を行う
3.新規作成、変更、削除をGitのインデックスに追加する
4.インデックスに追加された内容をローカルリポジトリにコミットする。
5.ローカルリポジトリの内容をリモートリポジトリ（GitHub）にプッシュする
2.で登場する「インデックス」は、ローカルリポジトリにコミットする前に一時的に変更内容を保存しておく場所です。ファイルを編集し、最終的にGitHubに変更が反映されるまでにはインデックス→ローカルリポジトリ→リモートリポジトリ（GitHub）という3段階を踏むようになっています。
また、ローカルリポジトリに変更内容をアップすることを「コミット」、リモートリポジトリに変更内容をアップをすることを「プッシュ」と呼びます。逆に、他の開発者がリモートリポジトリに追加した内容をローカルリポジトリに反映させる操作は「プル」と呼ばれます。
こうして複数の開発者がリモートリポジトリに最新の状態をプッシュしていき、ソースコードのバージョン管理を行います。

■初心者向けおすすめサイト

もっと知りたい！という方は、こちらのサイトも見てみてくださいね。
・Git　
わかりやすいGit入門です。まずはここから。
http://www.backlog.jp/git-guide/
概念を「写真・カメラ・アルバム」などに例えて解説
http://liginc.co.jp/246190
・GitHub
チーム開発について連載されています。
https://seleck.cc/note/seleck_howto/article/30
GUIツールを使ったGitHubの使い方が解説
http://liginc.co.jp/248093

GitHubは機能も豊富なので最初は分かりづらいかもしれませんが、これを使いこなせるかどうかでキャリアに凄い影響があるかも？！って言われると使わざるを得ないでしょう

ぜひ一度、実際に試してみてくださいね。

GitHubで丁寧に手順とコマンドを教えてもらった。
もらったプルリクエストをマージしようとしたけど、自分がそれに気づかずプッシュしててコンフリクトを起こしたらしい。
データベースの違いだったのですぐ直せたけど、この表示は初めてだったのでメモ代わりに残す。

GitHubでの表示

Checkout via command line
If you cannot merge a pull request automatically here, you have the option of checking it out via command line to resolve conflicts and perform a manual merge.

Step 1: From your project repository, check out a new branch and test the changes.
git checkout -b xxx(新しいブランチ) master
git pull https://github.com/xxx(プルリク元のURL、HTTPとか) master

Step 2: Merge the changes and update on GitHub.
git checkout master
git merge --no-ff xxx(新しく作ったブランチ名)
git push origin master

日本語訳

グーグル翻訳最高！

コマンドラインによるチェックアウト
ここでプルリクエストを自動的にマージできない場合は、コマンドラインからチェックアウトして競合を解決し、手動でマージするオプションがあります。

ステップ1：プロジェクトリポジトリから新しいブランチをチェックアウトし、変更をテストします。
git checkout -b xxx(新しいブランチ) master
git pull https://github.com/yyy(プルリク元のURL、HTTPとか) master

ステップ2：変更をマージし、GitHubで更新します。
git checkout master
git merge --no-ff xxx(新しく作ったブランチ名)
git push origin master

具体的に何したか

ターミナルでローカルリポジトリに移動
git checkout -b xxx(新しいブランチ) master
git pull https://github.com/yyy(プルリク元のURL、HTTPとか) master
うまくいかないので修正する。
VScode、DB Browserで。
修正したらもう一度プル。git statusとかで確認して、
git checkout master
git merge --no-ff xxx(新しく作ったブランチ名)
変更をaddしてなかったので上手くいかなかったっぽいのでaddしてもう一度した。
あとはstatus見て、
git push origin master

完成！
developブランチとかある場合はそれもマージしておく。
ここで新しく作ったブランチはもう削除してもいい

初めに

DockerとDocker Compose を用いてRailsの開発用コンテナ群を制作します。

マシンスペック

・macOS Catalina
・バージョン 10.15.4
・iMac(retina 4K, 21.5-inch,2019)
・プロセッサ 3 GHz 6コアIntel Core i5
・メモリ 8GB

①Gitのインストール

https://git-scm.com/download/mac
こちらのページに、ダウンロードファイルがあります。

②Rails開発用コンテナ群の構築

git clone https://github.com/oiax/rails6-compose.git

cd rails6-compose
./setup.sh

③コンテナ群のスタートとストップ

・コンテナ群のスタート
docker-compose up -d

・コンテナ群のストップ
docker-compose stop

以上がRailsのコンテナ群の構築でした。
ここまでは、エラーなしで構築できましたが、これからが心配です。

閲覧いただき、ありがとうございました。

git push origin "ローカルブランチ名"

リモートにローカルブランチと同名のブランチが存在しない場合にpushする際に使用。

git diff "ファイル名"

直前のcommitとの差分を出力。

git diff --name-only

前回commitから差分のあるファイルを出力。

git restore "ファイル名"

直前のcommitと現在までの変更差分を削除。
git status → git diff --name-only からの流れで使うことが多い。

git reset --hard "ハッシュ値"

指定したハッシュ値のcommitまで戻る。

git switch -c "ブランチ名"

新規ブランチ作成。(ブランチ切替を含む)
下記2つは新規ブランチ作成までは共通だが、切替を行うかで異なる。

• git checkout -b "ブランチ名"： ブランチ切替を行う。
• git branch "ブランチ名"： ブランチ切替を行わない。

git checkout -b "ブランチ名"

作業ブランチから変更が生じた際に、変更差分を別ブランチへ切り出す場合にも使える。
commitする前にこのコマンドを使用することで、親ブランチの最後のcommitから現在までの変更差分を別ブランチへ切り出すことができる。

参考

Git - git-switch Documentation

git rebase "ブランチ名"

作業ブランチに対し、指定したブランチ名と作業ブランチの変更差分を反映する。
新規でcommitが追加されるわけではない。（帳尻をあわせるイメージ）