Let's talk about Git

Internal company talk about Git and Github. Very introductory.

Transcript

1. Let’s talk about Git
2. A little history Git is a DVCS, built by Linus Torvalds to manage high volumes of merges into the Kernel It emerged after squabbles with the maker of the commercial BitKeeper VCS. Git is: Fast, simple, non-linear, distributed
3. DVCS? Distributed version control system.
4. Git cheatsheet • git init ◦ New self-hosted repo • git add ◦ Stage files for commit • git commit ◦ Commit to local ◦ -m “Commit Message” ◦ -a <add and commit all unstaged> ◦ -p <let you pick what to commit of unstaged>
5. • git branch <branchname> • git checkout <branchname|hash|HEAD|etc> • git pull ◦ shorthand for: git pull origin ◦ (actually git-fetch, then git-merge) • git push ◦ push changes to origin ◦ could be git push <target> <branch> • git log ◦ log of commits on current branch
6. Git is unixy • Git is composed of lots of smaller executables ◦ git commit == git-commit ◦ man git-commit • This means git is extensible sh-3.2# echo "#\!/bin/bash\necho 'hello polly'" > /usr/sbin/git-echo sh-3.2# chmod +x /usr/sbin/git-echo sh-3.2# git echo hello polly
7. Moar Git git-rebase git-cherry-pick git-bisect git-archive git-clone git-diff ….
8. Git flow Best branching strategy. ever. • Develop is ±messy. • Branch features off Develop. (e.g. feature/new_boondoggle) • Merge up to Develop. • Stabilize Develop. • Merge to master, tag, release. • Branch hotfixes off master Master is always a clean, dependable build.
9. Using git flow • Supported by some development environments • Commandline tools ◦ https://github.com/nvie/gitflow git clone --recursive git@github.com: <username>/gitflow.git cd gitflow git branch master origin/master git flow init -d git flow feature start <your feature>
10. Pull requests? Encapsulates a set of changes you want to merge between two repositories or branches. Groups together a set of logical changes. Nice UI in Github to interact and review.
11. Github pull requests (Open source) “Hey, please can someone look over my code” ◦ Only maintainers have write access to repo ◦ Anyone can clone/fork a repo ◦ Make changes to your fork ◦ Open a pull request against maintainer’s repo ◦ Reviewed and ingested by repo owner(s)
12. Github pull requests (private edition) “Hey, please can someone look over my code” • Branch Develop -> feature/my_feature • code code code commit code code commit code commit push code code commit push code commit push • Instead of merging locally, create pull request from feature/my_feature -> Develop
13. • Write a nice descriptive PR • PR -> Slack channel • Open for comments ◦ Comments can be on PR generally ◦ Comments can be on specific changes ◦ Comments can just be :+1: ◦ Comments can enforce culture ▪ “This doesn’t have tests” ▪ “This is some fine ass code” ▪ “Please rework this to use new interfaces” • Additional commits to branch are appended
14. Merge the PR Eventually hit the merge button on the Pull request to close issue, and merge code.
15. Nerdy stuff Questions, demos, blah blah