（フェッチ＆プッシュ）のGit /ヘリットコマンドを理解する必要がある、と私は、このコマンドは正確にやっているかを理解したいと思います：は、私たちのIT部門からの例を、以下のい
git fetch origin +refs/changes/*:refs/remotes/origin/changes/*
をいくつかのフレームを与えるためにこれは連続的な統合（CI）ツールの一部であり、これはテストするコードをチェックアウトするステップの一部です。 CIビルドがでヘリットに押してトリガーされます。
git push origin HEAD:refs/for/master
I二次の質問に、私は開発ブランチに変更をプッシュしたい場合は、私が使用することができます：
git push origin HEAD:refs/for/development
私にはわかりませんゲリットについては何でも。しかし、私はあなたが言及する最初のgitコマンドについて何かを言うことができます。
言及したコマンドの最後の部分をrefspecsと呼びます。 Refspec chapter of the Pro Git bookで何ができるかについて読むことができます。要するに：
git fetch origin +refs/changes/*:refs/remotes/origin/changes/*
これは、リモートoriginため、originリポジトリに、Gitのディレクトリ（つまり、標準リポジトリ内.git/refs/changes/とrefs/changesにrefs/changesディレクトリにあり、枝のコミットをフェッチする、と述べています通常の裸のリポジトリで）。これらのブランチはローカルディレクトリ.git/refs/remotes/origin/changes/にコピーされます。最後に、通常のフェッチ動作ごとに、それらのブランチに属するコミットを.git/objectディレクトリにコピーします。
標準refspecは+refs/heads/*:refs/remotes/origin/*ですので、refs/changesは少し奇妙に見えます。これは標準のGitディレクトリではありませんが、おそらくGerritのことです。構造refs/remotes/origin/changesはchangesのように見えますが、ローカルリポジトリの支店です。
パッチの典型的なプルは次のようになります。 git pull ssh://www.example/com:29418/project refs/changes/24/24/2
これは、プロジェクトのプラスの変化24の第2のパッチセットを引っ張るだろうだから、たくさんすることができ、すべての変更をプルする場合。
ジェンキンス（CI）とGerritプラグインを使用し、choosing strategyを必ずGerrit Triggerと指定することをお勧めします。これにより、ビルドが適切な変更セットをテストすることが確認されます。
はい、開発ブランチにプッシュできます。もちろん、正しい権利を持っていることを確認する必要があります。最良の方法は、最初にGerritでブランチを作成することです。この方法では、「参照の作成」権限を与える必要はなく、誤ってブランチを作成することを防ぐことができます。
どのCIツールを使用していますか？ジェンキンス？ – uncletall
私はTeamcityを使用しています – Plazgoth