gitのブランチリストを鮮度順に表示する - Qiita
この記事を書いた2013年当初のgit(version 1.8)から月日は流れ、いまどきのgit (version 2.7以降) は、--sort オプションがあるのでそれを使うのがよいでしょう。というわけでこれを追記しておきます。 git branch --sort=<key> --sortオプションのkeyを指定するだけになりました。 (version 2.7.0以降) 使えるkey は git-for-each-ref のそれと同じなので、日付順にソートしたいときには、authordate,committerdate などが指定可能です。 同じようにタグのリストも git tag --sort=taggerdate のようにタグ付け日時順に並び替えられます。 --sortオプションやkeyの詳細については以下を参照してください。 Git - git-branch Documentat
git rebaseでブランチをきれいにする - Qiita
この記事で言いたいこと git rebase masterで、現在のブランチのコミットをすべてmasterに適応できる。 コミットを一つずつ適応するため、一度に解決すべき競合が少なくなる。 また、履歴が一本化できるため後から見直したときにわかりやすい履歴になる。 ブランチがこんがらがる 複数のブランチを切って作業していると、 マージがあちらこちらで行われるため、入り組んで見にくくなります。 こういう時に役立つのが、git rebase です。 このコマンドは、現在のブランチと指定したブランチとが分岐し始めたコミットを探し、 そこから現在までのすべてのコミットを、指定したブランチの最新の状態に適応し直します。 例 例をあげると、 Masterのコミットm1 m2 m3 m4があるとします。 さらに、m2から派生したbranch_Aのm2-a1 m2-a2 m2-a3と、 m2-a1から派生し
Gitのコミット指定時に使うキャレット(^)とチルダ(~)の違い - chulip.org
例えばgit-resetなどをする時などにHEADの2世代前のコミットにHEADを移す場合は HEAD^^としたりHEAD~2としたり。でもHEAD^2という指定もあります。そのへんのまとめ 題材としてアイドルマスターシンデレラガールズ(以下モバマス)で考えます。 まず、適当にリモートリポジトリを作った後git-cloneして最初のgit-commitを行います。 その後、運営の犬であるちひろさんを追加します。ここまでは共通作業ですのでm@sterブランチで行います モバマスはキュート、クール、パッションの3属性があるので3属性分のブランチを作ります。 次に、いわゆる2コスと呼ばれている各属性のコスト2アイドルを追加していきましょう。 キュート:島村卯月 クール:渋谷凛 パッション:本多未央 キュートブランチ $ git co master $ git co -b cute 島村卯月はノー
git rebase -i はやっぱりイケてる件【git】【rebase 】【iオプション】 - DRYな備忘録
はじめに ※ 以前git rebase -i して何か失敗して痛い目にあったりした ※ これ。git rebase master に失敗した模様のとき【git】 ※ でも最近ちゃんとgitを理解し出したので再挑戦したらgit rebase -i がやっぱりイケてる 前提 ※ .zshrc (.bash_profile?) にて、gitのデフォルトエディタを設定しときます .zshrc export GIT_EDITOR=vim ※ あと、念のためローカルbranchは新しく切って試します % git branch * develop master % git branch rebase_test % git branch rebase_test * develop master % git checkout rebase_test ※ ぜんぜん関係無いけど、tigあるとちょっと幸せかも そ
Gitによるチケット駆動開発の事例 - プログラマの思索
資料を要約しながら、自分の感想も入れてみる。 SVN主導の開発で抱えていた問題。 「pull request主導のチケット駆動開発したい。svnには障壁が多い。」 trunk, staging, releaseの3つのメインブランチ戦略。 (僕もSVNでこのブランチ管理の経験はある。 きちんとソース管理はされているが、マージが手作業な場合、ライブラリアンの負荷が途方もなく大きい。 どのリビジョンをリリースするのかというExcel申請書が大量に届いて、それを見ながら手作業でマージしてビルドする。) SVNはマージやブランチを切るコストが大きすぎる。 (trunkから派生したブランチとtrunkの間のマージはまだ楽だが、ブランチ間同士のマージはまだまだ厳しい。) 理想は、GitによるPullRequest主導のチケット駆動開発。 (チケットにソースの修正理由や発端、経緯が記載されている、ないし
はてなブログ | 無料ブログを作成しよう
新米と秋刀魚のわた焼き お刺身用の秋刀魚を買いました。1尾250円です 3枚におろして、秋刀魚のわたに酒、味醂、醤油で調味して1時間ほど漬け込み、グリルで焼きました 秋刀魚のわた焼き わたの、苦味が程よくマイルドに調味され、クセになる味わいです 艶やかな新米と一緒に 自家製お漬物 土…
Subversionのタグとブランチの使い方 - takayukisの日記
タグとブランチの作り方はわかっても、実際にリポジトリを運用していくとき、どういうタイミングで作ると良いかがわからなかったりします。 資料は少なめですが、Subversionのドキュメントのブランチの作り方あたりが参考になります。 ドキュメントには、おおむねこんなことが書いてあります。 リリースが近づいたらリリースブランチを作り、 ブランチ上ではバグフィックス以外の大きな変更はしないようになります。 その間の機能追加などの大きな変更はtrunkで行います。 ブランチはリリースするときにタグにコピーします。 タグはそれ以上変更しないことでスナップショットとして使います。 リリース後に見つかったバグの修正はブランチ上で行い、またタグをつけて修正版をリリースします。 あとはSubversionを利用しているオープンソースプロジェクトのリポジトリを見るのが良いでしょう。いくつか見てみましたが、やはり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gitで複数のブランチを一括削除するには | KATSUMI KOKUZAWA'S BLOG