Some Git Help

November 8, 2016    Development Git

Some Git Help

I shared some information at a Lunch and Learn along with a demo and now I’m sharing it with you.

“branching as a tool vs branching as a strategy” ~ Scott a branch is a playground

new task = new branch, use Pull Requests to get the code into master

  • or allow direct check-in to master (for 1 or 2 person teams?)

checkout a branch with git checkout myBranch

create and checkout the branch with git checkout -b myNewBranch

A taskNumber in comment will link up to a TFS task.

Command Line

get latest = git pull

check in = git add -A (stage), git commit -m "commit message" (repeat), git push

git checkout is switching the branch

to automatically prune branches that are no longer in remote on fetch use:

git config remote.origin.prune true from StackOverflow question

your force push will only complete if the upstream branch has not been updated by someone else git push --force-with-lease


I use this approach with rebasing when I am working on a branch on my own and need to get the latest from master into my branch. This replay’s your commits on top of the master branch. Another way to say it, is that git pretends your changes were made after the master’s latest changes.

You may have to merge, but the more often you update your branch, the less painful the merges.

git checkout master

git pull

git checkout myBranch

git rebase master

git push --force // VS doesn’t do this

git ..master karma.conf.js (compare your branched code against master)

rebase or merge? I prefer rebase when I’m the only one working on the branch.

Here’s a good walk-through of merging vs rebasing with graphics. “Once you understand what rebasing is, the most important thing to learn is when not to do it. The golden rule of git rebase is to never use it on public branches.”

Use Pull Requests

I recommend turning off permissions to check into master, expect for a select few how, in a rare scenario, may need to fix up that branch.

One possible work flow is to only have code merge into master through Pull Requests.

Run you “gated” builds before allowing the PR to be completed.

Setup approval policies where one or more need to approve the PR before it can be completed and merged into master.

Pull Requests with code reviews helps keep code quality high and continual learning and sharing of information. Scott Nonnenberg has some tips on doing a good pull request review.

I don’t know about the exact numbers, but Eric Elliot has a good insight “Code review, collaboration, and knowledge sharing (each hour of code review saves 33 hours of maintenance)”.

VSTS/TFS has some nice tools for Pull Requests.


Having Problems?

Git fix workflow from

XKCD is relevant here:

XKCD git

This was originaly posted on my blog.

comments powered by Disqus