-1

私たちはチーム内で、個々の開発者がフィーチャー ブランチやリベースなどに取り組むための最適なプロセスについて行ったり来たりしてきました。複雑で多くのステップがあります。他の SO の質問と、同様でより単純に見えるいくつかの回答例があります。

これは良いワークフローですか？どのように単純化するか (もしあれば)、または変更することができますか?

git checkout develop # all developer work is off of this branch
git pull --rebase # make sure local develop is up-to-date
git checkout -b my-nifty-feature-559876 # create your feature branch; I like to put Pivotal story ID in it for convenience; not required

# do your work, make sure all tests still pass, etc. COMMIT FREQUENTLY
git commit -m "First part of my nifty feature working; now on to the back-end."

# fetch latest remote develop and rebase your local feature branch on this.
git fetch
git rebase origin/develop
# Local feature branch now has latest origin/develop code as base

# repeat above 3 frequently as you're working

# when you're done, pull and rebase one last time, make sure tests pass, then final commit with Pivotal comment
git commit -m "It works! [Fixes #559876]" # commit when done. Include comment like that for Pivotal integration
git fetch
git rebase origin/develop

# Local feature branch now has latest origin/develop code as base

git checkout develop # switch back to develop
git pull
git merge my-nifty-feature-559876 # This should be a simple FF merge
git push origin develop # send to github
git branch -d my-nifty-feature-559876 # you can get rid of your feature branch
4

1 に答える 1

-1

それはほとんどgitワークフローです。他のほぼすべての VCS で同じです。

git rebase origin/developvs.git merge origin/developは好みの問題ですが、最終結果は基本的に同等です。リベースはよりクリーンな履歴を提供しますが、マージは、いつでも昨日の場所にロールバックできることを意味します。

同様に--squash、メインブランチの履歴をいくらかきれいに保つために、最終的なマージを行うことを好む場合もあります。

ただし、オプションではないと私が考える小さなヒントが 1 つあります。それは、リベース前のバックアップです。リベースを使用して履歴を書き換えると、すべてが台無しになり、ロールバックできなくなる危険性があります。

git branch my-nifty-feature-559876-BACKUP
git rebase origin/develop

# verify everything rebased ok
git branch -D my-nifty-feature-559876-BACKUP

新しいブランチを作成するということは、リベースの前に機能ブランチのコピーがあることを意味します。resetリベースがひどく失敗した場合は、ロールバックするために使用できます。

于 2013-08-27T13:52:55.803 に答える