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.
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.
However, sometimes I still use the command line. Don't want to forget how it works.
Check the status of files
> git status
Add all changed/new files at once.
> git add .
Or add them one at a time or in batches.
> git add app/models
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:
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.
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.
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.
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.
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 .