4

私は分岐せずにコードの多くの新機能に取り組み始めました。

これらの新機能は、展開する準備ができていません。ただし、別の問題を修正するための緊急のリクエストがありました。

新しい機能の追加を開始する前のバージョンに戻り、そこで修正を適用してからデプロイしたいと思います。

ただし、どちらをブランチにするか、どのバージョンをどのバージョンにマージするかについては混乱しています。

誰かがこれを行うためのステップバイステップのgitプロセスとして、この問題の解決策を私に提供できますか？

注、私はソース管理に分岐したことはありません（今、私が持つべき理由がわかります）！

4

4 に答える 4

2

これは1つの方法であり、もっと簡単な方法があるかもしれません。これは、行った変更がマシン上でのみローカルであり、リモートブランチにプッシュされないことも前提としています。

私たちが持っているとしましょう

           master
             |
A - B - C' - D'

ここでC'、D'マークは、デプロイしたくない新機能でコミットをマークします。

まず、現在のコミットで新しいブランチを作成します（master）：

git branch new_feature

ここで、commit D'、masterおよびへのポインタを指定する必要がありnew_featureます。これは、すでに行った変更を失わないようにするために重要です。

           master
             |
A - B - C' - D'
             |
        new_feature

ここで、masterブランチを新しい機能のない状態にリセットします。つまり、コミットします。Bを使用してこれを行うことができますgit reset --hard。
重要：この時点でコミットされていない変更がある場合、それらは失われます。についてのこの優れた記事git resetを読んで、それが実際に何をしているのかを理解することをお勧めします。

git reset --hard B

構造は次のようになります。

   master
    |
A - B - C' - D'
             |
        new_feature

ブランチで、masterホットフィックスの変更（commit E）を行い、それらをherokuにプッシュできるようになりました。

      master
        |
A - B - E
     \
      C' - D'
           |
       new_feature

次に、修正プログラムをブランチにマージするか、修正プログラムのnew_feature上にリベースすることができます。

git rebase master new_feature

その結果：

      master
        |
A - B - E
         \
          C' - D'
               |
          new_feature

Pro Gitの本は、Gitを学ぶための非常に優れた情報源であり、無料です：http: //git-scm.com/book。

于 2013-03-24T12:07:06.133 に答える
1

私がすることは、あなたが仕事を失うことがないように、あなたの現在の状態から機能ブランチとしてブランチを作成することです。

git checkout -b new-features && git push origin new-features

現在の状態をブランチに保存した（そしてリモートにプッシュした）のでgit checkout、元のブランチを現在のヘッドの前のポイントに戻します。

これを行う最良の方法は、を使用することgit revertです。理由と方法に関する適切な説明は、次の場所にあります。複数のgitcommitを元に戻します。

変更を元に戻し、コミットしてプッシュしたら、バグ修正を開発するためのブランチを作成することをお勧めします。これは、人々が機能ブランチを作成するのと同じ理由で良い習慣です。経験則として、作業中の問題と同じまたは類似の名前/番号でブランチを作成することをお勧めします。そこですべての変更を行い、すべての変更が完了したら、デプロイメントにタグを付けているブランチにプルインできます。

これの最良の部分は、変更がリモートにプッシュされているかどうかに関係なく機能し、シンプルで、ベストプラクティスに従っていることです。

お役に立てば幸いです。

編集：コメントで質問に答える。

「これは、行った変更がマシン上でのみローカルであり、リモートブランチにプッシュされないことも前提としています。」

すでにプッシュしている場合、そのメソッドは機能しません。それを回避する方法はありますが、私はお勧めしません。

基本的に、2つの方法の核となる唯一の違いは、一方がgit reset --hard [commit]使用し、もう一方がを使用することgit revertです。リセットすると、実際にはgitに特定のコミットに戻るように指示されます。これは基本的に必要な効果ですが、すでにプッシュしている場合は嫌われます。gitはプッシュに早送り以外の変更を加えることを許可せず、実際に履歴を消去しているためgit push origin [branch] --force、リモートも変更を失う原因となるようにする必要があります。

Revertは実際に、元に戻しているコミットに関する履歴をgitに追加するコミットを作成します。これは、元に戻されたすべての変更を追跡でき、そのブランチからプルした人​​が同期しなくなることがないため、より優れています。彼らが引っ張ると、彼らは元に戻るか、または元に戻ります。これの良い副作用は、元に戻した変更を間違えた場合、それは単なる別のコミットであるため、後で元に戻すことができることです。

于 2013-03-24T12:23:43.007 に答える
0

のように、今すぐ新しいブランチを作成できますgit checkout -b my_current_work。その後git checkout master、master-に戻り、デプロイされたコミットに戻ることができます[覚えておいてください]。たとえば、gitkコマンドを使用してグラフを表示し、適切なコミットのハッシュを取得できます。その後、git checkout hash_of_the_commitまたはgit reset --hard hash_of_the_commit（チェックアウトをお勧めします。より安全だと思います）のいずれかを実行できます。前のコミットの場合は、いつでも次のような構文を使用できますgit checkout HEAD~1。ここで、〜1は前のコミットを意味し、〜2は最後から2番目のコミットを意味します。作業全体は「my_current_work」ブランチにある必要があるため、何も失われません。新しいブランチを作成する前に、必ずすべての変更をコミットしてください。

于 2013-03-24T12:02:38.890 に答える
0

私は分岐せずにコードの多くの新機能に取り組み始めました。

それらのいずれもコミットしていないと仮定すると、一時的なブランチでそれらをコミットできます。

git checkout -b temp_work
git commit -am "temporary work"

その後master、もう一度チェックアウトし、そこから分岐して、そこで緊急の作業を行うことができます。

git checkout -b urgent_work

完了したら、テストなどに合格し、マージしてmaster

git checkout master
git merge urgent_work
于 2013-03-24T12:04:14.647 に答える