gitで手こずった時に色々ググってると、「git fetch」と「git pull」がぐちゃぐちゃになってしまったのでまとめておきます。

結論から言えば、「fetchもpullもリモートリポジトリの最新情報をローカルリポジトリへ持ってくる」という操作になりますが、それまでの流れが違うので説明していきます。

git fetch

リモートから最新情報をローカルに持ってくるのですが、場所は「master」ブランチではなく、「origin/master」ブランチに取り込まれます。

初めは「何それ知らない」となるのですが、具体的に言うと

• 「master」ブランチ…ローカルの中心となる統合ブランチで、他のローカルの作業ブランチと繋がったもの。
• 「origin/master」ブランチ…ローカルにある、リモートのmasterブランチを追跡するリモート追跡ブランチ。

となります。

両方ともローカルにあるブランチで分かりにくいのですが、図でイメージするとこんな感じです。

ローカルの「master」ブランチの1歩先(リモート寄り)に「origin/master」ブランチがあって、git fetchではこの「origin/master」ブランチで最新情報を受け取ります。

それをローカルの「master」ブランチが貰えるようにgit fetch → git mergeをして、「origin/master」→「master」へ最新情報を持ってくるわけですね。ここまで処理を行うことで、ローカルのファイルが最新の状態に更新されます。

まとめると、

• git fetch…リモートの「master」ブランチ → ローカルの「origin/master」ブランチ
• git merge…ローカルの「origin/master」ブランチ → ローカルの「master」ブランチ

となります。

git pull

git pullは、上のgit fetch、git mergeを同時に行うコマンドです。そのため、リモートの「master」ブランチから、ローカルの「origin/master」ブランチを介して、ローカルの「master」まで一気に最新情報を持ってきます。

mergeまで一気に行なってしまうため、ローカルのブランチとコンフリクトが起きやすいのは、この理由なんですね。

まとめると、

• git pull…リモートの「master」ブランチ →（ローカルの「origin/master」ブランチ→） ローカルの「master」ブランチ

となります。

コマンド例

$ git fetch origin master
$ git merge origin/master

$ git pull origin master

戻す方法

いろんな手段があると思いますが、パニックになる前に、とりあえず解決できそうなコマンドです。

まず、

$ git fetch

でエラーがあって元に戻したい時は、
まだローカルの「master」ブランチまで更新されていない（mergeされていない）ので、

$ git reset --hard HEAD

で直前のcommitまで戻して、無かった事にします。
これは簡単です。

そして、

$ git pull

でエラーがあって元に戻したい、コンフリクトを無くしたいという時は、

まずpull = fetch + mergeなので、mergeを

$ git merge --abort

で取り消します。その後は同じように

$ git reset --hard HEAD

で、直前のcommitまで戻して、無かった事にします。

コンフリクトの理由を把握し、うまく解決してmergeするのが１番ですが、それはまたいずれ違う記事で書きます。

参考記事

git fetchの理解からgit mergeとpullの役割
origin masterとorigin/masterの違い

gitのリモートリポジトリーにmasterとは別でdevelopmentブランチがあるとする。
これをローカルにfetchする。

git fetch origin development

 * branch            development -> FETCH_HEAD

↑によって、ローカルのリモート追跡ブランチ origin/developmentが生成されたはずだが、
git branchを確認してもmasterしかない。

$ git branch
* master

↓
↓
◇git checkout FETCH_HEAD するとdevelopmentブランチに切り替わる。

git checkout FETCH_HEAD

$ git branch
* (HEAD detached at FETCH_HEAD)
  master

ブランチ名が(HEAD detached at FETCH_HEAD)となっているが中身はdevelopmetブランチ。

staging環境などで、masterへマージしたくないけど動作は確認したい という時に使えそう。

はじめに

Gitを使おうよ！ - Local編 -（GitKrakenを入れてGUIでGitを操作するハンズオン）の後編的なものです。
GitHubなどにリポジトリをpushしたり、cloneしてきたりします。

GitHubを使ってみよう！

GitHubはGitリポジトリを共有するサービスのひとつです。

自分のソースコードを公開して、いろいろな人に見てもらったり、使ってもらったりもできるし、その逆に色んな人のコードを見たり、使ったりすることができます。

2018年にはMicrosoftに買収されることが決まって、そのおかげか有料だった非公開リポジトリが無料で利用できるようにもなりました！

実際にGitHubのアカウントを作成して、自分のリポジトリをGitHubにPushしてみましょう！

GitHubのアカウント作成

促されるままにGitHubのアカウントを取得しましょう！
残念ながらOAuthに対応してないのでユーザー名とか、メアドとかを入力する必要があります。

プランはまぁ、Freeでいいでしょう。
Proにすると大人数で非公開のリポジトリを使ったり、膨大なデータをGitHubへアップロードすることができたりします。
学生なら、申請したりするとPro相当のが無料で利用できるとかできないとか...

最後にちょっとしたアンケートがあります。
スキップもできるので、なんかいいかんじにしておきましょう。

最後に「登録されたメアドあてに確認メール送ったったわ。確認してくれや」みたいになるので確認してあげましょう。

これで今日からあなたもエンジニアだ！！！！

GitKrakenとGitHubを連携させる

GitKrakenはGitHubと連携させることができる。
GitKurakenのみでリポジトリをGitHub上に作成したり、GitHubにあるリポジトリを作成したりすることができる！便利！

GitKrakenの「Preferenecs」を開いて、「Authentication」をクリックしましょう。

「Connect to GitHub」のボタンをクリックするとブラウザが立ち上がって、GitKrakenのサイトが認証を開始してくれます。
GitHubへログインし、連携を許可してあげればおっけいです。

最終的にこんな感じになればできてます。

Remoteにリポジトリを作ってみる

Gitでは自分のPC側のことをLocal、GitHubなどのホスティングサービス側のことをRemoteと呼んでいます。
自分のLocalのリポジトリをRemoteにアップロードするためにまずはRemoteの準備を整えましょう。

GitKrakenのInitからGitHubのリポジトリを作成しましょう。

Nameにリポジトリの名前、Descriptionはそのリポジトリの説明です。
Accessはみんなに僕のソースコードを見てもらおうと思うのでPublicにしました。
誰にも見せるつもりがなかったり、今はいいや...ってときはPrivateにしておくのが良いでしょう。

このリポジトリには、前回作ったリポジトリをそのまま使おうと思ったので「Clone after init」のチェックは外しました。

最初からGitHubへ共有するつもりでリポジトリを作成するのなら、「Clone after init」のチェックを入れてローカルでの保存場所やlicenseを設定しておきましょう。

必要事項の入力が済んだら「Create Repository」！！

Remoteを追加してみる

「Remote」の欄にカーソルを当てて、「Add Remote」しましょう。

次に開くダイアログからGitHubリポジトリが参照できそうな雰囲気があるのですが、なんかいつも表示されないので、手動で設定してあげましょう。
ブラウザでGitHubを開いて、自分のアカウントのアイコンをクリックして「Your Repositories」のページを開きましょう。

で、先程作成したリモートのリポジトリがあるはずなのでそれを開いて、でかく表示されてるアドレスをコピーします。

コピーしてきたものをGitKrakenのPull URLのところへペーストします。
Pull URLにペーストすると、うすくPush URLのところにも同じ物が入ります。GitHubの場合はPullもPushも同じアドレスなのでこれで大丈夫です。

Push（アップロード）とPull（ダウンロード）でURLが分かれてる場合があるので、その時用です。

ここのNameは「なんのRemoteなのか」を表すものなのでなんでも大丈夫です。わかりやすい名前を付けましょう。

「Add Remote」して終了！
RemoteにGitHubが加わりました。

Pushしてみる

Pushとは、ローカルで増やしたリポジトリの変更をリモートへ反映する操作です。
先程追加したRemoteへプッシュしてみましょう。

上の方にある「Push」をクリックして、Submitです。

これでローカルの状態がリモートに反映されました！

Pullしてみる

Pullはリモートの状態をローカルへ反映する操作のこと。

他の人が作ったブランチが役目を終え、developやmasterへマージされていたりするとdevelopブランチが変更されますよね。
そういった場合にローカルへdevelopをプルしてきて、自分のブランチへマージしたりする必要が出てくるんです。

その辺のお話はあとでするとして、GitHubからファイルをひとつ追加してきました。
ファイルの追加/編集程度であればGitHubからも直接操作ができます。

変なアイコンになっている方がリモート、パソコンのアイコンのほうがローカルのリポジトリの最新のコミットです。
リモートのほうに新しいコミットがあるのでひとつ伸びてますね。

じゃあ、さっきプッシュしたみたいに、その隣のPullをクリックしてみましょう。

うん。ひとつにまとまりましたね。
同じブランチを複数のPCとかで操作するとプルするときにも衝突が発生することがあります。
その時は前回の記事のマージのときと同じように衝突を解決する必要があります。

Pull Requestしてみる

「addJavaHelloWorldブランチの作業は完璧だ！！developにマージしてほしい！！」
それをリポジトリの管理者に直訴する手段がPull requestです！

マージさせてほしいブランチで何を作ったのかを説明して、あなたの書いたコードをレビューしてもらいます。
コードのレビューをしてもらうことで、プロジェクト内でコーディングのルールを厳守させたり、いい加減な実装をあぶり出して不具合の早期発見や防止ができます。

プルリクエストを作らないで勝手にマージしてしまうとせっかく定めたプロジェクト内のルールが破綻したり、他の人のコードとモロかぶりしてしまったりするので...

コードレビューは大変な作業だけど、大事な作業です...
プロジェクトのルールにもよるのですが、基本的に作るべきだと思います。

プルリクエストはローカルで作っても仕方ないので、ブラウザを開いてGitHub上で作成します。
GitHubのリポジトリのページで、ブランチを自分のものに切り替えて、「New pull request」をクリックします。

そして、このブランチで何を作ったのか説明をします。
この辺はプロジェクトごとに何を書くのか決めておくのがいいと思います。

いろいろ書いて「Create pull request」しましょう。

こんな感じになるので、イケてるエンジニアに自分のコードを見てもらいます。
ぼくはひとりなので、このまま下の方にある「Merge pull request」をします。

すると、マージするときのコミットメッセージを入力できるので、いじるなり、デフォの値をそのまま使うなりして、マージします。
んで、GitKrakenで確認してみましょう！

プルリクエストが受理されました！やった！
masterにチェックアウトして、プルして、また新たなブランチをmasterから作って、新しい機能の実装に励みましょう！！

cloneしてみる

GitHubに存在しているリポジトリをローカルにコピーするのがClone。
このエントリでこねくり回してきたリポジトリをクローンしてみよう！！

GitHubからURLをコピります。

で、GitKrakenでファイルのアイコンのところをクリックして、「Clone」のところを開きます。

URLのところにさっきコピーしたURLをペースト、パスは好きなように設定して「Clone the repo!」しましょう！

クローンできました！
いろいろなオープンソースのリポジトリをクローンしてコードを呼んだり、自分のプロジェクトに使ったりしてみましょう！！

GitHubのプロジェクトに限りませんが、他人のものを使うときはオープンソースライセンスへの配慮をお忘れなく。
中には自分のプロジェクトを公開する必要があるものもあります。
ライセンスの種類を調べたり、読んだりして必要な要件を満たすようにしましょう。

さいごに

これさえ知っておけばとりあえずなんとか使える...かな...

初心者だからこそGitとうまく付き合っていくのが効率よくプログラミングに対して理解を深める上で大切なのではないかなと思います。
いろいろ書いて、動かなくなって、原因がわからなくなる...とかよくある話なので...
そんなときにGitで管理していれば動かなくなる前の状態に戻したりすることができるし。

Gitは現場では必須といえるスキルのひとつだと思います。
複数人で作業するとなるとこれなしでは...と思うことが多いです。

僕もわからない機能とか、知らない機能がたくさんあるので大きな事は言えませんが...

効率的なツールを使って快適なプログラミング・ライフを楽しみましょう！！

概要

目標のリポジトリのパスでgitコマンドを叩いて、
そこからブランチ名をチェックするシェルスクリプトのサンプルです。

目的

ソースコードを自動的にデプロイ、コミットするときの
事故防止のためのブランチ名チェックや
gitHubでmasterをロックできないけど自衛したい場合などに。

使い方

REPOSITORY_PATH と CHECK_BRANCH_NAMEを書き換えて、
サーバーの任意の場所に設置し、実行可能パーミッション（ 755 など）にし、
実行してください。

他のシェルスクリプトに組み込む場合などはお好みで書き換えてください。

サンプルコード

checkBranchName.sh

#!/bin/bash

# config
REPOSITORY_PATH=${HOME}'/hoge'
CHECK_BRANCH_NAME='master'

# change dir, if not found then exit
cd ${REPOSITORY_PATH}||exit

# get current branch name
branch=`git rev-parse --abbrev-ref HEAD`||exit

# check branch name 
if [ ${branch} = ${CHECK_BRANCH_NAME} ]; then
  echo "[NG] current branch \"${branch}\" is \"${CHECK_BRANCH_NAME}\""
  exit
else
  echo "[OK] current branch \"${branch}\" is not \"${CHECK_BRANCH_NAME}\""
fi

参考

• git-rev-parse

概要

やむを得ない事情でgitアカウントが複数あり、会社用アカウントと個人用アカウントなどを分けたいケースがあると思います。
そういったときは、会社用アカウントで作業するフォルダと個人用アカウントで作業するフォルダを分け、gitconfigの includeIf で このフォルダ配下ならこのアカウントを使うよ という設定を書いてあげるとよさげです。

ベースとなるgitconfigを作り、分けたいアカウントの数だけ[user]だけ描いたgitconfigを作ってincludeIfで参照するといい感じだと思います。

ベースgitconfig

~/.gitconfig

省略

# workフォルダの時会社用gitアカウントに切り替え
[includeIf "gitdir:~/project/work/"]
  path = ~/.gitconfig-work

# otherフォルダの時は個人用アカウントを使用する
[includeIf "gitdir:~/project/other/"]
  path = ~/.gitconfig-other

会社用gitconfig

~/.gitconfig-work

[user]
  email = ***@***.co.jp
  name = ***

個人用gitconfig

~/.gitconfig-other

[user]
  email = ＊＊＊@gmail.com
  name = SugarShootingStar

はるか昔に見た参考記事

git configをプロジェクトによって使い分ける - Qiita

ずっとgithub desktopを使用していましたが、さすがにコマンドでも操作できた方がいいだろうと思い、色々コマンドを調べて、ざっくりとした使い方がわかってきたので流れを簡潔に書きます。

gitを使用したブランチ作成からpushまでの簡単な流れ

作業を開始するために、、、

git branch -a #今いるブランチを確認 (-aをつけることでリモートブランチも見れる)

git branch ブランチ名　#ブランチ作成

git checkout ブランチ名 #ブランチ移動  

ファイルを編集したら、、、

git status #ファイルの編集状態確認

git add . #コミットしたいファイル追加("."ではなくディレクトリを指定する事で個別に追加する事ができる)
# 例git add app #appディレクトリのファイル変更分のみコミット対象にする

git commit -m "コミットコメント" #addしたファイルをコミット

git push origin HEAD 
git push origin ブランチ名 
#コミットをリモートにpushする。HEADと記述するとわざわざブランチ名を書かなくてよくなる

pushしたcommitをmasterにマージできたら、、、

git checkout master #masterブランチに移動

git pull #リモートからマージしたファイルを取得する

備忘録として書きました。細かい説明はいらないけど、とりあえず使いたいという人向けにこれからブラッシュアップしていくつもりです。
最初、commitとpushの違いがわからなかったのでそれについても記載したいです。

gitコマンド(ディレクトリの作成〜GitHubに公開するまで)

macのターミナルで…

1.ディレクトリを作成

$ mkdir ディレクトリ名

2.1で作成したディレクトリを表示

$ cd ディレクトリ名

3.gitリポジトリを作成

$ git init

4.ファイルを追加

$ git add ファイル名

5.4で追加したものを記録

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

6.リモートリポジトリに情報追加

$ git remote add origin GitHubで作成したリポジトリのURL

7.反映させる

$ git push origin master

色々作業を端折っており雑ですが、簡単にまとめてみました。

css のmarginコマンドの学習
　<!DOCTYPE html>

<meta charset="UTF-8">

<link rel=”stylesheet” href=”style.css”>

<title>書いてみよう！</title>

<p class="first">一番目の要素</p>

<p class="second">二番目の要素</p>

css

.first {
background-color: skyblue;

}

.second {

background-color: orange;

padding: 10px;

margin: 10px;

}

※{margin: 20px 10px 5px 0px;}

上から時計回りで連続指定も可能