I've used git for many years to manage my source code. This is the workflow that's been working for me lately.

Start with the master branch

> git checkout master

Pull the latest version

> git pull

Start a new feature branch

> git checkout -b new-feature

Do some work

This is usually the tricky part... 😆

Stage and commit the work

Try to commit often, to keep from having too many file changes pending at once. At some point (maybe sooner than you think), it's too much to keep track of. It may also help to move files into the staging area while working, to keep track of items that are "done", or changes you're confident in.

Text editor

I've been doing this through the UI in Atom or VSCode lately. Both have a pretty similar UI for git. I like having the list of changed files easily accessible alongside my code. And the UI allows me to write my commit message first, which keeps me focused on the actual change I'm intending to make.

Terminal

However, sometimes I still use the command line. Don't want to forget how it works.

Check the status of files

> git status

Stage files

Add all changed/new files at once.

> git add .

Or add them one at a time or in batches.

> git add app/models

Commit changes

Edit the commit message separately or using a multi-line message.

> git commit

This will open your terminal's text editor. Type a message and close + save to commit.

Or you can do it all in one line.

> git commit -m 'Did some work'

Push to Github

The first time you push, copy the message it gives you and push again to create the branch on Github.

> git push
fatal: The current branch new-feature has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin new-feature

> git push --set-upstream origin new-feature

After that, the push works as you'd expect.

> git push

Open pull request

The first time you push, git provides a handy link to create a pull request, so click it or paste it into your browser:

https://github.com/ryanstrickler/ryanstrickler.com/pull/new/new-feature

Otherwise, open Github and create your pull request through the UI.

Either way, you end up on the new pull request screen. Make sure your pull request name makes sense, add a description if there's any need to clarify the purpose of the pull request, then click the Create pull request button.

Code review

Usually, someone on my team looks over my pull request, asks questions, and makes suggestions. I make any necessary updates and we go back and forth as necessary until the work is ready to ship.

Merge

After code review, merge using the Squash and merge option. This takes multiple commits and combines them into one new commit, which comes in handy when deploying or looking at git history later.

Remove the automatic description that Github creates. The point of squashing is to keep the history easy to read, and keeping the list of individual commits doesn't usually help much. If the changes are complex, add a description to the pull request.

Delete Github branch

After merging, delete the branch using the Delete branch button. No need to hang onto it now that it's been merged.

Reset your local environment

Switch back to the terminal and change to the master branch.

> git checkout master

Pull the updated master branch.

> git pull

List all branches to show your local feature branch and the corresponding remote branch.

> git branch -a
* master
  new-feature
  remotes/origin/master
  remotes/origin/new-feature

Delete the local branch

> git branch -d new-feature
warning: deleting branch 'new-feature' that has been merged to
         'refs/remotes/origin/new-feature', but not yet merged to HEAD.
Deleted branch new-feature (was e5c03f7).

You'll see a warning because you used the Squash and merge option, but as long as you've already merged your branch on Github, it's fine.

Delete the remote branch

> git remote prune origin
Pruning origin
URL: https://github.com/ryanstrickler/ryanstrickler.com.git
 * [pruned] origin/new-feature

If you want to be extra careful, you can check what's about to be pruned first.

git remote prune origin --dry-run 
Pruning origin
URL: https://github.com/ryanstrickler/ryanstrickler.com.git
 * [would prune] origin/new-feature

I can never remember these commands, so I put them into TextExpander snippets so I don't have to remember them.

Done 🎉

Now you're back on the master branch. Everything is clean and tidy both on your local repo and your remote (Github) repo. Rinse and repeat for your next feature.

Extra credit

If you're cleaning up a bunch of branches at once, perhaps because you've been reviewing pull requests from your teammates, then check out this method for cleaning up a bunch of branches at once .