問題タブ [git-workflow]

私がほとんどの Web サイトを見ると、人々は自分の git ワークフローを絵で表現しています。同じ目的でどのツールが使用されているか知りたいですか?
たとえば、https://wiki.phpbb.com/images/c/c8/Phpbb-git-workflow-small.png
およびhttp://nvie.com/posts/a-successful-git-branching-model/

私は企業向けに git を実装しており、(例に示すように) 同様の図式表現を表示したいので、それを構築するのに役立つツールがあるかどうか疑問に思っていました。

私は多くの開発者がいるいくつかのプロジェクトでgitを使用しています。私の通常のワークフローは、特定の機能/リクエストのためにローカルでブランチし、早送りマージとしてアップストリームで追跡されるローカルブランチに変更をマージし、変更をプッシュすることです。私は常に1つのコミットでも分岐します。他の人と共有しているブランチでローカルにコミットすることはないので、変更をアップストリームにプッシュするまで、ローカルでリベース/マックすることができます。好みの問題として、可能な限り、マージを早送りコミットにするのが好きです。origin/v1例として、プロジェクトのバージョン1のすべてが、ブランチ上のすべての開発者によってプッシュされた場合、次のようになります。

v1最終的には、変更をローカルにマージしてにプッシュしたいところですorigin/v1。チェックアウトしてやりgit fetch originます。feature-A変更があった場合は、チェックアウトv1してマージします

feature-Aここで、チェックアウトfeature-A、リベースv1、チェックアウトv1、マージfeature-A、およびプッシュv1バックの早送りマージを実現しoriginます。

非早送りコミットには何も問題はなく、マージコミットにも問題はありません。繰り返しますが、それは好みの問題です。ブランチのすべてのチェックアウトを実行せずに同じことを達成するためのより良いワークフローがあるかどうか疑問に思います。更新されたブランチfeature-Aの上にリベースした後、それが機能することに気付いていないgitコマンドがあるかもしれません。v1

https://stackoverflow.com/a/4157106/620304それが役立つようです。考えられるワークフローはv1、元の場所からの最新の変更で更新し、リベース後にローカルv1のHEADに更新することです。feature-A

もっと良い方法があるかもしれないと確信しています。ヘルプ/入力は大歓迎です。

私たちには約 10 人の開発者のチームがあり、誰かの変更が予期せず元に戻されるという状況に頻繁に遭遇しています。私たちのワークフローはとてもシンプルです。開発者はローカル コミットを作成し、アップストリームからプルしてからアップストリームにプッシュします (これは簡単に言えば私たちのワークフローですが、アップストリームの開発者個人のフォークから Github でプル リクエストを発行することも含まれる場合があります)。奇妙な動作は、開発者がローカル コミットを行い、アップストリームからプルしてから、自分の変更が元に戻ったことに気付くというものです。theirs私たちの誰もこの設定を持っておらず、実際のマージの競合も関係していませんが、git が戦略との競合を解決しているかのようです。変更は次のようになります。

ローカルコミット:

マージ後:

コードのこのセクションに触れる他のコミットはなく、マージの競合を手動で解決する人もいません (とにかく存在しないはずです)。開発者がマージを完了してアップストリームにプッシュした後、最初の開発者が行った変更を元に戻したように見える別の開発者のコ​​ミットに関する差分ログが表示されることがあります。通常、このリバート コミットは他の人の名前で表示されますが、その人は問題のファイルに触れていません。

他の開発者のコ​​ミット:

これがどのように起こっているか、またはそれを再現する方法はわかりません。おそらく、git コラボレーションに関する私たちの知識はいくつかの点で不足しており、誰かが私たちを正しい方向に向けてくれることを願っています.

編集 この問題は css/scss ファイルにのみ影響するようです。diff ヘッダーに間違った情報が表示されていることに気付きました。

ヘッダーがこのスタイルを として識別していることに注意してくださいimg.badge-pic。そのスタイルは、実際にはファイルのかなり前に表示されます。git が css/sass の解析に問題を抱えている可能性はありますか?

gitを使い始めたとき、ワークフローはGitflowモデルに基づいていました：http：//nvie.com/posts/a-successful-git-branching-model/。主なアイデアは、適切なブランチへのコミットを維持することだと思いました。たとえば、メインブランチには、開発ブランチからマージされたコミットのみが含まれるようになります...つまり、タグ...0.1。0.2。グラフィックの1.0。gitがどのように機能するか、またはこのワークフローがどのように動作するかを完全には理解していませんが、特にそのページのグラフィックは、すべての開発ブランチではなく、マスターブランチでのこれらのいくつかのコミットのみを示しているためです。

リポジトリをBitbucketにプッシュすると、開発ブランチで作業している間はすべてうまくいきましたが、開発が終了したときは、そしてマスターブランチをプッシュアップすると、Bitbucketのマスターブランチには開発ブランチで行ったすべてのコミットが含まれていることがわかりましたが、最後のコミット（マージしたコミット）のみが含まれると思いました。誰かがこれを理由に説明できますか、これが意図された動作であるかどうか、そうでない場合は、ワークフローを上記のモデルに沿って機能させるために何ができるかを説明できますか？Smartgitを使用しています。

Nvieのgitブランチモデルに従って、同じ「release」ブランチを両方にマージした後、「develop」と「master」がそれぞれ1つずつ先行し、1つ遅れてしまうのはなぜですか？同じ「リリース」ブランチがそれぞれにマージされている場合、マスターと開発は同意すべきではありませんか？

$ git log origin / master ^ origin / development

$ git log origin / development ^ origin / master

私は何が欠けていますか？

削除しようとしているブランチの github にオープン プル リクエストがあることをユーザーに停止/通知する方法を誰か提案できますか?

現在、さまざまな環境を表すために、次のブランチmaster、rc、hotfixおよびを使用しています。プロモートしたいブランチprodがある場合、ブランチを削除し、ブランチが構築された時点でブランチを強制的にプッシュします。通常、これは期待どおりに機能します。ただし、私が質問している例では、一部の変更セットを使用して本番環境にデプロイするケースがありました(ブランチはデプロイされているものではありません。いくつかのケースでは、これらはまだプルの形でコードレビューを待っています。さらなる優れた作品のリクエスト。hotfixprodprodhotfixhotfixHEADhotfix

私が探しているのは、ユーザーがホットフィックス ブランチを削除しようとしているときに、これがHEAD本番環境にデプロイしたものではなく、さらに重要なことに、未解決のマージ リクエストがあることをユーザーに知らせる方法です。

リモート ブランチが削除された以外の理由でプル リクエストが自動クローズされたことがありましたが、これは不要であり、prodブランチから再作成してリクエストを再開する必要があるだけです。これは、上記のようにこれらのブランチを削除する git ワークフローによるものですが、理想的には、プル リクエストが完了し、その後のデプロイが行われ、未処理の作業がない場合にのみブランチが削除されるまで、ブランチを開いたままにしておくことができます。

現在、非オープンソース プロジェクトに取り組んでおり、約 50 人のチームで、毎日平均 20 ～ 30 件のコミットを行っています。これらの人々の一部はジュニア開発者であるため、メイン リポジトリに全員がコミットできないようにするシステムを実装する必要がありました。

これまでは、次の構造で SVN を使用していました。

• トランク - すべての開発者コードが含まれていました
• ブランチ - すべての検証済みコードが含まれていました

ときどき、上級開発者の 1 人がトランクに「入り」、それをブランチとマージし、承認されていないコードをすべて拒否します (元に戻す承認されていないコードがたくさんある場合、これはおかしなことになります)。最後に、トランクに承認済みのコードしかない場合は、両者が完全にマージされます。

最近、Git と GitLab を使っていくつかのテストを開始し、Git 承認システムが SVN から移行する価値があるかどうかを確認し、この統合の狂気すべてを和らげました。

最初は有望に見えましたが、しばらくして、魔法の公式は存在しないという残念な結論に達しました。私たちは上級開発者だけが変更をプッシュするためのアクセス権を持つ保護されたマスター ブランチを作成しましたが、後輩開発者に問題が生じました。

おそらく私たちは SVN のやり方に慣れすぎているため、見つけた唯一の解決策は"ジュニア ブランチ"を作成することでした。

何か足りないものがある場合や、問題の処理方法が間違っている場合はお知らせください。

編集 私が承認されたコードと言うとき、私はすべてのクラス構造の検証、正しいオブジェクトのインスタンス化を指しています...改行、タブ(および同様のもの)が正しい場合ではありません。

私が使用するワークフローは次のとおりです。

1. ブランチに変更を加えますA。
2. チェックアウト ブランチB。
3. Aブランチからブランチへの変更をマージしますB。
4. Bブランチをリモート ブランチに同期 (プッシュおよびプル)します。
5. チェックアウト ブランチA。
6. ステップ 1に戻ります。

問題は、ときどきステップ 5 を忘れて、 branch の代わりに branchAに変更を加えることBです。

B「通常の」コミットを拒否し、マージコミットのみを許可するようにブランチを構成することは可能ですか?