7

私は git を初めて使用する開発者と仕事をしています。この開発者が行ったコミットを監査する (そしておそらく拒否する) ことができるようにする git ワークフローをセットアップしたいと考えています。新規ユーザー向け）。

シナリオは次のとおりです。

  • masterブランチには監査済みコードのみが含まれています
  • develブランチは forkmasterブランチによって作成されます
  • 開発者がdevelブランチで作業しており、私が監査するために彼のコードをプッシュしています
  • 私は彼のコードにいくつかの問題を見つけたので、develブランチでさらにコミットして問題を修正するように彼に依頼しました
  • コードに満足したら、masterブランチで開発者がコミットするチェリーピック (またはスカッシュとマージ) し、独自のコメントを追加して、開発者によって作成されたものとしてコミットをマークします。
  • master開発者はブランチを自分のdevelブランチにマージします

このシナリオの視覚的な図を次に示します。

ビジュアルシナリオ

このシーケンスの後、開発者が他のコミットの後にブランチを再度プッシュするときに、「ミス/やり直し」シーケンス中に開発者が犯したミスが再び表示されないことを100％確実にするにはどうすればよいですか?devel

devel最善の解決策は、開発者に自分のブランチをそのブランチに合わせてリベースするよう依頼することmasterですが、これは新しい git ユーザーにとって難しい作業です。

このワークフローが何らかの形で間違っている場合は、コミットをマスター ブランチにマージする前に監査できる別の方法を提案してください。

編集

友人が有望そうな方向性を提案してくれました: コミットするときの--fixup オプションです。

--fixup=<commit>

で使用するコミット メッセージを作成しrebase --autosquashます。コミット メッセージは、指定されたコミットの件名に "fixup!" というプレフィックスが付いたものになります。詳細については、 git-rebaseを参照してください。

このオプションは、開発者が 2 回目と 3 回目のコミットを最初のコミットの修正として適切にマークするために使用できます。探索するための良い解決策...

4

7 に答える 7

8

devel注意 1: 別々のコミット onを 1 つのコミット on にしようとすると、履歴がmaster書き換えられます。でクリーンで線形の履歴を維持しようとする点はわかりますが、マージによる線形性の低い履歴は、git 基本コマンドとより簡単に統合できます。master

注意 2: コードを共有するために使用する基本的なツールに慣れていないメンバーがワークフローに明示的に含まれている場合は、その結果を受け入れる必要があります。ある時点で、開発者は git を学ぶべきだと思います。

以下に 2 つの提案を示します。

  1. マスターに線形履歴をドロップし、 master から実行して変更を「検証」します。

    git merge --no-ff devel

    develこれは、 での変更が で考慮されることを git に通知する最も簡単な方法masterです。

  2. devel自分でマージを行い、開発者に から変更をプルしてもらいますorigin/devel。
    master での単一のコミットが実際に でのコミットを押しつぶすことだけで構成されている場合devel、これによって競合が発生することはありません。マージ コミットmaster->develは 0 の変更を導入する必要があります。
    押しつぶされたコミットを実際に変更し、開発者が独自のローカル変更を行うことができる場合、いずれにせよ、彼の側で競合を引き起こす可能性に直面する必要があります...

于 2014-04-15T14:42:17.710 に答える
2

単にゲリットを使用してください。gerrit を使用すると、コメント、コミットなどの履歴を保持できます。変更を放棄することもできます。私が開発者として使用するワークフロー:

準備

gerrit commit-message フックを にコピーしますrepo/.git/hooks。実行可能であり、crlf が含まれていないことを確認してください。

*nixで作業している場合は、プッシュするか、より良いシェルエイリアスのリモートレビューを行います。

~/.gitconfig にリベース用のエイリアスを作成 ( fork-pointについて)

[alias]
        reb = !"git rebase -i $(git merge-base --fork-point origin/master HEAD)"

ワークフロー

while unapproved do
    git commit -a --amend
    git push review
    # reviewers comment, reject, approve etc.
    # If rejected, I change commit as required, then
end

つぶす

gerrit にプッシュする場合、(おそらく) コミットは 1 つだけです。

したがって、ブランチのコミットを 1 つにまとめるには:

git reb

エディターが開きます。最初 (最も古いコミット) を除くすべての行に変更pickします。squash保存して終了します。エディターが開き、コミット メッセージが表示されます。最も古いコミット メッセージと Commit-ID の行を除くすべてを削除します (これは gerrit に必要です)。

リベース

ブランチのマージが gerrit で失敗した場合は、origin/master にリベースできます

git rebase origin/master

多くの競合がある場合、cherry-pick を使用するだけでそれらの多くを解決するという苦痛を回避できます

git checkout -b topic2 origin/master
git cherry-pick topic
git branch -D topic
git branch -m topic

gitレビュー

git reviewを使用して、gerrit を操作するときに一部の操作を簡素化することもできます。

于 2014-04-15T14:54:51.563 に答える
0

次のワークフローをテストし、うまくいっているかどうかをお知らせします。

前提条件

  • 開発者はコマンドラインからコミットできる必要があります
  • 開発者は、現在どのブランチがチェックアウトされているかを気にする必要がないように、常に同じブランチに留まる必要があります。
  • 開発者は、自分が書いていないコードに影響を与える競合を解決する必要はありません。
  • 開発者は、作業ツリーへのローカルの変更を失う可能性がある状況に陥ることはありません

ツール

git commit--fixup オプションを使用:

--fixup=<commit>

で使用するコミット メッセージを作成しrebase --autosquashます。コミット メッセージは、指定されたコミットの件名に "fixup!" というプレフィックスが付いたものになります。

git rebase--autosquash、--autostash、および --interactive オプションを使用

--interactive

リベースしようとしているコミットのリストを作成します。リベースする前に、ユーザーがそのリストを編集できるようにします。このモードは、コミットの分割にも使用できます。

--autosquash

コミット ログ メッセージが「squash! ...」(または「fixup! ...」) で始まり、タイトルが同じ ... で始まるコミットがある場合、 rebase -i so の todo リストを自動的に変更します。 squashing のマークが付けられたコミットが、変更されるコミットの直後に来ることを確認し、移動したコミットのアクションpickをsquash(またはfixup) に変更します。以前の fixup/squash をgit commit --fixup/--squash.

このオプションは、 --interactiveオプションが使用されている場合にのみ有効です。

構成変数を使用して--autosquashrebase.autosquashオプションがデフォルトで有効になっている場合、このオプションを使用してこの設定を上書きおよび無効にすることができます。

--autostash

操作の開始前に一時スタッシュを自動的に作成し、操作の終了後に適用します。これは、ダーティ ワークツリーで rebase を実行できることを意味します。ただし、注意して使用してください。リベースが成功した後の最終的な stash アプリケーションで、重要な競合が発生する可能性があります。

ワークフロー

  1. master開発者は、ブランチをブランチにフォークしdevelます。分岐点にはタグが付いています (例: version_1.1)
  2. devel開発者はブランチで作業してコミットします。作業が完了すると、彼は自分のブランチをリモート リポジトリにプッシュし、監査人がそれを確認して検証できるようにします。
  3. 監査人はdevelブランチを取得し、コードを調べます。何かが正しくない場合は、開発者に修正を依頼します。
  4. 開発者が行った変更ごとに、次のコマンドを使用して修正をコミットする必要があります git commit --fixup <commit that was not OK>。ブランチが再度プッシュされます。
  5. 監査人が修正に満足したら、開発者はブランチをリベースして、すべての修正コミットを美しくエラーのない 1 つのコミットにまとめる必要があります (その間に他の無関係な作業がコミットされている可能性があります)。

GIT_EDITOR=: git rebase tags/version_1.1 --interactive --autosquash --autostash.

オプションGIT_EDITOR=: により、コミット リストを表示するエディタが表示されないようにするためです。このオプションは、コミットを自動的に並べ替える--interactiveために必要です。fixup

最後のステップは、develブランチを (オプションで) 再度プッシュ--forceして、監査人がブランチにマージできるようにすることmasterです。次の devel フィックスアップのリベース ベースは、マスター ブランチか、開発者がマスター ブランチをマージして戻した後に自分の devel ブランチに付けた新しいタグである可能性があります。

結果の git ツリーは次のとおりです。

修正ワークフローの gitk の図

于 2014-04-17T15:52:31.567 に答える
0

他の開発者が常に特定のブランチ (develop など) から変更を作成するようにする場合は、次のように、常に存在するメイン ブランチのセットアップを行うことができます。

マスターする、開発する

開発者が開発ブランチから機能ブランチのみを作成する場合、必要なすべてのコミットを作成できます。次に、準備ができたと思ったら、チェリーピック/リベースして、それで自分のことをすることができます。機能ブランチは削除され、書き換えられた履歴が確実に失われます。

開発者が覚えておく必要があるのは、新しい機能を開始するたびにリモートの開発ブランチからブランチを作成し、開発にいくつかのものをマージしようとしているときにローカルの機能ブランチに触れないことだけです。

次に、準備ができたら、彼は自分の myfeature ブランチをローカルで削除し、あなたが彼の良い変更を開発にマージ/リベース/チェリーピックしたときにリモートで削除します。

良いコミットだけが開発ブランチに入ります。開発者は、以前と同様に開発から新しいブランチを作成します。

基本的な分岐は、開発者が最低限知っておくべきことだと思います。彼がブランチ/コミットをリベース/クリーンできない場合は、特定のワークフローに従うことに同意する必要があると思います。

完璧ではないかもしれませんが、それでも可能なワークフローかもしれません。それが役に立てば幸い。

于 2014-04-11T07:48:37.957 に答える