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