Git + GitHub

Transcript

2.   SVN is centralized SCM (Source Control Management). Everyone pushes and pulls from the server. Server goes down, everyone is down.   Git is decentralized — everyone’s local copy is a fully-functional copy of the repository. If the main Git host explodes, you can move to another host in minutes, or just work and commit locally.   Branching and merging are advanced (and potentially dangerous) techniques in SVN — in Git they’re simple and easy, part of your everyday process.   HEAD in SVN is simply the latest revision — In Git HEAD is where your working branch is currently located; you can move around dynamically to any point in the history.
4.   git init: Creates a new repository in the current directory.   git add: Stages les you’ve created, modi ed, or deleted to be committed.   git commit: Commits the les you’ve staged with a message.
5.   git remote add: Adds a remote with a given name and URL. Add as many as you need.   git remote (-v): List the remotes we’ve added.   git push/pull (remote) (branch): Push code to and pull from a remote copy of the repo.
6.   git clone repo-url (directory-name): Now that the repo is made and on a public server, share it with your team — they clone their own local copy of your work to- date.
7.   git branch branch-name (branch- from-where): Creates a new branch at the current point, or a point you specify.   git checkout: Switch branches.   git merge another-branch: Merges another branch into the current branch. Use the “no-ff” ag to keep branching history.
8.   With a .gitignore you can specify les for git to… ignore. is is great for cache les, generated code (minconcat, etc.).   Like an .htaccess it works for all children les and directories.   You can specify global ignores for things that you’d never want to version, like DS_STORE and other system les. https://help.github.com/ articles/ignoring- les
9. Based largely on this excellent post by Vincent Driessen: http://nvie.com/posts/a-successful-git-branching-model/
10.   We consider the main branches to be develop and master.   From develop, we can create branches for speci c features, merging them back into develop as we nish.   When tasks are complete, we create a release branch to prepare a candidate build — bug xes and the like would go here. Once QA has approved the release, we merge the release into master and tag it.   Hot xes are branched from master and merged into develop / master on approval.
11.   Let’s walk through a hypothetical project with developers Jane and John, and Tech Lead Frank.
12.   Jane starts by branching develop into feature- foo.
13.   Once she’s nished her feature, she merges the branch into develop with the no-ff option to preserve her branch’s history.
14.   Meanwhile, John has nished his feature. He checks out develop, pulls down Jane’s work, then merges his branch.
15.   The result looks like this — note that using no-ff preserved the history of both feature branches’ commits.
16.   Frank’s cool with those features, so he forks develop into release-v0.2. QA kicks back a few bugs, which are addressed in this branch.
17.   QA clears the release, so Frank merges the release branch into master, then tags it.
18.   Now that v0.2 is released Frank deletes his local branch, and the branch on origin.   Note the syntax for deleting a remote branch: git push origin :branch-name
19.   What the tree looks like after the release:
20.   QA nds a critical bug on production, so Frank creates a hot x branch off of master.
21.   Frank’s x looks good, so he merges it back into develop and master, then tags it as v0.2.1
22.   Here’s the tree re ecting Frank’s hot x:
24.   A solid, sharable front-end UI for repo management.   @user mentions, subscriptions, inter-project references.   Inline code commenting.   Ease of sharing code, commits, and anything else pertaining to your project.   Gives the option to use a central-server model (as seen in the branching walkthrough) or a blessed/lieutenant model to manage code reviews, complex features, etc.
26.   In the admin panel, you can specify which groups have access to your project.
27.   A developer creates a fork of the “blessed” repository, which is their working environment.
28.   Once you push a feature branch to your fork, you can switch to it to compare the changes you’ve made, add comments, or open a pull request.
29.   If I want to open a discussion around a particular piece of my commit, I can comment inline.
30.   Once your feature branch is ready, open a Pull Request by specifying what you’d like to merge. In my case I’d like to merge feature-foo into develop.
31.   Now that I’ve submitted my request, the project lead can code-review my commit before merging it into the blessed repo’s develop branch.
32.   For complex projects labels help organize what needs to be reviewed, what has been reviewed, and what needs more work.   Assignees also make it easy to delegate review responsibilities to other team members, or a dev on another project that has time to help out.
33.   If I need to add more code, I simply push to my fork’s feature branch to add to the pull request.
34.   If all looks good, the project lead can approve the changes and merge the code into develop.
36.   More about GitHub’s markdown syntax: http://github.github.com/github- avored-markdown/   A great talk on “secret” features in GitHub: http://www.youtube.com/watch?v=Foz9yvMkvlA   Getting started articles: https://help.github.com/categories/54/articles
37.   If you’re on a legacy SVN project, you can still use Git with the git-svn module (built in with standard Git installs).   Cloning: git svn clone repo-url   For very large repos, use the –r ag to only grab a set number of revisions: git svn clone -r1600:HEAD repo-url   Locally, you can work with regular Git — add / commit / branch / etc.   To svn ci run git svn dcommit — is will push your local commits up to SVN individually.   To svn up run git svn rebase — is will pull remote changes to your local.   More info: http://git-scm.com/course/svn.html
39.   Free.   Works with SVN, using git-svn.   http:// www.sourcetreeapp.co m/
40.   Needs a license   Also works with SVN via git-svn   http://www.git- tower.com/
41.   Free   Simple UI — optimized for GitHub repos but will work with any remote.   Does not support multiple remotes.   http://mac.github.com http:// windows.github.com
42.   Free   http:// code.google.com/p/ gitextensions/
43.   To get nice logs like the ones earlier in the presentation (using git lg –all, etc.), check out: http://www.jukie.net/bart/blog/pimping-out-git-log   All colors are customizable — here’s a quick way to enable automatic colors: http://faizanshaharyar.com/enabling-colors-in-git-command-line-interface   Autocompletion for branches, and more enhancements: http://en.newinstance.it/2010/05/23/git-autocompletion-and-enhanced-bash- prompt/
44.   Git Project Homepage: http://git-scm.com/   15 Minutes to learn Git — Interactive Tutorial: http://try.github.com/levels/1/challenges/1   Git Cheatsheet: http://byte.kde.org/~zrusin/git/git-cheat-sheet-medium.png   Converting an SVN project to Git: http://john.albin.net/git/convert-subversion-to-git   A great walkthrough on making a self-hosted Git repo: http://kb.mediatemple.net/questions/1594/Using+Git#gs   Con uence Article on GitHub and Project setup: https://con uence.cpbgroup.net/pages/viewpage.action?pageId=6554387