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 re-basing 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.”
We had a rebranding branch (changing the whole UI), then had to fix some things in master. We had moved folders and other changes in the rebranding branch, so the
git rebase master gave us the same merge conflicts over and over. At the end we still didn’t have it correct.
git merge master let us resolve the conflicts once, commit that change and move on.
I have an active PR and I want to start work based on the PR branch. What’s the best way to do that? In the past I’ve branched off the PR branch, but then when the PR completes it seems like there are a lot of conflicts when re-basing from master
Scott to the rescue!
“That’s where the –onto helps out”
git rebase --onto master pr-branch pr-and-more
“It figures out the set of commits that happen between pr-branch and pr-and-more, and then replays those onto master”
“Running just git rebase pr-and-more master will have git find where
pr-and-more diverged from
master (which means it grabs everything from your
pr-branch), and replay that whole set of commits onto latest master.”
I suggest doing
git branch myBackup so you can cherry pick if something gets lost
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.
Please consider using Brave and adding me to your payment ledger. Then you won't have to see ads!