コンフリクトの解決を記録して再適用する git rerere - Qiita
はじめに Git を使う場合、ブランチの作成とマージを頻繁に行うような運用が多いと思います。例えば、機能追加やバグ修正を行う場合には本流ブランチからトピックブランチを作成して、作業はトピックブランチにコミット、作業が終わったらトピックブランチを本流ブランチにマージ、といった運用です。 この場合、トピックブランチは細かい単位で作成して、作業が終わったらすぐマージする、というのが良いプラクティスであろうと思います。すぐマージすると、コンフリクトは起こらない場合が多いです。とはいえ、やはりコンフリクトが起こる場合はあります。 コンフリクトが起こる場合とは、feature/12345 ブランチを作成して作業して master ブランチにマージしようとしたところ、別の誰かによる変更が既に master ブランチに取り込まれており、しかもその変更箇所が feature/12345 ブランチでの変更箇所
内部構造から見るGit - Qiita
こんにちは@a_suenamiと申します。 これはGit Advent Calendar 2012の17日目の記事になります。 前日はid:akiyokoさんのGitコマンド総選挙でした。 Gitの内部構造 みなさんはGitがどういう風にデータを管理しているか意識したことはありますか？ コマンドの使い方に関するTipsはよく見かけるのですが、なかなかデータ構造に着目した解説は少ないのが実情かと思います。 そこで本日は僕が以前社内で行ったGit勉強会の話をもとにして、Gitの内部でどのようなデータがやりとりされているのかという話をしたいと思います。以下が以前僕が社内で勉強会をしたときの資料です。 http://www.slideshare.net/asuenami/git-15199548 タイトルの通り、非プログラマ向けの内容なのですが、PART2ではGitの内部構造を擬人化して説明すると
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
