本記事の内容
・Gitでよく使うコマンドをまとめてみた。
会社の人がGitを全く知らなくてびっくりした。みんな複数人で開発してこなかったらしい。どうやったらわかりやすく伝えられるか悩んだ結果、Gitのコマンド集を作って配布しようかと思ってるけど、どーなんだろ。まずGitが何故必要なのか、その辺からだろうな。。。
— いぬ (@inuengineer) June 25, 2020
地方のweb制作会社に就職したんだけど、開発の先輩方がGitを使ってないのです。
確かにGitに頼らずとも、いい感じのwebサイトは作れます。
ただ、複数人で同じプロジェクトを編集するってなった時にめちゃめちゃ不便です。
自分用のメモとしてGitのコマンドを残しておきます。(Gitは導入しないのに、社内セキュリティは妙に頑丈で自宅で作成したコードとか現場に持ち込めないので「ググって出てきたら尚良し」程度の内容です。)
もくじ
- 1 Gitメモ
- 2 コマンド一覧
- 3 コマンドの詳細
- 3.1 git clone
- 3.2 git status
- 3.3 git log
- 3.4 git add ***(file名)
- 3.5 git add .
- 3.6 git commit -m “コミットの際のメッセージを保存”
- 3.7 git push origin
- 3.8 git pull origin
- 3.9 git checkout -b ***(ブランチ名) master
- 3.10 git branch
- 3.11 git checkout ***(切り替えたい作業環境名)
- 3.12 git push origin ***(現在作業中のブランチ名)
- 3.13 git marge ***(本番環境に統合したいブランチ名)
- 4 作業上のよくあるエラー
- 5 余談
- 6 注意点
Gitメモ
注意：自分用のGitメモです。
・リポジトリを作成する場合はGithubからが楽
・Githubはweb上からGItコマンドの中身を確認するツール
※SSH推奨
Github右上の＋のボタンから「New repository」を選択し命名
OpenかPrivateかを選択する(Privateは月額¥700くらいお金がかかるので注意)
「Create Regository」を選択してリポジトリを作成する。
コマンド一覧
| git clone | 新規に作成したrepository(プロジェクト)をローカル環境へコピーするコマンド |
|---|---|
| git status | 現在のrepositoryの状況を確認するコマンド |
| git log | gitの履歴を確認できるコマンド |
| git add ***(file名) | gitにファイルを管理下に置くためのコマンド |
| git add . | コミットをする為の準備 |
| git commit -m “コミットの際のメッセージを保存” | コミットメッセージ付き、コミットのこと |
| git push origin | 作成、編集したデータをアップロードするコマンド |
| git pull origin | 【git push origin】した最新の情報を持ってくるコマンド |
| git checkout -b ***(ブランチ名) master | masterとは別に、同様のデータを基にして機能追加・開発をする際にブランチを作成するコマンド |
| git branch | 現在作業しているブランチがどこなのかを確認する為のコマンド |
| git checkout ***(切り替えたい作業環境名) | ブランチを切った際に作業環境を切り替えるコマンド |
| git push origin ***(現在作業中のブランチ名) | リモートに変更後のデータをアップロードする際に使用するコマンド |
| git marge ***(本番環境に統合したいブランチ名) | 本番環境に対して各自変更・開発してきたデータを統合するコマンド |
| git reset —hard HEAD | 「変更前に戻したい」となった場合、このコマンドを実施する |
| git stash | 変更内容を一時的に保存している状態 |
| git stash pop | git stash した一時保存データを呼び出すことができるコマンド |
コマンドの詳細
簡単にコマンドの詳細を説明
git clone
・新規に作成したrepository(プロジェクト)をローカル環境へコピーすること
・(※SSHの場合にはrepository名の横にあるURLをコピーして「git clone ***」のように半角スペースの後にペーストする。)
git status
現在のrepositoryの状況を確認するコマンド
git log
gitのコミット履歴を確認できるコマンド
何時何分に誰がコミットしたのか？が分かるコマンド
git add ***(file名)
gitにファイルを管理下に置くためのコマンド
ステージングとも呼ばれる行為
fileを認識させないと一時保存も本番へのマージも実施することはできない
git add .
コミットをする為の準備
全てのfileをステージングする為のコマンド
gitを使用した時点で複数ファイルが存在する場合、初めてコミットしたい場合には実施することがある
git commit -m “コミットの際のメッセージを保存”
コミットメッセージ付き、コミットのこと
何の目的でfileをコミット(一時保存)するのかが分かるので、単なるコミットよりも使用した方が良い
git push origin
リモートサーバーに対して作成、編集したデータをアップロードするコマンド
この時点でGithubを確認することで、web上で複数人のプロジェクトに関わる人が編集状況を確認することが可能になる
git pull origin
「git clone」と似ているが、git cloneは新規の場合
git pullは別の誰かが変更して「git push origin」した最新の情報を持ってくるコマンド
git checkout -b ***(ブランチ名) master
masterとは別に、同様のデータを基にして機能追加・開発をする際にブランチを作成する。
一機能毎にブランチを切ると安全である。
ゲームのセーブデータの「別のセーブデータ」のような扱い
git branch
現在作業しているブランチがどこなのかを確認する為のコマンド
git checkout ***(切り替えたい作業環境名)
ブランチを切った際に作業環境を切り替える場合、「git checkout 切り替えたい作業環境名」とすることでブランチを切り替えることができる。
git push origin ***(現在作業中のブランチ名)
pushの段階ではデータを共有するだけ。
ブランチを切って作業した際、リモートに変更後のデータをアップロードする際に使用するコマンド
git marge ***(本番環境に統合したいブランチ名)
本番環境に対して各自変更・開発してきたデータを統合するコマンド
margeを実施する際には、マージしたいブランチにて「git marge」を実施する必要がある
【cd ***】でマージしたいブランチに移動するのを忘れずに。。。
「git branch」にて作業環境を確認後「git checkout master」を実施しブランチを切り替えるケースもあるので注意
作業上のよくあるエラー
「rejected ……(fetch first)」
git push origin ***(コミットしたいブランチ名) を行い
「rejected ……(fetch first)」というエラーが出た場合、fetchを実施しない限りエラーを解消することはできない。
考えられる理由として、他の開発者と同じファイルを編集していたり、誰かが先にコミットを実施した可能性がある。
先ずは、
【git fetch origin】
を実施してみる。
更に確認として
【git branch -a】
にて、現在作業中のブランチと差分が生じているブランチを確認することができる。
確認した上で、
【git marge origin/(ローカルのブランチ名)】
を実施し、vi(通称「viエディター」)にて内容を確認
viエディターはインサート(キーボード「i」)で編集可能となり、エスケープキー(キーボード左上の「esc」でインサートモードを離脱)したあと「:wq」にて保存して終了
【git push origin】でアップして一段落
※上記は「git pull (マージしたいブランチ名)」としても同様の結果が得られる
コンフリクト
CONFLICT
※コンフリクトとは、同一ブランチ、または同一ファイルを編集した場合何を正(コミットすべき正しい情報)とするかGitが判断ができない状況
例えば同じブランチ、同じファイル、同じ箇所を複数人で編集した場合に発生する
【git pull origin ***(対象のファイル名)】
とした場合、変更箇所がどん被りすることがある。
例えば、コンフリクトした場合Gitがエディターに以下のようなエラーメッセージを吐いてくれる。
<<<<<<< HEAD
Hello World !!
=======
Hello !! Hello World !!
>>>>>>>※今回のケースでは、「Hello World !!」に対して、『Hello !!』を追加した場合にコンフリクトが発生したと仮定する。
最終的に「Hello World !!」という行をどうするのか決めてターミナルで【git status】を実行する。
<<<<<<< HEAD
Hello World !!
=======
Hello !! Hello World !!
>>>>>>>
※赤文字は削除する。
↓
Hello !! Hello World !!
というように、最終的にどう変更したいのかを修正する。問題ない場合には、ターミナルで
(fix conflicts and run “git commit”)
と出るのでcommitを実行する。
その際【git commit -m “◯◯のコンフリクトを解消”】
みたいな感じでメッセージを入れておくと後からブランチを見ても理解しやすくなる。
git reset —hard HEAD
エディターで色んな修正・変更を実施したけど、考えた結果「変更前に戻したい」となった場合、このコマンドを実施すると便利。
具体的には、ブランチが増えてきて「よし、終わったぞ。コミットするか！」という時に変更したいブランチじゃないブランチを変更していたということがよく起こる。(何ていうか、伝わるかな。)
もしコミット前に間違いに気づけたのなら、リセットで作業直前に戻してしまった方が結果的に早い
git stash
上記のリセットに似ている。リセットする必要がなく、編集した内容は他の部分に適用したい場合に有効
変更内容を一時的に保存している状態
git stash pop
git stash した一時保存データを呼び出すことができる。
別のブランチをまたいでも実施可能である。
余談
そもそもGitって何の為に必要なのか？
ファイルの状態を記録するためのツールです。
一般的にはファイルの状態を記録するとは、バージョン管理をすることになります。バージョン管理って何だ？？？となります。
バージョン管理とはスマホを使っているとよく目にするアレですわ。
「Ver.1.2」とかあるでしょう？
アレです。
例えばスマホに、新たにアラームの機能を後付けで実装するとします。
これがVer1とします。
Ver1から、また新たに地図を使えるようにしたとします。
これはVer1.1です。
そして、また今度スマホに新しい機能を実装します。
これがVer1.2です。
というようにバージョン管理という仕組み自体、自分たちの日常生活でよく目にしています。
もしこの時、Ver1.2で致命的な不具合が発生したとして、一刻も早く修正しないととんでもない損失が出る場合にはどうしたらいいでしょうか。
答えは、不具合が出る前の状態に戻すことです。
これが一番時間とコストがかからない安全パイです。
また、複数人で同じシステムを開発する場合、専用のツールやシステムを使用しないと「今から◯◯のファイルを変更します。作業が終わるまで触らないようにお願いします。」とかいちいち声掛けしたりしないといけません。
これだと開発速度がめちゃ下がります。
上記理由以外にも、いつ・誰が・何をしたのかが記録として視覚化することが可能です。
これは一人であろうと、複数人であろうと大きなメリットがあります。
試しに１ヶ月前、自分が書いたコードはどこからどこまでだったか明確に思い出せますか？多分無理だろね。
バージョン管理を行うと、一人で開発する場合でもいつ何をしたか後から確認できるので、やっぱGitが使えてなんぼなんだな。
なるべく「一機能実装する毎に」コミットして、レビュー(有識者や先輩に確認してもらうこと)を経て、それから実装した方が安心・安全です。
注意点
Gitを使用する際の注意点なんかもあるっちゃあります。
第一に、Gitはオープンソースでプログラムのソースを管理しています。
つまり、全世界の人に対して、このwebサイトはこうやってこの機能を実装しているということが丸わかりです。
これが何で問題かというと、ソースコードさえ秘密にしたい場合があるからです。
実際に地方で自社開発を行なっている企業さんで遭遇したケースが、全て守秘義務が生じるからダメ！ってケースでした。
この場合、Gitを使いたいのであればPrivateリポジトリにした方がいいです。また会社専用のアカウントを作成して、複数人でシェアする必要があります。
守秘義務だという点については、100歩譲って良しとします。
ただ、
というようにGitを使ったことがない人にとっては、こんな意見も存在するのも事実です。(実際にGitを知らない人たちに対して提案したところ上記のようなことを言われました。)
笑っちゃいますが、本当に上記のようなことを言う人がいます。(笑ったら怒られるで。)
ってな具体に、Gitが使えない場合もあるのでそこは要検討・協議ですね。
