revup

Revupは、開発者が並列変更をより速く反復し、コードレビューの作成と維持のオーバーヘッドを減らすことができるコマンドラインツールを提供します。

特徴

• Revupは、作業ツリーに触れることなく、背景に枝の複数の独立したチェーンを作成します。次に、これらすべてのブランチのGitHubプルリクエストを作成および管理します。
• プルリクエストは実際のベースブランチをターゲットにし、手動または継続的な統合によってマージすることができます
• リベース検出により、パッチが変更されていない場合、再プッシングしないことで時間と継続的な統合コストを節約できます
• レビュー担当者、ラベルを追加し、コミットテキストからすべてのドラフトを作成します
• 「レビューグラフ」と「パッチセット」要素を自動更新するために、プルリクエストをナビゲートしやすくする
• ゆっくりしたレベースを交換することにより、 revup amendてrevup restack節約時間を節約します

互換性

Revupには、Python 3.8以降、GIT 2.43以上が必要です。 Revupは、Linux、OSX、およびWindows（限られたテスト）で動作します。

ここで手順に従って、OSの最新のgitバージョンを取得します。 Revupは、新しいgitバージョンにのみ存在するフラグを使用します。

インストール

pipまたはお気に入りのパッケージマネージャーとともにインストールします。

python3.8 -m pip install revup

ヘルプページを表示することでインストールが成功したことを確認してください。

revup -h

ソースから構築して、最新の更新を取得することもできます。

 git clone https://github.com/Skydio/revup.git && cd revup
make deps && make package && make install

チュートリアル

このチュートリアルでは、基本的なRevup機能を使用してガイドします。

初めてのセットアップ

Revupを分岐し、新しいリポジトリの作成、または所有している他のリポジトリを使用して、Sandbox Repoをクローンします。テストPRを作成することはスパムである可能性があるため、他の人のレポでチュートリアルを行わないでください。

git clone https://github.com/ < your-name > /revup.git && cd revup

最初の実行では、GitHub資格情報を構成する必要があります。ここで個人的なアクセストークンを作成し、「完全なレポード許可」についてはボックスを確認してください。 Revupは、プルリクエストを作成および変更するためにこれを必要とします。その後、実行します

revup config github_oauth

OAUTHをコピーしてプロンプトに貼り付けます。

独立したプルリクエストを作成します

2つの個別のプルリクエストになる最初の2つのコミットを作成します。コミットメッセージの「トピック：」タグに注意してください - これは、Revupがコミットを認識し、行動する原因となるものです。それぞれ別々に指定されたトピックが新しいプルリクエストになります。

 echo meh > foo ; git add foo
git commit -m " My first revup foo " -m " Topic: foo "
echo peh > bar ; git add bar
git commit -m " My first revup bar " -m " Topic: bar "

revup upload

最初のRevupの変更をアップロードしました！ Githubで、両方の分岐が「メイン」をターゲットにする方法に注意してください。これにより、それらを独立してマージすることができます。

ボンネットの下で、Revupはこれらのブランチを作成およびプッシュし、必要に応じて依存関係を追跡および管理します。

相対的なプルリクエストを作成します

次に、「foo」に関連する新しいレビューを作成します。 「相対」タグは、新しいレビューが正しいブランチをターゲットにすることを保証します。

 echo deh >> foo ; git add foo
git commit -m " My second revup foo " -m " Topic: foo2 " -m " Relative: foo "

revup upload

このシンプルで強力なモデルを使用すると、独立した依存の変更を一度にアップロードできます。

• 複数のコミットが1つのトピックになる可能性があります。その場合、それらはすべて1つのプルリクエストになります。
• 同じトピックでコミットすることは、歴史上隣接する必要はありません。
• 互いに関連するトピックは歴史上隣接する必要はありませんが、2番目のトピックは最初のトピックの後に来なければなりません。

プルリクエストを変更します

それでは、プルリクエストを更新しましょう。

 echo heh >> bar ; git add bar
# Either
revup amend HEAD~ --no-edit  # Specify a commit to amend
# or
revup amend bar --no-edit  # Specify a topic name to amend

revup upload

revup amend 、歴史の中でコミットを簡単に変更できます。また、レビューを変更する他のオプションもあります。

• 同じトピックで新しいコミットメントを追加します
• git rebase --interactiveを使用します - git commit --amendとともに対話型

上流の変更を引き込みます

git pull --rebaseを使用して変更を引き込みます。 Merge Commitを作成するため、Rebaseなしでgit mergeまたはgit pull使用しないでください。

デフォルトでは、Revupはプルしてもアップロードされませんが、コミットに変更を加えていません。これをオーバーライドして常にアップロードするには、 revup upload --rebase実行します。

 [pull]
    rebase = true
[rebase]
    autoStash = true

上記を.gitconfigに追加して、引っ張ってリベッシングを簡単にすることをお勧めします。

その他の機能

これは、より便利な改訂機能の網羅的ではないイントロです。

機能の完全な説明については、ドキュメントを参照するか、 revup -hまたはrevup upload -hを実行して、 man形式でドキュメントを表示します。

フォークを使用します

プッシュアクセスがない可能性のあるプロジェクトに貢献するために、メインプロジェクトでプルリクエストを作成しながら、フォークにプッシュするようにRevupを設定できます。

オリジナルとフォークの両方にGit Remotesを追加します。

 $ git remote -v
origin  https://github.com/ORIGINAL_OWNER/REPO_NAME.git (fetch)
origin  https://github.com/ORIGINAL_OWNER/REPO_NAME.git (push)
myfork  https://github.com/YOUR_USERNAME/REPO_NAME.git (fetch)
myfork  https://github.com/YOUR_USERNAME/REPO_NAME.git (push)

アップロードするときは、リモコンを渡して、 --remote-nameとForked Remote as --fork-nameとしてプル要求を作成します。

 revup --remote-name origin --fork-name myfork upload

レビュー担当者 /ラベルを追加します

Revupは、レビュアー、譲受人、およびラベルを追加してリクエストをプルすることもできます。トピックのコミットに適切なタグを追加します。

 Reviewers: alice, bob
Assignees: eve
Labels: bug, feature, draft

GitHubのユーザー名は省略でき、指定されたプレフィックスと最短の名前を一致させます。

ラベルは正確に一致する必要があります。 draftラベルは特別であり、存在する場合はドラフトをプルリクエストし、削除した場合はドラフトを解除します。

他のブランチで作業しています

Revupは通常、地元のベースブランチを自動検出し、それを使用してコミットとターゲットのレビューをリストします。特定のトピックを別のブランチまたは複数のブランチにターゲットにすることを選択できます。この場合、Revupは代わりにそれらをベースブランチとして使用します（そして、後者の場合に複数のプル要求を作成します）。

 A fix for multiple branches

Topic: fix
Branches: main, rel1.1

コマンドラインのベースブランチも指定できますが、これは通常、オートデテクタが知らないブランチで作業している場合を除き、通常は必要ありません（以下のレポ設定を参照）。

 revup upload --base-branch custom-branch-name

グラフとパッチセットを確認します

Revupは、ユーザーとレビュアーに役立つ機能を提供するために、すべてのプルリクエストに2つのコメントを追加します。これらはデフォルトで有効になり、プル要求が変更されると自動的に更新されます。

レビューグラフは、現在のプル要求と相対的な関係を持つすべてのローカルプルリクエストへのリンクとタイトルを提供します。これにより、チェーン内のプルリクエスト間ですばやく閲覧できます。

PatchSetsテーブルは、特定のプル要求のアップロードの履歴と、各アップロード間のDIFFのリンクと要約を提供します。特に、Revupは特別に、Rebaseのアップロードを再確認し、上流ファイルを除外したDIFFを表示します。

Revupの構成

Revupは、標準の構成ファイル形式を使用して高度に構成できます。すべてのフラグは設定オプションでもあるため、ユーザーは必要な正確な動作を取得できます。

コマンドラインで指定されたフラグが優先され、その後に~/.revupconfigの設定が続き、現在のリポジトリで.revupconfigが続きます。

リポジトリ構成

In-Repo構成ファイルの主要なUSECASEは、メインブランチとリリースブランチの命名を設定することです。

たとえば、メインブランチがmasterとリリースブランチがrel1.1のように名前が付けられている場合、レポートルートの.revupconfigに以下をコミットします。

 [revup]
main_branch = master
base_branch_globs =
    rel[1-9].[0-9]
    rel[1-9].[0-9][0-9]

ユーザー構成

~/.revupconfigのユーザー構成は、最も一般的に使用されるフラグをデフォルトで節約することにより時間を節約します。

たとえば、ワークフローに慣れた後、ユーザーは確認チェックを必要としない場合があります。次の行を追加することは--skip-confirmで実行されるのと同じです。

 [upload]
skip_confirm = True

付録

コミットベースの開発

（別名「積み重ねられたdiffs」、「パッチベース」など）

Gerrit、Phabricator、またはGitメーリングリストなどのツールを使用している場合、このスタイルの開発にはすでに精通している可能性があります。もっと読みたい場合は、このテーマに関するいくつかのよく書かれた議論をご紹介します。

• 積み重ねられたdiffs vsプルリクエスト
• 積み重ねられたPRを賞賛しています

ピアプロジェクト

Revupは、パッチベースのワークフローもサポートするオープンソースプロジェクトのこの非網羅的なリストに一部触発されています。

• Ghstack：GitHubと統合されたパッチベースのツールも。 Revupは、このプロジェクト、特にGraphQL使用量のコードに基づいて構築されます。
• git-branchstack： revup uploadに似たブランチを作成しますが、レビューをプッシュまたは作成しません。
• Git-Revise：競合を処理するマージシステムを使用して、上記のrevup amendとバックエンドと同様

貢献とサポート

Revupに貢献してくれてありがとう！自分のアイデアを始めたり、他の人が興奮しているアイデアの問題ページを見ることができます。

問題を報告するとき：

• 問題のトラッカーが既に報告されているかどうかを確認してください。
• レプロステップの説明を提供します。
• 可能であれば、 revup -vで同じコマンドを実行して、冗長なログを提供します。

免責事項

RevupはSkyDioによって公開されていますが、公式にサポートされているSkyDio製品ではありません。