Github Walkthrough

This was originally sent to Acer from Matt, but thought it had good information so everyone had a better overall understanding of the Github workflow when it comes to self-dev.

I was a pleasure meeting you on Friday, as promised here is the online I would use to manage your changes in Vanilla. I included the main “ideal” path and one example of how to handle a situation where you have to rush code out ahead of a already active release.

Key of terms:

• Development – this is the “development” branch in your Github Repo. This is where all of your new development will start from.
• Staging – this is your “stage” or “ready to ship” repo. Code should only go here that you expect to be able to go to production but you might want to do some light user testing before the actual release.
• Master – for all intents and purposes this is just “Release” do not expect code that goes here to sit for any period of time.

Ideal Workflow

1. Both Erin and Rob work off of feature branches created from Development
2. Name your branch “feature/some-descriptive-name”
3. When you want to test your code merge your feature branch into development for testing.
4. When each developer is done they each independently create pull requests via the Github UI from “feature/some-descriptive-name”  to “Stage”

             i.     Navigate to https://github.com/vanillaforums/acer/pulls click “New Pull Request”

            ii.     Select the target branch first (in this case stage)

            iii.     Select the branch you want to sync to stage (in this case feature/some-descriptive-name”)

            iv.     Click Create Pull Request

1. If there are issues on Stage you fix the issue on your feature branch, test it on dev, and then merge your feature branch back to Stage as described in step 1.c.
2. The code is reviewed by my staff and I
3. The feature is reviewed by Brad
4. Create a pull request from Stage to Master
5. Navigate to https://github.com/vanillaforums/acer/pulls click “New Pull Request”
6. Select the target branch first (in this case Master)
7. Select the source branch (in this case Stage)
8. Click Create Pull Request
9. Email Support at Vanilla Forums to let them know you have a ticket for review.
10. We will just skip the review, merge and promote the code.

What happens in I have code on stage that I don’t want released yet but I need to get a hotfix out?

1. Create a hotfix branch from development called “hotfix/some-descriptive-name”
2. Merge it back to development for testing
3. Create a PR to Stage from your hotfix branch via the UI
4. Navigate to https://github.com/vanillaforums/acer/pulls click “New Pull Request”
5. Select the target branch first (in this case stage)
6. Select the branch you want to sync to stage (in this case “hotfix/some-descriptive-name”)
7. Click Create Pull Request
8. The code is reviewed by my staff and I
9. The fix is reviewed by Brad ( I assume)
10. Create a pull request from “hotfix/some-descriptive-name” to Master
11. Email Support at Vanilla Forums to let them know you have a ticket for review.
12. We cannot skip this review, but we will merge it once its done.
13. Everything will be back in sync again once the code on stage is ready to go, at that point since your hotfix is already on stage and master you are fine to create the PR “Stage” -> “Master” and everything is back in sync.

What do I do if I am starting to get Master diverged from Dev

• This will happen over time if you create feature branches, merge them to development, but then ultimately abandon them before pushing to stage and master.
• These are normally innocuous differences that won’t impede your development
• If you do start to notice difference between how Stage and Development behaves, it could be due to differences in code caused by these abandoned feature branches
• At this point you can create a new development branch by renaming the current one to something like Dev-old and creating a new development branch off of master. If you need help with this step at any time, do not hesitate to ask us for assistance.