Talk from Kansas City Developer Conference 2017
As a long time Windows user and .NET developer, I’ve challenged myself to level-up my skills using Git and GitHub. As an industry, I feel we provide great content for beginners and for experts, but how do we target content for people in the intermediate category? To answer this question, I'm going to blog every. single. day. in 2017 about something new I’ve learned about using Git and GitHub. I’m hoping that showing my day by day progression can help others who are in similar situations, i.e. trying to reskill after years of industry experience.
I've been calling this guide "a penultimate guide" because I don't know what I don't know yet. I don't know which tips will be the best ones for an ultimate guide to Git(Hub). However, by the time KCDC rolls around, I will be more than half way through the Git(Hub) Tip of the Day series. This means I'll be half-way to an ultimate guide for intermediates leveling-up their skills to more advanced topics. This talk will cover the best of the best tips for this half-way point.
So, um, about that blog every. single. day. idea...
I made it until May 8th or 35% of my goal. I left GitHub (the company) in early May for a true summer vacation. Having said that, I still found the challenge of writing all this content very rewarding. Forcing myself to blog about what I did not know forced me to learn or ask for help.
If I could go back in time, this is the readme file I'd give myself. It contains the major lightbulb moments where Git(Hub) concepts click. Hopefully you'll (or somebody you know) will find it useful.
P.S. This is a git pun-free zone.
P.P.S. If you are just getting started, jump to the new machine setup section.
- GitHub offers an excellent cheat sheet. Print it out!
- Setup your practice area using bash commands
- GitHub Services offers On Demand Training - shows how to use a bash script to quickly create a test repo
- Make sure to
git initfirst! - See Tip 086 for walkthrough
- ohshitgit.com I've committed on master
- Git Visualization Tool
- A couple of GitHubbers created a Git Visualization Tool
- This was my NEO WHOA moment - git branches are just pointers.
- Now to visualize what
git reset HEAD~ --hardactually did - See Tip 082 for walkthrough
- git reflog (cmd line vs visualization tool)
- Go back and demo in cmd line - OH NO MY FILES ARE GONE I HATE GIT IT IS THE WORST WHY DIDN'T I SAY IN AREOSPACE ENGINEERING WHY DID I MAKE SO MANY BAD CHOICES IN LIFE
- Remember your training - go back to the visualization tool. notice the commits are still there, but with a dashed line.
- See Tip 87 for walkthrough
- Demo reset in visualization tool, then git log. Notice we're all back to where we were before - remember these git branches are just pointers.
- Revert vs reset (demo in visualization tool)
- Revert - this doesn't change history. It creates a new commit.
- Reset - let's just pretend everything after this point never happened
- And git reflog still shows the truth for both commands
- See Tip 084 for Revert walkthrough in command line / visualization tool
- See Tip 085 for Revert in Visual Studio
- See Tip 087 for Reset walkthrough
- Merging branches in visualization tool
- I always speak in full sentences. "I want to merge into "
- visualization tool can't do a --no-ff (no fast forwards)
- See Tip 088 for walkthrough
- You can do an Undo in the visualization tool
- if you're following along at home, type
undoin tool. you'll go back to the point before the branch merge
- if you're following along at home, type
- Rebase
- "I want to rebase onto "
- Note how rebase is a destructive action - the commit ids are different
- Not done yet! After rebase, have to move master up (same as merging branches)
- Git checkout master; git merge feature
- See Tip 111 for cmd line walkthrough
- See Tip 114 for Visual Studio walkthrough
- Cherry-pick in visualization tool
- Switch to cherry-pick
- git cherry-pick bugfix1
- Detatched Head
- Do a
git checkout <some commit id>and freak out that you're in a detatched head state - Do a
git checkout masterto calm back down and stay in your current profession - One thing about git that drives me crazy is when you checkout the commit id that master is pointing to, but yet are still in a detatched head state. After seeing this demo'ed in the visualization tool, I felt for hte first time I had a fighting chance using git.
- Do a
- Limitations of the tool
- No working directory, so no way to do interactive rebase
- no reset
--hardor--soft
- More GitHub Tutorials
- GitHub Services On Demand Git Out Of Trouble
- Note: This tutorial offers "I've pushed" and "I've didn't push" guidance which is awesome!
- How to see if my email address is in a commit that's already on GitHub?
- Go to the commit
- add
.patchto the end of the URL - See Tip 051 for walkthrough
- GitHub Keyboard Shortcuts
- Press
?from on the page - On Code page
- press 't' to start type-ahead search
- Permalink 'y' - for a permalink to the blob (if you link to master, and file is updated, it'll be out of context)
- Issues
- '/' to start searching
- 'ctrl+shift+p' - toggle preview, but for Issues only
- See Tip 013 for shortcut walkthrough
- See Tip 052 for permalink walkthroug
- Press
- Protect your email address
- Check the option to block pushes containing your private email address
- Pull Request UX - what absolutely confused me originally
- When you create a PR going through the edit a doc workflow, the branch is already created
- You don't have to create this Pull Request immediately. You can "cancel out"
- PRs are the start of a conversation
- Just creating this PR doesn't mean I've submitted my homework
- You can still go back to the branch and make updates and see it updated in the PR
- Inline comments or start review
- BTW even if you are the only one working in the repo and want to merge branches via the UI, you still need to create a PR. PRs are the only way to get to merge button.
- Can also do simple merge conflicts from the website now
- How to add License / Readme
- It is part of the codebase - not metadata - so license/readme follows the code around
- Repo != Visual Studio solution
- If you type in License you'll get a prompt
- See Tip 048 for adding license walkthrough
- Gists - code samples
- Pages
- Can have a pages site for a repo, e.g. https://saraford.github.io/TheoryC
- You might have seem sites like https://saraford.github.io/ which maps back to https://github.com/saraford/saraford.github.io
- Jekyll - for static pages only
- There's an API for pages
- https://developer.github.com/v3/repos/pages/#request-a-page-build
- I thought it might be fun to do the ToD blog as a Pages site, but remember Jekyll is only static content
- Blame
- TBH I initially didn't want to push my code up on github when I saw "Blame" - I didn't want people to make fun of my code by blaming it. True story
- Shows the commit when this line or block of code was changed
- Blame is called Annotate in Visual Studio
- See Tip 059 for walkthrough
- Desktop
- Do it for 2FA setup
- It also changes the defaults from vi to notepad in some cases to give you a fighting chance
- See Tip 038 for walkthrough
- Git Shell
- wished I had known this when I originally signed up for 2FA
- Tip 038 for walkthrough
- My ToD really turned into a VS Team Explorer blog
- Staging
- same as git add, but within VS
- See Tip 068 for walkthrough
- Status bar for push, commit, view history, switch branches, etc.
- The GitHub Extension for VS is not the Team Explorer
- There's git and then there's Team Explorer and then there's the GitHub extension
- GitHub Extension for Visual Studio
- Looks like it is safe now to have an existing github repo and push it to a newly created GitHub repo without having to worry about different histories when pushing.
- "Maintainer workflow" - ability to review and modify PRs from within Visual Studio
- See Tip 066 for walkthrough
- Desktop / Git Shell
- Configure email / setup as private
- Configure external diff and merge tool
- Verify core editor (anything but vi)