github.com/yacovm/fabric@v2.0.0-alpha.0.20191128145320-c5d4087dc723+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 should contain meaningingful information as to why this work was completed,
   144    as well as the Jira number in the commit header:
   145  
   146  .. code::
   147  
   148     git commit -s
   149  
   150  .. note::
   151  
   152     Hyperledger requires that commits be signed by the commiter.
   153     When issuing the `commit` command, specify the `-s` flag to
   154     automatically add your signature to your commit.
   155  
   156  - You can now push your local changes to your forked repository
   157  
   158  .. code::
   159  
   160     git push origin <feature_branch_name>
   161  
   162  .. note::
   163  
   164     If you want to integrate upstream changes from the original repository
   165     before pushing your changes see the section at the bottom of this page titled,
   166     `Syncing Your Fork With the Upstream Repository`_.
   167  
   168  You have now successfully pushed your local changes to your forked repository. To
   169  integrate these changes you must now go through the pull request process.
   170  
   171  Opening a Pull Request in GitHub
   172  --------------------------------
   173  
   174  Now that you've created and pushed changes to a feature branch in your forked
   175  repository, you can now open a pull request against the original Hyperledger
   176  repository from which you created your fork and begin the code review process.
   177  
   178  - To begin, navigate to `https://github.com/hyperledger/<original_repository>` in your browser
   179  - Select the `Pull Requests` tab at the top of the page
   180  - In the top right corner of the Pull Requests page, select `New Pull Request`
   181  - On the Compare Changes page, select `compare across forks` at the top of the page
   182  - Select the Hyperledger repo from which you created the fork as the `base repository`
   183    and the branch you want to merge into as the `base`
   184  - Select your fork as the `head repository` and your feature branch as the `compare`
   185  
   186  .. image:: ../images/pull_request.png
   187     :scale: 50%
   188  
   189  - Select `Create Pull Request`
   190  - You can now enter a title for your pull request and a comment if you desire
   191  - You can now choose one of two options for creating your pull request.
   192    In the green `Create Pull Request` box select the down-arrow to the right of it.
   193  - You can choose the first option to open your pull request as-is.
   194    This will automatically assign the repostiories maintainers as reviewers for
   195    your pull request.
   196  - You can choose the second option to open your pull request as a draft.
   197    Opening your pull request as a draft will not assign any reviewers, but will
   198    still allow your change to run through CI.
   199  
   200  Congratulations, you have now submitted your first pull request to a Hyperledger project.
   201  Your pull request will now run through CI. You can monitor your pull request CI progress
   202  by navigating to the `Checks` tab of the pull request.
   203  
   204  .. warning::
   205  
   206     If you bypass the perscribed pull request process and generate a pull request
   207     from an edit you made using GitHub's editor UI, you must manually add your
   208     signature to the commit message when the commit is generated in the UI.
   209  
   210  Updating a Pull Request
   211  -----------------------
   212  As you receive review comments on your pull request, you may need to make edits
   213  to your commit. In the local branch you are working from, you may add additional
   214  commits and re-push as documented above. This will automatically add the new
   215  commits to the pull request and CI checks will be re-triggered.
   216  
   217  However, it is usually not desired to keep a history of all the changes.
   218  You can keep the pull request and the ultimate merge into the upstream
   219  'clean' by squashing your commits into a single final commit. For example
   220  to squash your two most recent commits into a single commit:
   221  
   222  .. code::
   223  
   224     git rebase -i HEAD~2
   225  
   226  This will open an interactive dialog. Change the second (and any subsequent)
   227  commit action from 'pick' to 'squash' in the dialog. The dialog will then
   228  present all the commit messages, which you can edit into a final message.
   229  
   230  Then do a force push to your remote origin:
   231  
   232  .. code::
   233  
   234     git push origin <feature_branch_name> -f
   235  
   236  This will update your remote origin to be at the final single commit, and
   237  will update the pull request accordingly.
   238  
   239  Alternatively, rather than creating a second commit and squashing, you
   240  could amend the original commit and force push it back to your
   241  remote origin:
   242  
   243  .. code::
   244  
   245     git add -p
   246     git commit --amend
   247     git push origin <feature_branch_name> -f
   248  
   249  Again, the pull request will be updated accordingly and CI checks
   250  will be re-triggered.
   251  
   252  Cleaning Up Local And Remote Feature branches
   253  ---------------------------------------------
   254  
   255  Once you have completed work on a feature branch and the changes have been merged, you
   256  should delete the local and remote feature branches as they are no longer valid to build
   257  on. You can delete them by executing the following commands:
   258  
   259  .. code::
   260  
   261     git branch -d <feature_branch_name>
   262     git push --delete origin <feature_branch_name>
   263  
   264  Syncing Your Fork With the Upstream Repository
   265  ----------------------------------------------
   266  
   267  As your development progresses, invariably new commits will be merged into the original
   268  project from which your forked repo was generated from. To avoid surprise merge conflicts
   269  you should integrate these changes into your local repository. To integrate changes
   270  from the upstream repository, assuming you are working on changes to the master branch,
   271  execute the following commands from the root of your repository:
   272  
   273  .. code::
   274  
   275     git fetch upstream
   276     git rebase upstream/master
   277  
   278  Syncing your fork only updates your local repository, you will need to push these
   279  updates to your forked repository to save them using the following command:
   280  
   281  .. code::
   282  
   283     git push origin master