問題タブ [fast-forward]

私は多くの開発者がいるいくつかのプロジェクトで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

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

レポの git リポジトリのコレクションに対する Android システム (AOSP) の毎日のビルドと、早送りマージを使用した場合の影響との間の再現性を探しています。

問題は、毎日のビルドを行うと、他の場所で開発が行われている間にツリーの先端を取得することです。変更がプッシュされたときに HEAD が変更されていない場合、早送りマージが行われ、時刻が書き換えられます。したがって、事実上、3 日前のリポジトリの物理的な状態は、git に 3 日前に戻るように要求する場合とは異なります。

私が見ることができる主な解決策は、 --no-ff で git を使用してマージコミットを強制することです。これは小さなコミットに多くのノイズを注入し、きれいなツリーを維持する上で悪い習慣と見なされているようです.

この背景には、Android のビルド環境で再現性を持たせようとする試みがあります。知らない人のために説明すると、Android ビルドはさまざまな git リポジトリのコレクションです。私の究極のユースケースは、コードベースを 3 日前の開発者向けの状態に戻せるようにしたいということです。早送りマージでは、複数のリポジトリ プロジェクト (例: git リポジトリ) の変更を関連付ける方法に関する重要な情報が失われます。

http://nvie.com/posts/a-successful-git-branching-model/で説明されているように、リポジトリでブランチを管理する git フローの方法を使用しています。

したがって、使用するコマンドのシーケンスは次のようになります。

ただし、場合によっては、別の方法でやりたいことが 1 つあります。

機能ブランチ ( ) のすべてのコミットを保持したいのですが、mybranchにマージするときにそれらを 1 つの diff にまとめて (または押しつぶして)もらいたいと考えていますdevelop。

したがって、これはコマンドのシーケンスが次のようになるべきだと私が考えるものです。

--no-ffと組み合わせると、間違ったことをする--squashでしょうか?

これを試すのをためらっているのは、「スカッシング」と「履歴の保存」がどのように直交する要件であるかに起因します-履歴を変更せずにすべてのコミット (マージを含む) を 1 つのコミットにスカッシングするを参照してください

mybranch私の理論的根拠は、あるブランチ ( ) で履歴を保存し、別のブランチ ( ) で suqashを保存したいということですdevelop--> これらのアクションは別々のブランチで実行されるため、これで問題ありません。

私はこの状況を持っています：しばらくの間いくつかのtestBranchに取り組んでいて、マスターと同期したかったので、git checkout testBranchとgit merge master/testBranchを行いました

私のブランチはマスターと同期されましたが、そのマージを元に戻したいことがわかりました。問題は、マージが早送りで行われ、コミット履歴がマスターコミットとtestBranchコミットと混合され、方法がわからないことですtestBranch でマージする前の状態に戻します。

助けてくれてありがとう

成功した Git 分岐モデル--no-ffでは、分岐をマージするときに使用することをお勧めします。

この--no-ffフラグにより​​、マージが早送りで実行できる場合でも、マージは常に新しいコミット オブジェクトを作成します。これにより、機能ブランチの歴史的な存在に関する情報が失われるのを回避し、機能を一緒に追加したすべてのコミットをグループ化します。[…]

はい、さらにいくつかの (空の) コミット オブジェクトが作成されますが、そのコストよりもはるかに大きなメリットがあります。残念ながら、私は--no-ffまだ git merge のデフォルトの動作をする方法を見つけていませんが、そうすべきです。

ただし、 Git ワークフローを理解するためには、以下を使用しないことをお勧めします--no-ff。

そこで、新しいルールを追加します –-no-ff。これで作業が完了し、先に進みます。[…]

--no-ffバンドエイド、壊れた、bisect謎blameはすべて、ドライバーをハンマーとして使用しているという症状です。[…]

どちらのアプローチも、異なるシナリオでは妥当に思えますが、「優れた方法」と見なされるものは何ですか?

いつ使うか--no-ff、いつ使わないか、なぜ?

ストリームのメディア再生として MPMoviePlayerController があります。ストリームなので、RW 関数と FF 関数は使用しません。

そしてAppleのドキュメントは明示的に言っています

beginSeekingForward : 基になるコンテンツがストリーミングされている場合、このメソッドは効果がありません。

しかし、実際には効果があります。RW はストリームを再開し、FF はすべてを壊しているように見えます (RW または再生できません)。

私の質問は次のとおりです: beginSeekingForward および beginSeekingBackward メソッドがストリームに影響を与えない場合、なぜユーザーに表示されるのですか (フルスクリーンの場合)? また、RW ボタンと FF ボタンを非表示にする方法はありますか?

まだGITを学んでいます。「中央リポジトリ」スタイルのリモートリポジトリで行われたコミットでローカルリポジトリを同期しようとしました。最初のステップは fetch origin でした:

次に、ステータスとブランチを確認しました。

次に、--ff-only を試みました。

では、非 ff マージを実行します。

コミットを確認しました：

非 ff マージが行われたようです。マージ 'Fast-fowarding to: origin' からの出力は紛らわしいものです - それは私に何を伝えようとしていますか? 私は何が欠けていますか？ありがとう！

git pull git@github.com:myaccount/random.gitローカルの git ディレクトリを更新するために使用しました。シェルで次の結果を見つけました

次の出力を理解しようとしましたが、限界まで理解しました。削除モードまたは作成モードとは何ですか。しかし、|記号の後の数とは何なのか、何+を-表しているのか。Fast Forward行の先頭にあるもの。|ファイルが削除された場合、その出力は数値と-sのみで構成されるなど、さらに多くのことがわかりました。では、それは実際にはどういう意味ですか？

Jenkins ジョブの自動化スクリプトを開発しています。このスクリプトはパラメーターを受け取り、$1リポジトリ ファイルに小さな変更を加えて、その変更をプッシュします。それは単に行います：

これらの Jenkins ジョブが一度に実行されると、次のエラーでgit push頻繁に失敗します。

これは完全に理解できます。しかし、スクリプトの呼び出しごとに異なる$1.

マニュアルページから、次のことを学びました。

フラグは私のシナリオに適していますか?

特定のブランチの履歴を照会するプログラムを開発しています。これにより、そのブランチでのみアクティビティを実行したいと考えています。

1. そのブランチでユーザーが作成したコメントを表示したいと思います。
2. その他の情報。

これは、マスター ブランチとフィーチャー ブランチ (照会したいブランチ) がまだマージされていないときに実行できます。

私にできることは、このように master と feature-branch の間でクエリを実行し、ログを取得することです。

実行されたアクティビティのリストを取得します。

しかし、私の問題は、ブランチで Fast Forward Merge が発生すると、次のコマンドが行を返さないため、そのブランチのデータを照会または取得できないことです。

何も返されません。

早送りマージが発生した場合でも、コマンドを使用して履歴を見つける方法が Git にあることを知りたいです。