freeCodeCampGuam / freecodecampguam.github.io

The website for Free Code Camp Guam
https://freecodecampguam.github.io/freecodecampguam.github.io/
0 stars 4 forks source link

Project Workflow #16

Open Chovin opened 8 years ago

Chovin commented 8 years ago

Contribution Workflow

I'd like to start a discussion about the workflow we will be using for this project. We will most likely be using Git and Github for our project. We should set some guidelines so that things can go as smoothly, efficiently, and pleasantly as Git will allow... >.> Gittttt.

Here is an Interactive resource to help learn Git. I would recommend finding a git GUI you like and using it. If you have any resources or questions on how to use git/github, please post them below.

Proposed Workflow

I believe most open source projects using git are using a workflow similar to this. I believe it is called gitflow. You may want to skim the linked article and get semi-familiar with it if you plan on contributing to more open source projects.

Due to our small, busy, and git-green team of friends and volunteers, I think we may be better off using a workflow that focuses mainly on Github Flow, a simple and efficiency-centered workflow.

Here are a few more resources on Github Flow:

master branch is deployable/deployed, so try not to push to master

If you push something to master that is not tested or breaks the build, you break the social contract of the development team and you normally feel pretty bad about it.

Flow:

  1. Branch - when you want to work on anything, make a branch with a descriptive name and do your work on that.
    • Typically only off of master, but for our workflows where a large feature may take over a week, feel free to branch off of a branch and PR back into it.
  2. Commit/Push often - This keeps everyone in the loop and is a backup of your work.
    • Use descriptive commit messages so we know what you are doing/trying to do.
    • If you are doing multiple things in a commit that aren't logically connected, it'd be nice if you git add/git commited them separately to make the branch history easier to follow.
  3. Open Pull Requests(PRs) any time the development process.
    • Not only when you would like to merge the code; start one if you would also like to start a conversation/code review/request for help or input.
  4. Merge only after a PR review.
    • Obvious communication and code quality plus
    • 👍 <-- general sign that you have reviewed and/or tested the code and approve of the merge
Chovin commented 8 years ago

http://ben.balter.com/2014/11/06/rules-of-communicating-at-github/ https://zachholman.com/posts/github-communication/ thoughts?