正しい方法は何ですか？
git add foo.js
git commit foo.js -m "commit"
git pull
git push
または
git pull
git add foo.js
git commit foo.js -m "commit"
git push
または
git add foo.js
git pull
git commit foo.js -m "commit"
git push
UPD：
この場合git add、追跡および変更されたファイルをステージングするために使用することを忘れました。リポジトリに新しいファイルを含めないでください。これにより、コマンドの順序が変わりますか？
回答:
これを行うための最良の方法は次のとおりだと思います。
ローカルの変更を隠します：
git stash
ブランチを最新のコードに更新します
git pull
ローカルの変更を最新のコードにマージします。
git stash apply
変更を追加、コミット、プッシュします
git add
git commit
git push
私の経験では、これはGitでの抵抗を最小限に抑えるためのパスです（とにかくコマンドラインで）。
git stashですか？
プル=フェッチ+マージ。
マージする前に、行ったことをコミットする必要があります。
したがって、コミット後にプルします。
rebase代わりにできますmerge。git commit && git rebaseまたはのいずれかでそれを行うことができますgit pull --rebase。
git pull、変更をステージングした後です。これが最も自然なことです。私は多くの異なるワークフローが機能することを認識していますが（スタッシュも素晴らしいです）、それはおそらく好みの問題です。
大規模なマージや競合の可能性を最小限に抑えるために、できるだけ頻繁にリモートブランチからプルすることをお勧めします。
そうは言っても、私は最初のオプションを選択します。
git add foo.js
git commit foo.js -m "commit"
git pull
git push
プルする前に変更をコミットして、プル中にコミットがリモートの変更とマージされるようにします。これにより競合が発生する可能性があり、問題が発生した場合にコードが既にコミットされていることを認識して対処を開始でき、何らかの理由でマージを中止する必要があります。
誰かが私に同意しないと確信していますが、このマージフローを実行する正しい方法はないと思います。人々にとって最も効果的な方法だけです。
git add私の例では、forが正確に使用されていることを説明するのを忘れました。
git pull --rebase特定の時点で持っていないリモートコミットの上にローカルで最近のコミットを設定する最もクリーンな方法だと思います。
したがって、この方法では、変更を開始するたびにプルする必要はありません。
リモートブランチの現在の状態の上に変更を配置する必要があります。ですから、おそらくあなたは自分自身をコミットする直前に引っ張りたいと思うでしょう。その後、変更をもう一度プッシュします。
リモートブランチとの競合がない限り、「ダーティ」なローカルファイルは問題になりません。ただし、競合がある場合、マージは失敗するため、ローカルの変更をコミットする前にプルするリスクや危険はありません。