Github for Mac ブログの発表によると、
コミットを共有する、またはリモート コミットをプルする準備ができたら、[ブランチの同期] ボタンを押すだけです。
pull --rebase && pushマージのコミットを減らしますが、マージを書き換えない、よりスマートなバージョンを実行します。
の「よりスマートなバージョン」とはpull --rebase && push何ですか? 彼らは正確に何をしているのですか?コマンドラインでこの「よりスマートな」ことを行うことは可能ですか?
Github for Mac ブログの発表によると、
コミットを共有する、またはリモート コミットをプルする準備ができたら、[ブランチの同期] ボタンを押すだけです。
pull --rebase && pushマージのコミットを減らしますが、マージを書き換えない、よりスマートなバージョンを実行します。
の「よりスマートなバージョン」とはpull --rebase && push何ですか? 彼らは正確に何をしているのですか?コマンドラインでこの「よりスマートな」ことを行うことは可能ですか?
ブログ投稿 " Rebasing Merge Commits in Git " ( Glen Madderngit pull --rebase による) は、ローカル マージを行った場合の危険性を示しています。

今git pull --rebaseのmaster上に ofを実行すると、ローカルの mergeorigin/masterが削除されます。
リベース後の次の図を参照してください。マージコミットはもうありません。

これは多くの理由で悪いです。
- 1 つには、実際にはマージをリベースしたいだけなのに、機能のコミットが実際に複製されています。後でフィーチャー ブランチを再度マージすると、両方のコミットが の履歴に残ります
 master。- そして
 origin/feature、完成したはずmasterの が ぶら下がったままになっています。
優れた分岐/マージ モデルに従って得られる素晴らしい歴史とは異なり、実際には誤解を招くような歴史があります。
たとえば、誰かが のブランチを見ると、master にマージされていても、まだマージされていないoriginように見えます! その人が展開を行うと、あらゆる種類の問題が発生する可能性があります。全体的に悪いニュースばかりです。origin/feature
これは、Github for (Mac|Windows) が検出して回避するものです。
時間内に検出できなかった場合は、同じブログ投稿で次の回復について言及されています。
[master] git reset --hard origin/master
HEAD is now at 9f3e34d sneaky extra commit
[master] git merge --no-ff feature
実際の解決策:
望ましい結果を得ることができます。

を使用する代わりに、 と を
git pull --rebase使用します。git fetch origingit rebase -p origin/master
の「よりスマートなバージョン」は、pull --rebase「マージを保持するフェッチ + リベース」の組み合わせだと思います。
Glenはまた、この一連のコマンドがローカル ブランチに関連付けられた追跡情報を使用しなくなるという事実に対抗するために、次のエイリアスを提案しています。
function git_current_branch() {
  git symbolic-ref HEAD 2> /dev/null | sed -e 's/refs\/heads\///'
}
alias gpthis='git push origin HEAD:$(git_current_branch)'
alias grb='git rebase -p'
alias gup='git fetch origin && grb origin/$(git_current_branch)'
Jason Weatheredは「 http://jasoncodes.com/posts/gup-git-rebase 」を投稿しましたが、現在はAanand Prasadの git-upを参照しています。
@VonCの回答は非常に便利ですが、新しい合法について言及したかったのです。基本的にlegitはスマート マージです(GitHub for Mac が行うことと同じではないにしても、非常に似ています)。
git log --merges branch..from_branchmergeし、そうでない場合はrebasegit pull --rebase@VonCの回答どおりには機能しませんが、git rebase --preserve-mergesより良いですが、他のブランチをマージした場合は重複したコミットが作成されます。そのため、ある時点で「リベース」が実際に意味があるのか、それとも代わりに「マージ」する必要があるのかを判断する必要があり、それlegitが正確に行われます (これも GitHub for Mac と同様です)。