Subversionでtrunkの内容をbranchにmergeまたはその逆 - 常水商会::よしなしごと
備忘録。書きかけ＆未確認。 現在の作業リポジトリの変更をすべてコミットしておく これで失敗しても安心♡ trunkの内容をbranchにmerge 作業リポジトリをbranchに変更 svn switch file:///home/sysdev/svn_repos/branches/branched_version svn infoコマンドで現在の作業リポジトリのURL等を確認しておくこと。 branchの開始点のリビジョン番号を確認 svn log --stop-on-copy 一番最後に出力されるログのリビジョン番号を控えておく（仮にr411とする）。 trunkの内容をbranchにmerge（merge試行） svn merge --dry-run -r 411:HEAD file:///home/sysdev/svn_repos/trunk trunkのr411から最新までのコミ
git merge or rebase, ff or no-ff
Kazuho Oku @kazuho バージョン管理システムの目的は変更履歴を管理することなんだから、git rebase とか履歴を改変するコマンドは言うまでもなくダークサイド 2012-11-09 16:58:32
「こわくない Git」というスライドを発表しました - kotas.tech
社内向けに「こわくない Git」というタイトルのスライドを作って発表しました。 対象者は「マージがなんとなく怖い」「エラーが怖い」「リベース使うなって言われて怖い」と、Git が怖いと思っている人です！ こわくない Git from Kota Saito 発表中に出た質問など 補足も兼ねて、上のスライドを発表した際に出た質疑応答などをここに書いておきます。 Q: 常に Non Fast-Forward (--no-ff) でいいのでは、と思えるけど git merge がデフォルトだと Fast-Foward or Non Fast-Forward (--ff) なのはなぜ？ A1: Non Fast-Forward だと、確かにメリットが多いのですが、1点だけデメリットがあります。特に差分が無い状態で git merge --no-ff すると、空のマージコミットが作られてしまうのです。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
にひりずむ::しんぷる - 最近の .proverc
我流天性 - がらくた屋 svnで間違ったコミットをmergeで戻すコマンドのメモ
game online pulsa - little418.com
rebaseにまつわる３つの誤解
