こんにちは、まゆみです。

みなさんは、プログラミングを日々書いていますか？(笑)

特に大きなプロジェクトを抱えている時、ある一定の日まではコードが順調に実行されていたのに、ある日突然、気が付かないうちにどこかで間違えてコードが上手く実行できなくなった。。。

そんな経験は一度や二度はあるはずです。

例えばあなたの飼っている猫が

• パソコンのキーボードの上に寝そべってしまいコードが滅茶苦茶になってしまった。
• しかもあなたの猫は賢くて、そのまま保存までしてしまった。

あれだけ苦労して書いたコードなのに、頭の中は真っ白ですよね。

そんな時に役に立つのがGit

「コードが猫に壊されてしまったので、その前の状態に戻したい」

というあなたの要望に応えてくれるものです。

では早速説明していきます

Git とは？

Git とは、Version Control System のことです。

Version Controlとは？

では具体的に説明していきますね。

例えば、大きなプロジェクトを抱えてコードを書いている時、一日では終わらない時もありますよね。

3月3日は10行目までコードを書いた。(Version.1)

3月4日には20行目まで書いた(Version.2)

その次の日には40行目まで書いたのに、いつの間にかキーボードの上で寝落ちしてそのまま保存までしてしまった。

そんな時、コードが壊れる前のVersion 2　まで遡りたいと思いますよね。

それを可能にするのが『Git』になります。

Git で使われる用語の説明

では次にGitについて学ぶ前に知っておくべき用語の説明をします

①Working Directory
カレントディレクトリとも言われます。
今、自分が作業しているフォルダを指します。
ここで、Git の初期化(git init)をします。

②Staging Area
Version.1 で保存していたファイルをVersion.2 に保存する(commit)のと、Working Directoryの中間のこと。
なぜWorking Directory から一気にcommit までしないで中間にこのような物が設けられているかというと、全てのファイルをcommit したくない時もあるから。

③Local Repository
あなたのパソコン内に作られるファイルの保存場所。
Local Repositoryで、あなたの作ったファイルは安全に保存され、ファイルが壊れてしまった後も、遡ることができるようになります。

もし、③のプロセスをふんであなたのファイルをLocal Repository に保存した後で、ファイルが壊れてしまった場合は、コマンドラインに
『git checkout』
と打ち込めば、壊れる前の状態に戻すことができます。

コマンドラインはGitbush がおすすめ(Windowsユーザー)

コマンドラインはMacユーザーはTerminal を　Windows ユーザーはcommand prompt を使うように勧められていますが、エンジニア向けの情報は大体Mac ユーザーを想定して書かれている。

そして、Terminal とcommand prompt じゃ、使うコマンドラインが違うので、いちいち調べなおさなくてはいけなくて面倒くさいですよね。

そう感じているWindows ユーザーに、私は『Git bush』をおすすめします

私のサイトに使い方を載せていますので、Mac と同じコマンドラインをWindows で使いたいという人は、こちらの説明を見ながらGit bush を使ってみてください。

➡　https://python-laboratory.com/command-line-git-bash/

実際にGitを使って、あなたのコードを守る

では、コマンドラインを使って、実際にあなたがVersion Control したいファイルをGit のLocal Repository に保存させていきましょう

①『cd ディレクトリ名』で、あなたがLocal Repository に保存したいと思っているファイルが入っているディレクトリにいく

②『git init』とコマンドラインに打ち込むと、Gitの準備が整います(下記のスクショ参考)

※ただし、コマンドラインに『ls』(listの意味でディレクトリ内のファイルを表示してくれる)と打ち込んでも、Git のファイルは表示されません。

③Gitファイルがフォルダ内にあるかどうか心配な人は『ls』の代わりに『ls -a』と打ち込んでください。
隠れているGit ファイルも表示されます。(下記のスクショ参考)

④Gitの準備はしましたが、まだどのファイルもStaging Areaにありません。

『git status』とコマンドラインに打ち込むと、まだStaging Area にないファイルは赤色で表されます。

下記のスクショで、『chapter-1.txt』と『chapter-2.txt』と赤文字で書かれているのが分かりますね。

⑤git add でファイルをStaging Areaに入れる。

git add ファイル名　でStaging Area に入れたいファイルを選びコマンドラインに打ち込みます

Staging Area にあるファイルはgit statusとコマンドラインに打ち込むと緑色で表示されています

今回は、chapter-1.txt ファイルのみをStaging Area に移したので、chapter-1.txt は緑色で、chapter-2.txtはまだ赤色のままで表示されています。

⑥ファイルをcommitする

commit とは、Local Repository にファイルを保存して、何かがあった時に追跡できるようにすることです。

commitするには、

『git commit -m "Complete chapter 1" 』

とコマンドラインに打ち込みます。
-m 以下の　"Complete chapter 1"は、コミットメッセージと言われるもので、あなたがどのような事をしたのかの追跡を助ける役割をします。

なので、コミットメッセージは"Complete chapter 1"ではなくても良いです。

この作業が終わると、chapter-1.txtファイルはLocal Repositoryの中に入り、例えファイルの中身がぐちゃぐちゃになったとしても、そしてそのまま保存してしまったとしても、元に戻すことができます。

ファイルの中身が壊れてそのまま保存してしまった！

では、その時の直し方を書いていきますね。

壊れる前のファイルに何と書いていたのかの調べ方

『git diff』とコマンドラインに打ち込むと壊れる前と後のファイルの文言を調べることができます(diff はdifferent のこと)

上記のスクショを見てください。

赤文字で『This is the first version』と書かれているのが壊れる前のファイルの中身です。

緑色の『+kejkdjsklafjkdsjaklf』は今のファイルに書かれているものになります。

壊れたファイルから壊れる前のファイルに戻すにはコマンドラインに

『git checkout ファイル名』と打ち込むともとに戻すことができます。

もしディレクトリ内に2つ以上のファイルがある場合

ディレクトリ内にファイルが2つ以上ある時は、わざわざ1つずつStaging Area に持って行って、commit して。。。

というのは面倒くさいですよね。

その時は

『git add .』とgit add の後に半角スペースを置き　. (ドット)と打ち込むと2つ以上あるファイルも一気にStaging Area に持っていくことができます

まとめ

Git もコマンドラインも、あなたが使うものから少しづつ覚えていけば、そんなに圧倒される量でもないし、Git を覚えれば苦労して書いたコードをうっかりして消してしまうこともなくなります。

是非、今回の記事を参考にしてくださいね。

次回の記事は『Github』について説明していきますね。

お楽しみに！！

基本的な使い方

git init

リポジトリの作成をする
一番初めに必ず実行する

git add -A
もしくは
git add .

プロジェクトのすべてのファイルをリポジトリに追加する

git status

Gitにプロジェクトのファイルを追加すると、最初はステージング（Staging）という一種の待機用リポジトリに置かれ、コミットを待ちます。安全のため、いきなりコミットしないようになっているのです。ステージングの状態を知るにはstatusコマンドを使います。

git commit -m "Initialize repository"
Initialize repositoryは例なので、任意でコミット名を変える

ステージングエリアで控えている変更を本格的にリポジトリに反映（コミット）するには、commitコマンドを使います。
mフラグを使うと、コミットメッセージをコマンドラインで直接指定できます。-mフラグを使わない場合はシステムのデフォルトのエディタが開き、そこでコミットメッセージを入力します。

git log

logコマンドでコミットメッセージの履歴を参照できます。

ブランチを使用する場合

流れ

トピックブランチ作成
↓
ブランチ上で変更をコミット
↓
トピックブランチをmasterブランチにマージ
↓
（ブランチを削除）

git checkout -b (ブランチ名)

トピックブランチ（短期間だけ使う一時的なブランチ）はcheckoutと-bフラグを使って作成できます。

git branch
 master
* modify-README

git branchは、すべてのローカルブランチを一覧表示します。「*」はそのブランチが現在使用中であることを表します。

git commit -a -m "(コミット名：命令形かつ現在進行形)"

ブランチ上でコミット

git checkout master
git merge (今使用しているブランチ名)

コミット後、上記のコマンドでブランチをmasterブランチにマージ

git branch -d (ブランチ名)

変更をマージ後、上記のコマンドでトピックブランチを削除して終了。
トピックブランチの削除は必須ではありません。実際、トピックブランチを削除せずにそのままにしておくことはよく行われています。トピックブランチを削除せずに残しておけば、トピックブランチとmasterブランチを交互に行き来して、キリの良い所で変更をマージする事ができます。

git branch -D (ブランチ名)

トピックブランチ上の変更を破棄することができる
-dフラグと異なり、-Dフラグは変更をマージしていなくてもブランチを削除してくれます。

GitHubへのプッシュ

git push (origin masterは省略可)

はじめに

ローカル環境でのGithub連携方法についてまとめました。
railsアプリをGithubに連携させるためには、gitの知識も必要なため、gitを含めて説明します。

到達点

以下の2点を達成する
・gitが使えるようになる
・railsアプリをGithubに連携させる

流れ

① railsアプリを作成
② Github新規登録し、リポジトリを作成
③ gitコマンドを行い、連携させる

① railsアプリを作成

手前味噌ではありますが、私の記事を参照すると、ローカル環境でのrails環境構築ができます。
ローカル環境開発　Ruby on Railsの環境構築方法

　　

② Github新規登録し、リポジトリを作成

Githubを新規登録し、新しいリポジトリを作成する。

以下の画像の赤枠の New もしくは　New repository をクリックしてください。

Repository nameは、自身のアプリ名(rails new アプリ名)を入力し、Create Repositoryをクリックしてください。

③ gitコマンドを行い、連携させる

$ cd 自分のアプリ名
$ git init
$ git status   #作業ディレクトリでの現在の状態を表示する
$ git diff     #差分を見る

git addでファイルをstagedという状態にします
git add する前に変更した箇所とインデックスとの変更点を必ず確認しましょう
　　　

$ git add ..   #すべてのファイル・ディレクトリ
$ git diff     #差分を見る

git commitでローカルレポジトリにコミットします
git commit する前に差分を確認しましょう
　　

$ git commit -m "Initialize repository"
$ git diff     #差分を見る

git commit -m"コミット名" でコミット名が作成できます。
git　push する前にも差分を確認しましょう

$ git remote add origin http://Github.com/GitHubで作成したID/リポジトリ名.git
$ git push -u origin master

git pushで、ローカルレポジトリの内容がリモートに反映されます。
Githubのページからも確認しましょう。

参考記事

今日からはじめるGitHub 〜 初心者がGitをインストールして、プルリクできるようになるまでを解説

症状

git push herokuをやっても、herokuに変更が反映されませんでした。

git push heroku
Everything up-to-date

「Everything up-to-date」は変更するデータないよと言われているようです。

原因を調べると、gitも更新されていなかったことがわかりました。

解決策

コミットはしたものの変更をマージしていなかったことが分かりました。。
以下のコマンドを良しなに入力して解決しました。

初歩的なミスでしたが、解消に時間がかかったので書きました。

git merge ブランチ名