[Subversion]過去の分岐の歴史を修正する方法 · DQNEO日記
事例 動機 r40000まで進んだ今になって、r10000のコミットをやりなおしたい。 経緯 例えば、r10000付近で新人プログラマがこのようなコミットをしてしまっていたとします。 # r9999 trunkを丸ごと削除 svn del trunk svn ci -m "delete trunk" # r10000 ブランチをcpでコピー cp branches/hoge trunk svn add trunk svn ci -m "new trunk" (mergeしろよとかそういう話はさておき) 本来"svn cp"しないといけない場面で、"cp & svn add"してしまいました。 このオペレーションの結果、trunkの歴史はr9999以前とr10000以降で断絶してしまいました。 どうしていればよかったのか r10000のコミットは、こうであって欲しいところです。 svn cp
![[Subversion]過去の分岐の歴史を修正する方法 · DQNEO日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/8f7de7c0278993661a11fbc3637f96292ba773aa/height=288;version=1;width=512/http%3A%2F%2Fdqn.sakusakutto.jp%2Fimages%2Fkali.jpg)
Gitの良さが分からない？ ちょっとそこに座れ | To Be Decided
Gitの良さがいまだに分からないという人がいるようなので、Git派の一人としてSubversion(以下SVN)と比較してのGitの良さ(メリット)について語りたい。 (GitとSVNの違いについては他の人の記事に詳しいのであまり書いていない一方、勢い余ってGitのデメリットも書いた。) 本題に入る前に、冒頭にリンクを貼った記事についてひとつだけつっこんでおく。 つっこみどころは他にも沢山あるけど。 ※話の前提としてgitとSVNを採用している現場に下記のような割と違いがあるとする。 git イシューごとにブランチを切り、ローカルでコミットして、リモートブランチにpushして、GitHub・GitLab・Bitbucket経由でマージリクエスト。コードレビューの後にマージ。 SVN リモートのtrunkに個々人が直接コミット。コードレビューはあまりない。ブランチを切ることもない。 このよう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
