まず、ショートカット（人気の降順）：
エイリアスgst = 'git-status'
エイリアスga = 'git-add'
エイリアスgc = 'git-commit -m'
エイリアスgp = 'git pull && git push'
エイリアスgull = 'git pull'
エイリアスgush = 'git push'
エイリアスgb = 'git-branch'
エイリアスgco = 'git-checkout'
エイリアスgd = 'git-diff'
次に、コマンドラインで現在のブランチを表示します。
export PS1 = '' __git_ps1 "％s" `\ w \ $ '
次のようになります。
lazy-args-in-futures〜/ Work / io / oleganza-io.git $
（インストール方法： ericgoodwin.com/2008/4/10/auto-completion-with-git ）
1つのブランチでの典型的なワークフロー
1）おしっこ、テストを行った
2）$ gst-どのファイルが新しく、更新されたかを見ました。
3）$ ga abc-新規および更新されたファイルをインデックスに追加しました。
4）$ gc 'something done'-コミットをリポジトリに書き込みました
5）再び彼らは何かを書き、再びコミットした。
6）$ gp-他の人の変更をマージし、変更をアップロードしました。 競合が突然発生した場合、彼らはそれについてあなたに書き込みます、あなたはまばたきします
更新をプルアップするには、$ gull（git pull）と入力します。
現地支店
原則：1つの機能-1つのブランチ。 1つのバグ修正（2回のコミットよりも長い場合）-1つのブランチ。 1つの実験-1つのブランチ。 実験内の1つの機能は、ブランチからブランチです。 さて、あなたはアイデアを得た。
なぜ必要なのですか？ 機能Aで1日を開始し、Bを修正する必要があると言ったと想像してください。5分後に、Bを人間で修正するには、Cを固定して確認する必要があることが判明しました。別々の枝に入れておくと、頭が丸くならず、作品がのどを横切ることがなくなります。
入力する：
master〜/ project $ gco -b my-feature
取得するもの：
my-feature〜/プロジェクト$
すべてのブランチのリスト：$ gb
別のブランチに切り替えます：$ gco some-branch
git merge other-branchを使用して、現在のブランチにいつでもブランチを追加できることを忘れないでください。
枝のある生活状況
1）バグの修正/機能の追加。 ブランチを作成し、すべてをテストし、マスターを追加します：gull && git merge master、test again、exit to master（gco master）、exit（ブランチ（git merge my-branch）、test、fill in the master（gush）and delete the branch（gb） -Dマイブランチ）。
2）コラボレーションブランチの公開：gush origin my-branch：refs / heads / my-branch
ブランチの削除：gush origin：refs / heads / my-branch（コロンの前のスペースに注意）
3）あるブランチに座って、別のブランチにコミットしたいことをした。 まだコミットしていない場合は、すでに追加されたファイルのgit reset HEADを実行し（ga / git-addを使用）、git-stashを使用して目的のブランチに移動し、git-stash applyを実行してから、あたかもそこにいるかのように動作しますそして変更されました。
4）いくつかの実験的なブランチにコミットしましたが、これはマスターを埋めるのが理にかなっていますが、このコミット後にさらにいくつかの実験的なコミットがあったため、git merge my-branchは機能しません。
この場合のgit-cherry-pickがあります。 まず、git-logを見て、必要なコミットの番号をコピーします。 次に、プルコミットをスローするブランチ内のすべての変更をコミットする必要があります。 次に、git-cherry-pickを実行し、競合が発生した場合は解決します。
マスターにコミットを追加することでこの状況が正確に発生したため、これらの外科的操作の後、マスターをローカルブランチに追加する必要がありました。 cherry-pickはdiffのみを適用するため（コミット番号が異なります）、ブランチは既に変更が行われていることを認識せず、それを正規化できません。 したがって、ブランチ内のマスターをマージすると、「ABC line conflicts with ABV」と同じような愚かな競合が発生することが保証されます。
このような状況で競合を回避する方法を知っている人（そして5分の時間を節約する人）は、あなたの経験を共有してください。
最後に道徳を退屈させる
1）コミットは浅くする必要があります。 5画面の差分は、ルールではなく例外です。
2）最初は、リベースとコミット行の「純度」にだまされないでください。 これは、最新の麻酔薬またはLinus（1日に1ダースのブランチをマージする）のみを悩ませます。 git-logを読んで、通常のマージコミットを無視しても問題はありません。
3）プル後にgit-logを読み、コミットのわいせつな説明について同僚をscります。
4）.git / configを調べます:-)
次回は、git-submoduleとgit-svnで快適に作業するためのいくつかの言葉を書く必要があります。