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
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.
get latest =
check in =
git add -A (stage),
git commit -m "commit message" (repeat),
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 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? http://stackoverflow.com/questions/804115/when-do-you-use-git-rebase-instead-of-git-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.”
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)”.
XKCD is relevant here: https://imgs.xkcd.com/comics/git.png
This was originaly posted on my GeeksWithBlogs.net/aligned blog.