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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gitで複数のブランチを一括削除するには | KATSUMI KOKUZAWA'S BLOG
