OpenPunk/yuzu
1
0
Fork 0
mirror of https://github.com/yuzu-emu/yuzu.git synced 2024-11-26 21:20:06 +00:00
Code Issues Projects Releases Wiki Activity

Use formatted lists to make the steps nicer looking.

Mat M 2018-08-26 00:31:05 -04:00
parent 0ccb125b9c
commit 37073f6a71
1 changed files with 56 additions and 48 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

104
Typical-Git-Workflow.md

@ -2,61 +2,69 @@ This is a guide to a typical Git workflow with yuzu. It covers forking from the
It's appreciated if every single commit in a branch on its own compiles on all supported platforms (Windows, Linux, and OS X) and doesn't cause any regressions if the commits after it were left unmerged. We understand that with early development, sometimes it's easier to commit early-and-often, and sometimes you may unintentionally break things (and then later fix them in your branch). If this is part of your workflow, we expect appropriate use of Git rebase to squash broken commits and resolve merge conflicts. If you don't know how Git rebase works, please read [this article](http://git-scm.com/book/en/Git-Branching-Rebasing) before developing for yuzu. It's appreciated if every single commit in a branch on its own compiles on all supported platforms (Windows, Linux, and OS X) and doesn't cause any regressions if the commits after it were left unmerged. We understand that with early development, sometimes it's easier to commit early-and-often, and sometimes you may unintentionally break things (and then later fix them in your branch). If this is part of your workflow, we expect appropriate use of Git rebase to squash broken commits and resolve merge conflicts. If you don't know how Git rebase works, please read [this article](http://git-scm.com/book/en/Git-Branching-Rebasing) before developing for yuzu.
**Terminology** ## Terminology
* `upstream`: Main project repository (https://github.com/yuzu-emu/yuzu) * `upstream`: Main project repository (https://github.com/yuzu-emu/yuzu)
* `origin`: Your GitHub forked project repository (e.g. https://github.com/bunnei/yuzu) * `origin`: Your GitHub forked project repository (e.g. https://github.com/bunnei/yuzu)
**Before you begin** ## Before you begin
* GitHub fork the project
* Clone your GitHub fork locally
* `git clone https://github.com/your-username/yuzu.git`
* Grab the submodules
* `git submodule update --init --recursive`
* Set your `upstream` to the main project repository
* `git remote add upstream https://github.com/yuzu-emu/yuzu.git`
* Set your Git identity configuration
* `git config --global user.name "your-username"`
* `git config --global user.email your-email@example.com`
**Create a new branch** 1. GitHub fork the project
* Create your branch from the latest `upstream/master` (Note: please format-branch-names-like-this) 2. Clone your GitHub fork locally
* `git fetch upstream && git checkout -b new-branch-name upstream/master` * `git clone https://github.com/your-username/yuzu.git`
* Push your new branch to `origin` (required later for a pull request) 3. Grab the submodules
* `git push origin new-branch-name` * `git submodule update --init --recursive`
4. Set your `upstream` to the main project repository
* `git remote add upstream https://github.com/yuzu-emu/yuzu.git`
5. Set your Git identity configuration
* `git config --global user.name "your-username"`
* `git config --global user.email your-email@example.com`
**Scenario A: You did some work in your branch... Then, someone committed something to `upstream/master` that you want!** ## Create a new branch
* Make sure you're on your branch
* `git checkout new-branch-name`
* Rebase `upstream/master` onto it. With the rebase, move all of your changes to the top, and put all of the new master changes immediately after where you branched from. The goal should be that the branch now appears as though you just created it from `upstream/master`, and then committed all of your new stuff.
* `git rebase upstream/master`
**Scenario B: You did some more work in your branch... Then, someone committed something to `upstream/master` that will cause conflicts when trying to get the branch merged back to upstream/master!** 1. Create your branch from the latest `upstream/master` (Note: please format-branch-names-like-this)
* From your branch, rebase `upstream/master` * `git fetch upstream && git checkout -b new-branch-name upstream/master`
* `git checkout new-branch-name` 2. Push your new branch to `origin` (required later for a pull request)
* `git rebase -i upstream/master` * `git push origin new-branch-name`
**Your branch is getting near completion, now you're ready for a pull request!** ## Scenario A: You did some work in your branch... Then, someone committed something to `upstream/master` that you want!
* From your branch, rebase `upstream/master`
* `git checkout new-branch-name` 1. Make sure you're on your branch
* `git rebase -i upstream/master` * `git checkout new-branch-name`
* Update `origin/new-branch-name` 2. Rebase `upstream/master` onto it. With the rebase, move all of your changes to the top, and put all of the new master changes immediately after where you branched from. The goal should be that the branch now appears as though you just created it from `upstream/master`, and then committed all of your new stuff.
* `git push origin new-branch-name --force` * `git rebase upstream/master`
* Create the pull request on GitHub to merge `origin/new-branch-name` into `upstream/master`
## Scenario B: You did some more work in your branch... Then, someone committed something to `upstream/master` that will cause conflicts when trying to get the branch merged back to upstream/master!
1. From your branch, rebase `upstream/master`
* `git checkout new-branch-name`
* `git rebase -i upstream/master`
## Your branch is getting near completion, now you're ready for a pull request!
1. From your branch, rebase `upstream/master`
* `git checkout new-branch-name`
* `git rebase -i upstream/master`
2. Update `origin/new-branch-name`
* `git push origin new-branch-name --force`
3. Create the pull request on GitHub to merge `origin/new-branch-name` into `upstream/master`
## Gracefully receive feedback from the team
**Gracefully receive feedback from the team**
* Address each comment with a commit as needed * Address each comment with a commit as needed
**Once your pull request is ready to be merged...** ## Once your pull request is ready to be merged...
* From your branch, interactive rebase to squash all of the new commits (as a result of the pull request feedback) into the commits that they were addressing
* `git checkout new-branch-name` 1. From your branch, interactive rebase to squash all of the new commits (as a result of the pull request feedback) into the commits that they were addressing
* `git rebase -i upstream/master` * `git checkout new-branch-name`
* Now, you should see a file containing all the commits on this branch. * `git rebase -i upstream/master`
* For all commits that address feedback, replace `pick` with `fixup`. Re order if required (beware, you might get conflicts at this stage! Resolve them carefully, then use `git rebase --continue`) * Now, you should see a file containing all the commits on this branch.
* You can also change commit messages by replacing `pick` with `reword`. * For all commits that address feedback, replace `pick` with `fixup`. Re order if required (beware, you might get conflicts at this stage! Resolve them carefully, then use `git rebase --continue`)
* Then follow the steps as directed by Git (These are not specific to yuzu, so you shouldn't have a problem if you use Git regularly.) * You can also change commit messages by replacing `pick` with `reword`.
* Rebase complete! * Then follow the steps as directed by Git (These are not specific to yuzu, so you shouldn't have a problem if you use Git regularly.)
* Update `origin/new-branch-name` * Rebase complete!
* `git push origin new-branch-name --force` 2. Update `origin/new-branch-name`
* Merge your branch in * `git push origin new-branch-name --force`
* Always merge using the >merge< button in the GitHub pull request 3. Merge your branch in
* If GitHub says the branch cannot be merged automatically, you've likely done something incorrectly (e.g. you did not fully rebase changes from `upstream/master` into your branch). If things don't work for you, don't hesitate to ask us for help @ #yuzu on [freenode](http://webchat.freenode.net/) or @ #yuzu-general on [Discord](https://discordapp.com/invite/u77vRWY). Mastering Git is not as easy as it might sound, but we'll happily help you get started. * Always merge using the >merge< button in the GitHub pull request
* If GitHub says the branch cannot be merged automatically, you've likely done something incorrectly (e.g. you did not fully rebase changes from `upstream/master` into your branch). If things don't work for you, don't hesitate to ask us for help @ #yuzu on [freenode](http://webchat.freenode.net/) or @ #yuzu-general on [Discord](https://discordapp.com/invite/u77vRWY). Mastering Git is not as easy as it might sound, but we'll happily help you get started.