Gitでコンフリクトした時のための備忘録 - アジャイルSEを目指すブログ
コンフリクトしたときに便利そうなので、備忘録を残しておく Gitのコマンド コンフリクトしているファイルの一覧を表示する。 $ git ls-files -u [<path>] ファイルの状態(コンフリクト含む)を表示する。 -s でshort-format で特定のディレクトリのファイル一覧を表示できる $ git status [<path>] 手動で直す方法 修正後にaddが必要 $ vi <path> (手動でコンフリクトを直す) $ git add <path> mergetool でマージする方法 -y でデフォルトのマージツールが実行する で1つずつ指定できる $ git mergetool -y [<path>] をHEADと同じ状態にする。 修正後にaddが必要 $ git checkout --ours [<path>] $ git add <path> をマージで指定
Git使ってて困ったこんな時 - Qiita
ブランチの派生元間違えた!! 本当はdevelopブランチから切らないといけないのに、masterブランチからfeature/hogeブランチを切ってしまった もう３回くらいコミットしてしまった...(´；ω；｀)ﾌﾞﾜｯ ブランチ作りなおしてcherry-pickするか....... こんなとき!! $ git log --graph --all --decorate --oneline * 08733a5 (HEAD -> feature/test) test 1 * e7872a3 (master) master 2 | * 09140ba (develop) develop 1 |/ * 8c001b5 master 1 $ git rebase --onto develop master feature/test First, rewinding head to replay y
ネイティブと働いて分かった英語コミットメッセージの頻出動詞10つ
ウッ ここで詰まる事は往々にしてあります. 特に急いでる時の煩わしさは甚だしいです. どうせならそれっぽい英語を使いたいのでOSSや同僚のコミットメージの語彙の出現確率を調べてみましたら、 もちろんfeatureによってコミットメッセージの付け方など数多あるものの、一定の頻出パターンは見い出せたので筆を取りました. （英語勉強しないと..） 方法 github.com/rails/railsのコミットメッセージ内における各動詞の出現確率を求め、 またOSSと仕事でのコミットメッセージの趣向も変わってくる事も勘案するため、 （仕事でDeprecateとか滅多に使わんし） 同僚に聞きつつ10つあげてみた. 以下列挙 （例は実際の同僚やOSS上でのコミットメッセージです.） Add *A to *B AをBに加える
git でリモートリポジトリを clone する際、特定のブランチだけ取ってきたい - oogatta のブログ
$ git clone -b [branch] --single-branch [remote-repository]でした。 古い文章だと $ mkdir test $ cd test $ git init $ git remote add [remote] [remote-repository] $ git fetch [remote] $ git co [branch]って書いてるのもあるけど、これだと remote tracking branch がリモートリポジトリにある全ブランチ分できてしまうのに対し、 --single-branch ではその時 -b で指定したブランチ分のみできる。 --single-branch で clone すると、それ以降の git fetch [remote] でも --single-branch した時のブランチだけが fetch されて来ます。
git addするファイルをpecoで選択できるようにした - petitviolet_blog
みんな大好きpecoを使って、git add出来るようにした 作ったもの 深いディレクトリにあるファイルが複数ある時、zshのtab補完でやるのも面倒だったので、peco使ってやりたいな〜と思ったからzsh関数書いた コード 複数選択に対応した 上のgifのように複数選択出来る 検索のハイライトと選択中のハイライトの色が被ってるため見難くなってしまっている function peco-select-gitadd() { local SELECTED_FILE_TO_ADD="$(git status --porcelain | \ peco --query "$LBUFFER" | \ awk -F ' ' '{print $NF}')" if [ -n "$SELECTED_FILE_TO_ADD" ]; then BUFFER="git add $(echo "$SELECTED_FI
巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
Gitで最初のコミットをどうにかする - tmtms のメモ
最初のコミットの内容を変更したい Gitで最初のコミットの内容を変更したいと思って git rebase -i <最初のコミット> とやっても、最初のコミットは出てきません。 % git log --oneline 4f4f42c 二番目のコミット 9d4876c 最初のコミット % git rebase -i 9d4876c pick 4f4f42c 二番目のコミット このような場合は git rebase -i --root を指定すると良いようです。 % git rebase -i --root pick 9d4876c 最初のコミット pick 4f4f42c 二番目のコミット 最初のコミットの前に別のコミットを入れたい さっきと同様に git rebase -i --root で開いて、最初のコミットを edit にします。 % git rebase -i --root edit
percolを使って、gitのコミットハッシュ値をクリップボードにコピーする - Qiita
まずこれを実行すると、以下のようにpercolが立ち上がる。 --onelineだと情報がちょっと足りないので、git-logのフォーマットを指定してtigのmain viewっぽくした（--graph入れても良さそう）。 コミットコメントが適当すぎるのは、個人用のリポジトリということでご容赦ください... ここで1個あるいは複数個指定してENTERを押すと、ハッシュ値だけが出力される。 match~substrを調べるのにすごい時間掛かった...awk力が足りない そして出力したハッシュ値のリストをpbcopyに突っ込んでコピーする。 tee >(pbcopy)なんてややこしい書き方をしてるのは、こうしておくとターミナルにも出力され、かつクリップボードにもコピーできるから。 （あまり自信のある書き方ではないので、ターミナルに出力しつつクリップボードにコピー出来る、別な方法があれば教えてく
git difftool --dir-diff が便利すぎて泣きそうです
Git の 1.7.11 から git difftool コマンドに --dir-diff というオプションが追加されたのですが、これがライフ チェンジングだと思ったので紹介します。 --dir-diff 登場以前の git difftool は「ファイルごとに順番に差分を表示していく」ことしかできず、使い勝手はいまいちでした。それが、--dir-diff オプションの登場で状況が一変したわけです。 こんな感じの使い心地だよ ある Git レポジトリーで dir1/a.txt と dir2/c.txt を編集したとしましょう。 この状態で git difftool --dir-diff または git difftool -d を実行してみると・・・。 はい、差分のあるファイルが一覧で表示されました。 (difftool に WinMerge を設定して、メニューから [ツリー表示] を有効
.gitconfig に include で設定を読み込めるようになった (Example)
git 1.7.10以上で .gitconfig ファイルから include ディレクティブを使って別の設定ファイルを読み込めるようになったらしい。これで GitHub に置いてる dotfiles に .gitconfig も安心して置ける。 .gitconfigにinclude書くと捗る - かるぱねるらすたいる こんな感じで設定するときっと捗るね。 - example file: .gitconfig [core] excludesfile = ~/.gitignore [include] path = ~/.gitconfig.local [alias] *many alias* [color] ui = true diff = true - example file: .gitconfig.local [user] name = hoge hogenosuke email =
Changelogのための英文テンプレート集 - ぴょぴょぴょ？ - Linuxとかプログラミングの覚え書き -
Changelog を英語で書く際に参考になるようなテンプレートをまとめてみました．git や svn のコミットログにも使えます． このエントリは今後も逐次更新を続けます（最終更新2018/11/01） リリースノートの英文についてはRelease note のための英文テンプレート集 - pyopyopyo - Linuxとかプログラミングの覚え書き -に分離しました git等のcommit メッセージにも使えます 以下，例文． バグ修正した場合 修正した場合 → fix を使うのが定番です Fixed a performance regression. （パフォーマンスが低下するバグを修正しました） Fix possible memory leak Fixed an issue where some devices would display the wrong image. (いく
Git で複数ブランチを同時に扱いたいなら git-new-workdir が便利
Git で管理してるレポジトリーで、いくつかのブランチを別々の場所にチェックアウトしたいことがある。 たとえば GUI なツールでブランチ間の比較したい 同時に実行して比較しつつテストしたい ブランチ間でファイルをコピーしたい ドキュメントの生成結果を別ブランチで管理したい といったときに、必要になる。 ブランチの個数だけ clone しちゃえば用は足りそうなんだけど、でかいレポジトリーだったら時間もディスク容量ももったいない。 git-new-workdir を使うべきでしょう！ 先日、「git-new-workdir を使えばワーキング ディレクトリーを複数を作れて便利」と書いてあるブログを読んだ。 git-new-workdir が便利 - #生存戦略 、それは - subtech git-new-workdir の usage を見てたら、別ブランチのワーキング ディレクトリー作成
branchを切った時点のコミットとbranchの最新コミットとのlogとdiffをみたい - （ひ）メモ
Pro Gitから図を引用すると、こういう 場合に、分岐した時点のmasterとexperimentの先っちょのlogやdiffをみたいというお話です。実際的には、topic branchをmasterにマージする前に変更点を確認したいといった局面です。 log logの場合は「..」です。 $ git log --pretty=oneline master..experiment ec8428d4d1884d3413e0949603c0c5cdd8aef414 D 863f5738a395fe090afaeaa120b67c45d65131c4 Clogにおける「..」についてPro Gitから引用すると、以下のように書かれています。 これは "experiment からはたどれるけれど、master からはたどれないすべてのコミット" という意味です。 Git - リビジョンの選択 一
vimで簡単にバージョン管理システムを使いたい! - sugoi < yabai < kimoi
導入 この記事は vim advent calendar 2012 の 18 日目の記事です。 17日目は @kanno_kanno さんの 「Vimを使い始めようと思うんですけど、おすすめを教えてください」 でした。 とてもいい記事をありがとうございます！ 本題 今回紹介するのは vim-versions というプラグインです。 簡単に説明すると、バージョン管理システム（vcs）の操作を vim から行えるようにするものです。 この手のプラグインはまじで便利で、是非みんなに使ってもらいたいと思ってます。 ちなみに、vim-versions に限らず vcs と連携する類似プラグインはたくさん公開されているので、 自分にあったものを選んで導入してみてくださいね！ （もちろん、その上で vim-versions を選んでもらえたら嬉しいです。） vim-versions のインストール 最近
英語でコミットを書こう
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
git reset --hard HEAD を安全にした - 永遠に未完成
昨日、git reset --hard HEAD してしまって大変なことになった話を書いた。私は普段これを cancel と言う名前に alias して使っている。 [alias] # 中略 cancel = reset --hard HEAD しかし前回のようなことがまたあってはたまらない。人間はミスするものだ。 alias があって実行しやすいのが問題なのだろうか? いや、割とよくする操作*1だし、alias しなくても使うだろう。 てことで、cancel が安全になるようにしてみた。 [alias] # 中略 cancel = !git commit -a -m 'Temporary commit for cancel' && git reset --hard HEAD~ 一旦コミットしてからそのコミットを消す。こうしておけば最悪 git reflog から元に戻せる。特にコミットす
あまり知られていないGitのTips - アジャイルSEを目指すブログ
思い浮かんだGitのTipsを列挙してみました。 gitのコマンドをで補完する git-completion.bash を入れると、でコマンドの補完が効くようになります。 また、PS1の設定を行うと現在のブランチ名が常にbash上に表示されるようになります。 （Windowsの場合、msysgit は標準で入ってます） contrib/completion/git-completion.bash - GitHub インストール方法（引用） # To use these routines: # # 1) Copy this file to somewhere (e.g. ~/.git-completion.sh). # 2) Add the following line to your .bashrc/.zshrc: # source ~/.git-completion.sh # # 3)
【翻訳】あなたの知らないGit Tips
Mislav Marohnićさんの "A few git tips you didn't know about" を翻訳しました。 元記事はこちら： http://mislav.uniqpath.com/2010/07/git-tips/ （翻訳の公開は本人より許諾済みです） 翻訳の間違い等があれば遠慮なくご指摘ください。 あなたの知らないGit Tips注意：いくつかのコマンドやオプションは Git の version 1.7.2 以降が必要です。 OS Xでは、 Homebrew で簡単にアップグレードできます： brew install git git log でブランチとタグも見る$ git log --oneline --decorate 7466000 (HEAD, mislav/master, mislav) fix test that fails if current d
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ag(The Silver Searcher)で検索しpecoで更に絞り込みvimで該当行を開く - Qiita
http://defunkt.io/hub/