プログラミング

Gitコマンド集

ギットメモ

本記事の内容

・Gitでよく使うコマンドをまとめてみた。


地方のweb制作会社に就職したんだけど、開発の先輩方がGitを使ってないのです。

確かにGitに頼らずとも、いい感じのwebサイトは作れます。

ただ、複数人で同じプロジェクトを編集するってなった時にめちゃめちゃ不便です。

自分用のメモとしてGitのコマンドを残しておきます。(Gitは導入しないのに、社内セキュリティは妙に頑丈で自宅で作成したコードとか現場に持ち込めないので「ググって出てきたら尚良し」程度の内容です。)

Gitメモ

注意:自分用のGitメモです。

・リポジトリを作成する場合はGithubからが楽

Githubweb上からGItコマンドの中身を確認するツール

SSH推奨

Github右上の+のボタンから「New repository」を選択し命名

OpenPrivateかを選択する(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で致命的な不具合が発生したとして、一刻も早く修正しないととんでもない損失が出る場合にはどうしたらいいでしょうか。

答えは、不具合が出る前の状態に戻すことです。

これが一番時間とコストがかからない安全パイです。

また、複数人で同じシステムを開発する場合、専用のツールやシステムを使用しないと「今から◯◯のファイルを変更します。作業が終わるまで触らないようにお願いします。」とかいちいち声掛けしたりしないといけません。

これだと開発速度がめちゃ下がります。

上記理由以外にも、いつ・誰が・何をしたのかが記録として視覚化することが可能です。

これは一人であろうと、複数人であろうと大きなメリットがあります。

試しに1ヶ月前、自分が書いたコードはどこからどこまでだったか明確に思い出せますか?多分無理だろね。

バージョン管理を行うと、一人で開発する場合でもいつ何をしたか後から確認できるので、やっぱGitが使えてなんぼなんだな。

なるべく「一機能実装する毎に」コミットして、レビュー(有識者や先輩に確認してもらうこと)を経て、それから実装した方が安心・安全です。

注意点

Gitを使用する際の注意点なんかもあるっちゃあります。

第一に、Gitはオープンソースでプログラムのソースを管理しています。

つまり、全世界の人に対して、このwebサイトはこうやってこの機能を実装しているということが丸わかりです。

これが何で問題かというと、ソースコードさえ秘密にしたい場合があるからです。

実際に地方で自社開発を行なっている企業さんで遭遇したケースが、全て守秘義務が生じるからダメ!ってケースでした。

この場合、Gitを使いたいのであればPrivateリポジトリにした方がいいです。また会社専用のアカウントを作成して、複数人でシェアする必要があります。

守秘義務だという点については、100歩譲って良しとします。

ただ、

いぬ
いぬ
ソースコードを管理するのに何で金がかかるんだ!

というようにGitを使ったことがない人にとっては、こんな意見も存在するのも事実です。(実際にGitを知らない人たちに対して提案したところ上記のようなことを言われました。)

笑っちゃいますが、本当に上記のようなことを言う人がいます。(笑ったら怒られるで。)

ってな具体に、Gitが使えない場合もあるのでそこは要検討・協議ですね。

いぬ子
いぬ子
「これもあったな!」ってなったら追記します。では!