[B! git] y-imayaのブックマーク

Gitでやらかした時に使える19個の奥義 - Qiita

タイトルは大目に見てください><。本内容は危険な操作を伴うのでくれぐれも自己責任でお願いします。間違いもあったら指摘ください。ローカル編自分のローカル環境だけで閉じていて、他の人への影響がない場合に有効です。リモートにプッシュしちゃってる時は、他人への影響が発生するので危険です。やらかし１：コミットメッセージに禁止ワード入ってて人生やめたい時コミットメッセージを修正するのは簡単です。ファイルの追加なんかもできちゃいます

y-imaya 2015/02/18

git

リンク

空コミット便利！git commit --allow-emptyでgitを使った開発フローを改善 - fukajun - DeepValley -

何か？ git commitのオプション--allow-emptyご存知でしょうか？これは、オプションの名前の通り空のコミットの作成を許可するオプションです。通常変更がないとコミットが作れないようになってるので空コミットを作るにはこのオプションを指定する必要があります。 add(もしくはrm)もしない(stageに何も載せない)で commitしたときの注意文には登場するので知ってましたが使ってませんでした。最近、開発フローの中で使い道を思いついて使うようになったので紹介です。その1 空Pull Request作れるプルリクって、基準になるブランチから変更されたコミットがないと作れないと思ってます。でも、変更はないんだけどプルリクのcommentに変更の「概要」「目的」「ビジネスインパクト」「どの数値が改善するのか」など色々さきに書いておきたいこととかありますね。考えてる内

y-imaya 2014/02/23

git

リンク

git-flowでもgithub flowでもない、Git本家推奨のワークフロー

このドキュメントは git.git (訳注: Git プロジェクトのgitリポジトリ) それ自身で使われているワークフローの要素を書きとめ、それを使いたいと思わせることを意図しています。多くのアイデアが一般に適用できますが、より少人数が参加する小さなプロジェクトで完全なワークフローを必要とするのは稀です。私たちはクイックリファレンスのためにひとまとまりのルールをとりまとめ、文章でそれぞれのルールへの動機を与えます。言葉通りにとらないようにしてください; 重視すべきなのは、この文書のようなmanページの記述よりもあなたがそうすべき理由の方です。

y-imaya 2014/02/03

git

リンク

tig でいま見ているコミットをブラウザで開く - @kyanny's blog

tig で Git リポジトリのログを読んでるときに「このコミットのページをブラウザで見たい！でもコピペするのは面倒だ！」と思ったので o 押したら開くようにした。 tig のキーバインドは .tigrc というファイルでカスタマイズできる。外部コマンドの呼び出しができるし、いまみている commit の SHA1 を渡せるので、こんな感じで hub コマンドを呼び出せる。だいぶ楽なのでおすすめです。

y-imaya 2014/01/28

git
tig

リンク

GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点 - プログラマの思索

GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点について指摘していた記事があったのでメモ。【参考】 GitHub でチケット駆動開発とプルリクエスト駆動開発を併用する - mallowlabsの備忘録 GitHub の Issue をあとから Pull Request にする (あとからコードを添付する) - Qiita [キータ] Fujimura ? GitHubで既存のissueに対してpull requestする hub コマンドで github から fork して pull request をさくっと - #生存戦略、それは - subtech Git+Redmineな人におすすめのフックスクリプト集 - みずぴー日記 bleis-tift/Git-Hooks かんばん！～もし女子高生がRedmineでスクラム開発をしたら（6）：Redmine×Gitのハー

y-imaya 2014/01/20

リンク

git による分散作業パターン | GREE Engineering

分散バージョン管理を華麗に扱いたい堀口です。 GREE Advent calendar 2013 の 14 日目として参加させていただきます。お二人に続き Haskell の話をしようかと思ったのですが、急遽無難な開発の話に変更しました :o Java や C++ には OOP の概念が必要であったように、分散作業の認識が薄いまま git や Mercurial を使うことは長期的に不幸をもたらします。とあるプロジェクトにて、その一部を副産物のミドルウェアとして抽出すべく、アプリケーションと分離したい不具合があったので原因を探りたいが、依存関係が複雑すぎるのでコードを読む量を減らしたいテストやレビュー、提案、リファクタの運用を強化したいよそのプロジェクトに迷惑を掛けないように、そこのツールを改良して使いたい。いままで何気なく「こんなもんだろう」と思って手間をかけていませんでした

y-imaya 2013/12/14

堀口さんのおかげでgit覚えることが出来ました

git

リンク

git rebaseを使うときのルール | Yakst

Re: [git pull] drm-next Linus Torvalds Sun, 29 Mar 2009 14:48:18 -0700 (訳注 : Daveのrebaseのやり方が好みでないというLinusに対して) > 2009年5月29日(日曜日) Dave Airlieの発言 > > 今から自分がしようとしているのは、直線じゃないツリーを送ろうとしているだけだ。 > パッチを自分の次のツリーにマージする時はいつでも、そこにそれがあるからだ。 > 自分は、Ericのツリーを自分のツリーに直接プルして、その結果を送ろうとしている。 > きれいなマージ履歴について注意しているとは思っているけど、前に言ったように、 > カーネルツリーに関してのドキュメントが何もない状態では、君がどうしたいのか > 本当のところは今の今まで分からないよ。自分が求めているのは、きれいな履歴だ。でも、それ