Git workflow

Basic git workflow

Keep in mind: never commit on master, always branch first

Cloning the repo

1. Setup SSH keys with your machine and github. Their docs explain better than I can.
2. Navigate to your desired directory
3. $ git clone [email protected]:ngmiller/docker-manager.git
4. You should now have a docker-manager directory!

Getting updates

Typically, you will always want to update your local branch with any changes that have been made to master.

1. stash any uncommitted changes you may have in your working directory. (see "Stashing" below)
2. $ git checkout master
3. $ git fetch origin
4. $ git pull origin master
5. Done!

Note: If want to do some CI ("continuous integration") with a longer running feature branch you are working on, you may merge your fresh pulled master into said branch. To do so, just checkout the feature branch then run:

$ git merge master

You'll be prompted by whichever text editor you've told git to use by default (see $ git man config) which will have some default merge commit message already filled in. Something like "Merge 'master' into feature-branch" - That is fine, no need to change. Saving from your editor will continue with the commit.

The above isn't absolutely necessary after pulling in a fresh master, but it can reduce headaches. In general, the merge conflict will show up in the final PR (pull request) on github anyway, so we'll see it.

Branching

Simple as, $ git checkout -b new-branch-name Note, you do not need the -b when just switching branches. $ git branch will show you all your existing branches with the active highlighted by an asterisk.

Remember, the checkout is always relative to the branch you are on, not master. So, in theory, you could branch off a feature branch, let the originating branch get merged into master, then open a pull request against master with the other branch, and only those changes will show up. Remember, everything is just a diff with respect to some commit - thinking in those terms helps conceptualize what's going on.

Stashing

Sometimes, you don't want to commit changes you've made just to switch a branch. Any uncommitted changes can be saved with $ git stash save "message". This stashes are literally stored on a stack - so $ git stash pop will apply the most recent stash. Applying a stash won't commit, it will just reapply the uncommitted changes to the working directory. So be sure you're back on the branch you want to commit those changes to!

General workflow

Ok, now that we've got the basics down, we'll go through a simple, but effective, git workflow.

1. Get a fresh copy of master
2. Make a feature branch
3. Hack on that sucker - commit, stash, do a CI, etc
4. Once the work is done, make a PR (pull request) on github.

Making the pull request

1. $ git push origin branch-name (origin is the remote alias for our github repo - this gets set when you clone)
2. Open the github repo, and you'll see a notification about your new branch. Click the button.
3. Add a descriptive title to the PR and some information about what you did, what Trello card it resolves, etc.
4. Github let's you "@" mention other users for code reviews. For example, "@ngmiller". They will get an email notification.
5. If, during code review, suggestions are made that require you to make more changes, all you have to do is commit the changes on your local branch and rerun $ git push origin branch-name. Github will notice this, automatically update the PR to show the new commit history, and mark all the commented diffs as "out-dated". (This feature alone makes github awesome)
6. Once the code review is complete, (i.e. all reviewers have commented "+1" on the PR) merge that puppy and grab another ticket! Feel free to delete the branch locally and on github when prompted. If later, more work needs to be done, a new ticket/branch should be made.