#Welcome.

#This is a template for the Small Developers to use for their development projects ##Fork this project ("repo") to make changes and submit a pull request so I can merge it to this Master repo.

I'll be testing Github out as a home for us to use as a framework as we look to build a Small Developer Coalition.

#Quick Git Glossary git repository "repo" (project)
commit (save)
push (upload)
README (instructions on how to contribute)
fork (makes a copy of). You use a fork to make changes to the main project and experiment, you then make a pull request so that your changes merge with the Master. For example, fork this repo to make changes to the template that you'd like incorporated. When managing your own project, clone this template repo and have your collaborators fork your clone. clone (downloads)
pull request (a request for you to "pull" from her fork, i.e., to accept her contribution)
pull (merge)
issues (point out mistakes, suggest improvements, etc). Note that issues have labels and milestones associated with them.

#Quick Narrative Describing the Practice of Git

Since GitHub has gone mainstream now, with authors, politicians, activists, etc. using it for all kinds of collaborative document editing / publishing / reviewing, I can understand where this question comes from. If you're not a programmer yourself the language can seem very strange. Here's an example:

Say you decide to collaborate with 79 random people all over the globe on a book called Around the World in 80 Essays, intended to celebrate the myriad cultures and thought systems of our era. GitHub is perfect for such a case.

So you create a git repository (folder) on your hard drive, write up your essay, and commit (save) the changes. Then you push (upload) it to GitHub with a nice README (instructions on how to contribute), and tweet a link to it.

An enthusiastic 17-year-old in a remote corner of the planet comes across it, and decides she wants to contribute. So she forks (makes a copy of) your repository on GitHub, and then clones (downloads) that copy to her hard drive. She writes up her essay and pushes to her GitHub fork.

But wait -- her essay is not officially part of the book yet, it's only in her own fork of your repository. So she sends you a pull request (a request for you to "pull" from her fork, i.e., to accept her contribution), at which point you are ecstatic to have your first collaborator! Now you review the pull request and suggest some improvements. A discussion ensues, and eventually some more commits (changes) are made by our budding author and pushed. Finally you pull (merge) her essay into the book.

As more and more people contribute, the book really starts to shape up. But it needs some editing, and some more reviewing. So you ask your friends to help out. They read all the great essays that have been contributed so far, and file issues (point out mistakes, suggest improvements, etc). Hopefully in a few months you reach the point where your book is ready to be published, and the 80 authors (plus the thousands who did a great job of editing) can bask in the glory of the ultimate legacy to our descendants. By the way, if you do write such a book, I'd be happy to send some pull requests your way.
[Via] (https://www.quora.com/What-does-the-slang-used-on-Github-mean)

#Quick Setup Guide [git - the simple guide] (http://rogerdudler.github.io/git-guide/). This guide is great and very quick