開発ワークフロー#

scikit-imageリポジトリのフォークされたコピーは、scikit-imageの独自のコピー（フォーク）を作成するに従って、すでに作成済みです。フォークを設定するが完了しています。gitを設定するに従ってgitを設定しました。これで、実際の作業を開始する準備が整いました。

ワークフローの概要#

以下では、アップストリームのscikit-image mainブランチを「trunk」と呼びます。

自分のmainブランチは何も使わないでください。削除することを検討してください。
新しい変更セットを開始する場合は、trunkから変更をフェッチし、そこから新しいフィーチャーブランチを開始します。
分離可能な変更セットごとに新しいブランチを作成します。「1つのタスク、1つのブランチ」（ipython gitワークフロー）。
変更の目的に合わせてブランチに名前を付けます。例：bugfix-for-issue-14またはrefactor-database-code。
可能な限り、作業中にtrunkや他のブランチをフィーチャーブランチにマージすることは避けてください。
trunkからマージしている場合は、trunkへのリベースを検討してください。
行き詰まった場合は、scikit-image開発者フォーラムで質問してください。
コードレビューを依頼してください！

この作業方法は、作業を整理し、読みやすい履歴を維持するのに役立ちます。これにより、プロジェクトメンテナー（あなたかもしれません）は、あなたが行ったこととその理由を簡単に確認できます。

いくつかの説明については、linux gitワークフローとipython gitワークフローを参照してください。

mainブランチの削除を検討する#

奇妙に聞こえるかもしれませんが、自分のmainブランチを削除すると、どのブランチにいるのかについての混乱を減らすことができます。詳細については、githubでのmasterの削除（masterをmainに置き換える）を参照してください。

trunkのミラーを更新する#

最初に、リポジトリをアップストリームリポジトリにリンクするを実行したことを確認してください。

時々、githubからアップストリーム（trunk）の変更をフェッチする必要があります。

git fetch upstream

これにより、まだ持っていないコミットがプルダウンされ、リモートブランチが正しいコミットを指すように設定されます。たとえば、「trunk」は（リモート/ブランチ名）upstream/mainで参照されるブランチであり、最後に確認したときからコミットがある場合は、フェッチを実行するとupstream/mainが変更されます。

新しいフィーチャーブランチを作成する#

コードを変更する準備ができたら、新しいブランチを開始する必要があります。関連する編集のコレクションのためのブランチは、しばしば「フィーチャーブランチ」と呼ばれます。

関連する変更のセットごとに新しいブランチを作成すると、ブランチをレビューする人が何をしているのかを簡単に確認できるようになります。

ブランチの名前には、自分自身と他の人にブランチの変更内容を思い出させるような情報に富んだ名前を選択します。たとえば、add-ability-to-fly、またはbuxfix-for-issue-42。

# Update the mirror of trunk
git fetch upstream
# Make new feature branch starting at current trunk
git branch my-new-feature upstream/main
git checkout my-new-feature

一般に、フィーチャーブランチは、scikit-imageの公開githubフォークに保持します。これを行うには、この新しいブランチをgit pushしてgithubリポジトリにアップロードします。一般に（これらのページの手順に従った場合、およびデフォルトでは）、gitにはoriginと呼ばれるgithubリポジトリへのリンクがあります。github上の自分のリポジトリにプッシュするには、

git push origin my-new-feature

git>=1.7では、--set-upstreamオプションを使用することで、リンクが正しく設定されていることを確認できます。

git push --set-upstream origin my-new-feature

今後は、gitはmy-new-featureがgithubリポジトリのmy-new-featureブランチに関連していることを認識します。

編集ワークフロー#

概要#

# hack hack
git add my_new_file
git commit -am 'NF - some message'
git push

詳細#

変更を加えます

git statusでどのファイルが変更されたかを確認します（git statusを参照）。次のようなリストが表示されます。

# On branch ny-new-feature
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#  modified:   README
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#  INSTALL
no changes added to commit (use "git add" and/or "git commit -a")

git diff（git diff）で実際の変更内容を確認します。
新しいファイルをバージョン管理に追加するには、git add new_file_nameを実行します（git addを参照）。
すべての変更されたファイルをリポジトリのローカルコピーにコミットするには、git commit -am 'A commit message'を実行します。commitの-amオプションに注意してください。mフラグは、コマンドラインでメッセージを入力することを示すだけです。aフラグは—信じるか、または-aフラグが必要な理由 —および絡まった作業コピーの問題での役立つユースケースの説明を参照してください。git commitマニュアルページも役立つ場合があります。
githubのフォークされたリポジトリに変更をプッシュするには、git pushを実行します（git pushを参照）。

変更のレビューまたはマージを依頼する#

コードをレビューしてマージを検討してもらう準備ができたら

フォークされたリポジトリのURL（たとえば、https://github.com/your-user-name/scikit-image）に移動します。
ページの左上近くにある「ブランチの切り替え」ドロップダウンメニューを使用して、変更が含まれるブランチを選択します。
「プルリクエスト」ボタンをクリックします

変更セットのタイトルと、行った変更の説明を入力します。複雑な変更や、満足していないコードなど、特に注意してほしいものがあれば記載してください。

リクエストをマージする準備ができていない場合は、プルリクエストメッセージでその旨を伝えてください。これは、予備的なコードレビューを行う良い方法です。

その他に実行できること#

githubでブランチを削除する#

git checkout main
# delete branch locally
git branch -D my-unwanted-branch
# delete branch on github
git push origin :my-unwanted-branch

（test-branchの前のコロン:に注意してください。以下も参照してください：https://help.github.com/en/github/using-git/managing-remote-repositories

リポジトリを探索する#

リポジトリのブランチとコミットをグラフィカルに表示するには

gitk --all

このブランチのコミットを直線的にリスト表示するには

git log

GitHubリポジトリのネットワークグラフビジュアライザーも確認できます。

最後に、Fancy log出力の lg エイリアスを使用すると、リポジトリのテキストベースのグラフを適切に表示できます。

トランクへのリベース#

何か作業をしたいと思ったとします。トランクのミラーを更新し、cool-featureという新しいフィーチャーブランチを作成します。この段階でトランクはあるコミット（Eとします）にあります。次に、cool-featureブランチに新しいコミット（A、B、Cとします）をいくつか作成します。変更に時間がかかる場合や、しばらくしてから変更を再開する場合があります。その間に、トランクはコミットEからコミットGに進んだとします。

      A---B---C cool-feature
     /
D---E---F---G trunk

この段階で、トランクをフィーチャーブランチにマージすることを検討し、このページでは履歴が乱雑になるため、マージしないように強く推奨していることを思い出します。ほとんどの場合、レビューを依頼するだけで済み、トランクが少し先行していることを気にする必要はありません。しかし、トランクの変更が自分の変更に影響を与え、それらを調和させる必要がある場合があります。このような状況では、リベースを行う方が良いかもしれません。

リベースは、自分の変更（A、B、C）を取得し、trunkの現在の状態に対して行ったかのようにそれらを再生します。言い換えれば、この場合、A、B、Cで表される変更を取得し、Gの上にそれらを再生します。リベース後、履歴は次のようになります。

              A'--B'--C' cool-feature
             /
D---E---F---G trunk

詳細については、涙なしのリベースを参照してください。

トランクでリベースを行うには

# Update the mirror of trunk
git fetch upstream
# go to the feature branch
git checkout cool-feature
# make a backup in case you mess up
git branch tmp cool-feature
# rebase cool-feature onto trunk
git rebase --onto upstream/main upstream/main cool-feature

すでにブランチcool-featureにいる場合は、最後のコマンドは次のように簡潔に記述できます。

git rebase upstream/main

すべて問題ないように見えたら、バックアップブランチを削除できます。

git branch -D tmp

うまくいかない場合は、混乱からの回復を確認する必要があるかもしれません。

トランクでも変更されたファイルに変更を加えた場合は、解決する必要があるマージ競合が発生する可能性があります。「Description」セクションの最後に記載されているgit rebase manページを参照してください。gitユーザーマニュアルのマージに関する関連ヘルプについては、マージの解決を参照してください。

混乱からの回復#

時々、マージやリベースを失敗することがあります。幸いなことに、gitではこのようなミスから比較的簡単に回復できます。

リベース中に失敗した場合

git rebase --abort

リベース後に失敗に気付いた場合

# reset branch back to the saved point
git reset --hard tmp

バックアップブランチを作成するのを忘れた場合

# look at the reflog of the branch
git reflog show cool-feature

8630830 cool-feature@{0}: commit: BUG: io: close file handles immediately
278dd2a cool-feature@{1}: rebase finished: refs/heads/my-feature-branch onto 11ee694744f2552d
26aa21a cool-feature@{2}: commit: BUG: lib: make seek_gzip_factory not leak gzip obj
...

# reset the branch to where it was before the botched rebase
git reset --hard cool-feature@{2}

コミット履歴の書き換え#

注意

これは自分のフィーチャーブランチでのみ行ってください。

コミットに恥ずかしいタイプミスがある場合や、後世に見せたくない失敗をいくつか行った場合。

これは、*対話型リベース* を使用して行うことができます。

コミット履歴が次のようになっていると仮定します。

git log --oneline
eadc391 Fix some remaining bugs
a815645 Modify it so that it works
2dec1ac Fix a few bugs + disable
13d7934 First implementation
6ad92e5 * masked is now an instance of a new object, MaskedConstant
29001ed Add pre-nep for a copule of structured_array_extensions.
...

そして、6ad92e5 が cool-feature ブランチの最後のコミットであるとします。次の変更を行うと仮定します。

13d7934 のコミットメッセージをもっと適切なものに書き換えます。
コミット 2dec1ac、a815645、eadc391 を1つにまとめます。

次のように実行します。

# make a backup of the current state
git branch tmp HEAD
# interactive rebase
git rebase -i 6ad92e5

これにより、次のテキストを含むエディターが開きます。

pick 13d7934 First implementation
pick 2dec1ac Fix a few bugs + disable
pick a815645 Modify it so that it works
pick eadc391 Fix some remaining bugs

# Rebase 6ad92e5..eadc391 onto 6ad92e5
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

目標を達成するために、次のように変更します。

r 13d7934 First implementation
pick 2dec1ac Fix a few bugs + disable
f a815645 Modify it so that it works
f eadc391 Fix some remaining bugs

これは、（i）13d7934 のコミットメッセージを編集し、（ii）最後の3つのコミットを1つにまとめることを意味します。次に、保存してエディターを終了します。

gitはコミットメッセージを編集するためのエディターをすぐに起動します。修正後、次の出力が得られます。

[detached HEAD 721fc64] FOO: First implementation
 2 files changed, 199 insertions(+), 66 deletions(-)
[detached HEAD 0f22701] Fix a few bugs + disable
 1 files changed, 79 insertions(+), 61 deletions(-)
Successfully rebased and updated refs/heads/my-feature-branch.

そして、履歴は次のようになります。

0f22701 Fix a few bugs + disable
721fc64 ENH: Sophisticated feature
6ad92e5 * masked is now an instance of a new object, MaskedConstant

うまくいかなかった場合、上記で説明したように、復旧が可能です。