GitHub "central point of collaboration"

 GitHub

GitHub is the single largest host for Git repositories, and is the central point of collaboration for millions of developers and projects. A large percentage of all Git repositories are hosted on GitHub, and many open-source projects use it for Git hosting, issue tracking, code review, and other things. So while it’s not a direct part of the Git open source project, there’s a good chance that you’ll want or need to interact with GitHub at some point while using Git professionally. 

If you are not interested in using GitHub to host your own projects or to collaborate with other projects that are hosted on GitHub, you can safely skip to Git Tools.

Account Setup and Configuration The first thing you need to do is set up a free user account. Simply visit https://github.com, choose a user name that isn’t already taken, provide an email address and a password, and click the big green “Sign up for GitHub” button.

GitHub will send you an email to verify the address you provided, Clicking the Octocat logo at the top-left of the screen will take you to your dashboard page. You’re now ready to use GitHub.

SSH Access As of right now, you’re fully able to connect with Git repositories using the https:// protocol, authenticating with the username and password you just set up. However, to simply clone public projects, you don’t even need to sign up - the account we just created.

The GitHub Flow GitHub is designed around a particular collaboration workflow, centered on Pull Requests. This flow works whether you’re collaborating with a tightly-knit team in a single shared repository, or a globally-distributed company or network of strangers contributing to a project through dozens of forks. It is centered on the Topic Branches workflow covered in Git Branching. Here’s how it generally works: 

1. Fork the project. 

2. Create a topic branch from master. 

3. Make some commits to improve the project.

 4. Push this branch to your GitHub project. 

5. Open a Pull Request on GitHub.

 6. Discuss, and optionally continue committing. 

7. The project owner merges or closes the Pull Request. 

8. Sync the updated master back to your fork. 

This is basically the Integration Manager workflow covered in Integration-Manager Workflow, but instead of using email to communicate and review changes, teams use GitHub’s web based tools.

Embedding Git in your Applications

 If your application is for developers, chances are good that it could benefit from integration with source control. Even non-developer applications, such as document editors, could potentially benefit from version-control features, and Git’s model works very well for many different scenarios. If you need to integrate Git with your application, you have essentially two options: spawn a shell and call the git command-line program, or embed a Git library into your application. Here we’ll cover command-line integration and several of the most popular embeddable Git libraries. 

Command-line Git 

One option is to spawn a shell process and use the Git command-line tool to do the work. This has the benefit of being canonical, and all of Git’s features are supported. This also happens to be fairly easy, as most runtime environments have a relatively simple facility for invoking a process with command-line arguments. However, this approach does have some downsides. 

One is that all the output is in plain text. This means that you’ll have to parse Git’s occasionally -changing output format to read progress and result information, which can be inefficient and error-prone. Another is the lack of error recovery. If a repository is corrupted somehow, or the user has a malformed configuration value, Git will simply refuse to perform many operations. Yet another is process management. Git requires you to maintain a shell environment on a separate process, which can add unwanted complexity. Trying to coordinate many of these processes (especially when potentially accessing the same repository from several processes) can be quite a challenge

git config 

Git has a default way of doing hundreds of things. For a lot of these things, you can tell Git to default to doing them a different way, or set your preferences. This involves everything from telling Git what your name is to specific terminal color preferences or what editor you use. There are several files this command will read from and write to so you can set values globally or down to specific repositories.

In First-Time Git Setup we used it to specify our name, email address and editor preference before we even got started using Git.

In Git Aliases we showed how you could use it to create shorthand commands that expand to long option sequences so you don’t have to type them every time

In Rebasing we used it to make --rebase the default when you run git pull.

In Credential Storage we used it to set up a default store for your HTTP passwords. In Keyword

 Expansion we showed how to set up smudge and clean filters on content coming in and out of Git.

Finally, basically the entirety of Git Configuration is dedicated to the command

git config core.editor commands 

git help 

The git help command is used to show you all the documentation shipped with Git about any command. While we’re giving a rough overview of most of the more popular ones in this appendix, for a full listing of all of the possible options and flags for every command, you can always run git help .