OpenPunk/citra
1
0
Fork 0
mirror of https://github.com/citra-emu/citra.git synced 2024-11-24 13:21:03 +00:00
Code Issues Projects Releases Wiki Activity

Updated Typical Git Workflow (markdown)

bunnei 2014-06-16 11:07:30 -07:00
parent a608e03b2d
commit a642c1e0b3
1 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
Typical-Git-Workflow.md

@ -1,5 +1,7 @@
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 following something along these lines, you'll be less likely to piss people off. 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 following 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 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.
**Terminology** **Terminology**
* `upstream`: Main project repository (https://github.com/citra-emu/citra) * `upstream`: Main project repository (https://github.com/citra-emu/citra)
* `origin`: Your GitHub forked project repository (e.g. https://github.com/bunnei/citra) * `origin`: Your GitHub forked project repository (e.g. https://github.com/bunnei/citra)
@ -10,16 +12,14 @@ This is a guide to a typical Git workflow with Citra. It covers forking from the
* `git clone https://github.com/your-username/citra.git` * `git clone https://github.com/your-username/citra.git`
* Set your `upstream` to the main project repository * 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/citra-emu/citra.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** **Create a new branch**
* Update your local `master` with `upstream/master` (if it's not a brand new GitHub fork)
* `git checkout master`
* `git fetch upstream && git rebase origin/master` or the equivalent `git pull upstream/master --rebase` (Note: `git pull upstream/master` is incorrect and may result in an undesired merge commit)
* Update origin/master with `upstream/master`, if you’d like
* `git push origin/master`
* Create your branch from the latest master (Note: please format-branch-names-like-this) * Create your branch from the latest master (Note: please format-branch-names-like-this)
* `git checkout -b new-branch-name` * `git fetch upstream && git checkout -b new-branch-name upstream/master`
* Push your new branch to origin if you'd like * Push your new branch to origin (required later for a pull request)
* `git push origin new-branch-name` * `git push origin new-branch-name`
**Scenario A: You did some work in your branch... Then, someone committed something to `upstream/master` that you want!** **Scenario A: You did some work in your branch... Then, someone committed something to `upstream/master` that you want!**
@ -30,7 +30,7 @@ This is a guide to a typical Git workflow with Citra. It covers forking from the
* Resolve any conflicts, then update `origin/new-branch-name` if you'd like * Resolve any conflicts, then update `origin/new-branch-name` if you'd like
* `git push origin/new-branch-name --force` * `git push origin/new-branch-name --force`
**Scenario B: You did some more work in your branch... Then, someone committed something to `upstream/master` that conflicts with something you've been working on!** **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!**
* Repeat the previous step (interactive rebase `upstream/master` to your branch) * Repeat the previous step (interactive rebase `upstream/master` to your branch)
* Resolve any conflicts, then update `origin/new-branch-name` if you'd like * Resolve any conflicts, then update `origin/new-branch-name` if you'd like
* `git push origin/new-branch-name --force` * `git push origin/new-branch-name --force`
@ -52,5 +52,5 @@ This is a guide to a typical Git workflow with Citra. It covers forking from the
* Resolve any conflicts, then update origin/new-branch-name * Resolve any conflicts, then update origin/new-branch-name
* `git push origin/new-branch-name --force` * `git push origin/new-branch-name --force`
* Merge your branch in * Merge your branch in
* Always merge to `upstream/master` using GitHub * Always merge using the >merge< button in the GitHub pull request
* If there are conflicts, you're doing it wrong :( Go back and try again. * If GitHub says the branch cannot be merged automatically, you've likely done something incorrectly. If things don't work for you, don't hesitate asking us @ #citra on [freenode](http://webchat.freenode.net/). Mastering Git is not as easy as it might sound, but we'll happily help you get started.