github.com/kaituanwang/hyperledger@v2.0.1+incompatible/docs/source/github/github.rst (about)

     1  **GitHub Contributions**
     2  ========================
     3  
     4  Forking the repository
     5  ----------------------
     6  
     7  To protect the Hyperledger Fabric source code, and maintain a clean state in
     8  the official GitHub repositories, Hyperledger Fabric GitHub pull requests
     9  are accepted from forked repositories only. The act of forking a GitHub
    10  repository creates an identical copy of the repository in your personal
    11  GitHub account. You are then able to edit code and propose these changes
    12  to the official Hyperledger Fabric repositories you forked the code from via
    13  the GitHub pull request process.
    14  
    15  To fork a repository:
    16  
    17  - Navigate to the GitHub repository you wish to fork in your browser
    18  - In the top right corner select the Fork button
    19  
    20  .. image:: ../images/fork.png
    21     :scale: 50%
    22  
    23  - Your browser will automatically take you to the forked repostiory within
    24    your personal GitHub account once the forking process has complete
    25  
    26  You can now clone your personal fork to your local machine.
    27  
    28  Cloning the Repository and Syncing With the Upstream Project
    29  ------------------------------------------------------------
    30  
    31  Once you have forked the repository you can now clone the project to your
    32  local machine to begin your development work. This will create a local
    33  GitHub repository on your machine.
    34  
    35  .. Note ::
    36  
    37     Prerequisite: This guide uses GitHub's SSH protocol for cloning repositories.
    38     If you have not yet setup SSH access for GitHub please use the
    39     `GitHub guide <https://help.github.com/en/articles/connecting-to-github-with-ssh>`_
    40     to configure your SSH access.
    41  
    42  To clone a repository:
    43  
    44  - Open your terminal
    45  - Navigate to the location on your local disk where you want to clone the repository
    46  
    47  .. note::
    48     For Go-based repositories not yet using Go Modules, the location on your disk
    49     must be relative to your GOPATH's `src` directory, i.e.,
    50     `$GOPATH/src/github.com/hyperledger`.
    51  
    52  - Execute the following command to clone your fork
    53  
    54  .. code::
    55  
    56     git clone git@github.com:<your_github_id>/<repository_name>.git
    57  
    58  - Now change to the repositories directory and sync your local
    59    repository with its remote upstream repository
    60  
    61  .. code::
    62  
    63     cd <repository_name>
    64     git remote add upstream https://github.com/hyperledger/<repository_name>.git
    65  
    66  - You can now list your remote branches and confirm your local repository has created
    67    a link with the remote upstream repository
    68  
    69  .. code::
    70  
    71     git remote -v
    72  
    73  You have now cloned your forked repository and configured its upstream repository.
    74  You can now begin development.
    75  
    76  Create a Local Feature Branch for Your Development work
    77  -------------------------------------------------------
    78  
    79  To protect the state of the existing branches in your forked repository
    80  and ensure the work you perform is saved in a logical location, the use
    81  of feature branches in your forked repository is recommended. A feature
    82  branch is created from an existing branch and is where you will perform
    83  your development work before pushing the changes back to your fork of
    84  the GitHub repository. To create a feature branch, perform the following steps:
    85  
    86  - Fetch the project branches from the upstream repository
    87  
    88  .. code::
    89  
    90     git fetch upstream
    91  
    92  - Checkout one of the existing branches
    93  
    94  .. code::
    95  
    96     git checkout -t origin/master
    97  
    98  - Merge the upstream counterpart into your local master
    99  
   100  .. code::
   101  
   102     git merge upstream/master
   103  
   104  - Update your fork on GitHub with any changes from the upstream master
   105  
   106  .. code::
   107  
   108     git push origin master
   109  
   110  - You can now checkout a new local feature branch, this ensures you do not diverge
   111    the local master branch from its remote counterpart. The feature branch will be
   112    an exact copy of the branch from which you created it.
   113  
   114  .. code::
   115  
   116     git checkout -b <feature_branch_name>
   117  
   118  Now that you have created a local feature branch, you can perform your updates.
   119  
   120  Commiting and Pushing Changes to Your Forked Repository
   121  -------------------------------------------------------
   122  
   123  Once you have completed the work you intend to perform in your local feature branch,
   124  you can commit this code and push it to your forked repository to save its state.
   125  This is a prerequisite to opening pull requests against the Hyperledger repositories.
   126  Perform the following steps to commit and push your code to your forked repository:
   127  
   128  - Add existing files you have changed to your commit by executing the following command,
   129    the '-p' flag will open an interactive terminal for you to review and approve your
   130    changes before adding them to your commit:
   131  
   132  .. code::
   133  
   134     git add -p
   135  
   136  - Add new files you have created by executing:
   137  
   138  .. code::
   139  
   140     git add <file1> <file2>
   141  
   142  - You can now create your commit containing the changes you just added. Your commit
   143    message must contain the following information:
   144  
   145    - one line summary of the work in this commit as title, followed by an empty line
   146    - in the commit message body, explain why this change is needed, and how you approached it.
   147      This helps reviewers better understand your code and often speeds up the review process.
   148    - link to JIRA item or JIRA number, i.e. FAB-XXXXX
   149    - (optional) if no new tests are added, how the code is tested
   150  
   151  .. code::
   152  
   153     git commit -s
   154  
   155  .. note::
   156  
   157     Hyperledger requires that commits be signed by the commiter.
   158     When issuing the `commit` command, specify the `-s` flag to
   159     automatically add your signature to your commit.
   160  
   161  - You can now push your local changes to your forked repository
   162  
   163  .. code::
   164  
   165     git push origin <feature_branch_name>
   166  
   167  .. note::
   168  
   169     If you want to integrate upstream changes from the original repository
   170     before pushing your changes see the section at the bottom of this page titled,
   171     `Syncing Your Fork With the Upstream Repository`_.
   172  
   173  You have now successfully pushed your local changes to your forked repository. To
   174  integrate these changes you must now go through the pull request process.
   175  
   176  Opening a Pull Request in GitHub
   177  --------------------------------
   178  
   179  Now that you've created and pushed changes to a feature branch in your forked
   180  repository, you can now open a pull request against the original Hyperledger
   181  repository from which you created your fork and begin the code review process.
   182  
   183  - To begin, navigate to `https://github.com/hyperledger/<original_repository>` in your browser
   184  - Select the `Pull Requests` tab at the top of the page
   185  - In the top right corner of the Pull Requests page, select `New Pull Request`
   186  - On the Compare Changes page, select `compare across forks` at the top of the page
   187  - Select the Hyperledger repo from which you created the fork as the `base repository`
   188    and the branch you want to merge into as the `base`
   189  - Select your fork as the `head repository` and your feature branch as the `compare`
   190  
   191  .. image:: ../images/pull_request.png
   192     :scale: 50%
   193  
   194  - Select `Create Pull Request`
   195  - You can now enter a title for your pull request and a comment if you desire
   196  - You can now choose one of two options for creating your pull request.
   197    In the green `Create Pull Request` box select the down-arrow to the right of it.
   198  - You can choose the first option to open your pull request as-is.
   199    This will automatically assign the repostiories maintainers as reviewers for
   200    your pull request.
   201  - You can choose the second option to open your pull request as a draft.
   202    Opening your pull request as a draft will not assign any reviewers, but will
   203    still allow your change to run through CI.
   204  
   205  Congratulations, you have now submitted your first pull request to a Hyperledger project.
   206  Your pull request will now run through CI. You can monitor your pull request CI progress
   207  by navigating to the `Checks` tab of the pull request.
   208  
   209  .. warning::
   210  
   211     If you bypass the perscribed pull request process and generate a pull request
   212     from an edit you made using GitHub's editor UI, you must manually add your
   213     signature to the commit message when the commit is generated in the UI.
   214  
   215  Updating a Pull Request
   216  -----------------------
   217  As you receive review comments on your pull request, you may need to make edits
   218  to your commit. In the local branch you are working from, you may add additional
   219  commits and re-push as documented above. This will automatically add the new
   220  commits to the pull request and CI checks will be re-triggered.
   221  
   222  However, it is usually not desired to keep a history of all the changes.
   223  You can keep the pull request and the ultimate merge into the upstream
   224  'clean' by squashing your commits into a single final commit. For example
   225  to squash your two most recent commits into a single commit:
   226  
   227  .. code::
   228  
   229     git rebase -i HEAD~2
   230  
   231  This will open an interactive dialog. Change the second (and any subsequent)
   232  commit action from 'pick' to 'squash' in the dialog. The dialog will then
   233  present all the commit messages, which you can edit into a final message.
   234  
   235  Then do a force push to your remote origin:
   236  
   237  .. code::
   238  
   239     git push origin <feature_branch_name> -f
   240  
   241  This will update your remote origin to be at the final single commit, and
   242  will update the pull request accordingly.
   243  
   244  Alternatively, rather than creating a second commit and squashing, you
   245  could amend the original commit and force push it back to your
   246  remote origin:
   247  
   248  .. code::
   249  
   250     git add -p
   251     git commit --amend
   252     git push origin <feature_branch_name> -f
   253  
   254  Again, the pull request will be updated accordingly and CI checks
   255  will be re-triggered.
   256  
   257  Cleaning Up Local And Remote Feature branches
   258  ---------------------------------------------
   259  
   260  Once you have completed work on a feature branch and the changes have been merged, you
   261  should delete the local and remote feature branches as they are no longer valid to build
   262  on. You can delete them by executing the following commands:
   263  
   264  .. code::
   265  
   266     git branch -d <feature_branch_name>
   267     git push --delete origin <feature_branch_name>
   268  
   269  Syncing Your Fork With the Upstream Repository
   270  ----------------------------------------------
   271  
   272  As your development progresses, invariably new commits will be merged into the original
   273  project from which your forked repo was generated from. To avoid surprise merge conflicts
   274  you should integrate these changes into your local repository. To integrate changes
   275  from the upstream repository, assuming you are working on changes to the master branch,
   276  execute the following commands from the root of your repository:
   277  
   278  .. code::
   279  
   280     git fetch upstream
   281     git rebase upstream/master
   282  
   283  Syncing your fork only updates your local repository, you will need to push these
   284  updates to your forked repository to save them using the following command:
   285  
   286  .. code::
   287  
   288     git push origin master