First create an empty repository on GitHub, and clone it to your computer:
# If you've set up ssh use the ssh url, otherwise the https url
git clone git@github.com/shiftyp/my-awesome-repo.git
When you first create and clone your repository, checkout whatever branch you want to be your main branch (master for most things, gh-pages if a github page is all you'll be doing); touch a README file; and push that main branch up to github.
# if the branch doesn't already exist
# check it out. (master will, but just
# for example purposes.
git checkout -b master
touch README.md
git add .
git push -u origin master
Start your work from your main branch like so:
# to tell waffle.io that you are starting an issue
# the key part of the branch name is `#1-`,
# everything else is up to you.
git checkout -b feature/#1-first-issue
git push -u origin feature/#1-first-issue
That moves the issue into the “In Progress” column. Remember that I made a separate column for "In Review" that contained all PR’s? If you don’t choose to do that then you can tell waffle.io to move your pr’s wherever by starting your PR title with Closes #1. Everything else in the title can be whatever. Then when you merge the PR the issue will be moved into the Done column. A PR is just an alias for doing this in your terminal:
git checkout master
git merge --no-ff feature/#1-first-issue
git push origin master
The difference is that the commits that go into that merge are now codified in a PR page on Github, so people can review the changes and refer to it in the future. Creating a PR is a good time for you and others to review the changes and provide feedback prior to merging them into the master branch. That way you can push additional changes to address any comments that come up in review. The comments on the code will all show up in the PR activity stream. Just remember that after you merge a PR the workflow is:
git checkout master
git pull origin master
git checkout -b feature/#2-the-next-feature
So you’re always starting your features from the latest merged code. The real benefit is when you see some line of code and are like, "why did I do that?" Or you see some issue you thought you solved, and you can go back and say “how did I fix that?" Especially on long term projects. For short term projects though the organization of your work and the motivation that milestones provide is the real bonus.
Annndddd, see tig-keystrokes.gif for some tig goodness (to install tig with brew do brew install tig)
