• Using Git
• HOW GITHUB WORKS

GitHub info for newbies

https://help.github.com
http://cworth.org/hgbook-git/tour
http://stackoverflow.com/questions/7076164/terminology-used-by-git
http://pcottle.github.io/learnGitBranching
http://think-like-a-git.net

After creating new repository through the Web browser at GitHub, do the following at the command prompt on local machine for the new repo:

mkdir new repo directory.
cd into new directory.

Then ...

Create a new repository on the command line

touch README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin git@github.com:username/DateTimeFormatter.git
git push -u origin master

Then ...

You can add files using:
- git add
- git add README
- git add <folder>/*
- git add *

To commit files, use:
- git commit -m "<Message>"

Finally, to push files:
- git push -u origin master

other commands:
- git status
- git pull origin master (to ensure you have absorbed any upstream changes)
- git fetch (to fetch changes)
- get merge (to merge changes)
- get pull (combination of fetch and merge)

remove file
http://stackoverflow.com/questions/2047465/how-can-i-delete-a-file-from-git-repo
git rm file1.txt
git commit -m "remove file1.txt"

http://status.github.com

---

• https://git.wiki.kernel.org/index.php/Main_Page
• Sample Perl and MySQL project
  • https://github.com/cosimo/TicketServer
• https://speakerdeck.com/kiyohara/githubs-hub
• http://sixrevisions.com/resources/git-tutorials-beginners/
• http://stackoverflow.com/questions/315911/git-for-beginners-the-definitive-practical-guide
• http://wiki.freegeek.org/index.php/Git_for_dummies
• https://github.com/blog/120-new-to-git
• http://windows.github.com

---

==================================

Markdown Format Text

Headers

# This is an <h1> tag
## This is an <h2> tag
###### This is an <h6> tag

Text styles

*This text will be italic*
_This will also be italic_

**This text will be bold**
__This will also be bold__

*You **can** combine them*


Lists

Unordered
* Item 1
* Item 2
  * Item 2a
  * Item 2b

Ordered
1. Item 1
2. Item 2
3. Item 3
   * Item 3a
   * Item 3b

Miscellaneous

Images

![GitHub Logo](/images/logo.png)
Format: ![Alt Text](url)

Links

http://github.com - automatic!
[GitHub](http://github.com)


Blockquotes

As Kanye West said:

> We're living the future so
> the present is our past.


GitHub Flavored Markdown

Syntax highlighting with GFM
```javascript
function fancyAlert(arg) {
  if(arg) {
    $.facebox({div:'#foo'})
  }
}
```

Task Lists
- [ ] a task list item
- [ ] list syntax required
- [ ] normal **formatting**,
      @mentions, # 1234 refs
- [ ] incomplete
- [x] completed

Using Git

http://www.bioperl.org/wiki/Using_Git

Excerpts:

To checkout (or clone) the BioPerl core package (most people only want the core package) from GitHub, use:

$ git clone git://github.com/bioperl/bioperl-live.git

Alternatively, you can checkout (or clone) a specific BioPerl package such as bioperl-db (assuming you know what you are doing):

$ git clone git://github.com/bioperl/bioperl-db.git

By default, after 'cloning' (above), your checkout is on the BioPerl 'master' development branch. Git makes it easy to switch to a release tag or branch. For more information on these version control concepts see the repositories and branches section of the Git user's manual.

To list tags and branches, use:

$ git tag -l
$ git branch -r

To checkout a release tag or branch (for example), use:

$ git checkout bioperl-release-1-6-1 # tag
$ git checkout origin/release-1-6-2 # branch

To pull all the latest updates into your local repository, hit:

$ git pull

It is recommended to run this command every time you start to work on code (or if you know there has been a bug fix).

The preferred procedure for most developers to contribute changes to BioPerl is to fork the project on GitHub, make changes, and then send a pull request on GitHub to the main BioPerl project describing the changes.

GitHub itself has excellent documentation on forking and pull requests, see:

• Forking a repository
• Sending a pull request

HOW GITHUB WORKS

http://zachholman.com/posts/how-github-works-asynchronous/

This is — by far — my favorite aspect of working at GitHub. Everything is asynchronous.

GitHub didn't have an office for the first two years. Chat rooms (in our case, Campfire ) is where things got done. Today we've moved into our second office, and Campfire is still where we get things done. There's a reason for that: chat is asynchronous.

The majority of our development workflow involves Pull Requests. I'm going to be going into a lot more detail about this in future blog posts and talks but in the meantime let me say this: living in a pull request world is sublime. Gone are days at companies with complicated branching strategies, with in-person code-on-a-screen code review.

If I want to add a new feature or impact the codebase, I'll push a new branch, create a Pull Request for it, and my coworkers will review it 1) if they're impacted by those changes, 2) interested in the subject, or 3) when they have ample time to check out my changes. At that point, we can run a partial deploy of that branch on different subsets of machines and try things out in production, and if everything looks good, merge into master.

With Pull Requests, I don't have to drag anyone into a meeting that's inconvenient for them and for me. There's a good reason for that, too:

37signals originated "meetings are toxic" in Getting Real. I tend to loathe meetings even more than 37signals. I despise them.

Meetings are usually called when you need to hash something out. They tend to invite more people than necessary, and even if you're pretty interested in the meeting topic, you're still going to be frustrated because meetings pull you from doing actual work in order to talk about doing work. It's easier to push a branch up, check out the diff, and then iterate on that diff rather than assuming you're going to perfectly whiteboard system design ahead of time.

Beyond that, meetings are utterly forgettable. Even if you take meeting notes, you can't capture them all. You make a judgement at that point in time as to what to write down for later. Then three weeks later you try to remember what wasn't written down when it becomes apparent that that discussion was more important. You don't have this problem with chat transcripts. Forcing people to reduce their otherwise rambling thoughts into concrete sentences helps focus discussion, too.

#github
#programming
#versioncontrol
#business
#collaboration
#gtd