Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Let's talk about Git

Let's talk about Git

Internal company talk about Git and Github. Very introductory.

Bradley Whittington

August 19, 2014

More Decks by Bradley Whittington

Other Decks in Technology


  1. 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
  2. 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>
  3. • 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
  4. 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
  5. 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.
  6. Using git flow • Supported by some development environments •

    Commandline tools ◦ https://github.com/nvie/gitflow git clone --recursive [email protected]: <username>/gitflow.git cd gitflow git branch master origin/master git flow init -d git flow feature start <your feature>
  7. 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.
  8. 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)
  9. 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
  10. • 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
  11. Merge the PR Eventually hit the merge button on the

    Pull request to close issue, and merge code.