github.com/xuyutom/docker@v1.6.0/docs/sources/project/work-issue.md (about) 1 page_title: Work on your issue 2 page_description: Basic workflow for Docker contributions 3 page_keywords: contribute, pull request, review, workflow, beginner, squash, commit 4 5 6 # Work on your issue 7 8 The work you do for your issue depends on the specific issue you picked. 9 This section gives you a step-by-step workflow. Where appropriate, it provides 10 command examples. 11 12 However, this is a generalized workflow, depending on your issue you may repeat 13 steps or even skip some. How much time the work takes depends on you --- you 14 could spend days or 30 minutes of your time. 15 16 ## How to work on your local branch 17 18 Follow this workflow as you work: 19 20 1. Review the appropriate style guide. 21 22 If you are changing code, review the <a href="../coding-style" 23 target="_blank">coding style guide</a>. Changing documentation? Review the 24 <a href="../doc-style" target="_blank">documentation style guide</a>. 25 26 2. Make changes in your feature branch. 27 28 Your feature branch you created in the last section. Here you use the 29 development container. If you are making a code change, you can mount your 30 source into a development container and iterate that way. For documentation 31 alone, you can work on your local host. 32 33 Review <a href="../set-up-dev-env" target="_blank">if you forgot the details 34 of working with a container</a>. 35 36 37 3. Test your changes as you work. 38 39 If you have followed along with the guide, you know the `make test` target 40 runs the entire test suite and `make docs` builds the documentation. If you 41 forgot the other test targets, see the documentation for <a 42 href="../test-and-docs" target="_blank">testing both code and 43 documentation</a>. 44 45 4. For code changes, add unit tests if appropriate. 46 47 If you add new functionality or change existing functionality, you should 48 add a unit test also. Use the existing test files for inspiration. Aren't 49 sure if you need tests? Skip this step; you can add them later in the 50 process if necessary. 51 52 5. Format your source files correctly. 53 54 <table> 55 <thead> 56 <tr> 57 <th>File type</th> 58 <th>How to format</th> 59 </tr> 60 </thead> 61 <tbody> 62 <tr> 63 <td><code>.go</code></td> 64 <td> 65 <p> 66 Format <code>.go</code> files using the <code>gofmt</code> command. 67 For example, if you edited the `docker.go` file you would format the file 68 like this: 69 </p> 70 <p><code>$ gofmt -s -w file.go</code></p> 71 <p> 72 Most file editors have a plugin to format for you. Check your editor's 73 documentation. 74 </p> 75 </td> 76 </tr> 77 <tr> 78 <td style="white-space: nowrap"><code>.md</code> and non-<code>.go</code> files</td> 79 <td>Wrap lines to 80 characters.</td> 80 </tr> 81 </tbody> 82 </table> 83 84 6. List your changes. 85 86 $ git status 87 On branch 11038-fix-rhel-link 88 Changes not staged for commit: 89 (use "git add <file>..." to update what will be committed) 90 (use "git checkout -- <file>..." to discard changes in working directory) 91 92 modified: docs/sources/installation/mac.md 93 modified: docs/sources/installation/rhel.md 94 95 The `status` command lists what changed in the repository. Make sure you see 96 the changes you expect. 97 98 7. Add your change to Git. 99 100 $ git add docs/sources/installation/mac.md 101 $ git add docs/sources/installation/rhel.md 102 103 104 8. Commit your changes making sure you use the `-s` flag to sign your work. 105 106 $ git commit -s -m "Fixing RHEL link" 107 108 9. Push your change to your repository. 109 110 $ git push origin 111 Username for 'https://github.com': moxiegirl 112 Password for 'https://moxiegirl@github.com': 113 Counting objects: 60, done. 114 Compressing objects: 100% (7/7), done. 115 Writing objects: 100% (7/7), 582 bytes | 0 bytes/s, done. 116 Total 7 (delta 6), reused 0 (delta 0) 117 To https://github.com/moxiegirl/docker.git 118 * [new branch] 11038-fix-rhel-link -> 11038-fix-rhel-link 119 Branch 11038-fix-rhel-link set up to track remote branch 11038-fix-rhel-link from origin. 120 121 The first time you push a change, you must specify the branch. Later, you can just do this: 122 123 git push origin 124 125 ## Review your branch on GitHub 126 127 After you push a new branch, you should verify it on GitHub: 128 129 1. Open your browser to <a href="https://github.com" target="_blank">GitHub</a>. 130 131 2. Go to your Docker fork. 132 133 3. Select your branch from the dropdown. 134 135 ![Find branch](/project/images/locate_branch.png) 136 137 4. Use the "Compare" button to compare the differences between your branch and master. 138 139 Depending how long you've been working on your branch, your branch maybe 140 behind Docker's upstream repository. 141 142 5. Review the commits. 143 144 Make sure your branch only shows the work you've done. 145 146 ## Pull and rebase frequently 147 148 You should pull and rebase frequently as you work. 149 150 1. Return to the terminal on your local machine. 151 152 2. Make sure you are in your branch. 153 154 $ git branch 11038-fix-rhel-link 155 156 3. Fetch all the changes from the `upstream/master` branch. 157 158 $ git fetch upstream/master 159 160 This command says get all the changes from the `master` branch belonging to 161 the `upstream` remote. 162 163 4. Rebase your local master with Docker's `upstream/master` branch. 164 165 $ git rebase -i upstream/master 166 167 This command starts an interactive rebase to merge code from Docker's 168 `upstream/master` branch into your local branch. If you aren't familiar or 169 comfortable with rebase, you can <a 170 href="http://nathanleclaire.com/blog/2014/09/14/dont-be-scared-of-git- 171 rebase" target="_blank">learn more about rebasing</a> on the web. 172 173 5. Rebase opens an editor with a list of commits. 174 175 pick 1a79f55 Tweak some of the other text for grammar 176 pick 53e4983 Fix a link 177 pick 3ce07bb Add a new line about RHEL 178 179 If you run into trouble, `git --rebase abort` removes any changes and gets 180 you back to where you started. 181 182 6. Squash the `pick` keyword with `squash` on all but the first commit. 183 184 pick 1a79f55 Tweak some of the other text for grammar 185 squash 53e4983 Fix a link 186 squash 3ce07bb Add a new line about RHEL 187 188 After closing the file, `git` opens your editor again to edit the commit 189 message. 190 191 7. Edit and save your commit message. 192 193 Make sure you include your signature. 194 195 8. Push any changes to your fork on GitHub. 196 197 $ git push origin 11038-fix-rhel-link 198 199 200 ## Where to go next 201 202 At this point, you should understand how to work on an issue. In the next 203 section, you [learn how to make a pull request](/project/create-pr/).