これは何? git merge コマンドには、--no-ffオプションや--squashオプションがあり。 もう語り尽くされている部分ですが、それらの違いを整理して図にしてみたものです。 前提 merge前のブランチは、git rebase masterしておく。 git merge の履歴の違い ネットワーク図的な特徴 --no-ff : マージコミットが作られる + コミットログのネットワーク図を見ればどこから分岐してどこにマージされたのか視覚的にすぐわかる。 --squash : コミットが1つにまとまって綺麗 + コミット履歴が1列になる + masterブランチとの関係性が途切れる オプションなし : コミット履歴が一列になる。(masterブランチとbranchXブランチが同じ位置にくる)
ここでは newSetting が新しい設定項目だと思ってください。 この時、もともとの設定項目 path が存在していますが、 これが動作確認に必要な項目で ローカル特有の設定値に変更していたとしたらどうでしょうか? add 前にリポジトリの内容に戻しておかないと、 このローカル用設定のままコミットされてしまいます。 こんな時に使えるのが magit の部分 stage です。 使い方はいたって簡単です。 編集が完了した状態で magit-status を実行します。 magit での git 操作画面が開きますので、部分的に stage したいファイルにカーソルを合わせます。 この状態で M-s (alt+s, Cmd+s, Opt+s)をタイプします。 するとファイルリストの下部に Diff が表示されます。 この Diff 上でリージョン選択して s をタイプすると、 リージョン選
はじめに いい感じにGitを使うための備忘録。 Githubにリポジトリを置いときたいけど、細かいコミットは上げたくない人用。 流れ topic branchを切ってその下にさらにtopic-develop branchを切る topic-develop branchはローカルだけに置いといて、適当にコミットを生やす いい感じのところでtopic branchにgit merge --squashする。 こうすると2.の部分でコミットメッセージに悩まなくて済む。 2.で生やしたコミットは3.でSquashされる(まとめられる)ので、 Githubから見たときに変にコミットが増えなくて済む。 いい感じ。 topic branch 2つのbranchを切る。 $ git branch * master $ git checkout -b topic-branch Switched to a n
最近某OSSに出されたPRが、git merge --squash <branch> でマージされたことにより、コミットのAuthorが書き換えられてしまったことが一部界隈で話題になっていました。この件にはマージを行った人に悪意はなかったようなのですが、gitの理解不足により生じてしまった案件だとすると悲しい話なので一応メモ 何が起きたか コミッターが複数の内容が含まれたPRを送った 管理者はその中の一部の内容だけをマージするために、管理者はgit merge --squashを実施し、コミットを改変した上でmergeを実施した ←これが問題 コードの内容はコミッターのものなのに、Authorだけ管理者にすげ変わってしまいコミッターのモチベを損ねた そもそもsquashするとどうなるの ここに分かりやすくまとまっています。 アジャイルSEを目指すブログ 図で分かるgit-mergeの--f
読者がGitHubで何かを公開しているとしよう。そのレポジトリに対して他人がプルリクエストを送ってきた。なかなか良さそうな変更だ。早速マージしたい。 しかし、残念なことにそのプルリクをそのままマージすることができない。なぜならば、 コンフリクトを起こしている 追加の修正が必要だ こういう場合、大規模なプロジェクトや、PR主が職場の同僚や開発仲間であった場合、PR主に修正を依頼するものだ。しかし、個人的な小規模なプロジェクトなのでPR主はPRを出したまま返事がない。 こういう場合に、PRをマージするにはどうすればいいのか。答えは簡単で、プルリクエストが裏でやっているgit操作を自分のローカルでやればいいのだ。 まず、該当のPRのGitHub上のページの、「プルリクエストをマージ」ボタンの横に、コマンドライン操作を表示(view command line instructions)というリンク
I would like to be able to use ediff with "git mergetool". I found some patches that alter the source code, which I don't want to do. Instead, I'd like to add ediff support with my .gitconfig. I know git has builtin support for emerge, but I prefer ediff. I attempted to add these lines to my .gitconfig: [mergetool "ediff"] cmd = emacs --eval "(ediff-merge-files-with-ancestor \"$LOCAL\" \"$REMOTE\"
git log --merges -1 --format=%H Pull Request ベースで開発しているとメインブランチの最新のコミットは原則としてマージコミットになるので、トピックブランチを作るときの起点となるコミットもマージコミットになる。 手元のメインブランチが pull で新しくなると tig で作業中のトピックブランチを眺めたとき、どこから派生したかちょっとだけわかりづらくなるし、 rebase -i の指定がちょっとだけ面倒になる。 メインブランチから直接派生している場合は rebase -i master のようにすればよくて楽だが、 master が派生元でなくなると rebase -i head~N のようにするか、 rebase -i xxxx のようにするか、いずれも対象を調べるのが面倒くさい。 大抵の場合、派生元は(たとえそれがもはや master HEAD
**「upstreamのmasterブランチをマージしようとしたら大量のコンフリクトが発生した」**こと、ありませんか? 私はよくあります **「せっせっとコンフリクトを解消してるけど、そろそろ時間切れ。このブランチ、いったんプッシュしたいなぁ」**ということ、ありませんか? 私はよくあります ですが、未処理のコンフリクトを残したままコミットしようとしても、 $ git commit error: 'commit' is not possible because you have unmerged files. hint: Fix them up in the work tree, hint: and then use 'git add/rm <file>' as hint: appropriate to mark resolution and make a commit, hint: o
git mergetoolに使えるツールとして、デフォルトで"emerge"というのが用意されており、Emacs使いはこれを使えばEmergeでマージが行えるわけだが、難点もある。ひとつは、新たなEmacsインスタンスを起動してしまうということだ。起動に無駄な時間が掛かるし、マージにあたって既存のセッションで開いているファイルをその場で参照できないのは不便だろう。もっとも、これはemacsclientを使うようにして、Emergeの呼び出し方を少し直せば済む。もうひとつは、EmergeではなくよりモダンなEdiffを使いたいということだが、これは思ったほど簡単ではないのでわざわざこうして記事を書くことになった。 というのも、Emergeにはemerge-files-with-ancestor-commandという便利なものがあり、「マージが終わったらマージ結果を保存して即終了」ということが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く