続・Gitリポジトリ運用の最適解 - chulip.org
このエントリは過去に書いたエントリの続編として位置づけています。 過去の記事：Gitリポジトリ運用の最適解 - chulip.org この記事を書いた当時、いや少なくとも少し前までは本気でマージコミットがないGit運用が最高だと考えていました。 だからこそ、何故A successful Git branching modelがNon-Fast-Forwordマージを推奨しているか疑問であり、昨今のgit-mergeには--no--ffオプションを設定。むしろgit-configでデフォルトの挙動を--no-ffにできるから設定しとけお前らという話に対してよく理解ができていませんでした。 マージコミットがないGit運用が最高だというのは限られた場合の話ではないか ある特定の場合においてのみこの話は適応されるのではないかということに気づきはじめたような気がします。 これは例えばリリース前の開発
git-mergeで--ff(デフォルト)と--no-ffと--squashの違い - u1tnkの日記
きっかけ A successful Git branching model » nvie.com ここらあたりを見て、--no-ffつけときゃいいんだなーと深く考えずに使ってたら、--squashつけると安全とかなんとかチラ聞きして混乱しまくったので調べてみた。 とりあえずman。 man git-merge ... --ff, --no-ff Do not generate a merge commit if the merge resolved as a fast-forward, only update the branch pointer. This is the default behavior of git-merge. With --no-ff Generate a merge commit even if the merge resolved as a fast-forwa
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
