|
| 1 | +# Contributing to the runtime |
| 2 | + |
| 3 | +The [Intel® FPGA Runtime for OpenCL™ Software Technology] is developed using |
| 4 | +the [fork and pull model]. Every runtime contributor, whether an external |
| 5 | +contributor or an [Intel organization] member, has their own public fork of the |
| 6 | +runtime repository and submits changes using [pull requests]. Contributions |
| 7 | +must pass continuous integration checks and review by the runtime maintainers |
| 8 | +before they are merged into the `main` branch of the [runtime repository]. |
| 9 | + |
| 10 | +## Setting up your local repository |
| 11 | + |
| 12 | +Using the following steps, you will create a local repository that references |
| 13 | +two [remote repositories], the [runtime repository] and your own forked |
| 14 | +repository. During development, you will use the runtime repository to *pull* |
| 15 | +new changes merged into the `main` branch, and your forked repository to *push* |
| 16 | +your proposed changes. |
| 17 | + |
| 18 | +1. Browse to the [runtime repository] and [create a forked repository] under |
| 19 | + your GitHub username. |
| 20 | + |
| 21 | +2. Clone the [runtime repository]: |
| 22 | + |
| 23 | + ``` |
| 24 | + git clone -o intel https://github.com/intel/fpga-runtime-for-opencl |
| 25 | + ``` |
| 26 | +
|
| 27 | + This sets the remote's name to `intel` to avoid confusion with your forked |
| 28 | + repository. |
| 29 | +
|
| 30 | +3. Change to the cloned repository: |
| 31 | +
|
| 32 | + ``` |
| 33 | + cd fpga-runtime-for-opencl |
| 34 | + ``` |
| 35 | +
|
| 36 | +4. Add your forked repository as an additional remote: |
| 37 | +
|
| 38 | + ``` |
| 39 | + git remote add -f yourusername https://github.com/yourusername/fpga-runtime-for-opencl |
| 40 | + ``` |
| 41 | +
|
| 42 | + This sets the remote's name to your GitHub username to avoid confusion |
| 43 | + with the [runtime repository]. |
| 44 | +
|
| 45 | +5. Set your forked repository as the default remote to push to: |
| 46 | +
|
| 47 | + ``` |
| 48 | + git config remote.pushDefault yourusername |
| 49 | + ``` |
| 50 | +
|
| 51 | +## Preparing a change |
| 52 | +
|
| 53 | +While you may prepare changes in the top-level checkout of your local |
| 54 | +repository and switch between branches when needed, Git provides a handy |
| 55 | +feature to manage multiple working trees in the same repository, the [git |
| 56 | +worktree] command. For each new fix or feature, you will create a separate |
| 57 | +branch that is checked out in a separate worktree. |
| 58 | +
|
| 59 | +1. Ensure that your copy of the remote `main` branch is up-to-date: |
| 60 | +
|
| 61 | + ``` |
| 62 | + git fetch intel |
| 63 | + ``` |
| 64 | +
|
| 65 | +2. Create a new remote branch in your forked repository based on the `main` |
| 66 | + branch. |
| 67 | +
|
| 68 | + ``` |
| 69 | + git push yourusername intel/main:refs/heads/my-feature |
| 70 | + ``` |
| 71 | +
|
| 72 | +3. Create and checkout a new local branch in a new worktree: |
| 73 | +
|
| 74 | + ``` |
| 75 | + git worktree add --track -b my-feature my-feature yourusername/my-feature |
| 76 | + ``` |
| 77 | +
|
| 78 | + With a shell such as `bash` or `zsh`, this command may be shortened to: |
| 79 | +
|
| 80 | + ``` |
| 81 | + git worktree add --track -b {,,yourusername/}my-feature |
| 82 | + ``` |
| 83 | +
|
| 84 | +4. Change to the new worktree: |
| 85 | +
|
| 86 | + ``` |
| 87 | + cd my-feature |
| 88 | + ``` |
| 89 | +
|
| 90 | +5. Apply, build, test, and commit your change, iterating as many times as needed. |
| 91 | +
|
| 92 | + Each commit should represent a self-contained, logical unit of change with |
| 93 | + a clear and concise commit message that describes the context and the |
| 94 | + *reason* for the change. On the other hand, there is usually no need to |
| 95 | + describe *how* the change was implemented, unless this is not immediately |
| 96 | + evident from the contents. If you find that your commit needs a rather |
| 97 | + extensive message, e.g., an itemized list of changes, consider whether it |
| 98 | + could be broken up into multiple commits that would still be functional |
| 99 | + when applied and tested one after another. |
| 100 | +
|
| 101 | +6. Push your new commits to your forked repository: |
| 102 | +
|
| 103 | + ``` |
| 104 | + git push |
| 105 | + ``` |
| 106 | +
|
| 107 | + If you would like to review your commits before pushing, try a dry-run: |
| 108 | +
|
| 109 | + ``` |
| 110 | + git push -n -v |
| 111 | + ``` |
| 112 | +
|
| 113 | + This outputs the range of commits that would be pushed, which you may review with, e.g.: |
| 114 | +
|
| 115 | + ``` |
| 116 | + git log --stat -p aaaaaa...bbbbbb |
| 117 | + ``` |
| 118 | +
|
| 119 | +[Intel organization]: https://github.com/intel |
| 120 | +[Intel® FPGA Runtime for OpenCL™ Software Technology]: https://github.com/intel/fpga-runtime-for-opencl |
| 121 | +[create a forked repository]: https://docs.github.com/en/get-started/quickstart/fork-a-repo#forking-a-repository |
| 122 | +[fork and pull model]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models#fork-and-pull-model |
| 123 | +[git worktree]: https://git-scm.com/docs/git-worktree |
| 124 | +[pull requests]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests |
| 125 | +[remote repositories]: https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes |
| 126 | +[runtime repository]: https://github.com/intel/fpga-runtime-for-opencl |
0 commit comments