Whether you're running an open source project or a Fortune 500 company, Organizations simplify team management.
With teams you can give your developers as much or as little power as they need, from the ability to create projects on behalf of your organization to read-only access on existing projects.
Team permissions: Read-only, read-write, and admin-level access.
Best of all: create as many teams with as many members as you need. There are no limits on teams or their members.
Organizations allow the people who oversee your group's billing information and the people who oversee team management to work together brilliantly using their existing, free GitHub accounts.
Our wikis are powered by gollum — an open source wiki engine created by GitHub. They’re backed by Git, clonable, usable offline, and accept a plethora of text formats — what’s not to love?
Supported formats: Markdown, Textile, RDoc, Org Mode, Creole, ReStructured Text (ReST), ASCIIDoc, POD and Roff.
And of course since gollum is open source if there’s a text format you’d like to use that we don’t support you can contribute a parser!
Since every wiki is a git repository, your wikis are importable and exportable by default. Just clone your wiki locally and push it up at another time — all your content, images, and history stays intact.
git clone git://github.com/defunkt/resque.wiki.git
Every GitHub repository comes fully loaded with a next generation issue tracker so you can stay on top of bugs and focus on features.
Assignment, labels, and milestones help manage large projects
while Gmail-style keyboard shortcuts make Issues perfect for a
simple TODO
list or an open source project's bug
tracker.
Only teammates and collaborators can create and view issues on private repositories. Anyone may create and view issues on public repositories.
Pull Request integration and the ability to close or reference issues from commits help bring your workflow closer to your code.
GitHub Issues can be assigned to a user to make it easy to know who's working on what, or which issues you need to tackle next.
Labels are another way to organize your issues and are available in a variety of exciting colors.
Milestones are great at helping everyone work towards a goal. Set a due date, name your milestone, then start grouping issues together.
GitHub Issues are easy to find. Issue titles, descriptions, and comments are all indexed with our new search engine. If someone wrote it, you can find it.
Our state of the art quicksearch makes finding milestones and issues even easier. Just start typing and we'll do the rest.
Want to get more specific? The advanced search is great at narrowing down issues by their state, who they're assigned to, and more.
Issues know all about commits. By using a few simple keywords you can close an issue right from a commit message, or just leave a note on the issue.
The syntax is basic: if you want to close issue #35, put
closes #35
somewhere in your commit message then
push to GitHub.
Supported keywords: close, closes, closed, fixes, fixed
Leaving a note on an issues referencing your commit is even
easier — just mention the issue number without using one
of the above keywords, e.g. This commit references
#35
.
Anyone with write access to your repository may close an issue or leave a note.
The year 3000 called: they want their code review back. But we're not giving in. Pull Requests are living discussions that streamline the process of discussing, reviewing, and managing changes to code.
GitHub Pull Request = Code + Issue + Code Comments
Each Pull Request takes into account not only what you would like pulled but also where you intend those changes to be applied. From there your team can discuss the changes as a whole, individual parts, or even specific lines. Later commits addressing concerns or ideas appear as part of the discussion.
Our pull requests are everything you've ever wanted in code review and more. If you're unsure, just check out open pull requests for some of our popular open source projects to see them in action
GitHub allows you and your teammates to have a detailed discussion about each and every commit that is pushed to your project. Should it be included? Was it done correctly? Should something else be added? Talk about each change to your code with everyone involved before releasing or incorporating them. See an example now.
GitHub allows you to either comment on each commit as a whole, or click on any line and start a conversation on that individual line.
You can click on a checkbox at the top of any commit to toggle showing inline notes next to the code or at the bottom of the whole commit.
Many people love Git because of its amazing branching and merging ability. This often leads to having many more branches than in most other version control systems, since they're so easy to work with. This can cause confusion in knowing what work is in what branch or the status of your various branches.
GitHub addresses this problem with a unique visualization of your branches in our Branch Listing page. Here we list out each of your branches with a graphical representation of how ahead or behind each branch is relative to your currently selected branch. This means you can quickly see which branches have been recently worked on and how many unique commits are on them. If you want to see exactly what the total change is, you can click on the 'Compare' button next to any branch. See an example branches page for rails/rails.
With GitHub you can easily and efficiently compare any two branches in your project or network. It shows what work is unique to a branch with respect to another branch - that is, if you were to merge the branches together, what changes would be applied?
The Compare View between two branches is often used by teams as a permalink to summarize changes in emails or hooks.
The GitHub Compare View will show a list of all the commits unique to a branch, the sum of all the files changed across all of those commits and a unified diff of all of those changes. It summarizes what the branch represents simply and understandably. See an example compare view in action.
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*
Unordered
* Item 1 * Item 2 * Item 2a * Item 2b
Ordered
1. Item 1 2. Item 2 3. Item 3 * Item 3a * Item 3b
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.
Syntax highlighting with GFM
```javascript function fancyAlert(arg) { if(arg) { $.facebox({div:'#foo'}) } } ```
Or, indent your code 4 spaces
Here is a Python code example without syntax highlighting: def foo: if not bar: return true
Inline code for comments
I think you should use an `<addr>` element here instead.