問題タブ [git-squash]

1. 別のレポ @github のフォークがあります。
2. いくつかのコードを実行し、アップストリームにプル リクエストを発行しました
3. アップストリーム マスターがスカッシュオプションとマージされました
4. 次のプル リクエストには、新しいコードと古いコミットも含まれます。そのため、それらはますます積み重なっていきます。

私はそれで何ができますか？

• リポジトリはコードに関して完全に同期しています
• 上部のまだ github バッジは、私のフォークがアップストリームより xx コミット進んでいることを示しています
• アップストリームを自分のレポにマージしようとしました（同期しているため効果はありません）
• リベースが役立つかどうかはわかりませんが、私のコミットと他の人のコミットがあります。そのため、そこは混乱していて、何をリベースすればよいかわかりません。

私が Git コミットを押しつぶした数回のうち、押しつぶしたい以前のコミットを選択するのに手作業が必要でした。

これを自動的に行う方法はありますか-私の目標は、特定のリモートブランチにまだプッシュされていない以前のすべてのコミットを押しつぶすことです。

詳しく説明すると、「dev」というローカル ブランチが 1 つと、パブリックとプライベートの 2 つのリモートがあるとします。必要なものをすべてコミットして、プライベート リモートの「dev」というブランチにプッシュしprivate/devます。しかし、公共のリモートでは、物事を整理整頓し、「マスター」と呼ばれる 1 つの標準ブランチを維持したいと考えていpublic/masterます。私が言ったように、パブリック リモート マスター ブランチにまだ到達していないすべてのコミットについて、それらを 1 つの大きなコミットに押しつぶして、パブリック/マスターにプッシュしたいと考えています。

どうすればそれを達成できますか？複雑そうです。

ブランチをマージしたい (と呼びましょうmy_branch) を master にします。github.com のプル リクエストで、マージの競合として表示されるファイルが 1 つあります。リベースする前に、自分のコミット (11 個のコミット) をつぶしたいと考えています。だから私はこのようなことをしました：

これにより、すべてのコミットでvimエディターが開きました-最初のものをそのままにしてpick、残りを次のように変更しましたs (squash)

保存して終了すると、エラーが発生します -error: could not apply e7ce468... 'commit1 message'

誰が私に問題が何であるかを説明できますか? すべてのコミットを解決する必要があるため、スカッシュせずにリベースできないことはわかっています..

git スカッシュをリセットするにはどうすればよいですか?

PhpStormを使用しています。過去 14 日間の作業からのコミットを押しつぶしました。コミット「HEAD DEV Refactor gulp file」には、50以上の押しつぶされたコミットが含まれています。

それらを再度表示/非圧縮するにはどうすればよいですか?

私は git で 2 つの別々のブランチを保持しようとしています。私が作業している「Dev」と、基本的にプロジェクトのクリーン バージョンをプッシュするクリーン ブランチである「Master」です。

ここでの問題は、マージ時に以前のコミットからの履歴が必要ないことです。私は、それを行う方法を理解し、最初のマージでは問題なく機能しましたが、現在（2番目のマージでは）多くのマージ競合で問題が発生しています。

これが私が以前にしたことです：

git チェックアウト開発者

git タグ -a 1.0 -m "バージョン 1.0"

git push オリジン --tags

git チェックアウト マスター

git マージ --スカッシュ 1.0

git commit "メッセージ"

git push オリジンマスター

そのため、マスター ブランチが完全にクリーンなときに初めて機能しましたが、今では多くのマージ競合が発生します。タグ 1.0 にあるすべての変更を master に強制的にマージする方法はありますか? または、これをすべて行うためのより良い方法はありますか?

リリース ブランチを master にマージしようとしていますが、master にマージするときに、develop からのコミットを単一のマージ コミットに押しつぶす必要があるかどうか疑問に思っています。

git フローに関する一般的なドキュメントには、Atlassian ページの次のような図が含まれています。

これらの図では、開発のために行われたすべてのコミットではなく、単一のコミットのみがマスターに表示されます。

実際のところ、コミットのみをリリースするマスター ブランチを持つというアイデアが気に入っています。

マスターにマージするときに、開発時にすべてのコミットを保持する必要がありますか? それとも、Gitflow に従っている場合、マスターにマージする前にコミットをスカッシュしますか?

ソース記事へのリンク: Gitflow ワークフロー - アトラシアン

次のbashスクリプトがあります：

2 つの質問があります。

1. マージが失敗した場合、マージ開始前の状態に戻すために git reset を実行する必要がありますか?
2. 1 に対する答えが「はい」であると仮定すると、上記のスクリプトは正しく、node-c.sh スクリプトがゼロ以外のコードで終了した場合、その git reset --hard が呼び出され、コード = で完全に終了します。 1?

git merge を実行すると、インデックスは常に更新されるので、 git reset --hard は常に正しいことだと考えています。

余談ですが、Git の悪いバグのように見えるものを見ています。マージが機能せず、破損した .js ファイルが生成され、「$ node -c」でコンパイルすることさえできないことがよくあります。誰かがこれを以前に見たかどうかはわかりませんが、Git にバグレポートを提出しました。

私は2つの枝を持っています。branch1には最新の変更があり、その他 ( branch2) にはリモートにある最新の変更が含まれています。

だから私がすることは、次のように最新の共有コミットを取得することです:

次に、リベースを実行します

私が抱えている問題は、これがブランチ 1 のコミットを押しつぶしているように見えないことです。コミットをつぶす必要がありますが、私の概要は間違っていますか?

Interactive オプションで rebase を使用する場合、コミットをスカッシュするかどうかを指定します。

rebase コマンドでそのようなオプションを使用する必要があるかどうか疑問に思っています

または多分