franklinblanco/yuzu
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Updated Typical Git Workflow (markdown)

Tobias 2018-08-25 13:23:23 +02:00
parent 390c5fa85c
commit 11d9c79977
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
Typical-Git-Workflow.md

@ -1,19 +1,19 @@
This is a guide to a typical Git workflow with Citra. It covers forking from the main repository, creating a branch, keeping your branch up to date with the main repository, resolving conflicts, and merging back into the main repository. It's not meant to be a hard-and-fast set of rules. However, if you follow something along these lines, you'll be less likely to piss people off.
This is a guide to a typical Git workflow with yuzu. It covers forking from the main repository, creating a branch, keeping your branch up to date with the main repository, resolving conflicts, and merging back into the main repository. It's not meant to be a hard-and-fast set of rules. However, if you follow something along these lines, you'll be less likely to piss people off.
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 Citra.
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**
* `upstream`: Main project repository (https://github.com/citra-emu/citra)
* `origin`: Your GitHub forked project repository (e.g. https://github.com/bunnei/citra)
* `upstream`: Main project repository (https://github.com/yuzu-emu/yuzu)
* `origin`: Your GitHub forked project repository (e.g. https://github.com/bunnei/yuzu)
**Before you begin**
* GitHub fork the project
* Clone your GitHub fork locally
* `git clone https://github.com/your-username/citra.git`
* `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/citra-emu/citra.git`
* `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`
@ -53,10 +53,10 @@ It's appreciated if every single commit in a branch on its own compiles on all s
* Now, you should see a file containing all the commits on this branch.
* 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`)
* You can also change commit messages by replacing `pick` with `reword`.
* Then follow the steps as directed by Git (These are not specific to Citra, so you shouldn't have a problem if you use Git regularly.)
* 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.)
* Rebase complete!
* Update `origin/new-branch-name`
* `git push origin new-branch-name --force`
* Merge your branch in
* 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 @ #citra on [freenode](http://webchat.freenode.net/) or @ #citra-general on [Discord](https://citra-emu.org/discord/). Mastering Git is not as easy as it might sound, but we'll happily help you get started.
* 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://yuzu-emu.org/discord/). Mastering Git is not as easy as it might sound, but we'll happily help you get started.