気になっていてそのままだったgit/githubをやっとこさ触ってみました。 Atomで使うことを前提に色々調べながらやりました。個人的に躓いたところとかをメモ代わりに記載していきます。 後々連携する場合は事前準備として先にgithubにリポジトリを作成しておくこと。 プロジェクトディレクトリを作成、移動。そして git init 空でコミットしておく。この方がAtomと連携する場合に良さそうです。 git commit --allow-empty -m "First Commit" 先に作成したgithubのリポジトリを登録。 ※atomを開く前にリモートリポジトリ登録しておかないと「No Remote」という表示が出てどうにもならなくなる。 git remote add origin https://github.com/XXXXX/XXXXX.git ローカルとリモートを同期させる意味でfetch。 git fetch ここまで来たら無事にAtomでgit/githubを扱えるようになったので。 atom . pushに失敗した時は % git fetch && git merge origin/master この時 fatal: refusing to merge unrelated histories と表示されマージに失敗した時は % git merge --allow-unrelated-histories origin/master とすると Merge made by the 'recursive' strategy. README.md | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 README.md というコメントと共にマージすることができる。
気になっていてそのままだったgit/githubをやっとこさ触ってみました。 Atomで使うことを前提に色々調べながらやりました。個人的に躓いたところとかをメモ代わりに記載していきます。
後々連携する場合は事前準備として先にgithubにリポジトリを作成しておくこと。
プロジェクトディレクトリを作成、移動。そして
git init
空でコミットしておく。この方がAtomと連携する場合に良さそうです。
git commit --allow-empty -m "First Commit"
先に作成したgithubのリポジトリを登録。 ※atomを開く前にリモートリポジトリ登録しておかないと「No Remote」という表示が出てどうにもならなくなる。
git remote add origin https://github.com/XXXXX/XXXXX.git
ローカルとリモートを同期させる意味でfetch。
git fetch
ここまで来たら無事にAtomでgit/githubを扱えるようになったので。
atom .
pushに失敗した時は
% git fetch && git merge origin/master
この時
fatal: refusing to merge unrelated histories
と表示されマージに失敗した時は
% git merge --allow-unrelated-histories origin/master
とすると
Merge made by the 'recursive' strategy. README.md | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 README.md
というコメントと共にマージすることができる。
はじめに こんにちは。初投稿です。テストを兼ねて自分のメモを投稿したいと思います。 間違いもあるかとは思いますが、ご指摘いただけると幸いです。 【初心者向け】git(GUI)へ成果物をアップロードする方法 gitのインストールからリポジトリの作成まで ・gitについて ・gitのインストール方法について ・gitの日本語化 はこちらのページが大変参考になりました。 https://eng-entrance.com/programming-git 途中、TortoiseGitのsettingが出てきますが、「デスクトップで右クリック」→「TortoiseGit」 → 「setting」で表示することができます。 リポジトリにプッシュ (1)作成したプロジェクトのページへ行く (2)「<>code」の「Upload files」をクリック (3)赤枠で囲った場所にアップしたいファイルをフォルダごとドラッグアンドドロップ (4)Commite changesをクリック 以上で、自分の成果物をgitのリモートリポジトリにアップすることができます。
こんにちは。初投稿です。テストを兼ねて自分のメモを投稿したいと思います。 間違いもあるかとは思いますが、ご指摘いただけると幸いです。
・gitについて ・gitのインストール方法について ・gitの日本語化 はこちらのページが大変参考になりました。 https://eng-entrance.com/programming-git
途中、TortoiseGitのsettingが出てきますが、「デスクトップで右クリック」→「TortoiseGit」 → 「setting」で表示することができます。
(1)作成したプロジェクトのページへ行く (2)「<>code」の「Upload files」をクリック (3)赤枠で囲った場所にアップしたいファイルをフォルダごとドラッグアンドドロップ (4)Commite changesをクリック
以上で、自分の成果物をgitのリモートリポジトリにアップすることができます。
やりたいこと デバッグ中に一時的に入れたコード等を間違えてコミットしてしまわないようにファイル中に NEVER_COMMIT という文字が入っていたら Git コミットできないようにする。 動作を確認した Git クライアントのバージョン → git version 2.20.1 (Apple Git-117) 。 個別の Git プロジェクトディレクトリのみで設定 .git/hooks/pre_commit を作成。内容は以下のような感じ。 #!/bin/sh NG_WORD="NEVER_COMMIT" git diff --cached -U0 | grep ${NG_WORD} if [ $? -eq 0 ]; then echo "[ERROR] Can't commit because ${NG_WORD} is detected" git grep --cached $NG_WORD exit 1 else exit 0 fi 実行権限が必要なので付与しておく。 $ chmod +x .git/hooks/pre-commit ローカルでグローバル設定化（テンプレート化） ローカルでグローバルって新鮮な古米みたいな響きだけど $ mkdir -p ~/.git-templates/hooks $ git config --global init.templatedir '~/.git-templates' $ vim ~/.git-template/hooks/pre-commit （スクリプト貼り付ける） $ chmod +x ~/.git-template/hooks/pre-commit これで今後ローカル（PC内）で git init や git clone すると作成される Git のプロジェクトディレクトリに自動的にスクリプトがコピーされる。 一元管理 お察しの通り、前項の方法だと既に git init git clone 済みのプロジェクトに適用されない。さらにスクリプトを書き換えてグローバルに（全プロジェクトに）適用したいときにコピー済みの全ファイル全部書き換え直す必要があって手間かかること山の如しなので $ git config --global init.templatedir '~/.git-templates' じゃなくて $ git config --global core.hookspath=~/.git-templates/hooks ってしておいたほうがおすすめ（最初からそう書けばいいのにね）。 この場合 .git-templates/hooks という名前は微妙なので .git-hooks とかそれっぽいものにすると良い。 シェルスクリプト（というより主に Git コマンド）の説明 git diff は何もオプションを指定しないと git add されていないワーキングコピーの差分のある行とその前後を表示する。 --cached を指定すると git add されているファイル（staged files）のみを対象とする。差分表示時に差分の前後行の diff は必要ないので -U0 で差分行のみを抽出している。表示された結果にNGワードが含まれていればその行が取得される。 $? は直前に実行したコマンドの結果が取得できる。diff があるときは正常終了 = 0 となっているはずで、もしNGワードがコミット対象に含まれていれば 0 と比較して等しくなる。 どのファイルにNGワードが含まれているのかわかりやすいように git grep で該当ファイルと該当行を表示している。ここもやはり git add 済みのファイルだけを対象としたいので --cached オプションを付与している。 exit 0 なら正常終了なのでコミットは続行され、 exit 1 なら異常終了なのでコミットは実行されない。 ちなみに git add せず git commit -a などとしたときもシェルスクリプト内の --cached オプションは対象ファイルを git add している場合と同様に動く。 それはともかく git add するときに -p 付けるとか、 git commit する前に git diff --cached 見て意図していないコードが含まれていないか見ろよって話ですよ。
デバッグ中に一時的に入れたコード等を間違えてコミットしてしまわないようにファイル中に NEVER_COMMIT という文字が入っていたら Git コミットできないようにする。
NEVER_COMMIT
動作を確認した Git クライアントのバージョン → git version 2.20.1 (Apple Git-117) 。
git version 2.20.1 (Apple Git-117)
.git/hooks/pre_commit を作成。内容は以下のような感じ。
.git/hooks/pre_commit
#!/bin/sh NG_WORD="NEVER_COMMIT" git diff --cached -U0 | grep ${NG_WORD} if [ $? -eq 0 ]; then echo "[ERROR] Can't commit because ${NG_WORD} is detected" git grep --cached $NG_WORD exit 1 else exit 0 fi
実行権限が必要なので付与しておく。
$ chmod +x .git/hooks/pre-commit
ローカルでグローバルって新鮮な古米みたいな響きだけど
$ mkdir -p ~/.git-templates/hooks $ git config --global init.templatedir '~/.git-templates' $ vim ~/.git-template/hooks/pre-commit （スクリプト貼り付ける） $ chmod +x ~/.git-template/hooks/pre-commit
これで今後ローカル（PC内）で git init や git clone すると作成される Git のプロジェクトディレクトリに自動的にスクリプトがコピーされる。
git clone
お察しの通り、前項の方法だと既に git init git clone 済みのプロジェクトに適用されない。さらにスクリプトを書き換えてグローバルに（全プロジェクトに）適用したいときにコピー済みの全ファイル全部書き換え直す必要があって手間かかること山の如しなので
$ git config --global init.templatedir '~/.git-templates'
じゃなくて
$ git config --global core.hookspath=~/.git-templates/hooks
ってしておいたほうがおすすめ（最初からそう書けばいいのにね）。
この場合 .git-templates/hooks という名前は微妙なので .git-hooks とかそれっぽいものにすると良い。
.git-templates/hooks
.git-hooks
git diff は何もオプションを指定しないと git add されていないワーキングコピーの差分のある行とその前後を表示する。 --cached を指定すると git add されているファイル（staged files）のみを対象とする。差分表示時に差分の前後行の diff は必要ないので -U0 で差分行のみを抽出している。表示された結果にNGワードが含まれていればその行が取得される。
git diff
git add
--cached
$? は直前に実行したコマンドの結果が取得できる。diff があるときは正常終了 = 0 となっているはずで、もしNGワードがコミット対象に含まれていれば 0 と比較して等しくなる。
$?
どのファイルにNGワードが含まれているのかわかりやすいように git grep で該当ファイルと該当行を表示している。ここもやはり git add 済みのファイルだけを対象としたいので --cached オプションを付与している。
git grep
exit 0 なら正常終了なのでコミットは続行され、 exit 1 なら異常終了なのでコミットは実行されない。
exit 0
exit 1
ちなみに git add せず git commit -a などとしたときもシェルスクリプト内の --cached オプションは対象ファイルを git add している場合と同様に動く。
git commit -a
git add するときに -p 付けるとか、 git commit する前に git diff --cached 見て意図していないコードが含まれていないか見ろよって話ですよ。
-p
git commit
git diff --cached
はじめに 今回の記事では開発で使われるGitについてまとめたいと思います。 あくまでも個人用の簡単なまとめなので、そこのところはよろしくお願いします。 Gitとは まずGitの概念についてまとめます。 Gitとはプログラムのソースコードなどを変更履歴を管理してくれる分散型のバージョン管理システムです。 Gitとは「プログラムのソースコードなどを変更履歴を管理してくれる分散型のバージョン管理システム」であり、もともとはLinuxのソースコードを効果的に管理するために開発されました。 このシステムによって複数人での開発の際に誰がどのファイルを「誰が変更したのか」「いつ変更したのか」「どのようなことを変更したのか」などの情報やファイルのバージョン管理などを行うことができます。 また同時にファイルを変更したときに発生する競合を防ぐことができます。 Gitの仕組み 簡単なGitの仕組みを図で表すと以下のようになります。 まずAさんは「Javaファイル①」を共有空間に20XX年1月1日に更新しました。 このとき、Gitによって「誰：Aさん」「ファイル：Javaファイル①」「いつ：20XX年1月1日」などの情報が記録されます。 次にBさんが「Javaファイル②」を共有空間に20XX年1月2日に更新しました。 よってGitによって「誰：Bさん」「ファイル：Javaファイル②」「いつ：20XX年1月2日」などの情報が記録されます。 最後にCさんは「Javaファイル①」を共有空間に20XX年1月2日に更新しました。 このときの「Javaファイル①」はAさんが共有空間に更新したものを使っていると想定しています。 ファイルの種類はAさんが更新したファイルを編集しているので、Cさんが更新しようとしているファイルはAさんの「Javaファイル①」のバージョンが更新されたものになります。 よってGitによって記録される情報は「誰：Cさん」「ファイル：Javaファイル①」「いつ：20XX年1月2日」「バージョン：Aさんが更新した次のバージョン」となります。 リポジトリ(repository) Gitではこういった共有空間のことを「リポジトリ(repository)」と呼んでいます。 リポジトリでは各ファイルやディレクトリの管理や変更履歴などの情報を記録をしています。 またリポジトリは2種類あり、上図であったように複数人で共有を行う「リモートリポジトリ」と個人のパソコンに配置するローカルリポジトリがあります。 ・リモートリポジトリ ⇒複数人で使用するサーバなどでバージョン管理するために作成したリポジトリのこと。 ・ローカルリポジトリ ⇒自分のパソコン内でバージョン管理するために作成したリポジトリのこと。 作成する方法として、ローカルリポジトリを普通に作る方法とリモートリポジトリからコピーする方法がある。 ブランチ(branch) ブランチ(branch)とは変更履歴の流れを分岐して表したものである。 分岐したブランチは他のブランチの影響を受けないため、同じリポジトリ中で複数の変更を同時に進めていくことができます。 つまり自分専用のブランチを作って作業をを行い、作業が終わるとメインのブランチに組み込みます。 ブランチを用いて分岐した例として、以下のような図を作ってみました。 青線は「masterブランチ」といい、基軸となるブランチのことをいいます。 他にも、この図では機能追加のための赤線［XやY］、バグの修正のための緑線［Z］などの分岐が存在します。 それらのブランチを合流させるために「マージ (merge)」を行うことで1つにまとめることができます。 プル(pull) 「プル(pull)」とはリモートリポジトリから情報をダウンロードすることができます。 プッシュ(Push) 「プッシュ(Push)」はリモートリポジトリに自分の変更履歴がアップロードされて、リモートリポジトリ内の変更履歴がローカルリポジトリの変更履歴と同じ状態になります。 クローン(Clone) 「クローン(Clone)」はリモートリポジトリをローカルリポジトリに複製することができます。 コミット(commit) 「コミット(commit)」とは作業用のツリーからリポジトリに情報をコピーすることをいいます。
今回の記事では開発で使われるGitについてまとめたいと思います。 あくまでも個人用の簡単なまとめなので、そこのところはよろしくお願いします。
まずGitの概念についてまとめます。 Gitとはプログラムのソースコードなどを変更履歴を管理してくれる分散型のバージョン管理システムです。 Gitとは「プログラムのソースコードなどを変更履歴を管理してくれる分散型のバージョン管理システム」であり、もともとはLinuxのソースコードを効果的に管理するために開発されました。
このシステムによって複数人での開発の際に誰がどのファイルを「誰が変更したのか」「いつ変更したのか」「どのようなことを変更したのか」などの情報やファイルのバージョン管理などを行うことができます。
また同時にファイルを変更したときに発生する競合を防ぐことができます。
簡単なGitの仕組みを図で表すと以下のようになります。
まずAさんは「Javaファイル①」を共有空間に20XX年1月1日に更新しました。 このとき、Gitによって「誰：Aさん」「ファイル：Javaファイル①」「いつ：20XX年1月1日」などの情報が記録されます。
次にBさんが「Javaファイル②」を共有空間に20XX年1月2日に更新しました。 よってGitによって「誰：Bさん」「ファイル：Javaファイル②」「いつ：20XX年1月2日」などの情報が記録されます。
最後にCさんは「Javaファイル①」を共有空間に20XX年1月2日に更新しました。 このときの「Javaファイル①」はAさんが共有空間に更新したものを使っていると想定しています。 ファイルの種類はAさんが更新したファイルを編集しているので、Cさんが更新しようとしているファイルはAさんの「Javaファイル①」のバージョンが更新されたものになります。 よってGitによって記録される情報は「誰：Cさん」「ファイル：Javaファイル①」「いつ：20XX年1月2日」「バージョン：Aさんが更新した次のバージョン」となります。
Gitではこういった共有空間のことを「リポジトリ(repository)」と呼んでいます。 リポジトリでは各ファイルやディレクトリの管理や変更履歴などの情報を記録をしています。 またリポジトリは2種類あり、上図であったように複数人で共有を行う「リモートリポジトリ」と個人のパソコンに配置するローカルリポジトリがあります。
・リモートリポジトリ ⇒複数人で使用するサーバなどでバージョン管理するために作成したリポジトリのこと。
・ローカルリポジトリ ⇒自分のパソコン内でバージョン管理するために作成したリポジトリのこと。 作成する方法として、ローカルリポジトリを普通に作る方法とリモートリポジトリからコピーする方法がある。
ブランチ(branch)とは変更履歴の流れを分岐して表したものである。 分岐したブランチは他のブランチの影響を受けないため、同じリポジトリ中で複数の変更を同時に進めていくことができます。 つまり自分専用のブランチを作って作業をを行い、作業が終わるとメインのブランチに組み込みます。 ブランチを用いて分岐した例として、以下のような図を作ってみました。 青線は「masterブランチ」といい、基軸となるブランチのことをいいます。 他にも、この図では機能追加のための赤線［XやY］、バグの修正のための緑線［Z］などの分岐が存在します。 それらのブランチを合流させるために「マージ (merge)」を行うことで1つにまとめることができます。
「プル(pull)」とはリモートリポジトリから情報をダウンロードすることができます。
「プッシュ(Push)」はリモートリポジトリに自分の変更履歴がアップロードされて、リモートリポジトリ内の変更履歴がローカルリポジトリの変更履歴と同じ状態になります。
「クローン(Clone)」はリモートリポジトリをローカルリポジトリに複製することができます。
「コミット(commit)」とは作業用のツリーからリポジトリに情報をコピーすることをいいます。
初期設定 $ git config --global user.name "XXXX" $ git config --global user.email "XXXX@hogehoge.com" localリポジトリ作成、追加、remoteへのpush $ git init $ git add -A # 全ファイルをadd $ git add <ファイル名> # 指定ファイルのみadd $ git commit -m "comment" # addされたファイルにコメント付与 $ git commit -am "comment" # addとコメント付与同時実行 $ git remote add origin https://github.com/XXXX/XXXXXX.git $ git push -u origin master remoteからclone クローンは \$ git init と \$ git pull を一括してしくれ、リモートリポジトリの各種設定もしてくれるためミスがない。基本これを使うべき。また \$ git pull は \$ git fetch と \$ git merge を一括したもの。 $ git clone https://github.com/XXXX/XXXXXX.git localの変更確認 $ git status localとremoteの差分表示 $ git diff <ファイル名> commit変更履歴参照 $ git log addの取り消し $ git reset HEAD <ファイル名> commitの取り消し $ git reset --hard HEAD^ --hard：コミット取り消した上でワークディレクトリの内容も書き換えたい場合 --soft：ワークディレクトリの内容はそのままでコミットだけを取り消したい場合 HEAD^：直前のコミット HEAD~{n} ：n個前のコミット commitの修正 $ git commit --amend "新しいコミットメッセージ" push取り消し $ git reset --hard <戻したいコミットのハッシュ値> $ git push -f localブランチ $ git branch <ブランチ名> # ブランチ作成 $ git checkout <ブランチ名> # ブランチ切り替え $ git checkout -b <ブランチ名> # ブランチ作成 & 切り替え $ git branch -m <古いブランチ名> <新しいブランチ名> # ブランチ名変更 $ git push -u origin <ローカルのブランチ名> # ブランチのpush $ git branch <ブランチ名> origin/<ブランチ名> # remoteのブランチをlocalに $ git branch -a # 全てのブランチ確認 git diff <ブランチ名> <ブランチ名> #ブランチ比較
初期設定
$ git config --global user.name "XXXX" $ git config --global user.email "XXXX@hogehoge.com"
localリポジトリ作成、追加、remoteへのpush
$ git init $ git add -A # 全ファイルをadd $ git add <ファイル名> # 指定ファイルのみadd $ git commit -m "comment" # addされたファイルにコメント付与 $ git commit -am "comment" # addとコメント付与同時実行 $ git remote add origin https://github.com/XXXX/XXXXXX.git $ git push -u origin master
remoteからclone クローンは \$ git init と \$ git pull を一括してしくれ、リモートリポジトリの各種設定もしてくれるためミスがない。基本これを使うべき。また \$ git pull は \$ git fetch と \$ git merge を一括したもの。
$ git clone https://github.com/XXXX/XXXXXX.git
localの変更確認
$ git status
localとremoteの差分表示
$ git diff <ファイル名>
commit変更履歴参照
$ git log
addの取り消し
$ git reset HEAD <ファイル名>
commitの取り消し
$ git reset --hard HEAD^
--hard：コミット取り消した上でワークディレクトリの内容も書き換えたい場合 --soft：ワークディレクトリの内容はそのままでコミットだけを取り消したい場合 HEAD^：直前のコミット HEAD~{n} ：n個前のコミット
commitの修正
$ git commit --amend "新しいコミットメッセージ"
push取り消し
$ git reset --hard <戻したいコミットのハッシュ値> $ git push -f
localブランチ
$ git branch <ブランチ名> # ブランチ作成 $ git checkout <ブランチ名> # ブランチ切り替え $ git checkout -b <ブランチ名> # ブランチ作成 & 切り替え $ git branch -m <古いブランチ名> <新しいブランチ名> # ブランチ名変更 $ git push -u origin <ローカルのブランチ名> # ブランチのpush $ git branch <ブランチ名> origin/<ブランチ名> # remoteのブランチをlocalに $ git branch -a # 全てのブランチ確認 git diff <ブランチ名> <ブランチ名> #ブランチ比較
