You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by po...@apache.org on 2020/09/20 19:34:54 UTC
[airflow] branch master updated: Refactor rebase copy (#11030)
This is an automated email from the ASF dual-hosted git repository.
potiuk pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/airflow.git
The following commit(s) were added to refs/heads/master by this push:
new cac5577 Refactor rebase copy (#11030)
cac5577 is described below
commit cac5577e839ed4d3094d1961b2cd5891504fd51b
Author: Patrick Cando <32...@users.noreply.github.com>
AuthorDate: Sun Sep 20 20:32:58 2020 +0100
Refactor rebase copy (#11030)
---
CONTRIBUTING.rst | 107 +++++++++++++++++++++++++++++++++++--------------------
1 file changed, 68 insertions(+), 39 deletions(-)
diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst
index c60d115..077e57d 100644
--- a/CONTRIBUTING.rst
+++ b/CONTRIBUTING.rst
@@ -954,65 +954,94 @@ modified the master in your fork, you might loose those changes.
How to rebase PR
================
-A lot of people are unfamiliar with rebase workflow in Git, but we think it is an excellent workflow,
-much better than merge workflow, so here is a short guide for those who would like to learn it. It's really
-worth to spend a few minutes learning it. As opposed to merge workflow, the rebase workflow allows to
-clearly separate your changes from changes of others, puts responsibility of proper rebase on the
-author of the change. It also produces a "single-line" series of commits in master branch which
-makes it much easier to understand what was going on and to find reasons for problems (it is especially
-useful for "bisecting" when looking for a commit that introduced some bugs.
-
-First of all - you can read about rebase workflow here:
-`Merging vs. rebasing <https://www.atlassian.com/git/tutorials/merging-vs-rebasing>`_ - this is an
-excellent article that describes all ins/outs of rebase. I recommend reading it and keeping it as reference.
+A lot of people are unfamiliar with the rebase workflow in Git, but we think it is an excellent workflow,
+providing a better alternative to the merge workflow. We've therefore written a short guide for those who would like to learn it.
+
+As opposed to the merge workflow, the rebase workflow allows us to
+clearly separate your changes from the changes of others. It puts the responsibility of rebasing on the
+author of the change. It also produces a "single-line" series of commits on the master branch. This
+makes it easier to understand what was going on and to find reasons for problems (it is especially
+useful for "bisecting" when looking for a commit that introduced some bugs).
+
+First of all, we suggest you read about the rebase workflow here:
+`Merging vs. rebasing <https://www.atlassian.com/git/tutorials/merging-vs-rebasing>`_. This is an
+excellent article that describes all the ins/outs of the rebase workflow. I recommend keeping it for future reference.
The goal of rebasing your PR on top of ``apache/master`` is to "transplant" your change on top of
the latest changes that are merged by others. It also allows you to fix all the conflicts
-that are result of other people changing the same files as you and merging the changes to ``apache/master``.
+that arise as a result of other people changing the same files as you and merging the changes to ``apache/master``.
Here is how rebase looks in practice:
-1. You need to add Apache remote to your git repository. You can add it as "apache" remote so that
- you can refer to it easily:
+1. You first need to add the Apache project remote to your git repository. In this example, we will be adding the remote
+as "apache" so you can refer to it easily:
+
+* If you use ssh: ``git remote add apache git@github.com:apache/airflow.git``
+* If you use https: ``git remote add apache https://github.com/apache/airflow.git``
+
+2. You then need to make sure that you have the latest master fetched from the ``apache`` repository. You can do this
+ via:
+
+ ``git fetch apache`` (to fetch apache remote)
+
+ ``git fetch --all`` (to fetch all remotes)
+
+3. Assuming that your feature is in a branch in your repository called ``my-branch`` you can easily check
+ what is the base commit you should rebase from by:
+
+ ``git merge-base my-branch apache/master``
+
+ This will print the HASH of the base commit which you should use to rebase your feature from.
+ For example: ``5abce471e0690c6b8d06ca25685b0845c5fd270f``. You can also find this commit hash manually if you want
+ better control.
+
+ Run:
-``git remote add apache git@github.com:apache/airflow.git`` if you use ssh or
-``git remote add apache https://github.com/apache/airflow.git`` if you use https.
+ ``git log``
-Later on
+ And find the first commit that you DO NOT want to "transplant".
-2. You need to make sure that you have the latest master fetched from ``apache`` repository. You can do it
- by ``git fetch apache`` for apache remote or ``git fetch --all`` to fetch all remotes.
+ Performing:
-3. Assuming that your feature is in a branch in your repository called ``my-branch`` you can check easily
- what is the base commit you should rebase from by: ``git merge-base my-branch apache/master``.
- This will print the HASH of the base commit which you should use to rebase your feature from -
- for example: ``5abce471e0690c6b8d06ca25685b0845c5fd270f``. You can also find this commit hash manually -
- if you want better control. Run ``git log`` and find the first commit that you DO NOT want to "transplant".
- ``git rebase HASH`` will "trasplant" all commits after the commit with the HASH.
+ ``git rebase HASH``
-4. Make sure you checked out your branch locally:
+ Will "transplant" all commits after the commit with the HASH.
-``git checkout my-branch``
+4. Check out your feature branch locally via:
+
+ ``git checkout my-branch``
5. Rebase:
- Run: ``git rebase HASH --onto apache/master``
- for example: ``git rebase 5abce471e0690c6b8d06ca25685b0845c5fd270f --onto apache/master``
+
+ ``git rebase HASH --onto apache/master``
+
+ For example:
+
+ ``git rebase 5abce471e0690c6b8d06ca25685b0845c5fd270f --onto apache/master``
6. If you have no conflicts - that's cool. You rebased. You can now run ``git push --force-with-lease`` to
push your changes to your repository. That should trigger the build in our CI if you have a
- Pull Request opened already.
+ Pull Request (PR) opened already.
7. While rebasing you might have conflicts. Read carefully what git tells you when it prints information
about the conflicts. You need to solve the conflicts manually. This is sometimes the most difficult
- part and requires deliberate correcting your code looking what has changed since you developed your
- changes. There are various tools that can help you with that. You can use ``git mergetool`` (and you can
- configure different merge tools with it). Also you can use IntelliJ/PyCharm excellent merge tool.
- When you open project in PyCharm which has conflict you can go to VCS->Git->Resolve Conflicts and there
- you have a very intuitive and helpful merge tool. You can see more information
- about it in `Resolve conflicts <https://www.jetbrains.com/help/idea/resolving-conflicts.html.>`_
-
-8. After you solved conflicts simply run ``git rebase --continue`` and go either to point 6. or 7.
- above depending if you have more commits that cause conflicts in your PR (rebasing applies each
+ part and requires deliberately correcting your code and looking at what has changed since you developed your
+ changes.
+
+ There are various tools that can help you with this. You can use:
+
+ ``git mergetool``
+
+ You can configure different merge tools with it. You can also use IntelliJ/PyCharm's excellent merge tool.
+ When you open a project in PyCharm which has conflicts, you can go to VCS > Git > Resolve Conflicts and there
+ you have a very intuitive and helpful merge tool. For more information, see
+ `Resolve conflicts <https://www.jetbrains.com/help/idea/resolving-conflicts.html.>`_.
+
+8. After you've solved your conflict run:
+
+ ``git rebase --continue``
+
+ And go either to point 6. or 7, depending on whether you have more commits that cause conflicts in your PR (rebasing applies each
commit from your PR one-by-one).
How to communicate