はじめに これまでWindows+tortoiseGitを使ってきたのだが、最近LinuxやMacでgitをCLIから使うことが多くなった。bashでgitを快適に使うために設定した項目をメモしておく。よく知られている設定だが、何でもアウトプットするのが大事とものの本で読んだので。 環境 Ubuntu 18.04 必要なスクリプトを探す 必要なのは、bashのプロンプトにリポジトリの情報を出力するためのgit-prompt.shと、コマンド補完をしてくれるgit-completion.bash。どちらもgitに同梱されているが、存在するディレクトリはgitのインストール方法によって違うらしいので、要検索。findコマンドは「許可がありません」の警告がうるさいので、/dev/nullにリダイレクトするとよい。 $ find / -name "git-prompt.sh" 2>/dev/null /home/linuxbrew/.linuxbrew/etc/bash_completion.d/git-prompt.sh /home/linuxbrew/.linuxbrew/Cellar/git/2.21.0/etc/bash_completion.d/git-prompt.sh $ find / -name "git-completion.bash" 2>/dev/null /home/linuxbrew/.linuxbrew/share/zsh/site-functions/git-completion.bash /home/linuxbrew/.linuxbrew/etc/bash_completion.d/git-completion.bash /home/linuxbrew/.linuxbrew/Cellar/git/2.21.0/share/zsh/site-functions/git-completion.bash /home/linuxbrew/.linuxbrew/Cellar/git/2.21.0/etc/bash_completion.d/git-completion.bash .bashrcの編集 source /home/linuxbrew/.linuxbrew/etc/bash_completion.d/git-completion.bash source /home/linuxbrew/.linuxbrew/etc/bash_completion.d/git-prompt.sh GIT_PS1_SHOWDIRTYSTATE=true # *:unstaged, +:staged GIT_PS1_SHOWUNTRACKEDFILES=true # %:untracked GIT_PS1_SHOWSTASHSTATE=true # $:stashed GIT_PS1_SHOWUPSTREAM=auto # >:ahead, <:behind GIT_PS1_STATESEPARATOR=':' export PS1='\[\e[34m\]\W\[\e[0m\]\[\e[32m\]$(__git_ps1 " (%s)")\[\e[0m\] \$ ' プロンプトの出力は環境変数PS1によって設定できる。現状の値をecho $PS1で出力し、それをもとに設定するとよい。また、エスケープシーケンスによって様々な情報が出力できたり、色を付けたりできる。詳しくはこの記事などを参照のこと。考慮した情報は次のとおり。 ホスト名\h：ターミナルのタイトルに表示されているので不要 ユーザー\u：切り替えることが少ないので不要 現在のディレクトリ（フルパス）\w：欲しいが、深い階層になったとき、プロンプトの大部分が占められそう 現在のディレクトリ（ベース）\W：上位階層まで表示してほしいタイミングがありそうだが、シンプルなので採用 コマンド__git_ps1でリポジトリに関する情報（ブランチ名など）を出力できる。引数にフォーマットを指定できるので、括弧をつけるなりお好みで。また、各種変数を設定することで、リポジトリの状態を出力ができる： GIT_PS1_SHOWDIRTYSTATE: staged/unstaged fileの有無 GIT_PS1_SHOWUNTRACKEDFILES: untracked fileの有無 GIT_PS1_SHOWSTASHSTATE: stashの有無 GIT_PS1_SHOWUPSTREAM: upstreamに対するahead/behind GIT_PS1_STATESEPARATOR: ブランチ名と上記の情報とを区切る文字の指定。デフォルトは半角空白 詳細はgit-prompt.sh内の説明を参照のこと。特にGIT_PS1_SHOWUPSTREAMが便利だと感じた。pullするタイミングを忘れないので。 おわりに うっかりmasterブランチで作業しちゃった、みたいなことが少なくなった気がする。また、ブランチ名などの補完が聞くようになったおかげで効率が多少上がった気もする。
これまでWindows+tortoiseGitを使ってきたのだが、最近LinuxやMacでgitをCLIから使うことが多くなった。bashでgitを快適に使うために設定した項目をメモしておく。よく知られている設定だが、何でもアウトプットするのが大事とものの本で読んだので。
Ubuntu 18.04
必要なのは、bashのプロンプトにリポジトリの情報を出力するためのgit-prompt.shと、コマンド補完をしてくれるgit-completion.bash。どちらもgitに同梱されているが、存在するディレクトリはgitのインストール方法によって違うらしいので、要検索。findコマンドは「許可がありません」の警告がうるさいので、/dev/nullにリダイレクトするとよい。
$ find / -name "git-prompt.sh" 2>/dev/null /home/linuxbrew/.linuxbrew/etc/bash_completion.d/git-prompt.sh /home/linuxbrew/.linuxbrew/Cellar/git/2.21.0/etc/bash_completion.d/git-prompt.sh $ find / -name "git-completion.bash" 2>/dev/null /home/linuxbrew/.linuxbrew/share/zsh/site-functions/git-completion.bash /home/linuxbrew/.linuxbrew/etc/bash_completion.d/git-completion.bash /home/linuxbrew/.linuxbrew/Cellar/git/2.21.0/share/zsh/site-functions/git-completion.bash /home/linuxbrew/.linuxbrew/Cellar/git/2.21.0/etc/bash_completion.d/git-completion.bash
source /home/linuxbrew/.linuxbrew/etc/bash_completion.d/git-completion.bash source /home/linuxbrew/.linuxbrew/etc/bash_completion.d/git-prompt.sh GIT_PS1_SHOWDIRTYSTATE=true # *:unstaged, +:staged GIT_PS1_SHOWUNTRACKEDFILES=true # %:untracked GIT_PS1_SHOWSTASHSTATE=true # $:stashed GIT_PS1_SHOWUPSTREAM=auto # >:ahead, <:behind GIT_PS1_STATESEPARATOR=':' export PS1='\[\e[34m\]\W\[\e[0m\]\[\e[32m\]$(__git_ps1 " (%s)")\[\e[0m\] \$ '
プロンプトの出力は環境変数PS1によって設定できる。現状の値をecho $PS1で出力し、それをもとに設定するとよい。また、エスケープシーケンスによって様々な情報が出力できたり、色を付けたりできる。詳しくはこの記事などを参照のこと。考慮した情報は次のとおり。
PS1
echo $PS1
\h
\u
\w
\W
コマンド__git_ps1でリポジトリに関する情報（ブランチ名など）を出力できる。引数にフォーマットを指定できるので、括弧をつけるなりお好みで。また、各種変数を設定することで、リポジトリの状態を出力ができる：
__git_ps1
GIT_PS1_SHOWDIRTYSTATE
GIT_PS1_SHOWUNTRACKEDFILES
GIT_PS1_SHOWSTASHSTATE
GIT_PS1_SHOWUPSTREAM
GIT_PS1_STATESEPARATOR
詳細はgit-prompt.sh内の説明を参照のこと。特にGIT_PS1_SHOWUPSTREAMが便利だと感じた。pullするタイミングを忘れないので。
うっかりmasterブランチで作業しちゃった、みたいなことが少なくなった気がする。また、ブランチ名などの補完が聞くようになったおかげで効率が多少上がった気もする。
背景 現場でsvnからgitへの移行を行ったのだが、約6日もかかってしまった・・・ リビジョンも1400程度だったので、自分の感覚だとせいぜい半日ぐらいだと考えていた。 とにかく遅かったのはgit svn fetch。 svnの1つのcommitをfetchするのになにやら数分かかっているような状態。 解決策 なにか方法は無いかと探したところ、「git svn clone」「git svn fetch」のオプションに「--log-window-size=」というのがあり、 こちらに値を設定して実行すると、速くなるという情報を見つけた。 公式：https://git-scm.com/docs/git-svn#Documentation/git-svn.txt---log-window-sizeltngt 日本語訳 Subversionの履歴をスキャンするときに、リクエストごとに個のログエントリを取得します。デフォルトは100です。非常に大きなSubversionリポジトリの場合、クローン / フェッチを適切な時間内に完了させるには、より大きな値が必要になることがあります。ただし、値が大きすぎると、メモリ使用量が増え、タイムアウトが発生する可能性があります。 ということでメモリ使用量を鑑みて調整してあげれば良いと理解するが、 適当に10000ぐらいにして実行。 結果 svnのcommit数が1400程度のうち、600程度が4日経過して終わったのが、 約800はオプション付与の実行後1晩で終わった・・・ 「--log-window-size」を使用している日本語のページはあまり発見できなかったので、あまり使用されていないのか？ 正直、オプションの仕様を理解しきれていないが、無事移行出来たのでこのページが誰かのためになると幸い。 参考：http://blog.leneghan.com/2012/03/experiences-of-using-git-svn-on-large.html
現場でsvnからgitへの移行を行ったのだが、約6日もかかってしまった・・・ リビジョンも1400程度だったので、自分の感覚だとせいぜい半日ぐらいだと考えていた。 とにかく遅かったのはgit svn fetch。 svnの1つのcommitをfetchするのになにやら数分かかっているような状態。
なにか方法は無いかと探したところ、「git svn clone」「git svn fetch」のオプションに「--log-window-size=」というのがあり、 こちらに値を設定して実行すると、速くなるという情報を見つけた。
公式：https://git-scm.com/docs/git-svn#Documentation/git-svn.txt---log-window-sizeltngt
日本語訳
Subversionの履歴をスキャンするときに、リクエストごとに個のログエントリを取得します。デフォルトは100です。非常に大きなSubversionリポジトリの場合、クローン / フェッチを適切な時間内に完了させるには、より大きな値が必要になることがあります。ただし、値が大きすぎると、メモリ使用量が増え、タイムアウトが発生する可能性があります。
ということでメモリ使用量を鑑みて調整してあげれば良いと理解するが、 適当に10000ぐらいにして実行。
svnのcommit数が1400程度のうち、600程度が4日経過して終わったのが、 約800はオプション付与の実行後1晩で終わった・・・
「--log-window-size」を使用している日本語のページはあまり発見できなかったので、あまり使用されていないのか？ 正直、オプションの仕様を理解しきれていないが、無事移行出来たのでこのページが誰かのためになると幸い。
参考：http://blog.leneghan.com/2012/03/experiences-of-using-git-svn-on-large.html
Sublime Text にはパスをコピーできる最強な機能がある！！！ git add 時にいちいちパスを打つのはめんどくせえ、、、 そう感じたそこのあなた パスを知りたいファイル内で右クリック！！！ ※Copy File Path これクリックすると自動でコピーされる(どや)
そう感じたそこのあなた パスを知りたいファイル内で右クリック！！！
※Copy File Path これクリックすると自動でコピーされる(どや)
※Copy File Path
Gitでいろいろミスすることってありますよね。 そのミスを解決するネタ的な記事です。 Gitの全体図 Gitの全体図は以下のような感じです。 図のようにGitの構成として、「リポジトリ」でファイルを管理していきます。そのリポジトリにファイルをもってくるためには「登録(add)」と「コミット(commit)」が必要になってきます。この処理ができた段階で、最後にリモート上にあるリポジトリにプッシュ(push)していきます。プッシュするとリモートに反映されてforkやpullをして、ローカルリポジトリに追記した内容等が反映されます。 参考：https://backlog.com/ja/git-tutorial/intro/intro1_4.html ローカルの取り消し そもそも、ローカル上の変更の取り消しをしたい場合は、checkoutで十分です。 $ git checkout . ただし、新規ファイルの作成で作成したファイル等は削除されませんので、そこは注意（下記コマンドで可能）。 $ git clean -df . addの取り消し $ git reset HEAD . このコマンドによりgit のステージングから取り除かれ、add前の状態になります。 add する前の状態に戻すということなので、コミットした場合の状態は戻していません。 commitの取り消し $ git reset --hard HEAD~ 上記は直前のコミット履歴を消し去る方法です。 他にも、コミットを変更するうえで「revert」と「--amend」があります。 revert git revert コミットのハッシュ値 指定したコミット時点の状態にまで戻し、コミットを行います。（履歴は消えません。） --amend git commit --amend --amendは直前のコミットに上書きするときに使用します。 使用方法は様々ですが、下記の場合でよく用いられます。 コミットメッセージを変更したい時 git rebase失敗した時、コンフリクトを避けるためにコミットを上書きしたい時 pushの取り消し $ git revert [<commit>] $ git push pushに関しては特に変わった操作はなく、コミット履歴で変わったもの（git revert [<commit>]）をpushしましょう。 mergeの取り消し $ git reset --hard HEAD^ addやcommit同様にresetで取り消し可能です。 HEAD^でひとつ前に指定し、--hardで強制的に戻すという意味です。 ハッシュ指定でもOKです（下記コマンド）。 $ git reset --hard aaaa(ハッシュ) pull requestの取り消し git push --delete origin [ブランチ名] pull requestを送ったブランチ名を指定して--deleteオプションつきでpush $ git push --delete origin [ブランチ名] git tag取り消し git tag -d タグ ローカルのタグを取り消し $ git tag -d タグ git push origin :refs/tags/タグ リモートのタグを取り消し $ git push origin :refs/tags/v1.0.6 まとめ Gitの扱いは慎重に。
Gitでいろいろミスすることってありますよね。 そのミスを解決するネタ的な記事です。
Gitの全体図は以下のような感じです。
図のようにGitの構成として、「リポジトリ」でファイルを管理していきます。そのリポジトリにファイルをもってくるためには「登録(add)」と「コミット(commit)」が必要になってきます。この処理ができた段階で、最後にリモート上にあるリポジトリにプッシュ(push)していきます。プッシュするとリモートに反映されてforkやpullをして、ローカルリポジトリに追記した内容等が反映されます。
参考：https://backlog.com/ja/git-tutorial/intro/intro1_4.html
そもそも、ローカル上の変更の取り消しをしたい場合は、checkoutで十分です。
checkout
$ git checkout .
ただし、新規ファイルの作成で作成したファイル等は削除されませんので、そこは注意（下記コマンドで可能）。
$ git clean -df .
$ git reset HEAD .
このコマンドによりgit のステージングから取り除かれ、add前の状態になります。 add する前の状態に戻すということなので、コミットした場合の状態は戻していません。
$ git reset --hard HEAD~
上記は直前のコミット履歴を消し去る方法です。 他にも、コミットを変更するうえで「revert」と「--amend」があります。
revert
--amend
git revert コミットのハッシュ値
指定したコミット時点の状態にまで戻し、コミットを行います。（履歴は消えません。）
git commit --amend
--amendは直前のコミットに上書きするときに使用します。
使用方法は様々ですが、下記の場合でよく用いられます。
git rebase
$ git revert [<commit>] $ git push
pushに関しては特に変わった操作はなく、コミット履歴で変わったもの（git revert [<commit>]）をpushしましょう。
git revert [<commit>]
$ git reset --hard HEAD^
addやcommit同様にresetで取り消し可能です。 HEAD^でひとつ前に指定し、--hardで強制的に戻すという意味です。
HEAD^
--hard
ハッシュ指定でもOKです（下記コマンド）。
$ git reset --hard aaaa(ハッシュ)
git push --delete origin [ブランチ名]
pull requestを送ったブランチ名を指定して--deleteオプションつきでpush
$ git push --delete origin [ブランチ名]
$ git tag -d タグ
$ git push origin :refs/tags/v1.0.6
Gitの扱いは慎重に。
VSCODEでの隠しフォルダの表示の仕方が探してもなかったので記事にしました。 ①下記をクリックして「設定」を選択 ②下記の画面でバツアイコンをクリックすれば隠しフォルダが表示される。（ペンのアイコンで編集できる） 以上で.gitファルダがアプリケーション内に表示されます。
VSCODEでの隠しフォルダの表示の仕方が探してもなかったので記事にしました。 ①下記をクリックして「設定」を選択 ②下記の画面でバツアイコンをクリックすれば隠しフォルダが表示される。（ペンのアイコンで編集できる）
以上で.gitファルダがアプリケーション内に表示されます。
gitとは 分散型バージョン管理システムの一つ。ファイルの状態を好きなときに更新履歴として保存しておくことができ、一度編集したファイルを過去の状態に戻したり、編集箇所の差分を表示したりすることがでる。 古いファイルを元に編集したファイルで、他人の編集した最新ファイルを上書きしようとすると、サーバにアップロードした時に警告が出るため、知らず知らずのうちに他人の編集内容を上書きしてしまうといった失敗は起こらない。(ほぼ さるわかの引用) gitとかgithubとか何やねん(ここからが独自理解) とりあえずgitという素晴らしい分散型バージョン管理システムがあって、リモートリポジトリ(共有のファイル置き場)とローカルリポジトリ(自分のPCに配置するリポジトリ)という概念がある。そして、リモート側を可視化してくれるのがgithubというアプリケーション。コマンド操作を可視化してくれるのがSorcetreeなどのGUIアプリケーション。gitに必要なコマンド操作とは、コミットしてリモートにプッシュしたり、リモートからプルしたり、、など。 ということで今後の方針 githubについてはリポジトリを作成するところまではできたので、GUIアプリケーションを使ってコミットしたりってのをやっていこうと思う。直感的にSorecetreeが良さげだったのといい動画を見つけたので、Sorcetreeでやってみる。 補足 リポジトリとは リポジトリとは、ファイルやディレクトリの状態を記録する場所です。保存された状態は、内容の変更履歴として格納されています。変更履歴を管理したいディレクトリをリポジトリの管理下に置くことで、そのディレクトリ内のファイルやディレクトリの変更履歴を記録することができます。 ディレクトリとは ディレクトリというのは、フォルダのことです。Windowsでは、わかりやすくフォルダと表現しています。WindowsやMacでは フォルダという言葉を使っていますが、コンピュータ全般では ディレクトリという言葉が昔から使われてます。 参考 【git】#01 はるちゃんと学ぶgit講座 コミット編 サルでもわかるGit入門 ディレクトリとは 次回のgitに関する投稿はこちら 苦手とするgit攻略への道 -新人HTML/CSSコーダーはシンプルに考えた-
分散型バージョン管理システムの一つ。ファイルの状態を好きなときに更新履歴として保存しておくことができ、一度編集したファイルを過去の状態に戻したり、編集箇所の差分を表示したりすることがでる。 古いファイルを元に編集したファイルで、他人の編集した最新ファイルを上書きしようとすると、サーバにアップロードした時に警告が出るため、知らず知らずのうちに他人の編集内容を上書きしてしまうといった失敗は起こらない。(ほぼ さるわかの引用)
とりあえずgitという素晴らしい分散型バージョン管理システムがあって、リモートリポジトリ(共有のファイル置き場)とローカルリポジトリ(自分のPCに配置するリポジトリ)という概念がある。そして、リモート側を可視化してくれるのがgithubというアプリケーション。コマンド操作を可視化してくれるのがSorcetreeなどのGUIアプリケーション。gitに必要なコマンド操作とは、コミットしてリモートにプッシュしたり、リモートからプルしたり、、など。
githubについてはリポジトリを作成するところまではできたので、GUIアプリケーションを使ってコミットしたりってのをやっていこうと思う。直感的にSorecetreeが良さげだったのといい動画を見つけたので、Sorcetreeでやってみる。
リポジトリとは、ファイルやディレクトリの状態を記録する場所です。保存された状態は、内容の変更履歴として格納されています。変更履歴を管理したいディレクトリをリポジトリの管理下に置くことで、そのディレクトリ内のファイルやディレクトリの変更履歴を記録することができます。
ディレクトリというのは、フォルダのことです。Windowsでは、わかりやすくフォルダと表現しています。WindowsやMacでは フォルダという言葉を使っていますが、コンピュータ全般では ディレクトリという言葉が昔から使われてます。
【git】#01 はるちゃんと学ぶgit講座 コミット編 サルでもわかるGit入門 ディレクトリとは
苦手とするgit攻略への道 -新人HTML/CSSコーダーはシンプルに考えた-
gitとは 分散型バージョン管理システムの一つ。ファイルの状態を好きなときに更新履歴として保存しておくことができ、一度編集したファイルを過去の状態に戻したり、編集箇所の差分を表示したりすることがでる。 古いファイルを元に編集したファイルで、他人の編集した最新ファイルを上書きしようとすると、サーバにアップロードした時に警告が出るため、知らず知らずのうちに他人の編集内容を上書きしてしまうといった失敗は起こらない。(ほぼ さるわかの引用) gitとかgithubとか何やねん(ここからが独自理解) とりあえずgitという素晴らしい分散型バージョン管理システムがあって、リモートリポジトリ(共有のファイル置き場)とローカルリポジトリ(自分のPCに配置するリポジトリ)という概念がある。そして、リモート側を可視化してくれるのがgithubというアプリケーション。コマンド操作を可視化してくれるのがSorcetreeなどのGUIアプリケーション。gitに必要なコマンド操作とは、コミットしてリモートにプッシュしたり、リモートからプルしたり、、など。 ということで今後の方針 githubについてはリポジトリを作成するところまではできたので、GUIアプリケーションを使ってコミットしたりってのをやっていこうと思う。直感的にSorecetreeが良さげだったのといい動画を見つけたので、Sorcetreeでやってみる。 補足 リポジトリとは リポジトリとは、ファイルやディレクトリの状態を記録する場所です。保存された状態は、内容の変更履歴として格納されています。変更履歴を管理したいディレクトリをリポジトリの管理下に置くことで、そのディレクトリ内のファイルやディレクトリの変更履歴を記録することができます。 ディレクトリとは ディレクトリというのは、フォルダのことです。Windowsでは、わかりやすくフォルダと表現しています。WindowsやMacでは フォルダという言葉を使っていますが、コンピュータ全般では ディレクトリという言葉が昔から使われてます。 参考 【git】#01 はるちゃんと学ぶgit講座 コミット編 サルでもわかるGit入門 ディレクトリとは
この記事は What happens to forks when a repository is deleted or changes visibility? - GitHub Help の日本語訳まとめです。 TL;DR パブリックリポジトリ → fork 元が削除されても fork は消えない プライベートリポジトリ → fork 元が削除されると fork はすべて消える パブリックリポジトリについて パブリックリポジトリが削除されたり、非公開にされた場合： fork は削除されない 既存の fork のうちどれか1つが新しい fork 元になり、残りのリポジトリからの Pull Request はこの選ばれたリポジトリに行くようになる プライベートリポジトリについて プライベートリポジトリが削除されたり、fork したユーザーが fork 元へのアクセス権限を失った場合： fork はすべて削除される ただしローカルクローンは保持される 逆にプライベートリポジトリが公開された場合： fork は自動的には公開されない fork はそれぞれ単独のリポジトリになる cf. fork 権限について https://help.github.com/en/articles/allowing-people-to-fork-a-private-repository-owned-by-your-organization https://help.github.com/en/articles/allowing-people-to-fork-private-repositories-in-your-organization
この記事は What happens to forks when a repository is deleted or changes visibility? - GitHub Help の日本語訳まとめです。
パブリックリポジトリが削除されたり、非公開にされた場合：
プライベートリポジトリが削除されたり、fork したユーザーが fork 元へのアクセス権限を失った場合：
逆にプライベートリポジトリが公開された場合：
cf. fork 権限について https://help.github.com/en/articles/allowing-people-to-fork-a-private-repository-owned-by-your-organization https://help.github.com/en/articles/allowing-people-to-fork-private-repositories-in-your-organization
