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