git

$ git br -m [new-branch-name]

複数回のコミットを取りやめたいけど、コミットはしたくない場合:

$ git show  | git apply -R
$ git show  | git apply -R
$ ...

ここで commit-ID1, 2, ... は、 git log で出てくる commit-ID

• git shortlog -sne

参考: https://stackoverflow.com/q/1486819/921859

$ git log --stat --graph --tags --decorate=full

(cd to workdir)
$ wget https://raw.githubusercontent.com/git/git/master/contrib/completion/git-completion.bash
$ wget https://raw.githubusercontent.com/git/git/master/contrib/completion/git-prompt.sh
$ sudo mv git-completion.bash /etc/bash_completion.d/
$ chmod a+x git-prompt.sh 
$ sudo mv git-prompt.sh /usr/local/bin/

ここで

1. git subtree

   $ git subtree split -P ext_site -b ext_site

2. 新リポジトリを適当なところに作成

   $ cd ~/temp
   $ mkdir ext_site
   $ cd ext_site
   $ git init
   $ git pull W ext_site

3. リモートリポジトリ R を作成
4. リモートに push

   $ git remote add origin R
   $ git push origin -u master

5. W/ext_site は削除

   $ cd W/
   $ git rm -rf ext_site

参考:

https://stackoverflow.com/questions/359424/detach-move-subdirectory-into-separate-git-repository/17864475#17864475

1. ファイル削除のコミットをリスト:

   $ git log --diff-filter=D --summary

2. チェックアウト

   $ git co $commit~1 filename

   • ここで $commit は具体的なコミット値。 例えば 25df22a17702ce71136a137582575f0b8b80bc66

補足: tilde(~)とcaret(^)の違いを今日知ったw: https://qiita.com/chihiro/items/d551c14cb9764454e0b9

see https://stackoverflow.com/a/953573/921859

今までホームディレクトリを git で管理していたのだけど、 サイズが増えてきて git操作のたびに時間がかかるのが辛くなってきた。

で、小分けに分けることに。

1. 作業用に close

   w$ git clone GIT-URL
   w$ cd [MYNAME]

2. サブディレクトリだけ取り出す

   w$ git filter-branch --prune-empty --subdirectory-filter DIR/TO/SUB-DIR master

3. リモートにリポジトリ作成

   r$ mkdir -p DIR/TO
   r$ git --git-dir DIR/TO/SUB-DIR.git init --shared=all --bare

4. サブディレクトリ用の新しいリポジトリを指定
   1. 現状確認

      w$ git remote -v
      origin  GIT-URL (fetch)
      origin  GIT-URL (push)

   2. 新リポジトリを拡張子 .git で作成
   w$ git remote set-url origin NEW-GIT-URL.git w$ git remote -v origin NEW-GIT-URL.git (fetch) origin NEW-GIT-URL.git (push)
5. remote に push

   w$ git push -u origin master

参考: https://help.github.com/articles/splitting-a-subfolder-out-into-a-new-repository/

[+] [-] 1.8.1. main / master を origin に登録

[+] [-] 1.9.1. 特定のコミットからブランチを作る

[+] [-] 1.9.2. ブランチ上の diff

[+] [-] 1.9.3. ブランチ上の tag と master との関係

[+] [-] 1.9.4. 別のリモートに特定のブランチを push

[+] [-] 1.9.5. リモートブランチをローカルに持ってくる

[+] [-] 1.9.6. ローカルで開発した branch を リモートに push

[+] [-] 1.9.7. 古いコミットから新たにブランチを切る(作成する)

[+] [-] 1.9.8. ブランチ名をプロンプトに表示

[+] [-] 1.9.9. ブランチ名の変更

[+] [-] 1.9.10. ローカルブランチとリモートブランチのひも付け

[+] [-] 1.9.11. コマンド例

Rails 3 対応の edgar2 なるものを作り、 既存 edgar プロジェクトの別リポジトリとする。

1. SourceForge shell service で git サブディレクトリを作成

   my$ ssh -t [MYNAME],jjedgar@shell.sourceforge.net create
     :
   sf$ umask 002                           # 多分要らない
   sf$ cd /home/scm_git/jjedgar/       
   sf$ git --git-dir edgar2 init --shared=all --bare

   ここで、プロンプトは下記:

   my$:	私のPC の shell
   sf$:	SourceForge shell

2. sourceforge edgar2 に、ローカルで開発していたものを push

   my$ git remote add origin ssh://[MYNAME]@jjedgar.git.sourceforge.net/gitroot/jjedgar/edgar2
   my$ git config branch.master.remote origin
   my$ git config branch.master.merge refs/heads/master
   my$ git push origin master
   my$ git push --all
   my$ git push --tags

3. 確認を兼ねて clone してみる。

   my$ cd SOME_TEMP_DIR    # 適当なディレクトリに移動
   my$ git clone ssh://[MYNAME]@jjedgar.git.sourceforge.net/gitroot/jjedgar/edgar2
   my$ cd edgar2/
   
   　　　_、_
   　（　,_ﾉ` ） 　 　　　n
   ￣　　 　 ＼　 　 （ E） ｸﾞｯｼﾞｮﾌﾞ!!
   ﾌ 　　　 /ヽ ヽ_／／

[+] [-] 1.10.1. 参考

誤って commit したが、生成されるデータなので(例: *.o, *.exe)リポジトリ の対象とさせないよう .gitignore に登録しても、後からは効かない。下記で対処:

$ git rm -n --cached '*.exe'      # dry-run
$ git rm    --cached '*.exe'      # real-run

参考: http://stackoverflow.com/questions/6535362/gitignore-after-commit

git filter-branch -f --env-filter "GIT_AUTHOR_NAME='Newname'; GIT_AUTHOR_EMAIL='newemail'; GIT_COMMITTER_NAME='Newname'; GIT_COMMITTER_EMAIL='newemail';" HEAD

参考: http://stackoverflow.com/questions/750172/how-do-i-change-the-author-of-a-commit-in-git

st(=status), co(=checkout), ci(=commit, checkin の意味), br(=branch) のショートカット:

$ git config --global alias.st status
$ git config --global alias.co checkout
$ git config --global alias.ci commit
$ git config --global alias.br branch

便利！(・∀・)

例: 'def category' というメソッドを消してしまったリビジョンを検索

$ git bisect start
$ git bisect bad
$ git bisect good NNNNN     # ok だった rev.
$ git bisect run grep 'def category' file/you/want/to/search
  :
d243a1e9c4501e0a222b7e098dead8611c0420b0 is the first bad commit  <---- !!
commit d243a1e9c4501e0a222b7e098dead8611c0420b0
  :

$ cd /etc
$ sudo git init
$ sudo vi .gitignore    # *~ を追加
*~
/ld.so.cache
/aliases.db
/apparmor.d/cache
/alternatives/
/ssl/certs
/ConsoleKit
$ sudo git add .
$ sudo env EDITOR=vi git commit -v

[+] [-] 1.15.1. リモートにプッシュすることでバックアップとする

1. 以下のグローバルセッティングをする:

   $ git config branch.autosetuprebase always

2. or, 以下をリポジトリごとにセットする:

   $ git config branch.branch-name.rebase true

3. or, git push の前に rebase すること。

参考: http://stevenharman.net/blog/archive/2011/06/09/git-pull-with-automatic-rebase.aspx

1. init。.git/config に submodule エントリが作成される:

   $ git submodule init

2. update。ファイルが fetch される:

   $ git submodule update

$ git submodule add http://HOST/PATH localpath
$ git diff --cached SUBMODULE   # ディレクトリエントリであることを確認
$ js .gitmodules                # 必要に応じて修正
$ git commit -v -a --dry-run    # 確認
$ git commit -v -a

$ git tag NEW OLD
$ git tag -d OLD

参考: stackoverflow サイト

$ git checkout stash@{0} -- db/seeds.rb

参考: http://stackoverflow.com/questions/1105253/how-would-i-extract-a-single-file-or-changes-to-a-file-from-a-git-stash

他に、 stash からパッチを作成する方法:

$ git stash show -p

$ git add -p ...

会話的に y/n/他でどの変更部分をコミットに含めるか指定できる。

git のインデックスの存在理由が少し分かった。やっと…。 コミットに向けてのステージングである、と考えればすっきりする。

$ git diff HEAD^ app lib >app-x.y.z.patch

適用先にて

$ patch -p1 --dry-run 

$ git reset --soft HEAD^
$ edit
$ git commit -a -c ORIG_HEAD

参考: EXAMPLES of 'man git-reset'

$ git stash               # 作業の退避
(クリーンな状態)
$ git stash list          # 退避した作業の一覧
$ git stash pop           # 作業の復帰

$ sudo apt-get install git-core

$ git config --global user.name 'MYNAME'
$ git config --global user.email 'MYNAME@MYDOMAIN'
$ git config --global color.ui auto
$ git config --global core.editor "jstar"
$ git config --global core.pager "less -R -X"

(2013/01/17) pager, 'lv -c' を今まで使っていたけど、画面がクリアされるのが 気に入らなかった。less でそれができるのでそれに変更してみる。

$ mkdir work
$ cd work
$ git init

1. localで開発していたものを SourceForge git に push。最初に必要な作業:

$ cd ~/nosvn/juli/repo    # it is juli's local_project
$ git remote add origin ssh://[MYNAME]@jjjuli.git.sourceforge.net/gitroot/jjjuli/jjjuli
$ git config branch.master.remote origin
$ git config branch.master.merge refs/heads/master

以下の実行前に、shell service(後述)が必要か？:

$ git push origin master

1. 後は git push だけで ok?

[+] [-] 3.1.1. Shell service

[+] [-] 3.1.2. juli_doc を共有化する

app, lib, public に限って(vendor/ 以下にいろいろパッケージを入れたので) v0.91.1 との差分をとる:

git diff 958a057f154d7c63ff252783ca547ca5204ac017 -- app lib public/

[+] [-] 3.2.1. タグ

[+] [-] 3.2.2. git下の packaging

[+] [-] 3.2.3. commit ログの訂正

git branch --track P-branch P
git branch
git checkout P-branch
git log
git reset --hard HEAD
git svn rebase
git svn fetch

ここで、P-branch

1. github の「pull リクエスト」と同等のことが出来る。
   • 「特定のユーザには特定のブランチのみ push してもらい、origin には触らせない」という設定も gitolite でできるようになるらしい。
2. 継続的インテグレーションは死んだ と言うサイトにて(やや「釣り」なタイトルではあるけれどw)、 問題とその解決策を提起してくれている「読み取り専用マスタブランチ」が設定可能。

1. セットアップ
   1. インストール

      s$ sudo apt-get install gitolite   # Ubuntu の場合
      s$ sudo apt     install gitolite3  # Ubuntu16.04 の場合

2. 初期管理者登録
   ※ 実行者に sudo 権限があるのが前提。
   1. 管理者公開鍵(/tmp/yarnanaio.pub とする)を作業域にコピー。

      s$ gl-setup /tmp/yarnanaio.pub
      ...
      hit enter...

   2. .gitolite.rc 編集画面になるが、何もせず終了(vi の場合は 「ESC:（コロン）q」)
   3. clone

      C$ git clone gitolite3@GITOLITE-SERVER.jp:gitolite-admin.git  # Ubuntu16.0
      C$ git clone ssh://GITOLITE-SERVER.jp/gitolite-admin.git      # CentOS-6

      ※ ここで ssh://GITOLITE-SERVER.jp は user=gitolite でアクセスするよう ~/.ssh/config で以下のように設定しておく:

      host GITOLITE-SERVER.jp
        user          gitolite

3. ユーザ登録
   1. ユーザ(yaruo としよう)の公開鍵(id_rsa.pub としよう)をもらう。 ここでは /tmp/yaruo.pub にその鍵があるとする。
   2. gitolite-admin リポジトリに移動
   3. yaruo の公開鍵を yaruo.pub として keydir/ にコピーし、登録:

      C$ cp /tmp/yaruo.pub keydir/
      C$ git add keydir/yaruo.pub
      C$ git commit -v keydir/yaruo.pub

   4. conf/gitolite.conf 編集

      C$ vi conf/gitolite.conf
      ...
      @admins               = me
      @project_A_developer  = yaruo
      
      repo testing
        RW+     =   @all
      
      repo project_A
        RW dev-     = @project_A_developer
        RW+         = @admins

      • このファイルで、@project_A_developer に属するユーザは dev-* ブランチでのみ RW できるようになる(origin には push できない)。
   5. push

      C$ git push

4. 既存リポジトリ(例: prefix/my_proj)を gitolite に登録
   1. gitolite-admin で my_proj リポジトリを新規作成
      1. gitolite-admin リポジトリに移動
      2. リポジトリを gitolite.conf に追加。例:

         C$ vi conf/gitolite.conf
         ...
         repo prefix/my_proj
           RW+     =   admin
           R       =   read-only-user
         C$ git commit -v -a
         C$ git push

         gitolite3@GITOLITE-SERVER.jp:/var/lib/gitolite3/repositories/prefix/my_proj.git が作成されているのを確認。
   2. write権のあるユーザにて既存リポジトリの remote リポジトリの１つとして "gitolite" を追加し、push

      c$ git remote add origin ssh://gitolite3@GITOLITE-SERVER.jp/prefix/my_proj
      #  git remote add origin ssh://GITOLITE-SERVER.jp/prefix/my_proj            # CentOS-6 の場合
      c$ git push origin master
      c$ git push origin --all
      c$ git push origin --tags

[+] [-] 5.4.1. アクセス権の確認

ローカルでの変更を放棄するケース:

$ git reset -- test/fixtures/a.yml
$ git diff test/fixtures/a.yml
$ git checkout test/fixtures/a.yml

[+] [-] 6.2.1. Edgar

[+] [-] 6.2.2. /home/[MYNAME]

[+] [-] 6.2.3. iway.dip.jp での作業

git svn clone --stdlayout SVN_REPO_URL

[+] [-] 6.3.1. svnでの認証

[+] [-] 6.3.2. svn ブランチにのみ git を使う方法。

[+] [-] 6.3.3. svn のサブディレクトリに git を使う方法

コミット

svn commit                              git commit
                                        git svn dcommit

リポジトリの反映

svn up[date]                            git svn rebase

作業ファイルの破棄

svn revert ...                          git checkout filename
                                        git reset --hard HEAD

diff

svn diff -c rev                         git show COMMIT-ID

1. pager がサポートされているので、いちいち svn log ... | lv とかしなくて済む。
2. git grep がサポートされている。
3. log コマンドが速い
4. 電車で移動中などの offline 環境でもコミットできる。
5. merge が簡単

上から重要度 高→低 の順。git の特徴である「merge が簡単」という点は、 まだそれほど使ってないので実感したメリットとしてはそれほど高くない。 でも、svn の merge は確かに苦痛だったなぁ。 だからここに挙げないわけにはいかないな、やはり。

分散型、という点は、直接には体感できてないのだけど、3. 4. は 分散型だからこそできるわけなので、これはやはり大きい。