シチュエーション yarn.lock など、変更が多数発生するような操作をした後に、ブランチを切り替えるなどすると、gitの参照が重くなりgitの反応が悪くなる時がある 解決策 git gc --prune=all を実行することで、未参照のオブジェクトを全て削除することができる。従って、gitの参照が重いという事象を解決することができる。
yarn.lock など、変更が多数発生するような操作をした後に、ブランチを切り替えるなどすると、gitの参照が重くなりgitの反応が悪くなる時がある
git gc --prune=all を実行することで、未参照のオブジェクトを全て削除することができる。従って、gitの参照が重いという事象を解決することができる。
git gc --prune=all
概要 個々のGitコマンドについての説明記事は多数存在するが、開発作業で利用するコマンドが整理されている記事はあまり見つからなかった。 開発作業は多種多様なためどのケースにも当てはまるものではないが、Gitのリモートリポジトリから資材を取得してからプルリクエストを出すまでの手順を参考として作成。 本文 １．開発着手時 リモートリポジトリをコピーし、作業用ブランチを作成する。 ①開発対象のリポジトリの内容をローカルコピー（ローカルリポジトリの作成） get clone xxxx(クローンURL) ②開発のマージ先ブランチに切り替え（デフォルトブランチがマージ先ブランチになっていない場合） git checkout feature/develop ③マージ先ブランチの最新資材を取得 git pull ④作業用ブランチの作成 git checkout -b feature/xxxxx ２．開発中 修正した資材をコミットし、リモートリポジトリにpushする。 ①修正資材の確認 git status ②修正資材をコミット対象に追加 git add (git statusで確認した資材のパス) ※以下コマンドを使用すると修正資材すべてがコミット対象に追加される。便利だが不要な資材までコミット対象に入ってしまないよう注意。 git add . 誤った資材をaddしてしまった場合、以下のコマンドで取消し。 git reset HEAD ④修正ソースのコミット git commit -m '（コミットコメント）' ⑤ローカルリポジトリのコミット内容をリモートリポジトリへpush git push origin feature/xxxxx ３．開発完了、プルリクエスト提出 マージ先ブランチの修正をマージし、競合を解消させてからプルリクエストを提出する。 ①マージ先へ切り替え git checkout feature/develop ②マージ先ブランチの最新資材をローカルリポジトリに取得 git pull ③マージ元（開発中ブランチ）へ切り替え git checkout feature/xxxxx ④ローカルリポジトリでマージ先ブランチの最新資材をマージ git merge feature/develop ⑤競合が発生した場合は競合を解消（※解消手順は別途作成） ⑥マージ結果をリモートリポジトリにpush git push origin feature/xxxxx ⑦プルリクエストを作成 ４．その他 ・ローカルリポジトリの修正を破棄して、リモートリポジトリの内容に戻したい。 git fetch origin git reset --hard origin/HEAD
個々のGitコマンドについての説明記事は多数存在するが、開発作業で利用するコマンドが整理されている記事はあまり見つからなかった。 開発作業は多種多様なためどのケースにも当てはまるものではないが、Gitのリモートリポジトリから資材を取得してからプルリクエストを出すまでの手順を参考として作成。
リモートリポジトリをコピーし、作業用ブランチを作成する。
①開発対象のリポジトリの内容をローカルコピー（ローカルリポジトリの作成）
get clone xxxx(クローンURL)
②開発のマージ先ブランチに切り替え（デフォルトブランチがマージ先ブランチになっていない場合）
git checkout feature/develop
③マージ先ブランチの最新資材を取得
git pull
④作業用ブランチの作成
git checkout -b feature/xxxxx
修正した資材をコミットし、リモートリポジトリにpushする。
①修正資材の確認
git status
②修正資材をコミット対象に追加
git add (git statusで確認した資材のパス)
※以下コマンドを使用すると修正資材すべてがコミット対象に追加される。便利だが不要な資材までコミット対象に入ってしまないよう注意。
git add .
誤った資材をaddしてしまった場合、以下のコマンドで取消し。
git reset HEAD
④修正ソースのコミット
git commit -m '（コミットコメント）'
⑤ローカルリポジトリのコミット内容をリモートリポジトリへpush
git push origin feature/xxxxx
マージ先ブランチの修正をマージし、競合を解消させてからプルリクエストを提出する。
①マージ先へ切り替え
②マージ先ブランチの最新資材をローカルリポジトリに取得
③マージ元（開発中ブランチ）へ切り替え
git checkout feature/xxxxx
④ローカルリポジトリでマージ先ブランチの最新資材をマージ
git merge feature/develop
⑤競合が発生した場合は競合を解消（※解消手順は別途作成）
⑥マージ結果をリモートリポジトリにpush
⑦プルリクエストを作成
・ローカルリポジトリの修正を破棄して、リモートリポジトリの内容に戻したい。
git fetch origin git reset --hard origin/HEAD
起こったこと gitを使って開発をしている際に、text_HOME.svgというファイル名をtext_home.svgに変更したところnothing to commit, working tree cleanと言われました。 どうやらファイル名の変更がGitに差分として認識されていないよう。 実験 同じような状況を再現してみます。 ディレクトリrename_testに実験用のファイルtext.txtが存在しており、working treeには何もない状態です。 それでは、test.txtをTest.txtにリネームしてみます。 普通にmvコマンドを使ってtext.txtをリネームしてもgitは差分を認識してくれません。 git mvコマンド 次はgit mvを使用してファイルをリネームしてみます。 今度はファイル名の変更が差分として認識されました? 参考 ファイルのリネームはgit mv でやろう
gitを使って開発をしている際に、text_HOME.svgというファイル名をtext_home.svgに変更したところnothing to commit, working tree cleanと言われました。 どうやらファイル名の変更がGitに差分として認識されていないよう。
nothing to commit, working tree clean
同じような状況を再現してみます。
ディレクトリrename_testに実験用のファイルtext.txtが存在しており、working treeには何もない状態です。
rename_test
それでは、test.txtをTest.txtにリネームしてみます。
普通にmvコマンドを使ってtext.txtをリネームしてもgitは差分を認識してくれません。
次はgit mvを使用してファイルをリネームしてみます。
git mv
今度はファイル名の変更が差分として認識されました?
先日、こちらの記事を書きました。 いまさらだけどSubversionからGitへ移行する 今回はその続きでSVNリポジトリー構成のバリエーションの話とGitLabなどを中心としたGitリポジトリー管理ツールとのマッピングの話になります。SVNリポジトリー上に実プロジェクトが複数含まれていた場合になります。SVN上での作業というよりも変換直後の複数実プロジェクトが混在する大きなGitリポジトリーをどうGit上で操作し分割していくかになります。 過去のSVNと最近のGitプロジェクト構成 前回の移行はこんなパターンに主に対応。 myproj ├─trunk ├─branches │ ├─hoge-fix │ └─foo-func └─tags ├─RELEASE_1_0 └─RELEASE_2_0 これは、GitLab/GitHubみたいな Group や Subgroup, Organization や Team みたいな概念がある場合、移行先は例えば、 https://gitlab.example.com/mygroup/myproj.git or git@gitlab.example.com:mygroup/myproj.git などに単純に移行することになるかと思います。 今回は、次のような形式で、GitLabの場合Group相当の部分にSVNのリポジトリーが存在し、その下にサブディレクトリーとして複数のプロジェクトが存在する場合、 myproj ├─trunk │ ├─proj-a │ └─proj-b ├─branches │ ├─proj-a-hoge-fix │ └─proj-b-foo-func └─tags ├─proj-a-RELEASE_1_0 ├─proj-a-RELEASE_2_0 └─proj-b-RELEASE_1_0 これを、 https://gitlab.example.com/mygroup/proj-a.git or git@gitlab.example.com:mygroup/proj-a.git https://gitlab.example.com/mygroup/proj-b.git or git@gitlab.example.com:mygroup/proj-b.git という形でGroup/Projectという形で分けたい場合を想定しています。 作業方法 前回の記事の作業でSVNリポジトリーが次のGitリポジトリーに既に移行できているものとします。 https://gitlab.example.com/mygroup/myproj.git 該当プロジェクトディレクトリーだけを抽出する myproj を proj-a ディレクトリーにcloneし、 $ git clone git@gitlab.example.com:mygroup/myproj.git proj-a $ cd proj-a/ proj-aを抽出しそれ以外を削除 $ git filter-branch --prune-empty --subdirectory-filter proj-a master これで、元の myproj/proj-a/* の内容が proj-a/* に抽出され他は消えます。 ブランチの抽出 $ for BRANCH_NAME in $(git branch -r | grep -e 'origin/myproj-a' | sed -e 's:origin/::');do git checkout "$BRANCH_NAME"; done $ git checkout master 上記は、proj-a のブランチ名付与が proj-a-hoge-fix など proj-aで始まっているのが条件。 そうでない場合は、何が proj-a 用のSVNブランチであったかを予め確認しリストアップしたブランチ名をテキストに書いておいて、for文で回すなどするのが良いかと思われます。あるいは元のSVNリポジトリーのbranchesを確認しつつ手で、 $ git checkout hoge-fix $ git checkout foo-func . . するのも数が少なければ良いかと。 幸い、私のSVN環境ではブランチ名前を統一していたので、上記のようにfor文で回せました。 異なるプロジェクトのタグの削除 proj-a 以外の proj-b, proj-c, ... のタグが残っているので削除する必要があります。 もっと良い方法があるかもしれませんが、 $ for TAG_NAME in $(git tag -l | grep -v 'proj-b.*'); do git tag -d "$TAG_NAME"; done $ for TAG_NAME in $(git tag -l | grep -v 'proj-c.*'); do git tag -d "$TAG_NAME"; done . . こんな感じで消去。 こちらもブランチ同様に proj-a-RELEASE_1.0 など proj-aで始まる名前をルールとしてタグ付けしていたので、上記で回せました。ブランチ同様に予めタグ一覧をテキストなどにしてfor文で回したり、GitLabなどをリモートリポジトリーにするなら、タグは残したままpushし、WebGUI上からポチポチと関係ないものを削除するのもアリかもしれません。 リモートへの登録 まあ、ここらへんは普通にリモート先を変更してpushします。 $ git remote rename origin old-origin $ git remote add origin git@gitlab.example.com:mygroup/proj-a.git $ git push -u origin --all $ git push -u origin --tags 繰り返し 以上を proj-b, proj-c, proj-d, ...で繰り返し、 https://gitlab.example.com/myproj/proj-a https://gitlab.example.com/myproj/proj-b https://gitlab.example.com/myproj/proj-c https://gitlab.example.com/myproj/proj-d などが移行できたら完了。 まとめ 面倒くさいですね。 SVN上でブランチ名、タグ名をある程度ルール化していたから良かったものの、そうでなかったらもっと手間がかかるはず。
先日、こちらの記事を書きました。
いまさらだけどSubversionからGitへ移行する
今回はその続きでSVNリポジトリー構成のバリエーションの話とGitLabなどを中心としたGitリポジトリー管理ツールとのマッピングの話になります。SVNリポジトリー上に実プロジェクトが複数含まれていた場合になります。SVN上での作業というよりも変換直後の複数実プロジェクトが混在する大きなGitリポジトリーをどうGit上で操作し分割していくかになります。
前回の移行はこんなパターンに主に対応。
myproj ├─trunk ├─branches │ ├─hoge-fix │ └─foo-func └─tags ├─RELEASE_1_0 └─RELEASE_2_0
これは、GitLab/GitHubみたいな Group や Subgroup, Organization や Team みたいな概念がある場合、移行先は例えば、
https://gitlab.example.com/mygroup/myproj.git
git@gitlab.example.com:mygroup/myproj.git
などに単純に移行することになるかと思います。
今回は、次のような形式で、GitLabの場合Group相当の部分にSVNのリポジトリーが存在し、その下にサブディレクトリーとして複数のプロジェクトが存在する場合、
myproj ├─trunk │ ├─proj-a │ └─proj-b ├─branches │ ├─proj-a-hoge-fix │ └─proj-b-foo-func └─tags ├─proj-a-RELEASE_1_0 ├─proj-a-RELEASE_2_0 └─proj-b-RELEASE_1_0
これを、
https://gitlab.example.com/mygroup/proj-a.git
git@gitlab.example.com:mygroup/proj-a.git
https://gitlab.example.com/mygroup/proj-b.git
git@gitlab.example.com:mygroup/proj-b.git
という形でGroup/Projectという形で分けたい場合を想定しています。
Group/Project
前回の記事の作業でSVNリポジトリーが次のGitリポジトリーに既に移行できているものとします。
myproj を proj-a ディレクトリーにcloneし、
myproj
proj-a
$ git clone git@gitlab.example.com:mygroup/myproj.git proj-a $ cd proj-a/
proj-aを抽出しそれ以外を削除
$ git filter-branch --prune-empty --subdirectory-filter proj-a master
これで、元の myproj/proj-a/* の内容が proj-a/* に抽出され他は消えます。
myproj/proj-a/*
proj-a/*
$ for BRANCH_NAME in $(git branch -r | grep -e 'origin/myproj-a' | sed -e 's:origin/::');do git checkout "$BRANCH_NAME"; done
$ git checkout master
上記は、proj-a のブランチ名付与が proj-a-hoge-fix など proj-aで始まっているのが条件。
proj-a-hoge-fix
そうでない場合は、何が proj-a 用のSVNブランチであったかを予め確認しリストアップしたブランチ名をテキストに書いておいて、for文で回すなどするのが良いかと思われます。あるいは元のSVNリポジトリーのbranchesを確認しつつ手で、
branches
$ git checkout hoge-fix $ git checkout foo-func . .
するのも数が少なければ良いかと。
幸い、私のSVN環境ではブランチ名前を統一していたので、上記のようにfor文で回せました。
proj-a 以外の proj-b, proj-c, ... のタグが残っているので削除する必要があります。
proj-b
proj-c
もっと良い方法があるかもしれませんが、
$ for TAG_NAME in $(git tag -l | grep -v 'proj-b.*'); do git tag -d "$TAG_NAME"; done $ for TAG_NAME in $(git tag -l | grep -v 'proj-c.*'); do git tag -d "$TAG_NAME"; done . .
こんな感じで消去。
こちらもブランチ同様に proj-a-RELEASE_1.0 など proj-aで始まる名前をルールとしてタグ付けしていたので、上記で回せました。ブランチ同様に予めタグ一覧をテキストなどにしてfor文で回したり、GitLabなどをリモートリポジトリーにするなら、タグは残したままpushし、WebGUI上からポチポチと関係ないものを削除するのもアリかもしれません。
proj-a-RELEASE_1.0
まあ、ここらへんは普通にリモート先を変更してpushします。
$ git remote rename origin old-origin $ git remote add origin git@gitlab.example.com:mygroup/proj-a.git $ git push -u origin --all $ git push -u origin --tags
以上を proj-b, proj-c, proj-d, ...で繰り返し、
proj-d
https://gitlab.example.com/myproj/proj-a
https://gitlab.example.com/myproj/proj-b
https://gitlab.example.com/myproj/proj-c
https://gitlab.example.com/myproj/proj-d
などが移行できたら完了。
面倒くさいですね。 SVN上でブランチ名、タグ名をある程度ルール化していたから良かったものの、そうでなかったらもっと手間がかかるはず。
はじめに GitHubでbranch名を変更したいと思い実践したのでアウトプット。 対処法 ①ターミナルにて現在登録されているbranchを確認 git branch ②変更後の新しいbranch名を登録 git push origin '新しいbranch名' #実際にターミナルに入力する際はシングルクォーテーション(' ')は無視して下さい（以下同様） ③変更したいbranch名を削除 git push origin :'変更したいbranch名' ④変更後のbranch名をプッシュ git push origin '新しいbranch名' これで変更できます！参考にして下さい。
GitHubでbranch名を変更したいと思い実践したのでアウトプット。
①ターミナルにて現在登録されているbranchを確認
git branch
②変更後の新しいbranch名を登録
git push origin '新しいbranch名' #実際にターミナルに入力する際はシングルクォーテーション(' ')は無視して下さい（以下同様）
③変更したいbranch名を削除
git push origin :'変更したいbranch名'
④変更後のbranch名をプッシュ
git push origin '新しいbranch名'
これで変更できます！参考にして下さい。
またやってしまった… 現在オリジナルアプリを開発中なのですが、最近gitにも慣れてきたせいか作業開始前によくブランチを切り忘れるので反省の念も込めて対処法を備忘録として書きます。 解決方法 まだコミットしていない場合 git checkout -b hoge(新しいブランチを作り切り替える） これだけでOKです！ このままコミットを行えばhogeブランチにコミットされます。 コミットされるまでブランチは分かれていない仕様のようです。ですので、変更しているファイルは変わらないです。 hogeブランチからmasterブランチに切り替えると作業開始前の綺麗な状態に戻ります。 コミットしてしまった場合 以下の2つのコマンドを実行 #ブランチを作り移動 git checkout -b hoge #masterをorigin/masterの状態へ戻す。 git branch -f master origin/master -f(force)はあまり使いたくない場合（私はこっちを使います） #masterブランチにいる状態で git branch -m hoge git branch master origin/master #masterブランチがなくなったことで-fオプション無しでブランチが作れる git branch -m, --moveを使うと現在いるブランチをリネームすることができます。 ローカルのmasterがなくなるので、二つ目のコマンドでmasterブランチを再作成します。 結論 リモートにpushする前に気付けば全然なんとかなる。（なお、反省してない模様） 最後までご覧いただきありがとうございます。 もし間違い等ありましたらコメントからご指摘いただけますと幸いです。
現在オリジナルアプリを開発中なのですが、最近gitにも慣れてきたせいか作業開始前によくブランチを切り忘れるので反省の念も込めて対処法を備忘録として書きます。
git checkout -b hoge(新しいブランチを作り切り替える）
これだけでOKです！ このままコミットを行えばhogeブランチにコミットされます。 コミットされるまでブランチは分かれていない仕様のようです。ですので、変更しているファイルは変わらないです。
hogeブランチからmasterブランチに切り替えると作業開始前の綺麗な状態に戻ります。
以下の2つのコマンドを実行
#ブランチを作り移動 git checkout -b hoge #masterをorigin/masterの状態へ戻す。 git branch -f master origin/master
-f(force)はあまり使いたくない場合（私はこっちを使います）
#masterブランチにいる状態で git branch -m hoge git branch master origin/master #masterブランチがなくなったことで-fオプション無しでブランチが作れる
git branch -m, --moveを使うと現在いるブランチをリネームすることができます。 ローカルのmasterがなくなるので、二つ目のコマンドでmasterブランチを再作成します。
git branch -m
--move
リモートにpushする前に気付けば全然なんとかなる。（なお、反省してない模様）
もし間違い等ありましたらコメントからご指摘いただけますと幸いです。
sshで開発する事があり、コマンド操作でgitを利用する事があったのでメモ。 よく使うコマンド リポジトリをダウンロード(clone) $ git clone https://〜〜〜 # リポジトリのURL リモートとローカルの同期（pull） git fetchも含まれている。 $ git pull 履歴の確認 commitIDとコメントが確認できる。 $ git log 差分の確認（diff） 差分ファイルを表示する。 $ git status ファイル内の差分表示する。（ファイルパスはgit statusで出たもの） $ git diff [コミットID | ファイルパス] qキーで確認終了。 差分の取り消し 変更前の状態に戻す。 $ git checkout [ファイルパス] 全てのファイルの差分を取り消す。 $ git checkout . # ピリオドを使用する 変更をindexに保持 差分ファイルをindexに保持する。 $ git add [ファイルパス] -Aオプションは差分が出ている全てのファイルを指定する。 $ git add -A 変更の記録（commit） indexに保持した差分をbranchに記録する。 $ git commit -m "hogehogeメッセージ" branchの確認 自分の使用しているbranchの確認と、branch一覧を表示する。 $ git branch branchの作成 現在いるbranchにて以下のコマンドで新しいbranchを派生させる。 個人で使うには自由、共同開発現場ではgit-flowチートシートの内容が一般的。 $ git checkout -b ブランチ名 branchの切り替え(checkout) $ git checkout 切り替え先のブランチ名 branchの削除 $ git branch -D ブランチ名 commitの削除 git logで表示させた対象のcommitIDまでのcommitを削除する。 $ git reset --hard commitID 変更をリモートに渡す(push) originはとりあえず固定でリモートを指すものと解釈しておく。 $ git push origin ブランチ名 強制的にremoteに渡す。（バージョンがエラーになって解決の糸口が無いときの手段） $ git push -f origin ブランチ名 他branchから差分を取り込む(merge) 開発中のbranchにいる状態でmasterを指定すればmasterの差分が取り込まれる。 競合（conflict）が起こるとエラーが出る。rebaseという手段もあり。 $ git merge 取り込むブランチ名 # 今checkoutしているブランチに取り込まれる タグを付ける $ git tag タグ名 タグにコメント（注釈）を付ける $ git tag -a tag -m "hogehogeテスト" タグのPUSH $ git push origin タグ名 全タグのPUSH $ git push origin --tags タグを消す $ git tag -d ダグ名 リモートのタグを消す ローカルのタグを消した後に以下のコマンド。タグ名の前に:が必要。 $ git push origin :タグ名 タグ一覧 $ git tag 初期設定 履歴に残る名前を設定 $ git config --global user.name "自分の名前" $ git config --global user.email "xxxxx@xxxxxxx.co.jp" 初期化 gitが設定されていないディレクトリで以下を実行するとgitが適用される。 $ git init 初期化後にbranchを作成(master)、変更をindexに保持、変更をbranchに記録(commit)することによって、最初のrepositoryが完成する。 初期化した後にファイルの変更を行うと差分が生まれる。 その他 Serverにrepositoryを用意 Server内でgit用のディレクトリ（xxxx.gitと名前を付ける）に移動し、以下のコマンドを実行。 $ git init --bare --shared ローカルとリモートの紐付け クライアント側で行う。 domainはIPでもURLでも。 xxxx.gitはServer内のgitディレクトリのフルパス。 $ git remote add origin https://[user名@]domain:xxxx.git 子リポジトリの読み込み $ git submodule hogehoge 子リポジトリの更新 $ git submodule update 【参考】originて何 http://dqn.sakusakutto.jp/2011/10/git_push_origin_master.html
sshで開発する事があり、コマンド操作でgitを利用する事があったのでメモ。
$ git clone https://〜〜〜 # リポジトリのURL
git fetchも含まれている。
git fetch
$ git pull
commitIDとコメントが確認できる。
$ git log
差分ファイルを表示する。
$ git status
ファイル内の差分表示する。（ファイルパスはgit statusで出たもの）
$ git diff [コミットID | ファイルパス]
qキーで確認終了。
q
変更前の状態に戻す。
$ git checkout [ファイルパス]
全てのファイルの差分を取り消す。
全てのファイル
$ git checkout . # ピリオドを使用する
差分ファイルをindexに保持する。
indexに保持
$ git add [ファイルパス]
-Aオプションは差分が出ている全てのファイルを指定する。
-A
$ git add -A
indexに保持した差分をbranchに記録する。
$ git commit -m "hogehogeメッセージ"
自分の使用しているbranchの確認と、branch一覧を表示する。
$ git branch
現在いるbranchにて以下のコマンドで新しいbranchを派生させる。 個人で使うには自由、共同開発現場ではgit-flowチートシートの内容が一般的。
git-flowチートシート
$ git checkout -b ブランチ名
$ git checkout 切り替え先のブランチ名
$ git branch -D ブランチ名
git logで表示させた対象のcommitIDまでのcommitを削除する。
git log
$ git reset --hard commitID
originはとりあえず固定でリモートを指すものと解釈しておく。
$ git push origin ブランチ名
強制的にremoteに渡す。（バージョンがエラーになって解決の糸口が無いときの手段）
$ git push -f origin ブランチ名
開発中のbranchにいる状態でmasterを指定すればmasterの差分が取り込まれる。 競合（conflict）が起こるとエラーが出る。rebaseという手段もあり。
rebase
$ git merge 取り込むブランチ名 # 今checkoutしているブランチに取り込まれる
$ git tag タグ名
$ git tag -a tag -m "hogehogeテスト"
$ git push origin タグ名
$ git push origin --tags
$ git tag -d ダグ名
ローカルのタグを消した後に以下のコマンド。タグ名の前に:が必要。
:
$ git push origin :タグ名
$ git tag
$ git config --global user.name "自分の名前" $ git config --global user.email "xxxxx@xxxxxxx.co.jp"
gitが設定されていないディレクトリで以下を実行するとgitが適用される。
$ git init
初期化後にbranchを作成(master)、変更をindexに保持、変更をbranchに記録(commit)することによって、最初のrepositoryが完成する。 初期化した後にファイルの変更を行うと差分が生まれる。
branchを作成(master)
変更をindexに保持
変更をbranchに記録(commit)
repositoryが完成
差分
Server内でgit用のディレクトリ（xxxx.gitと名前を付ける）に移動し、以下のコマンドを実行。
$ git init --bare --shared
クライアント側で行う。 domainはIPでもURLでも。 xxxx.gitはServer内のgitディレクトリのフルパス。
domain
xxxx.git
$ git remote add origin https://[user名@]domain:xxxx.git
$ git submodule hogehoge
$ git submodule update
http://dqn.sakusakutto.jp/2011/10/git_push_origin_master.html
sshで開発する事があり、コマンド操作でgitを利用する事があったので引き継ぎ用。 初期設定 履歴に残る名前を設定 $ git config --global user.name "自分の名前" $ git config --global user.email "xxxxx@xxxxxxx.co.jp" 初期化 gitが設定されていないディレクトリで以下を実行するとgitが適用される。 $ git init 初期化後にbranchを作成(master)、変更をindexに保持、変更をbranchに記録(commit)することによって、最初のrepositoryが完成する。 初期化した後にファイルの変更を行うと差分が生まれる。 普段使い branchの同期（リモートとローカル） git fetchも含まれている。 $ git pull 履歴の確認 commitIDとコメントが確認できる。 $ git log 差分の確認 差分ファイルを表示する。 $ git status ソースコードの差分を表示する。 $ git diff [コミットID | ファイルパス] qキーで確認終了。 差分の取り消し 変更前の状態に戻る。 $ git checkout [ファイルパス] 全てのファイルの差分を取り消す。 $ git checkout . #ピリオドを使用する 変更をindexに保持 差分ファイルをindexに保持する。 $ git add [ファイルパス] -Aオプションは差分が出ている全てのファイルを指定する。 $ git add -A 変更の記録（commit） indexに保持した差分を記録する。 $ git commit -m "hogehogeメッセージ" branchの確認 自分の使用しているbranchの確認と、branch一覧を表示する。 $ git branch branchの作成 現在いるbranchにて以下のコマンドで新しいbranchを派生させる。 個人で使うには自由、共同開発現場ではgit-flowチートシートの内容が一般的。 $ git checkout -b ブランチ名 branchの切り替え $ git checkout 切り替え先のブランチ名 branchの削除 $ git branch -D ブランチ名 commitの削除 対象のcommitIDまでのcommitを削除する。 $ git reset --hard commitID 変更をremoteに渡す(PUSH) originはとりあえず固定でリモートを指すものと解釈しておく。 $ git push origin ブランチ名 強制的にremoteに渡す。（バージョンがエラーになって解決の糸口が無いときの手段） $ git push -f origin ブランチ名 他branchから差分取り込み 開発中のブランチにいる状態でmasterを指定すればmasterの差分が取り込まれる。 競合が起こるとエラーが出る。rebaseというのもあり。 $ git merge ブランチ名 その他 Serverにrepositoryを用意 Server内でgit用のディレクトリ（xxxx.gitと名前を付ける）に移動し、以下のコマンドを実行。 $ git init --bare --shared ローカルとリモートの紐付け クライアント側で行う。 domainはIPでもURLでも。 xxxx.gitはServer内のgitディレクトリのフルパス。 $ git remote add origin https://[user名@]domain:xxxx.git originて何やねん http://dqn.sakusakutto.jp/2011/10/git_push_origin_master.html
sshで開発する事があり、コマンド操作でgitを利用する事があったので引き継ぎ用。
ソースコードの差分を表示する。
変更前の状態に戻る。
$ git checkout . #ピリオドを使用する
indexに保持した差分を記録する。
対象のcommitIDまでのcommitを削除する。
開発中のブランチにいる状態でmasterを指定すればmasterの差分が取り込まれる。 競合が起こるとエラーが出る。rebaseというのもあり。
$ git merge ブランチ名
?Gitの基本 Gitとは、 プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムである。 Gitの準備 １回目だけ実行 $ git init 共有するファイルを選択 $ git add ファイル名 選択したファイルを記録 $ git commit -m "コメント" リモートを登録 $ git remote add origin(リモート名) URL リモートのmasterブランチにファイルをアップロード $ git push origin master リモートのmasterブランチのファイルをダウンロードする $ git pull origin master 変更したファイルを確認 $ git status 現在の変更内容の確認 $ git diff 過去のコミットのログの確認 $ git log 過去の変更内容の確認 $ git log -p
Gitとは、 プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムである。
１回目だけ実行
$ git add ファイル名
$ git commit -m "コメント"
$ git remote add origin(リモート名) URL
$ git push origin master
$ git pull origin master
$ git diff
$ git log -p
前提 自分のところでは仕事用のアカウントがすでに設定されているmacで そこに勉強用を足すという状況でした。 なおこの設定は秘密鍵をgithubアカウント毎に設定しております。 事故が起きないよう~/.sshディレクトリのバックアップや 接続先の確認コマンドをこまめに実施することをオススメいたします。 確認コマンド.sh #コマンドは各リポジトリにて実施 # gitとの接続コマンド元から設定されているもの $ ssh -T github # gitとの接続コマンドプライベート用 $ ssh -T github-private # 現在のリポジトリのリモート接続先を確認 $ git remote -v 既存のリポジトリ設定 まずは既存のリポジトリ設定を整理していきます。 既存のリポジトリはホストがgithub.comで設定されている状況でした。 now.sh $ ssh -T git@github.com Hi username! Youve successfully authenticated, but GitHub does not provide shell access. 今回追加したいのもgithubの、もう１つのアカウントです。 つまり１つのPCからgithubの２つのアカウントにpushできるようにしたいのです。 そこでまずはmacの~/.ssh/configにhostの設定をします。 以下追記します。追記場所はどこでも大丈夫だと思います。 Host github-work User git Port 22 HostName github.com IdentityFile ~/.ssh/id_work_rsa TCPKeepAlive yes IdentitiesOnly yes UseKeychain yes AddKeysToAgent yes これはホスト名と秘密鍵を指定する作業となり github-workというホスト名でssh接続をしようとした際は id_work_rsaという秘密鍵を使ってくださいねとなります。 configファイルを保存したら以下のコマンドで githubと通信ができるか確認してみましょう。 connect.sh $ ssh -T github-work Hi username! Youve successfully authenticated, but GitHub does not provide shell access. ↑このようにこれまでと同じusernameでメッセージが返ってきたらこれまでと同じアカウントに指定の秘密鍵で通信ができているということになります。 エラーが出た場合はgithubの設定を確認して macの秘密鍵とgithub上に設定されている公開鍵が きちんと設定できているかを確認してみてください。 https://github.com/settings/ssh >>参考:GitHubでssh接続する手順~公開鍵・秘密鍵の生成から~ リモートリポジトリを設定（既存ローカルリポジトリ毎に） macの中で管理しているリポジトリ（githubに紐づいているもの）に移動して 以下のコマンドでリモートリポジトリを設定します。 setorigin.sh #mac内の既存リポジトリに移動 $ cd projectA #現状のリモートリポジトリを確認。 $ git remote -v origin git@github.com:username/ripositoryname.git #host名はconfigのHost＝github-private #ユーザーID、リポジトリはgithubのものを設定 #git remote set-url origin [Host名]:[ユーザ名]/[リポジトリ名].git $ git remote set-url origin github-work:username/ripositoryname.git このリモートリポジトリはローカルに複数のリポジトリがあれば ローカルリポジトリごとに設定する必要があります。 この作業で明示的にホスト名：秘密鍵のペアを作成して このホスト名だったらこの秘密鍵を使って リモートにアクセスするという設定ができました。 この設定をする前まではドメインに基づいて秘密鍵を選び ssh接続していたということになります。 新しいgithubアカウントへの接続設定 １.公開鍵、秘密鍵を別名生成 上書きを防ぐため鍵の入っていないディレクトリに移動して以下のコマンドを実行。 対話形式で進めますが以下のように最初に聞かれるところで 名前をid_private_rsaとします。 $ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/Users/(username)/.ssh/id_rsa):id_private_rsa 名前を聞かれた後にssh接続のパスワード設定をするか聞かれますが 今回は勉強用ということもあり何も入力せずにreturnキーを押します。 その後パスワードの確認も未入力でreturn。 2.githubにプライベート用アカウントを作成し 公開鍵をアップロードします。 >>参考:GitHubでssh接続する手順~公開鍵・秘密鍵の生成から~ 3.ローカルPCの~/.ssh/configファイルを設定 プライベート用のHostを設定します。 以下を追記します。 追記場所はおそらくどこでも良いと思います。 Host github-private User git Port 22 HostName github.com IdentityFile ~/.ssh/id_private_rsa TCPKeepAlive yes IdentitiesOnly yes UseKeychain yes AddKeysToAgent yes 4.リポジトリごとのリモートを設定します。 ローカルで新しく作った勉強用リポジトリに移動して以下を実行します。 これによりローカルのリポジトリとgithub上のリモートリポジトリが結びつきます。 addremote.sh #まずはリモートリポジトリを追加します。githubでアカウント作成した時に表示されるやつです。 #これやらずにいきなりsetーurlするとエラーが出ます。fatal: No such remote 'origin $ git remote add origin https://github.com/githubアカウント/リポジトリ名.git #host名はconfigのHost＝github-private #ユーザーID、リポジトリはgithubのものを設定 $ git remote set-url origin [Host名]:[ユーザID]/[リポジトリ].git リモートが設定できたかを確認します。 verify-remote.sh $ git remote -v 5.githubとの接続を確認します。 以下を実行します。 connect.sh #ここで新しいアカウント名が表示されていたらこのPCから新しいgithubアカウントに接続できているということになります。 $ ssh -T github-private 6.テストpush 勉強用リポジトリからテストを行います。 pushして新しいgithubアカウントのリポジトリに反映されれば完了です。 test.sh $ touch test.txt $ git add . $ git commit -m "Test commit" 参考URL 大変お世話になりました。感謝です。 >>参考：GitHubを複数のアカウントで利用するためのメモ >>参考:GitHubでssh接続する手順~公開鍵・秘密鍵の生成から~
自分のところでは仕事用のアカウントがすでに設定されているmacで そこに勉強用を足すという状況でした。 なおこの設定は秘密鍵をgithubアカウント毎に設定しております。
事故が起きないよう~/.sshディレクトリのバックアップや 接続先の確認コマンドをこまめに実施することをオススメいたします。
#コマンドは各リポジトリにて実施 # gitとの接続コマンド元から設定されているもの $ ssh -T github # gitとの接続コマンドプライベート用 $ ssh -T github-private # 現在のリポジトリのリモート接続先を確認 $ git remote -v
まずは既存のリポジトリ設定を整理していきます。 既存のリポジトリはホストがgithub.comで設定されている状況でした。
$ ssh -T git@github.com Hi username! Youve successfully authenticated, but GitHub does not provide shell access.
今回追加したいのもgithubの、もう１つのアカウントです。 つまり１つのPCからgithubの２つのアカウントにpushできるようにしたいのです。
そこでまずはmacの~/.ssh/configにhostの設定をします。 以下追記します。追記場所はどこでも大丈夫だと思います。
Host github-work User git Port 22 HostName github.com IdentityFile ~/.ssh/id_work_rsa TCPKeepAlive yes IdentitiesOnly yes UseKeychain yes AddKeysToAgent yes
これはホスト名と秘密鍵を指定する作業となり github-workというホスト名でssh接続をしようとした際は id_work_rsaという秘密鍵を使ってくださいねとなります。
configファイルを保存したら以下のコマンドで githubと通信ができるか確認してみましょう。
$ ssh -T github-work Hi username! Youve successfully authenticated, but GitHub does not provide shell access.
↑このようにこれまでと同じusernameでメッセージが返ってきたらこれまでと同じアカウントに指定の秘密鍵で通信ができているということになります。
エラーが出た場合はgithubの設定を確認して macの秘密鍵とgithub上に設定されている公開鍵が きちんと設定できているかを確認してみてください。 https://github.com/settings/ssh
>>参考:GitHubでssh接続する手順~公開鍵・秘密鍵の生成から~
macの中で管理しているリポジトリ（githubに紐づいているもの）に移動して 以下のコマンドでリモートリポジトリを設定します。
#mac内の既存リポジトリに移動 $ cd projectA #現状のリモートリポジトリを確認。 $ git remote -v origin git@github.com:username/ripositoryname.git #host名はconfigのHost＝github-private #ユーザーID、リポジトリはgithubのものを設定 #git remote set-url origin [Host名]:[ユーザ名]/[リポジトリ名].git $ git remote set-url origin github-work:username/ripositoryname.git
このリモートリポジトリはローカルに複数のリポジトリがあれば ローカルリポジトリごとに設定する必要があります。 この作業で明示的にホスト名：秘密鍵のペアを作成して このホスト名だったらこの秘密鍵を使って リモートにアクセスするという設定ができました。
この設定をする前まではドメインに基づいて秘密鍵を選び ssh接続していたということになります。
上書きを防ぐため鍵の入っていないディレクトリに移動して以下のコマンドを実行。
対話形式で進めますが以下のように最初に聞かれるところで 名前をid_private_rsaとします。
$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/Users/(username)/.ssh/id_rsa):id_private_rsa
名前を聞かれた後にssh接続のパスワード設定をするか聞かれますが 今回は勉強用ということもあり何も入力せずにreturnキーを押します。 その後パスワードの確認も未入力でreturn。
公開鍵をアップロードします。 >>参考:GitHubでssh接続する手順~公開鍵・秘密鍵の生成から~
プライベート用のHostを設定します。 以下を追記します。 追記場所はおそらくどこでも良いと思います。
Host github-private User git Port 22 HostName github.com IdentityFile ~/.ssh/id_private_rsa TCPKeepAlive yes IdentitiesOnly yes UseKeychain yes AddKeysToAgent yes
ローカルで新しく作った勉強用リポジトリに移動して以下を実行します。 これによりローカルのリポジトリとgithub上のリモートリポジトリが結びつきます。
#まずはリモートリポジトリを追加します。githubでアカウント作成した時に表示されるやつです。 #これやらずにいきなりsetーurlするとエラーが出ます。fatal: No such remote 'origin $ git remote add origin https://github.com/githubアカウント/リポジトリ名.git #host名はconfigのHost＝github-private #ユーザーID、リポジトリはgithubのものを設定 $ git remote set-url origin [Host名]:[ユーザID]/[リポジトリ].git
リモートが設定できたかを確認します。
$ git remote -v
以下を実行します。
#ここで新しいアカウント名が表示されていたらこのPCから新しいgithubアカウントに接続できているということになります。 $ ssh -T github-private
勉強用リポジトリからテストを行います。 pushして新しいgithubアカウントのリポジトリに反映されれば完了です。
$ touch test.txt $ git add . $ git commit -m "Test commit"
大変お世話になりました。感謝です。 >>参考：GitHubを複数のアカウントで利用するためのメモ >>参考:GitHubでssh接続する手順~公開鍵・秘密鍵の生成から~
はじめに チーム開発をしている際に、プルリクエストを作成したところconflictが発生した。 他のファイルはメンバーに相談しながら解消できたが、 Railsで自動更新されるschema.rbファイルは勝手に修正して良いのだろうか？と詰まった。 解消 以下の記事を参考に修正を試みた。 コンフリクトしたschema.rbをきれいにマージする手順 ターミナル $ git checkout master を実行しようとしたところ、 error: you need to resolve your current index first と出てしまい、ブランチの切り替えが出来なかった。 ターミナル git merge --abort これで一旦前の状態に戻すことで、ブランチの切り替えが可能になりました。以降は、上記の記事を参考にコンフリクトを解消し、マージすることが出来ました。 参考記事 【git】マージしたけどやっぱりやめたい時のやり方4種類
チーム開発をしている際に、プルリクエストを作成したところconflictが発生した。 他のファイルはメンバーに相談しながら解消できたが、 Railsで自動更新されるschema.rbファイルは勝手に修正して良いのだろうか？と詰まった。
以下の記事を参考に修正を試みた。 コンフリクトしたschema.rbをきれいにマージする手順
を実行しようとしたところ、 error: you need to resolve your current index first と出てしまい、ブランチの切り替えが出来なかった。
error: you need to resolve your current index first
git merge --abort
これで一旦前の状態に戻すことで、ブランチの切り替えが可能になりました。以降は、上記の記事を参考にコンフリクトを解消し、マージすることが出来ました。
参考記事 【git】マージしたけどやっぱりやめたい時のやり方4種類
はじめに ここではGit初心者向けに、よく使うGitのコマンド一覧とGitとGitHubの基本的な使い方を紹介します。 また最初にGitを使う際の基本的なターミナルのコマンドも紹介しています。 環境 mac OS Catalina バージョン10.15.5 git version 2.26.2 ターミナルの基本的なコマンド $ pwd 現在のフォルダ場所(ディレクトリ階層)の表示 $ ls ファイルやディレクトリの表示 ls -l ファイルやディレクトリを詳細まで表示 $ ls -a 隠しを含んだファイルやディレクトリの表示 ls -la 隠しを含んだファイルやディレクトリを詳細まで表示 $ cd ~~ 〜のフォルダに移動 $ cd .. 下の階層に移動 $ history コマンド履歴の表示 $ clear 画面をリセット Gitのコマンド Gitのバージョン確認 $ git --version 作業ディレクトリにGitを使う宣言をする $ git init GitHubのリポジトリをローカルにクローンする $ git clone git@github.com:【ユーザー名】/【リポジトリ名】.git ブランチを確認する $ git branch ブランチを新たに作成 $ git branch [ブランチ名] ブランチを削除 $git branch -d [ブランチ名] 現在のステータス確認 $ git status ステージングエリアにあげる $ git add [ファイル名] $ git add . git add [ファイル名]：[ファイル名]をステージングエリアにあげる git add . ：全てをステージングエリアにあげる。 コミットする $ git commit "コミット名" コミットメッセージを１行以内に納める $ git commit -m "コミット名" 一つ前のコミットと統合する $ git git commit --amend -m "コミット名" Gitのログを確認する $ git log Gitのlogを簡潔にまとめて表示する $ git log --oneline GitHubに初めてプッシュする $ git push origin [ブランチ名] GitHubにプッシュする（2回目以降） $ git push ローカルリポジトリをリモートリポジトリに同期する $ git fetch origin リモートブランチと同期したデータ、追跡ブランチをローカルリポジトリに取り込む $ git merge origin / [ブランチ名] mergeとfetchをまとめて行う $ git pull origin [ブランチ名] 前の状態に戻る $ git checkout --[ファイル名] 編集した箇所を表示 $ git diff ステージングエリアにあげた場合、コミットで変更されるファイルが分かる $ git diff --cached コミットした後の編集されたファイルが分かる $ git diff -r [ID名] git addを取り消す $ git reset HEAD または $ git reset HEAD [ファイル名] 直前に戻る $ git reset --hard HEAD 1つ前に戻る $ git reset --hard HEAD^ 指定されたlogに戻る $ git reset --hard [ID] マージを始めた頃のブランチに戻る $ git reset --hard ORIG_HEAD リモートリポジトリ削除 $ git remote rm origin 参考にしたサイト Gitコマンド一覧
ここではGit初心者向けに、よく使うGitのコマンド一覧とGitとGitHubの基本的な使い方を紹介します。 また最初にGitを使う際の基本的なターミナルのコマンドも紹介しています。
mac OS Catalina バージョン10.15.5 git version 2.26.2
$ pwd 現在のフォルダ場所(ディレクトリ階層)の表示
$ pwd
$ ls ファイルやディレクトリの表示 ls -l ファイルやディレクトリを詳細まで表示 $ ls -a 隠しを含んだファイルやディレクトリの表示 ls -la 隠しを含んだファイルやディレクトリを詳細まで表示
$ ls
ls -l
$ ls -a
ls -la
$ cd ~~ 〜のフォルダに移動 $ cd .. 下の階層に移動
$ cd ~~
$ cd ..
$ history コマンド履歴の表示
$ history
$ clear 画面をリセット
$ clear
$ git --version
$ git clone git@github.com:【ユーザー名】/【リポジトリ名】.git
$ git branch [ブランチ名]
$git branch -d [ブランチ名]
$ git add [ファイル名] $ git add .
git add [ファイル名]：[ファイル名]をステージングエリアにあげる git add . ：全てをステージングエリアにあげる。
$ git commit "コミット名"
$ git commit -m "コミット名"
$ git git commit --amend -m "コミット名"
$ git log --oneline
$ git push origin [ブランチ名]
$ git push
$ git fetch origin
$ git merge origin / [ブランチ名]
$ git pull origin [ブランチ名]
$ git checkout --[ファイル名]
$ git diff --cached
$ git diff -r [ID名]
$ git reset HEAD または $ git reset HEAD [ファイル名]
$ git reset --hard HEAD
$ git reset --hard HEAD^
$ git reset --hard [ID]
$ git reset --hard ORIG_HEAD
$ git remote rm origin
Gitコマンド一覧
フォークしたリポジトリを最新化したい GitHubでOSSに参加する時、 GitHub上の対象のOSSのリポジトリをフォークしリモートリポジトリを作成 GitHub上のリモートリポジトリをローカルにクローン ブランチを切って修正して commit リモートリポジトリへ push してプルリク のような流れを踏むと思います。 ただ、自分が修正を進めている間にも、フォーク元のオリジナルのリポジトリでは開発が進んでいます。 プルリクがコンフリクトしないように4.の前にオリジナルのリポジトリの開発差分をマージする必要があります。 その方法を調べたのでメモします。 方法 # ローカルのリポジトリに移動 $ cd ローカルのリポジトリのパス # GitHubのフォーク元のリポジトリをリモートブランチに追加する $ git remote add upstream https://github.com/フォーク元オーナー名/フォーク元リポジトリ名.git # リモートブランチの一覧を確認するとのフォーク元のリポジトリが追加されている git remote -v > origin ... > origin ... > upstream https://github.com/フォーク元オーナー名/フォーク元リポジトリ名.git (fetch) > upstream https://github.com/フォーク元オーナー名/フォーク元リポジトリ名.git (push) # フォーク元の master ブランチの変更差分をフェッチます。 # ※upstream/master に保管されます $ git fetch upstream # masterブランチをチェックアウトしフォーク元の差分をマージします。 $ git checkout master $ git merge upstream/master # 最後に自分の修正ブランチに master ブランチを取り込みます。コンフリクトが出たら解決します。 $ git checkout 自分の修正ブランチ $ git merge master 上記でフォークしたリポジトリを最新化し修正差分も自分のブランチに取り込めたのでコンフリクトなくプルリクを送ることができます。 参考 フォークにリモートを設定する https://docs.github.com/ja/github/collaborating-with-issues-and-pull-requests/configuring-a-remote-for-a-fork フォークを同期する https://docs.github.com/ja/github/collaborating-with-issues-and-pull-requests/syncing-a-fork
GitHubでOSSに参加する時、
のような流れを踏むと思います。
ただ、自分が修正を進めている間にも、フォーク元のオリジナルのリポジトリでは開発が進んでいます。 プルリクがコンフリクトしないように4.の前にオリジナルのリポジトリの開発差分をマージする必要があります。
その方法を調べたのでメモします。
# ローカルのリポジトリに移動 $ cd ローカルのリポジトリのパス # GitHubのフォーク元のリポジトリをリモートブランチに追加する $ git remote add upstream https://github.com/フォーク元オーナー名/フォーク元リポジトリ名.git # リモートブランチの一覧を確認するとのフォーク元のリポジトリが追加されている git remote -v > origin ... > origin ... > upstream https://github.com/フォーク元オーナー名/フォーク元リポジトリ名.git (fetch) > upstream https://github.com/フォーク元オーナー名/フォーク元リポジトリ名.git (push) # フォーク元の master ブランチの変更差分をフェッチます。 # ※upstream/master に保管されます $ git fetch upstream # masterブランチをチェックアウトしフォーク元の差分をマージします。 $ git checkout master $ git merge upstream/master # 最後に自分の修正ブランチに master ブランチを取り込みます。コンフリクトが出たら解決します。 $ git checkout 自分の修正ブランチ $ git merge master
上記でフォークしたリポジトリを最新化し修正差分も自分のブランチに取り込めたのでコンフリクトなくプルリクを送ることができます。
フォークにリモートを設定する https://docs.github.com/ja/github/collaborating-with-issues-and-pull-requests/configuring-a-remote-for-a-fork
フォークを同期する https://docs.github.com/ja/github/collaborating-with-issues-and-pull-requests/syncing-a-fork
git cloneする時でのエラー。 本番環境用のグループにpg gemを追加しましたが、この開発環境にはインストールしないようにbundle installを実行します。 bundle install --without production
git cloneする時でのエラー。 本番環境用のグループにpg gemを追加しましたが、この開発環境にはインストールしないようにbundle installを実行します。
bundle install --without production
