Git Workflow - Plateful/plateful-mobile GitHub Wiki

1. Fork the plateful organization repo.
2. Clone the forked repo to local computer:
   git clone https://github.com/<user_name>/plateful-mobile.git
3. Create an upstream remote to Plateful:
   git remote add upstream https://github.com/Plateful/plateful-mobile.git
4. Create a local branch for the current feature:
   git checkout -b <feat>
5. Make commits to your local master branch:
   git commit
6. Pull from upstream master using rebase and resolve conflicts:
   git pull --rebase upstream <feat OR master>
7. Use chrome incognito mode to verify app still works.
8. Push to your fork's feature branch:
   git push origin <feat>
9. Create Pull request to the Plateful dev branch. DO NOT create pull request's to Plateful master branch.
10. Project admins will review pull requests and merge or leave comments for resubmitting.
11. Once a feature or sprint is done and all testing is complete, issue a pull request from dev to master. Master is the production branch and should always be kept in a working state.

Use github’s interface to make a fork of the project repo. Clone your forked repo to your local computer:

git clone https://github.com/<USER_NAME>/plateful-mobile.git

Once complete navigate into the cloned folder and add the project repo as an upstream remote:

cd plateful-mobile
git remote add upstream https://github.com/Plateful/plateful-mobile.git

• The first line of your commit message should be a brief summary of what the commit changes. Aim for about 70 characters max. Remember: This is a summary, not a detailed description of everything that changed.
• If you want to explain the commit in more depth, following the first line should be a blank line and then a more detailed description of the commit. This can be as detailed as you want, so dig into details here and keep the first line short.

Once you are done making changes, you can begin the process of getting your code merged into the main repo. First, use incognito mode to see if the app is still working. Then, rebase upstream changes to the dev branch into yours by running this command from your branch:

git pull --rebase upstream dev

This will start the rebase process. You must commit all of your changes before doing this. If there are no conflicts, this should just roll all of your changes back on top of the changes from upstream, leading to a clean, linear commit history.

If there are conflicting changes, git will notify you and pause rebasing to allow you to sort out the merge conflicts. Check all files that have been modified in both histories and pick the versions you want. Be aware that these changes will show up in your pull request, so try and incorporate upstream changes as much as possible.

Once you are done fixing conflicts for a specific commit, run:

git rebase --continue

This will continue the rebasing process.

If rebasing broke anything, fix it, then repeat the above process until you get here again and nothing is broken and all the tests pass.

Make a clear pull request from your fork and branch to the upstream dev branch, detailing exactly what changes you made and what feature this should add. The clearer your pull request is the faster you can get your changes incorporated into this repo.

At least one other person MUST give your changes a code review, and once they are satisfied they will merge your changes into upstream dev. Alternatively, they may have some requested changes. You should make more commits to your branch to fix these, then follow this process again from rebasing onwards.

Once you get back here, make a comment requesting further review and someone will look at your code again. If they like it, it will get merged, else, just repeat again.

Master is our production branch. It should always have a working copy of the code on it. Only push to this branch after thoroughly testing the dev branch for bugs.

Dev is our development branch. All pull requests should be sent to dev (never to master). When dev has been tested and is in a production-ready state, issue a pull request from dev to master. Once the pull request is merged, master is up to date and deployed with the latest working version of our code.