マージコミットの分割が１本線の履歴の分割よりも困難となる理由
git-bisect(1) コマンドはマージコミットを含んだ履歴を正確に扱います。 しかし、コミットがマージコミットである時は、そのコミットが何故問題を起こしている かの原因を見つけ出すのに苦労することがあります。 次の履歴を考えてください： ---Z---o---X---...---o---A---C---D \ / o---o---Y---...---o---B上側の開発ライン上のコミットXにて Zから存在する関数の意味が 変更されたとします。ZからAにつながるコミットは、関数の実装を変更し、 Zの時点で存在する全コール箇所と新しく追加したコール箇所の両方を変更して、 矛盾のない状態にしていたとします。 A の時点ではバグはありません。 それと同時に下側の開発ラインではコミットYにてその関数の新しい コール箇所を追加していたとします。 ZからBにつながるコミットの全ては、その関数の古い
git/リモートリポジトリURLを変更する方法 - TOBY SOFT wiki
2020-06-02 Comments/Subversion/TortoiseSVNメモ/コミットしたログメッセージが編集できない 2020-03-31 ゲームを作る上でのバッドノウハウ/十字キーがボタンとして認識される 2019-11-12 Comments/Wiki/PukiWiki/スパム(spam)を防止する方法 2019-11-01 Delphi/XML/Delphi付属のXMLライブラリ 2019-08-27 Comments/SaGa2 秘宝伝説/モンスター一人クリア 2019-07-11 Comments/git/git rebaseを元に戻す方法 2019-06-08 VBA/関数呼び出し時に「オブジェクトが必要です。」というエラーが出る 2019-03-07 Comments/PhotoShop/「下のレイヤーとグループ化」はどこいったの？ 2019-02-06 Rub
gitはどう動くのか: コミットオブジェクト周辺の話 - <s>gnarl,</s>技術メモ”’<marquee><textarea>￥
私がgitを使いだしたのはgit入門(濱野2009)を読んでからなんですが、これが非常によかった。何のために用意された機能なのか/どのような仕組みで動いているのか、その根っこのところがきちんと解説されているので各種コマンドがどのような意味を持つのかすんなり理解できた。分散VCSは複雑そうで敬遠していたのだが、gitは構造がシンプルで直感的なので原理さえ理解すればsvnより容易に使いこなせる(というかsvnのアーキテクチャについてはいまだに理解できてない……。どこかにいい入門書ないだろうか)。 gitのアーキテクチャについて、自分なりの理解をまとめてみようと思う。 gitはどのようにリポジトリを管理しているか オブジェクトとは、gitがデータを扱う単位。コミット、ファイルの内容などはオブジェクトとして表される オブジェクトは内容に応じた一意のIDを持つ(内容のハッシュ値がIDになる) 一回の
A successful Git branching model を翻訳しました
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら： http://nvie.com/posts/a-successful-git-branching-model/ （翻訳の公開と画像の利用は本人より許諾済みです） このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
gitでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
ステージを理解して git をもっと便利に使う
git には「stage(ステージ)する」という概念があります。あるいは「index」と言い換えてもいいかもしれません。 簡単にいうと「stageする」＝「特定の変更内容をindexに登録する」＝「次回コミットに含めるようgitに指示する」ということなのですが、この概念は今まで主流だった CVS や Subversion といったバージョン管理システムにはありませんでいした。 長年CVSを使っていて、その考え方に凝り固まっていた私は、gitを使い始めてしばらくはstageやindexの概念を理解できなかったので、今回ここで紹介することにしました。 このstageとindexを覚えると「ひとつのコミットには、その主題となる変更と無関係な変更を含めない」という「バージョン管理システムを使う上で重要なはずなのに、つい疎かにしてしまいがち」なポリシーを簡単に実践できるようになります。 今回stag
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
技術者ブログ アーカイブ | Webシステム開発／教育ソリューションのタイムインターメディア