問題タブ [git-flow]

私はgitflowを使用していますが、考えずに、間違ったブランチ（機能）にコードをコミットしてから公開しました。

そのコードを取得して、たとえばブランチ1から削除し、正しいブランチ（ブランチ2）に移動する必要があります。

すべてのファイルは1つのフォルダーに保存されるため、作業が非常に簡単になります。これを行う方法がわかりません。

例えば。

私はgitとzshを使用しています。上司はgit-flowを使用しています。Zshは、「features」を「feature」と誤って入力したかどうかを尋ね続けます。同僚がこの理由で怒りからzshの使用をやめたので、彼をzshの光に戻すには、この問題を修正する必要があります。

更新：オートコレクトを完全に無効にする

受け入れられた答えのように、それはちょうどcorrect_allでしたが、zshオートコレクトを無効にするための構文はその更新によって異なります。以下はすべてをキャッチする必要があります：

DISABLE_CORRECTION = "true"-現在、ここから学んだことです。

更新：特定のコマンドのオートコレクトを無効にする

コマンドの自動修正を明確に無効にしますが、ディレクトリであるため「機能」ではありません（以下の回答に感謝します）。コマンドを免除するには、このソリューションを参照してください。

私たちの会社では、SvNからGitに移行しています（ええ、これまでよりも遅くなりました）。これにより、バージョン管理プロセスの合理化も試みます。そのために、興味深い記事を見つけました。VincentDriessenによるSuccessful GitBranchingModelです。

私が記事から読むことができる限り、開発者は線形リリースを想定しています。明確にするために：

古いリリースのサポートについては触れられていません。例：一部のクライアントはアップグレードを望まないため、最大3つのメジャーバージョンをサポートしています。したがって、次のバージョンがあると想像してください。

のリリースv8.0.0 後に重大なバグが見つかった場合は、v9.0.0タグをチェックアウトし、バグを修正して、ブランチv8.0.0にマージします。マージしてgetsタグを取得します。developmastermasterv8.0.1

2つの理由で、私にはどういうわけか奇妙に思えます。

1. masterタイムラインは次のようになりますv7.0.0 --> v8.0.0 --> v9.0.0 --> v8.0.1 --> v10.0.0。私はそれが可能であることを完全に承知していますが、それも受け入れられますか？
2. からにマージしhotfixてmaster（そしてmasterその時点でv9.0.0）タグを付けると、との間にv8.0.1機能が導入されますか？v8.0.0v9.0.0

前もって感謝します！

職場では、git フローに基づく git ワークフローがあります。dev、release、master の 3 つのメイン ブランチがあります。

Dev は現在取り組んでいるもの、master は本番環境にあるもの、release はリリースを行って最後のバグ修正を行っているときです。リリースの準備が整うと、リリース ブランチがマスターにマージされ、本番環境にプッシュされます。

master で作成された修正プログラムはすべて dev (およびリリース ブランチ (現在実行中の場合)) にもプッシュされます。

問題は、リリース ブランチのコードが実際にマージ後に master にあるものであることをどのように保証するかということです。別の言い方をすれば、(マージ後) リリースとマスターの間に違いはないはずです。

リリース ブランチから master にマージするときも、競合に対処したくないため、競合はすべて自動的に処理する必要があります。

私は現在、2つのソリューションに約15のプロジェクトとデータベース用のスクリプトを含む1つのgitリポジトリがあるシナリオで、gitフローを使用してリリース管理を行う方法を理解しようとしています。

各ソリューションには基本的に、実行可能ファイルを生成する 1 つのプロジェクトと、DAL、SAP アクセス ラッパーなどの両方のソリューションで使用される基本機能を含む 10 以上のプロジェクトが含まれます。
ソリューション 1 は、ユーザー向けの UI を備えたアプリケーションです。
解決策 2 は Windows サービスです。
2 つのソリューションのリリースとデータベースは同期していません。これは、多くの場合、3 つのうち 1 つまたは 2 つだけがリリースされることを意味します。これにより、バージョン番号が異なります。たとえば、UI は頻繁にリリースされますが、サービスはめったにリリースされません。その中間のデータベース。したがって、UI はバージョン 2.1.15、サービス 2.1.1、およびデータベース 2.1.5 を持つことができます。

では、共有プロジェクトをどうするか? UI のバージョン番号を使用する必要がありますか?それともサービスのバージョン番号を使用する必要がありますか?
共有プロジェクトの 1 つを変更しても、両方のソリューションのリリースが自動的にトリガーされないという事実をどのように説明すればよいでしょうか? これは、実稼働環境に同じプロジェクトの 2 つの異なるバージョンが同時に含まれていることを意味します。これは何らかの方法でリポジトリに反映する必要があります。

私はここで少し迷っています。アドバイス、経験などをいただければ幸いです。
私はレポジトリとコード ベースをどのような方法でも自由に構築できます。それが役立つ場合は、追加のレポジトリを作成できます。

私は現在、Git と GitHub を使用してバージョン管理とワークフローを管理するHubFlowの方法を学んでいます。

実践的な経験を積むために、このダミー リポジトリを作成しました。

私は次のことを試しました：

1. 開発ブランチからリリース ブランチを作成する
2. リリースブランチを閉じる
3. マスター ブランチからホットフィックス ブランチを作成する
4. ホットフィックス ブランチを閉じる

これで、マスター ブランチに 0.0.1-rc2 ができました。HubFlow 自動化ツールのおかげで、タグ付けは適切に行われています。

質問は、適切なマスター ブランチでバージョンを 0.0.1 に上げたい場合はどうすればよいですか?

それは...ですか

a) コマンドを使用して別のリリース ブランチを作成する

バージョンアップ

その後、リリースを終了します

また

b) マスター ブランチに移動

そしてバージョンアップ

また

c) 他に何か？

ありがとうございました。

私は現在、Git と GitHub を使用してバージョン管理とワークフローを管理するHubFlowの方法を学んでいます。

実践的な経験を積むために、このダミー リポジトリを作成しました。

次のような特定のコマンドを試しました

GitHub 資格情報の入力を何度も求められます。

次に例を示します。

HubFlow コマンドを使用するたびに、GitHub 資格情報を 1 回だけ提供する方法はありますか?

に本当のメッセージを伝えるにはどうすればよいgit flow release finishですか?

これは私の試みであり、その出力は次のようになります。

それを機能させる唯一の方法は、メッセージにスペースを使用しない場合です。

git flow release finishマージコミットメッセージを要求しない方法で使用するにはどうすればよいですか? 私が予想したように、-mフラグはこれを提供しません。

もちろん、目標は、対話を必要としないような方法でこれをスクリプト化できるようにすることです。

.git / config 1

.git / config 2

ただし、両方のリポジトリで、入力するbranch -aと、両方が返されます