Last Updated: February 25, 2016
·
1.594K
· jryancanty

Best practice: Team Workflow for Github

More and more on Stack Overflow I'm seeing people use some pretty bad practices with Git and Github, especially with all the IDE's that build functionality in. It's important to know how to use Git from the command line because you learn how things are happening step by step.

That being said, here is my team's way of handling our project on GitHub/Git.

We have several branches, but only keep two indefinitely: stable and development. We then create a branch per feature that gets deleted after the feature is merged into development.

Lets say I need to add a new feature onto development called, sexy-blog, I'll do the following:

#Get all refs from the remote repo to my local
git fetch origin 

#Make my working dir reflect stable's source code
git checkout origin/development

#Checkout a local branch for my feature based on stable
git checkout -b sexy-blog

So at this point, I've effectively 'based' my feature branch off stable. Once I make some changes, I need to get my source code up to my remote repo, a fork on GitHub. Lets say we've already named my remote repo my-remote.

#Start tracking all files that aren't ignored
git add -A

#Commit those tracked files to the branch
git commit -m 'Added a sexy blog feature'

#Push the commit to my remote repo
git push my-remote sexy-blog

Now we go to GitHub and make a pull request, comparing with development. Once the pull request is in, it's important to make a comment asking someone else in the team to review and test it. That team member does the following

git fetch origin

At this point your teammate should see a new branch with the PR number appear. You can just checkout that branch and run your unit tests (you should ALWAYS unit test!)

git checkout my_project/pull/345

Once he or she verifies that your code is awesome, they can merge the Pull Request back on GitHub.

You just repeat this process until you are ready to release, then merge development into stable. Now each feature has documentation associated with it, at least one person has verified and tested it, and all your code is based properly.

Stay tuned for my review on how to fix problems with git rebase