I shared some information at a Lunch and Learn along with a demo and now I’m sharing it with you.
“Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.” ~ https://git-scm.com/
Watch Scott Hanselman’s Computer Stuff They Didn’t Teach You #4 - Git 101 Basics . 33 minutes, He talks about what Git is and shows git in the command line and using VS Code.
“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
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
(deal with merging, use git rebase –continue)
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.”
git rebase --onto master pr-branch is also useful. It seems to skip having to merge every commit.
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 originally posted on my GeeksWithBlogs.net/aligned blog.
Please consider using Brave and adding me to your BAT payment ledger. Then you won't have to see ads! (when I get to $100 in Google Ads for a payout, I pledge to turn off ads)
Also check out my Resources Page for referrals that would help me.