忍者ブログ
日々の研究生活のメモ書きなど

■ 過去記事 : 【git】ひとつ前の状態に戻りたい git reset --soft HEAD^

と少し関係がある
git reset --soft HEAD^
で一つ前のコミットをする直前に戻ったとして、その中で
git rm hoge.c
としていた場合、この操作を取り消してコミットを分割とかしたいのにそもそも
git checkout hoge.c
ができない・・・・


そういうときは
git reset HEAD hoge.c
git checkout hoge.c
でOK





PR
git reset --soft HEAD^
で今、修正している他のソースコードはそのままにしてコミットだけを取り消すことができる

例えばhoge.cを修正して
git add hoge.c
git commit -m "Added hoge.c"
という状態で
git reset --soft HEAD^
すると、
hoge.cがまだcommitされていない状態に戻る


--softの代わりに、--hard もあるけどそちらはhoge.cの修正が完全になかったことになるので、
おそらくそちらを使いたい人はあまりいないはず









git status
とすると、configureで生成したファイルがワッサーーーと並ぶので、一番肝心の修正したファイルリストが隠れてしまう
そこで
git status | more
としていたが、
今度はcolorでなくなってしまう


ググったら解決方法が書いてあった

■ 参考 : git/git status|lessとかでカラー表示にならない件

git config --global color.branch always
git config --global color.diff always
git config --global color.interactive always
git config --global color.status always

でOK
このコマンドをどこでもいいので走らせると、~/gitconfigが書き換えられる

これらの設定が何かとコンフリクトして悪影響が出る場合は、以下のコマンドで元の設定に戻せる
git config --global color.branch auto
git config --global color.diff auto
git config --global color.interactive auto
git config --global color.status auto









それは・・・たぶん無理だ・・・


git add -p
で、1つのファイルを一度にコミットするんじゃなくて、1つのファイルの修正を分割してコミットすることができる

■ 参考 : Gitの便利な-pオプション四兄弟
git stash -p
も便利そう(絶対に使いこなせないけど)
これは今行った修正を更地に戻すけど、後でそこに復旧できるようにする
ファイルを最新の状態に戻すときは、git checkout hoge.c でOK


git log -pは割と使ってる、これはそのコミットでの修正点を具体的に見れる

あとここには書いてないけど
git log --stat
ってのも便利だと思う





(2016/10/27 追記)

git add hoge.c -p
は全然使わないだろうとか言ってたけど、かなり便利なことに気づいて活用している
表示された部分をaddしたいときはy、したくないときはn

ちなみにgitさんが提示してくるadd部分の範囲が広すぎる場合は
y/nの他に表示されているsを押すと、さらに細かい範囲を指定し直してくれる
それで良ければyを押せばいい




もらったメモにここで「git fetch origin hoge」をしてねと書いてあったがfetchって何?状態なので調べた

■ 参考 : Git 再入門 リモートリポジトリを使った作業

このページがとてつもなく分かりやすかった
自分みたいなアフォにわかるような文章を書いてくれて助かります・・・・


git remote
で、登録されているリモートリポジトリが一覧になる
詳細が知りたいときは
git remote show [リモートリポジトリ名]
おそらく .git/configに書いてある情報と同じだと思う

fetchはリモートリポジトリから最新情報をローカルリポジトリに持ってくるコマンド
ワーキングツリーには反映されないので、現在編集中のファイルが変更されることはない
ここがおそらくgit pullした場合との一番の違いか
ここで、修正したログがどういう風に扱われるのかが少しわからない・・・


リモートリポジトリなので、そもそも手元のmasterとはまったく別のbranchとしてgit fetchは落としてくる(これが一番の違い)
リモートリポジトリを手元に落としてきたあとで、git mergeまでやってコンフリクトが起こる可能性があるのがgit pull
な〜るほど〜〜〜

git のコンフリクトとか恐ろしくて手をつけたくないわ・・・
git fecth
git fecth [リモートリポジトリ名]
git fecth [リモートリポジトリ名] [branch名]
という使い方がある
git fetch --all
ですべてのリモートブランチをfetchする




■ 参考 : git pullは、fetchしてmergeするのと同じなのか?
実は git pull はC言語で実装されていません。git-pull.shというシェルスクリプトです。
へぇ〜
結論

git pullに、何も引数を付けずに実行した場合、git fetchしてgit mergeするのと同義であると確認できました。

伝説は本当でした。
だそうだ










git add -u

今までは、
git status | head -30
git add hoge
git add foo
...
としてたのがほんとアフォだった・・・・







そんなやつおる〜?(私です)


% git checkout hogehoge
Note: checking out 'hogehoge'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

git checkout -b

HEAD is now at hogehoge... foo
伏せ字ばっかりで申し訳ないですが、こんな感じで過去のコミットに遡ることができる
hogehogeというのはgitのコミットに割り当てられたID
fooはコミットメッセージ

こういう最新のHEADから切り離された状態をdetauched HEADというらしい


ここから、最新の状態に戻るためには
git checkout master
でOKらしい

危うくタイムマシーンに乗れないところだった・・・・・








まだgit pushしていない場合は簡単に書き換えられた
% git commit --amend -m "fixed xxx bug, refs #10"
git pushしてたらたぶん大変・・・・


■ 参考
git/コミットログを修正する方法









調べてみたらMacのキーチェーンを使う方法があるらしい

git config --global credential.helper osxkeychain
とコマンドを打つ

globalにしたくない(特定のgit repositoryでのみ有効にしたい)ときは、--globalオプションを外しておく


■ 参考
GitリポジトリにHTTPSでアクセスするときにパスワード入力を不要にする





■ 参考リンク
git clone 使い方

$ git clone --depth 1 "repository URL"
ただし、この方法でcloneしてきたリポジトリからは新たにpushすることはできないらしい
最新versionのみを配布するときはこのコマンドを使う?





gitの記事が増えてきたので、gitというカテゴリを作りましたー











完全に自分用のコマンドのメモ



■ 参考リンク

【Git】基本コマンド
だいたい必要なコマンドは↑のページにまとめられている





他にも
$git log --graph --stat
 もしくは
$ git log --graph
もかなり便利なコマンドだと思う

■ 参考
美しき git log --graph のエイリアス



これに関連して、こういうのもある
$git log --oneline




共有レポジトリにPushしてしまったコミットをやり直す



[Git] git repository size を削減する












残念ながら、この問題はまだ解決していません

色々とどん詰まりで、解決できそうにないのでひとまずメモとしてまとめておく




例えば意図せず大容量のファイル(hoge.txt)をコミットしてしまったとする
すぐにそれは間違いだと気づいて
$ git rm hoge.txt
とするも時既に遅し
.git以下にきちんと履歴として残っている


gitでは基本的に過去のコミットを消すことはできない
なぜなら、そういうことをすると他の開発者の手元で整合性が取れないことになるから

そこで1つ考えられるのが
$ git revert
というコマンド
これで消したいコミットを打ち消すようなコミットをしてくれる


しかし今回自分がやりたいのはそうではなくて、大容量のファイルを過去のコミットから完全に削除したい
過去のあるコミットの、さらに1部分だけを取り出して修正するのはいろいろと大変
最悪リポジトリの整合性を破壊してしまいかねない危険なことなのには重々注意しておくこと
なので
バックアップを取るなり、branchを切るなり、別のディレクトリでgit cloneして作業するなりするべし





■ 参考になりそうなページ

git最強のオプション filter-branch


[Git] git repository size を削減する


Maintaining a Git Repository


gitリポジトリを軽くしよう!


最強のオプション: filter-branch

特に上から2番目が一番自分がやりたいことを体現してくれていそうな記事





まずは3番目の記事から シェルスクリプト git_find_big.sh というのを落としてくる
$ chmod +x git_find_big.sh
$ ./git_find_big.sh
で一番ファイルサイズが大きいものを探す
左端の列がファイルサイズ(おそらく単位はキロバイト)

これをコミットログの中から探し出して、完全に亡き者にする
$ git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch hoge.txt" --prune-empty -- --all
上記スクリプトを参考にしてhoge.txtの部分を消したいファイルを置き換える
$ git for-each-ref --format="%(refname)" refs/original/ | xargs -n 1 git update-ref -d
$ /bin/rm -rf .git/refs/original/
$ git reflog expire --expire=now --all
$ git gc --aggressive --prune=now
で、削除したかった hoge.txt がリポジトリからなくなるはず
最初に表示されたファイルサイズ程度(もしくはそれ以上)の容量が減っているはず



と、ここまではいいのだが
上記のコマンドを走らせる前後でコミットログを見比べると、コミットのハッシュが書き変わっている・・・
$ git log
で一番上に出てくる英数字の並びのこと

そんなことはおかまいなしに
$ git push --all --force
としてみましたが、
remote: error: denying non-fast-forward refs/heads/master (you should pull first)
To https://xxxxxx
! [remote rejected] master -> master (non-fast-forward)
error: failed to push some refs to 'https://xxxxxx'
のようなエラーが出てうまくいかない・・・・

と、ここで詰まってしまっている・・・
このあと色々と試してみたがどうにもうまくいかず・・・





今の自分の現状について、わかりやすい解説を見つけた
Gitリポジトリのディレクトリ構成を変更する

↓ 引用
ここでいくつか注意点を述べる。

上記コマンドは、現在のブランチの履歴のみを書き換える。
リポジトリ内に複数のブランチが存在していた場合、他のブランチとの整合性は失われる。(もちろんoriginとの整合性も失われる。)もはや古いブランチと履歴ツリーを共有することはできない。
正確に言うと、他のブランチが持つ書き換え前のコミットと、現在のブランチが持つ書き換え後のコミットは完全に別々のコミットとして扱われる。コミットのハッシュ値が以前と変わっていることに注目してほしい。
-allオプションをつければ、リポジトリ内の全てのブランチに対して変更を適用することができる。
-allオプションによって、同リポジトリ内のブランチの整合性は保たれる。しかしこの方法でも、外部のリポジトリ(要するにorigin)との整合性を失うことは避けられない。
要するにこの操作は、リポジトリ自体を新しく作り直して、古いリポジトリは破棄する方法であると考えるべきである。
↑引用おわり

もはや新しいリポジトリを作った方が早い気がしてきた・・・

おそらく1つ前のコミット程度であればすぐに修正できるが
1ヶ月以上前のコミットなので、そのコミットを完全に削除しても、それはもう現状復帰ではなく「リポジトリ自体を新しく作り直して、古いリポジトリは破棄する」ということなんだろう・・・

何か解決方法をご存知の方は教えてください








今まで
$ git log
しか使ったことなかった
$ git pull
したときに出てくるような+++とか---があるようなlogを表示させることができるのかな?
とふと気になったので調べてみた。

答えは下のリンク先にまとめられていた
Git の基本 - コミット履歴の閲覧


簡単にまとめると
# 直近の1エントリについてのdiffなどを表示させる
$ git -p -1

# 直近の1エントリについてのdiffなどを表示させる
$ git log --stat -1

# 今までのlogをそれぞれ1行で出力する
$ git log --pretty=oneline
とりあえずこんな感じ?
文章で書くのは難しいので、ひとまず試しに入力してみるとよく理解できると思う・・・









空のディレクトリに、空のファイル .gitkeep というのを置いておくのが流儀らしい
git はきちんとそのファイルを認識してくれるので大丈夫
touch .gitkeep
■ 参考
空のディレクトリをgitで管理するには.gitkeepを使う







warning: push.default is unset; its implicit value is changing in Git 2.0 from 'matching' to 'simple'.
(一部分しかエラーメッセージを残していなかった・・・)


解決方法は簡単で、
git config --global push.default simple
としておけばよい



■ 参考

git push時に表示されるwarning: `push.default is unset...`の意味と解決方法

















.gitignoreを活用しましょう
このファイルに書いたファイルは git add する対象にはなりません
つまりディレクトリを一括でgit addしたときしても.DS_Storeはアップロードされません

.gitignoreの書き方
*.o
*.hi
*.chi
*.chs.h
/***/.DS_Store
たぶんこんな感じでおーけー


このファイルは、
gitで同期しているディレクトリ自身に.gitignoreを置いてもいいですし、
ホームディレクトリに.gitignoreを一つ置いて、それをglobalな設定にしてしまうのもいいかもしれません

globalな設定にする場合は
git config --global core.excludesfile ~/.gitignore
■ 参考
グローバルな.gitignore を設定して、すべてのgitリポジトリで無視するファイルを設定する





自分はいつものごとく .gitignoreをDropboxにアップロードしておいて
ln -s /Users/hoge/Dropbox/setup/.gitignore ~/
としておきます











HOME |
プロフィール
HN:coffee
職業:物理屋(自称)
趣味:映画鑑賞
自己紹介:
#include <stdio.h>
#include "MyProfile.h"

#define TWITTER coffee_pote

#define WISH_LIST
amazonのほしい物リスト
#ifdef RICH_FLAG
// ↑いつも支援いただきありがとうございます m(_ _)m
#endif


int main(void){

printf("\n");
printf("仕事きまりました\n");
printf("\n");
printf("猿でもわかるgnuplot を執筆中\\
少し追記しました\n");
/* 最終更新 2017/12/09 */
return 0;

}
カウンター
ブログ内検索
ツイートするボタン
Flickr

Template "simple02" by Emile*Emilie
忍者ブログ [PR]