私はWebチームの唯一のプログラマー/開発者であり、私は遠隔地で働いています。多くの場合、私の上司は電話をかけていくつかの変更をしたいので、変更を加えてコミットし、デベロッパーまたはライブサーバーにプッシュして、それらが正しいことを確認してから次に進む彼のリストの次の項目に移動します。私はGITのタイムラインを詰まらせていると感じていますが、多くのコミットが1行にすぎないと思います。誰にでも提案はありますか？リモート環境でのGitの優れたワークフロー
変更が関連している場合、それらは同時にコミットする必要があります。関連していない場合は、別のコミットがプロセスの文書化に役立ち、後で発生する可能性のある問題のトラブルシューティングが容易になります。
次の問題に移行する前に上司が変更をテストする必要がある場合は、確認のために変更をdevサーバーにアップロードし、承認後コミットすることを検討できます。
gitでは、私はあなたが最初にコミットする必要があり、その後、スカッシュ、rebase、修正すると思います。しかし、まず：コミットします。少なくとも、仕事は失われません。 承認後は、devブランチからのコミットをproduction/integration /にマージすることです。私が思うように安全です – Dolanor
個別のコミットがあまり必要ない場合は、それらを押す前にリベースを使用して、より少ない量（1回のコミットでも）でsquash themを実行できます。リベースは、一般に、押す前にローカルの履歴を書き直そうとしている場合には、後で実行する必要があります。
コードとインストールではgithubのように私はgit flowで良い経験をしました。
単一のコミットよりも大きいものはすべて、別個の機能ブランチになります。 gitflowの紹介については、screencastを参照してください。
私はgit archiveを使い、もう一方の端にgitを必要とせずに展開する傾向があります。
# fold all changes into the latest commit, no questions asked
git commit -a --amend -C HEAD
# publish
git archive HEAD | ssh devserver tar -xC /path/to/dev/instance
すべては私がコミットメッセージを改正作業をしたら、コミット押して、次のスクラッチがコミット準備：私のコマンドが迅速^ Rリコールのための1つの行で、ビットのようになります。または、私はローカルのいくつかのコミットを、迅速な磨きのためにgit rebase -i @{upstream}に保ち、それらを押します。
別のアイデアは、あなたのdevインスタンスにコミットフックから公開することです。
"多くのコミットが単なる1行です"何が問題なのですか？ –