From 75e24fdca4e70e751332c491a4b60a712e12c9e0 Mon Sep 17 00:00:00 2001 From: Cameron McEfee Date: Fri, 27 May 2011 16:25:16 -0700 Subject: Reorder files to alphabetize. Update titles to be more conducive to quick scans. The posts have been re-dated to not only alphabetize them within their categories, but also to make them easier to find with their directory. Files marked 2008 are active post files. Files marked 2009 are outdated or are redirects to newer files. Files have been renamed to match their title for easier updating. --- _posts/2008-01-01-linux-set-up-git.markdown | 94 ++++++ _posts/2008-01-01-mac-set-up-git.markdown | 78 +++++ _posts/2008-01-01-win-set-up-git.markdown | 94 ++++++ _posts/2008-01-02-create-a-repo.markdown | 113 +++++++ _posts/2008-01-03-fork-a-repo.markdown | 160 ++++++++++ _posts/2008-01-04-be-social.markdown | 95 ++++++ _posts/2008-01-05-delete-a-repo.markdown | 18 ++ _posts/2008-01-06-move-a-repo.markdown | 63 ++++ .../2008-01-07-leave-a-collaborative-repo.markdown | 16 + _posts/2008-01-08-send-pull-requests.md | 233 +++++++++++++++ ...-your-user-name-email-and-github-token.markdown | 12 + _posts/2008-02-01-change-author-info.markdown | 38 +++ _posts/2008-02-02-deploy-keys.markdown | 54 ++++ _posts/2008-02-03-ignore-files.markdown | 72 +++++ _posts/2008-02-04-import-from-subversion.markdown | 55 ++++ _posts/2008-02-05-install-git-html-help.markdown | 40 +++ _posts/2008-02-06-manage-multiple-clients.markdown | 33 +++ _posts/2008-02-07-multiple-ssh-keys.markdown | 49 +++ _posts/2008-02-08-rebase.markdown | 154 ++++++++++ _posts/2008-02-09-remotes.markdown | 98 ++++++ _posts/2008-02-10-ssh-key-passphrases.textile | 125 ++++++++ _posts/2008-02-15-set-up-git-redirect.markdown | 9 - _posts/2008-02-16-create-a-repo.markdown | 113 ------- _posts/2008-03-01-deploy-capistrano.textile | 89 ++++++ _posts/2008-03-02-post-receive-hooks.markdown | 121 ++++++++ _posts/2008-03-03-remove-sensitive-data.markdown | 120 ++++++++ _posts/2008-03-04-split-a-subpath-to-a-new-repo.md | 29 ++ _posts/2008-03-05-subtree-merge.markdown | 127 ++++++++ _posts/2008-03-06-test-webhooks.textile | 65 ++++ ...2008-04-01-common-issues-and-questions.markdown | 38 +++ _posts/2008-04-02-firewalls-and-proxies.markdown | 19 ++ _posts/2008-04-03-fix-a-bad-tree.markdown | 56 ++++ _posts/2008-04-04-fix-egit-corruption.markdown | 57 ++++ _posts/2008-04-05-line-endings.textile | 50 ++++ _posts/2008-04-06-ssh-issues.textile | 94 ++++++ _posts/2008-05-01-textmate.markdown | 10 + ...2008-06-01-userscripts-and-bookmarklets.textile | 29 ++ _posts/2008-07-01-git-cheat-sheets.textile | 328 +++++++++++++++++++++ _posts/2008-08-01-privacy-policy.markdown | 46 +++ _posts/2008-08-02-security.markdown | 87 ++++++ _posts/2008-08-03-terms-of-service.markdown | 127 ++++++++ _posts/2008-08-04-dmca-takedown.markdown | 71 +++++ _posts/2009-01-01-set-up-git-redirect.markdown | 9 + _posts/2009-01-30-forking.markdown | 6 + _posts/2009-06-11-forking.markdown | 6 - _posts/2009-06-13-fork-a-repo.markdown | 160 ---------- _posts/2009-06-13-linux-set-up-git.markdown | 92 ------ _posts/2009-06-13-mac-set-up-git.markdown | 76 ----- _posts/2009-06-13-win-set-up-git.markdown | 92 ------ ...09-06-16-troubleshooting-common-issues.markdown | 38 --- _posts/2009-06-17-troubleshooting-ssh.textile | 94 ------ _posts/2009-06-20-git-email-settings.markdown | 12 - _posts/2009-06-23-security.markdown | 87 ------ _posts/2009-06-25-deleting-a-repo.markdown | 18 -- _posts/2009-06-25-moving-a-repo.markdown | 63 ---- _posts/2009-07-04-git-html-help.markdown | 40 --- ...2009-09-03-working-with-key-passphrases.textile | 125 -------- _posts/2009-09-09-removing-sensitive-data.markdown | 120 -------- ...2009-09-27-splitting-a-subpath-to-a-new-repo.md | 29 -- _posts/2009-10-05-dealing-with-lineendings.textile | 50 ---- _posts/2009-10-10-subtree-merge.markdown | 127 -------- _posts/2009-10-16-post-receive-hooks.markdown | 121 -------- ...2009-11-03-userscripts-and-bookmarklets.textile | 29 -- _posts/2009-11-16-egit-corruption.markdown | 57 ---- _posts/2009-11-17-testing-webhooks.textile | 65 ---- _posts/2010-01-12-privacy.markdown | 46 --- _posts/2010-01-12-terms.markdown | 127 -------- _posts/2010-01-15-dmca.markdown | 71 ----- _posts/2010-01-16-deploy-keys.markdown | 54 ---- _posts/2010-01-17-capistrano.textile | 89 ------ _posts/2010-01-19-managing-clients.markdown | 33 --- _posts/2010-01-19-multiple-keys.markdown | 49 --- _posts/2010-01-19-textmate.markdown | 10 - _posts/2010-01-27-remotes.markdown | 98 ------ _posts/2010-01-28-git-ignore.markdown | 72 ----- _posts/2010-01-29-rebase.markdown | 154 ---------- _posts/2010-03-02-changing-author-info.markdown | 38 --- _posts/2010-06-02-svn-importing.markdown | 55 ---- _posts/2010-06-03-firewalls-and-proxies.markdown | 19 -- _posts/2010-08-29-pull-requests.md | 233 --------------- _posts/2010-10-14-git-cheat-sheets.textile | 328 --------------------- _posts/2011-02-18-be-social.markdown | 95 ------ _posts/2011-03-07-egit-bad-tree.markdown | 56 ---- _posts/2011-04-04-leave-a-repo.markdown | 16 - 84 files changed, 3272 insertions(+), 3266 deletions(-) create mode 100644 _posts/2008-01-01-linux-set-up-git.markdown create mode 100644 _posts/2008-01-01-mac-set-up-git.markdown create mode 100644 _posts/2008-01-01-win-set-up-git.markdown create mode 100644 _posts/2008-01-02-create-a-repo.markdown create mode 100644 _posts/2008-01-03-fork-a-repo.markdown create mode 100644 _posts/2008-01-04-be-social.markdown create mode 100644 _posts/2008-01-05-delete-a-repo.markdown create mode 100644 _posts/2008-01-06-move-a-repo.markdown create mode 100644 _posts/2008-01-07-leave-a-collaborative-repo.markdown create mode 100644 _posts/2008-01-08-send-pull-requests.md create mode 100644 _posts/2008-01-09-set-your-user-name-email-and-github-token.markdown create mode 100644 _posts/2008-02-01-change-author-info.markdown create mode 100644 _posts/2008-02-02-deploy-keys.markdown create mode 100644 _posts/2008-02-03-ignore-files.markdown create mode 100644 _posts/2008-02-04-import-from-subversion.markdown create mode 100644 _posts/2008-02-05-install-git-html-help.markdown create mode 100644 _posts/2008-02-06-manage-multiple-clients.markdown create mode 100644 _posts/2008-02-07-multiple-ssh-keys.markdown create mode 100644 _posts/2008-02-08-rebase.markdown create mode 100644 _posts/2008-02-09-remotes.markdown create mode 100644 _posts/2008-02-10-ssh-key-passphrases.textile delete mode 100644 _posts/2008-02-15-set-up-git-redirect.markdown delete mode 100644 _posts/2008-02-16-create-a-repo.markdown create mode 100644 _posts/2008-03-01-deploy-capistrano.textile create mode 100644 _posts/2008-03-02-post-receive-hooks.markdown create mode 100644 _posts/2008-03-03-remove-sensitive-data.markdown create mode 100644 _posts/2008-03-04-split-a-subpath-to-a-new-repo.md create mode 100644 _posts/2008-03-05-subtree-merge.markdown create mode 100644 _posts/2008-03-06-test-webhooks.textile create mode 100644 _posts/2008-04-01-common-issues-and-questions.markdown create mode 100644 _posts/2008-04-02-firewalls-and-proxies.markdown create mode 100644 _posts/2008-04-03-fix-a-bad-tree.markdown create mode 100644 _posts/2008-04-04-fix-egit-corruption.markdown create mode 100644 _posts/2008-04-05-line-endings.textile create mode 100644 _posts/2008-04-06-ssh-issues.textile create mode 100644 _posts/2008-05-01-textmate.markdown create mode 100644 _posts/2008-06-01-userscripts-and-bookmarklets.textile create mode 100644 _posts/2008-07-01-git-cheat-sheets.textile create mode 100644 _posts/2008-08-01-privacy-policy.markdown create mode 100644 _posts/2008-08-02-security.markdown create mode 100644 _posts/2008-08-03-terms-of-service.markdown create mode 100644 _posts/2008-08-04-dmca-takedown.markdown create mode 100644 _posts/2009-01-01-set-up-git-redirect.markdown create mode 100644 _posts/2009-01-30-forking.markdown delete mode 100644 _posts/2009-06-11-forking.markdown delete mode 100644 _posts/2009-06-13-fork-a-repo.markdown delete mode 100644 _posts/2009-06-13-linux-set-up-git.markdown delete mode 100644 _posts/2009-06-13-mac-set-up-git.markdown delete mode 100644 _posts/2009-06-13-win-set-up-git.markdown delete mode 100644 _posts/2009-06-16-troubleshooting-common-issues.markdown delete mode 100644 _posts/2009-06-17-troubleshooting-ssh.textile delete mode 100644 _posts/2009-06-20-git-email-settings.markdown delete mode 100644 _posts/2009-06-23-security.markdown delete mode 100644 _posts/2009-06-25-deleting-a-repo.markdown delete mode 100644 _posts/2009-06-25-moving-a-repo.markdown delete mode 100644 _posts/2009-07-04-git-html-help.markdown delete mode 100644 _posts/2009-09-03-working-with-key-passphrases.textile delete mode 100644 _posts/2009-09-09-removing-sensitive-data.markdown delete mode 100644 _posts/2009-09-27-splitting-a-subpath-to-a-new-repo.md delete mode 100644 _posts/2009-10-05-dealing-with-lineendings.textile delete mode 100644 _posts/2009-10-10-subtree-merge.markdown delete mode 100644 _posts/2009-10-16-post-receive-hooks.markdown delete mode 100644 _posts/2009-11-03-userscripts-and-bookmarklets.textile delete mode 100644 _posts/2009-11-16-egit-corruption.markdown delete mode 100644 _posts/2009-11-17-testing-webhooks.textile delete mode 100644 _posts/2010-01-12-privacy.markdown delete mode 100644 _posts/2010-01-12-terms.markdown delete mode 100644 _posts/2010-01-15-dmca.markdown delete mode 100644 _posts/2010-01-16-deploy-keys.markdown delete mode 100644 _posts/2010-01-17-capistrano.textile delete mode 100644 _posts/2010-01-19-managing-clients.markdown delete mode 100644 _posts/2010-01-19-multiple-keys.markdown delete mode 100644 _posts/2010-01-19-textmate.markdown delete mode 100644 _posts/2010-01-27-remotes.markdown delete mode 100644 _posts/2010-01-28-git-ignore.markdown delete mode 100644 _posts/2010-01-29-rebase.markdown delete mode 100644 _posts/2010-03-02-changing-author-info.markdown delete mode 100644 _posts/2010-06-02-svn-importing.markdown delete mode 100644 _posts/2010-06-03-firewalls-and-proxies.markdown delete mode 100644 _posts/2010-08-29-pull-requests.md delete mode 100644 _posts/2010-10-14-git-cheat-sheets.textile delete mode 100644 _posts/2011-02-18-be-social.markdown delete mode 100644 _posts/2011-03-07-egit-bad-tree.markdown delete mode 100644 _posts/2011-04-04-leave-a-repo.markdown diff --git a/_posts/2008-01-01-linux-set-up-git.markdown b/_posts/2008-01-01-linux-set-up-git.markdown new file mode 100644 index 0000000..0d1d92b --- /dev/null +++ b/_posts/2008-01-01-linux-set-up-git.markdown @@ -0,0 +1,94 @@ +--- +layout: default +title: Set Up Git +description: A quick guide to help you get started with Git +--- + +

If you’ve found yourself on this page, we’re assuming you’re brand new to Git and GitHub. This guide will walk you through the basics and explain a little bit about how everything works along the way.

+ +

This is the guide for setting up git in OSX. There are also guides for OSX and Windows.

+ +##First: Download and Install Git + +At the heart of GitHub is an open source version control system (VCS) called Git*. Created by the same dudes that created Linux, Git is responsible for everything GitHub related that happens locally on your computer. + +_*If you don’t already know what Git is, take a crash course._ + +1. Download and install the latest version of Git with Synaptic. + + We suggest you install git-core, git-gui, and git-doc. + + Open Synaptic + Mark git-core, git-gui, and git-doc for installation + git-core, git-gui, and git-doc are selected + + When you’ve selected git-core, git-gui, and git-doc, hit “Apply” to install them. + + Click Apply + + If you don’t have a package manager like Synaptic, or you’d rather install the necessary git components from the command line, you can alternatively run the script below: + + 
+		$ sudo apt-get install git-core git-gui git-docInstalls git-core, git-gui, and git-doc on your system
+
+ + __*Note*__ Don’t worry that you don’t see an icon when it’s done. It’s not that kind of application. + +##Next: Set Up SSH Keys + +We use SSH keys to establish a secure connection between your computer and GitHub. Setting them up is fairly easy, but does involve a number of steps. + +To make sure you generate a brand new key, you need to check if one already exists. First, you need to open an app called Terminal. + +Open the terminal + +
+

Need a quick lesson about Terminal?

+
+

Code blocks like those on this page are part of a scripting language called Bash. To use Bash scripts, we need to use an application that comes with Linux called Terminal.

+ +

Input

+ 
+			$ echo 'This is input text'This tooltip tells you what's going on.
+
+ +

A line that begins with the dollar sign ($) indicates a line of Bash script you need to type. To enter it, type the text that follows the $, hitting the return key at the end of each line. You can hover your mouse over each line for an explanation of what the script is doing.

+ +

Output

+ 
+			This is output text.
+
+ +

A line that does not begin with a $ is output text that is intended to give you information or tell you what to do next. We’ve colored output text green in these bootcamp tutorials.

+ +

User Specific Input

+ 
+			$ echo 'username'Outputs the text in the quotation marks.
+
+ +

Areas of yellow text represent your own personal info, repos, etc. If it is part of an input ($) line, you should replace your it with your own info when you type it. If it is part of output text, it is just for your reference. It will automatically show your own info in Terminal.

+ +

Good to know: There will be times when you type code, hit return, and all you are given is another prompt. Some actions that you execute in Terminal don’t have any output. Don’t worry, if there is ever a problem with your code, Terminal will let you know.

+ +

Good to know: For security reasons, Terminal will not display what you type when entering passwords. Just type your password and hit the return key.

+
+
+ +{% include ssh_setup.markdown %} + +##Then: Set Up Your Info + +Now that you have Git set up and your SSH keys entered into GitHub, it’s time to configure your personal info. + +{% include email_setup.markdown %} + +##Lastly: Celebrate + +Congratulations, you now have Git and GitHub all set up! What do you want to do next? + +
    +
  1. Set Up Git
    2. +
  2. Create A Repository
    3. +
  3. Fork A Repository
    4. +
  4. Be Social
    5. +
\ No newline at end of file diff --git a/_posts/2008-01-01-mac-set-up-git.markdown b/_posts/2008-01-01-mac-set-up-git.markdown new file mode 100644 index 0000000..99f742b --- /dev/null +++ b/_posts/2008-01-01-mac-set-up-git.markdown @@ -0,0 +1,78 @@ +--- +layout: default +title: Set Up Git +description: A quick guide to help you get started with Git +--- + +

If you’ve found yourself on this page, we’re assuming you’re brand new to Git and GitHub. This guide will walk you through the basics and explain a little bit about how everything works along the way.

+ +

This is the guide for setting up git in OSX. There are also guides for Windows and Linux.

+ +##First: Download and Install Git + +At the heart of GitHub is an open source version control system (VCS) called Git*. Created by the same dudes that created Linux, Git is responsible for everything GitHub related that happens locally on your computer. + +_*If you don’t already know what Git is, take a crash course._ + +1. Download and install the latest version of Git. + + __*Note*__ Don’t worry that you don’t see an icon when it’s done. It’s not that kind of application. + +##Next: Set Up SSH Keys + +We use SSH keys to establish a secure connection between your computer and GitHub. Setting them up is fairly easy, but does involve a number of steps. + +To make sure you generate a brand new key, you need to check if one already exists. First, you need to open Terminal.app, usually found at /Applications/Utilities. + +Open the terminal + +
+

Need a quick lesson about Terminal?

+
+

Code blocks like those on this page are part of a scripting language called Bash. To use Bash scripts, we need to use an application that comes with your Mac called Terminal.

+ +

Input

+ 
+			$ echo 'This is input text'This tooltip tells you what's going on.
+
+ +

A line that begins with the dollar sign ($) indicates a line of Bash script you need to type. To enter it, type the text that follows the $, hitting the return key at the end of each line. You can hover your mouse over each line for an explanation of what the script is doing.

+ +

Output

+ 
+			This is output text.
+
+ +

A line that does not begin with a $ is output text that is intended to give you information or tell you what to do next. We’ve colored output text green in these bootcamp tutorials.

+ +

User Specific Input

+ 
+			$ echo 'username'Outputs the text in the quotation marks.
+
+ +

Areas of yellow text represent your own personal info, repos, etc. If it is part of an input ($) line, you should replace it with your own info when you type it. If it is part of output text, it is just for your reference. It will automatically show your own info in Terminal.

+ +

Good to know: There will be times when you type code, hit return, and all you are given is another prompt. Some actions that you execute in Terminal don’t have any output. Don’t worry, if there is ever a problem with your code, Terminal will let you know.

+ +

Good to know: For security reasons, Terminal will not display what you type when entering passwords. Just type your password and hit the return key.

+
+
+ +{% include ssh_setup.markdown %} + +##Then: Set Up Your Info + +Now that you have Git set up and your SSH keys entered into GitHub, it’s time to configure your personal info. + +{% include email_setup.markdown %} + +##Lastly: Celebrate + +Congratulations, you now have Git and GitHub all set up! What do you want to do next? + +
    +
  1. Set Up Git
    2. +
  2. Create A Repository
    3. +
  3. Fork A Repository
    4. +
  4. Be Social
    5. +
\ No newline at end of file diff --git a/_posts/2008-01-01-win-set-up-git.markdown b/_posts/2008-01-01-win-set-up-git.markdown new file mode 100644 index 0000000..a468fab --- /dev/null +++ b/_posts/2008-01-01-win-set-up-git.markdown @@ -0,0 +1,94 @@ +--- +layout: default +title: Set Up Git +description: A quick guide to help you get started with Git +--- + +

If you’ve found yourself on this page, we’re assuming you’re brand new to Git and GitHub. This guide will walk you through the basics and explain a little bit about how everything works along the way.

+ +

This is the guide for setting up git in OSX. There are also guides for OSX and Linux.

+ +##First: Download and Install Git + +At the heart of GitHub is an open source version control system (VCS) called Git*. Created by the same dudes that created Linux, Git is responsible for everything GitHub related that happens locally on your computer. + +_*If you don’t already know what Git is, take a crash course._ + +1. Download and install the latest version of msysgit. + + Use the default options for each step. + + Welcome page + Information + Select destination location + Select start menu folder + Select components + Adjusting your PATH environment + Configuring the line ending conversions + Installing + Installation complete + + + __Do not use PuTTY if you are given the option. GitHub only provides support for openssh.__ + +##Next: Set Up SSH Keys + +We use SSH keys to establish a secure connection between your computer and GitHub. Setting them up is fairly easy, but does involve a number of steps. + +To make sure you generate a brand new key, you need to check if one already exists. First, you need to open Git Bash (not the Windows command line), found in the start menu in the git. + +Open the terminal + +
+

Need a quick lesson about Git Bash?

+
+

Code blocks like those on this page are part of a scripting language called Bash. To use Bash scripts, we need to use an application that was installed with Git called Git Bash.

+ +

Input

+ 
+			$ echo 'This is input text'This tooltip tells you what's going on.
+
+ +

A line that begins with the dollar sign ($) indicates a line of Bash script you need to type. To enter it, type the text that follows the $, hitting the return key at the end of each line. You can hover your mouse over each line for an explanation of what the script is doing.

+ +

Output

+ 
+			This is output text.
+
+ +

A line that does not begin with a $ is output text that is intended to give you information or tell you what to do next. We’ve colored output text green in these bootcamp tutorials.

+ +

User Specific Input

+ 
+			$ echo 'username'Outputs the text in the quotation marks.
+
+ +

Areas of yellow text represent your own personal info, repos, etc. If it is part of an input ($) line, you should replace it with your own info when you type it. If it is part of output text, it is just for your reference. It will automatically show your own info in Git Bash.

+ +

Good to know: There will be times when you type code, hit return, and all you are given is another prompt. Some actions that you execute in Git Bash don’t have any output. Don’t worry, if there is ever a problem with your code, Git Bash will let you know.

+ +

Good to know: For security reasons, Git Bash will not display what you type when entering passwords. Just type your password and hit the return key.

+
+
+ +{% include ssh_setup.markdown %} + +##Then: Set Up Your Info + +Now that you have Git set up and your SSH keys entered into GitHub, it’s time to configure your personal info. + +{% include email_setup.markdown %} + +##Lastly: Celebrate + +Congratulations, you now have Git and GitHub all set up! What do you want to do next? + +
    +
  1. Set Up Git
    2. +
  2. Create A Repository
    3. +
  3. Fork A Repository
    4. +
  4. Be Social
    5. +
+ \ No newline at end of file diff --git a/_posts/2008-01-02-create-a-repo.markdown b/_posts/2008-01-02-create-a-repo.markdown new file mode 100644 index 0000000..f10d79e --- /dev/null +++ b/_posts/2008-01-02-create-a-repo.markdown @@ -0,0 +1,113 @@ +--- +layout: default +title: Create A Repo +description: Create the place where your commits will be stored +categories: beginner +--- + +If you’ve found yourself on this page, we’re assuming you’re brand new to Git and GitHub. This guide will walk you through the basics and explain a little bit about how everything works along the way. + +##First: Create A Repo + +Every time you make a commit with Git, it is stored in a repository (a.k.a. “repo”). To put your project up on GitHub, you’ll need to have a GitHub repository for it to live in. + +
+

More about repositories

+
+

+ Git stores all of your project files in a repository. If you are able to view hidden files on your system, you’ll see a subdirectory called “.git” in the project directory where you run git init. This is where Git stores all of your commits, as well as everything else it needs. In addition to your local, you can also have remote repositories (like GitHub repos). Remote repositories are the same as your local repo, but stored on a different server or computer for easy collaboration, backup, and general awesomeness. +

+
+
+ +1. Create a new repo + + Click [New Repository](https://github.com/repositories/new). + + Click “New Repository + + Fill out the information on this page. When you’re done, click “Create Repository.” + + Fill in the info + + Congratulations! You have successfully created your first repo! + +##Next: Create a README for your repo. + +While a README isn’t a required part of a GitHub repo, it is a good idea to have one. READMEs are a great place to describe your project or add some documentation such as how to install or use your project. + +
+

More about READMEs

+
+

+ If you include a file with the filename “README” in your repo, it will automatically be shown on your repo’s front page. Pretty cool, huh? GitHub supports a number of different README formats. The one in this tutorial will result in a basic text file but other formats like .markdown or .textile can be used to render HTML content like links and headers. For more info about the supported markup formats, check out the github markup repo. +

+
+
+ +1. Create the README file + + In the prompt, type the following code: + + 
+	$ mkdir ~/Hello-WorldCreates a directory for your project called "Hello-World" in your user directory
+	$ cd ~/Hello-WorldChanges the current working directory to your newly created directory
+	$ git initSets up the necessary Git files
+	Initialized empty Git repository in /Users/your_user_directory/Hello-World/.git/
+	$ touch READMECreates a file called “README” in your Hello-World directory
+
+ + Open the new README file found in your Hello-World directory in a text editor and add the text “Hello World!” When you are finished, save and close the file. + +2. Commit your README + + Now that you have your README set up, it“s time to commit it. A commit is essentially a snapshot of all the files in your project at a particular point in time. In the prompt, type the following code: + +
+

More about commits

+
+

+ Think of a commit as a snapshot of your project —code, files, everything — at a particular point in time. More accurately, after your first commit, each subsequent commit is only a snapshot of your changes. For code files, this means it only takes a snapshot of the lines of code that have changed. For everything else like music or image files, it saves a new copy of the file. +

+
+
+ + 
+	$ git add READMEStages your README file, adding it to the list of files to be committed
+	$ git commit -m 'first commit'Commits your files, adding the message "first commit"
+
+ + The code above executes actions locally, meaning you still haven’t done anything on GitHub yet. To connect your local repository to your GitHub account, you will need to set a remote for your repo and push your commits to it: + +
+

More about remotes

+
+

+ A remote is a repo stored on another computer, in this case on GitHub’s server. It is standard practice (and also the default in some cases) to give the name origin to the remote that points to your main offsite repo (for example, your GitHub repo). +

+

+ Git supports multiple remotes. This is commonly used when forking a repo. +

+
+
+ + + 
+	$ git remote add origin git@github.com:username/Hello-World.gitSets the origin for the Hello-World repo
+	$ git push origin masterSends your commit to GitHub
+
+ + Now if you look at your repository on GitHub, you will see your README has been added to it. + + Your README has been created + +##Lastly: Celebrate + +Congratulations! You have now created a repository on GitHub, created a README, committed it, and pushed it to GitHub. What do you want to do next? + +
    +
  1. Set Up Git
    2. +
  2. Create A Repository
    3. +
  3. Fork A Repository
    4. +
  4. Be Social
    5. +
\ No newline at end of file diff --git a/_posts/2008-01-03-fork-a-repo.markdown b/_posts/2008-01-03-fork-a-repo.markdown new file mode 100644 index 0000000..eccf8df --- /dev/null +++ b/_posts/2008-01-03-fork-a-repo.markdown @@ -0,0 +1,160 @@ +--- +layout: default +title: Fork A Repo +description: Copy a repo to create a new, unique project from its contents. +categories: beginner +--- + +If you’ve found yourself on this page, we’re assuming you’re brand new to Git and GitHub. This guide will walk you through the basics and explain a little bit about how everything works along the way. + +##First: Fork A Repo + +At some point you may find yourself wanting to contribute to someone else's project, or would like to use someone's project as the starting point for your own. This is known as “forking.” For this tutorial, we’ll be using the Spoon-Knife project. + +1. Fork the “Spoon-Knife ” repo + + To fork this project, click the “Fork” button. + + Click “Fork + +##Next: Set Up Your Local Repo + +You’ve successfully forked the Spoon-Knife repo, but so far it only exists on GitHub. To be able to work on the project, you will need to clone it to your local machine. + +1. Clone the “Spoon-Knife” project + + Run the following code: + + 
+	$ git clone git@github.com:username/Spoon-Knife.gitClones your copy of the repo into the current directory in terminal
+
+ +2. Configure remotes + + When a repo is cloned, it has a default remote called `origin` that points to your fork on GitHub, not the original repo it was forked from. To keep track of the original repo, you need to add another remote named `upstream`: + +
+

More about remotes

+
+

+ A remote is a repo stored on another computer, in this case on GitHub’s server. It is standard practice (and also the default in some cases) to give the name origin to the remote that points to your main offsite repo (for example, your GitHub repo). +

+

+ Git supports multiple remotes. This is commonly used when forking a repo. +

+
+
+ + 
+	$ cd Spoon-KnifeChanges the active directory in the prompt to the newly cloned "Spoon-Knife" directory
+	$ git remote add upstream git://github.com/octocat/Spoon-Knife.gitAssigns the original repo to a remote called "upstream"
+	$ git fetch upstreamPulls in any changes not present in your local repository, but doesn't modify your working files
+
+ +##Then: More Things You Can Do + +You’ve successfully forked a repo, but get a load of these other cool things you can do: + +- Push commits + + Once you’ve made some commits to a forked repo and want to push it to your forked project, you do it the same way you would with a regular repo: + +
+

More about commits

+
+

+ Think of a commit as a snapshot of your project —code, files, everything — at a particular point in time. More accurately, after your first commit, each subsequent commit is only a snapshot of your changes. For code files, this means it only takes a snapshot of the lines of code that have changed. For everything else like music or image files, it saves a new copy of the file. +

+
+
+ + 
+	$ git push origin masterPushes commits to your remote repo stored on GitHub
+
+ +- Pull in upstream changes + + If the original repo you forked your project from gets updated, you can add those updates to your fork by running the following code: + + 
+	$ git fetch upstreamFetches any new changes from the original repo
+	$ git merge upstream/masterMerges any changes fetched into your working files
+
+ +
+

What is the difference between fetch and pull?

+
+

+ There are two ways to get commits from a remote repo or branch: fetch and pull. While they might seem similar at first, there are distinct differences you should consider. +

+

Pull

+ 
+					$ git pull upstreamPulls commits from 'upstream' and adds them to the local repo
+
+

When you use pull, Git tries to automatically do your work for you. It is context sensitive, so Git will merge any pulled commits into the branch you are currently working in. One thing to keep in mind is that pull automatically merges the commits without letting you review them first. If you don’t closely manage your branches you may run into frequent conflicts.

+ +

Fetch/Merge

+ 
+					$ git fetch upstreamFetches any new commits from the original repo
+					$ git merge upstream/masterMerges any commits fetched into your working files
+
+

When you fetch, Git gathers any commits from the target branch that do not exist in your current branch and stores them in your local repo. However, it does not merge them with your current branch. This is particularly useful if you need to keep your repo up to date but are working on something that might break if you update your files. To integrate the commits into your master branch, you use merge. This combines the specified branches and prompts you if there are any conflicts.

+
+
+ +- Work with branches + + Branching allows you to build new features or test out ideas without putting your main project at risk. A Git branch is a small file that references the commit it was spawned from. This makes Git branches very small and easy to work with. + +
+

How do I use branches?

+
+ +

+ Branches are pretty easy to work with and will save you a lot of headaches, especially when working with multiple people. To create a branch and begin working in it, use the following script: +

+ + 
+				$ git branch mybranchCreates a new branch called "mybranch"
+				$ git checkout mybranchMakes "mybranch" the active branch
+
+ +

Alternatively, you can use the shortcut:

+ + 
+				$ git checkout -b mybranchCreates a new branch called "mybranch" and makes it the active branch
+
+ +

To switch between branches, use checkout.

+ + 
+				$ git checkout masterMakes "master" the active branch
+				$ git checkout mybranchMakes "mybranch" the active branch
+
+ +

Once you’re finished working on your branch and are ready to combine it back into the master branch, use merge.

+ + 
+				$ git checkout masterMakes "master" the active branch
+				$ git merge mybranchMerges the commits from "mybranch" into "master"
+				$ git branch -d mybranchDeletes the "mybranch" branch
+
+ +
+
+ + +- Pull requests + + If you are hoping to contribute back to the original fork, you can send the original author a [pull request](/pull-requests/). + +##Lastly: Celebrate + +You have now created forked a repo. What do you want to do next? + +
    +
  1. Set Up Git
    2. +
  2. Create A Repository
    3. +
  3. Fork A Repository
    4. +
  4. Be Social
    5. +
\ No newline at end of file diff --git a/_posts/2008-01-04-be-social.markdown b/_posts/2008-01-04-be-social.markdown new file mode 100644 index 0000000..47a7c62 --- /dev/null +++ b/_posts/2008-01-04-be-social.markdown @@ -0,0 +1,95 @@ +--- +layout: default +title: Be Social +description: Follow a friend. Watch a project. +categories: beginner +--- + +If you’ve found yourself on this page, we’re assuming you’re brand new to Git and GitHub. This guide will walk you through the basics and explain a little bit about how everything works along the way. + +##First: Follow A Friend + +One of the great features on GitHub is the ability to see what other people are working on and who they are connecting with. When you follow someone, you will get notifications on your dashboard about their GitHub activity. + +1. Pick a friend. + + Why not follow one of these cool people? +
+ + +

Tom Preston-Werner

+

mojombo

+ + + +

Chris Wanstrath

+

defunkt

+ + + +

PJ Hyett

+

pjhyett

+ + + +

Scott Chacon

+

schacon

+ +
+ + Who are these fine fellows? Why the founders of GitHub, of course! + +2. Follow a friend + + Once you are on one of their pages, click the “follow” button. + + Click “Follow + + Congratulations! You are now following a friend. + +##Next: Watch A Project + +At some point you may want to stay up-to-date with a specific project. We’ve made this easy to do. + +1. Watch a project + + Our friend the Octocat has a project called Hello World that we’d like to watch. + + Once you are in the project page, you will notice there is a “watch” button at the top of the page. Click on it. + + Click “Watch + + Congratulations! You are now watching the the Hello World project. If the Octocat updates it, you will see what happened in your dashboard. + +##Then: More Things You Can Do + +You’ve done some of the most basic social interaction GitHub has to offer, but don’t stop there! Check out these other social features: + +- Pull Requests + + Pull Requests + + You may find yourself wanting to contribute to someone else’s project, whether to add features or to fix bugs. After making changes, you can let the original author know about them by sending a [pull request](/pull-requests/). + +- Issues + + Issues + + When you are collaborating on a project with someone, you some times come across problems that need to be fixed. To help you keep track of these problems, each GitHub repo has a section called Issues. For an example, check out the [issues](https://github.com/octocat/Spoon-Knife/issues) for the Spoon-Knife repo. + +- Organizations + + Organizations + + Have you found yourself wishing you could collaborate with multiple developers on one project? You can manage everyone with Organizations! With an organization you can establish teams with special permissions, have a public organization profile, and keep track of activity within the organization. + +##Lastly: Celebrate + +Congratulations! You are quite the socialite. What do you want to do next? + +
    +
  1. Set Up Git
    2. +
  2. Create A Repository
    3. +
  3. Fork A Repository
    4. +
  4. Be Social
    5. +
\ No newline at end of file diff --git a/_posts/2008-01-05-delete-a-repo.markdown b/_posts/2008-01-05-delete-a-repo.markdown new file mode 100644 index 0000000..fa770ea --- /dev/null +++ b/_posts/2008-01-05-delete-a-repo.markdown @@ -0,0 +1,18 @@ +--- +layout: default +title: Delete a repo +description: How to remove a repo from your GitHub account +categories: beginner +--- + +

Deleting a private repo will delete all forks of the repo. Deleting a public repo will not.

+ +Go to the repository homepage → Admin: + +![](http://img.skitch.com/20100110-jps511wbqpmjpgp16m8g17iiut.jpg) + +At the bottom of the page there is a button to delete the repo: + +![](http://img.skitch.com/20100527-fgtcuthgr5xrbcyqmxgiue5jwb.png) + +Collaborators can not delete repos, but they can [leave them](/leave-a-repo). diff --git a/_posts/2008-01-06-move-a-repo.markdown b/_posts/2008-01-06-move-a-repo.markdown new file mode 100644 index 0000000..c95d3f6 --- /dev/null +++ b/_posts/2008-01-06-move-a-repo.markdown @@ -0,0 +1,63 @@ +--- +layout: default +title: Move a repo +description: How to move a repo from one account to another +categories: beginner +--- + +This guide details the process of moving a repo to another account. + +Direct move +----------- + +If you wish to move a repo between users or organizations, please [contact support](http://support.github.com/) following the details below. + +**What to check before creating the support request** + +1. Make sure that there is not a repo with the same name on the destination account. + +2. Make sure the destination account has unused private repos available if the repo being moved is private. + +3. **Please** make sure you login with the account that owns the repositories you want support to move for you. If the repositories belong to different accounts, please create one support request per account. + +**What to include in your support request** + +1. List the repositories you want support to move. + +2. Tell us the destination account (the username) + +**Example** + +*Subject:* Move repositories + +*Repositories* + + myaccount/repoA + myaccount/repoB + myaccount/repoC + +*Destination* + + destinationaccount + +Existing forks +-------------- + +If a fork of the repo you wish to move already exists on the target account, you can [contact support](http://support.github.com/) to have the roots switched. Note that deleting the root repo will either delete all forks if the repo is private, or automatically pick a new root if the repo is public. You cannot pick which repo will become the root, so please contact support if you want a specific repo to become the new root. + +Note that if the repo is private the new owner will need a paid plan to support the repo. Issues, wikis, pages, commits comments and non-repo downloads **will not** be transferred to the new root. Make sure you do not delete your old repo if you have any of these you wish to keep. + +Manual clone and push +--------------------- + +If you have a repo on an external server that you wish to move to GitHub, you can move it with a special clone and push. This method will create an exact mirror of the repo into the new repo. + +First, create a new repo on the target account. Next, create a mirror that includes all branches and tags. To do this you need to do a bare-clone followed by a mirror-push: + +
+git clone --bare url/for/my-old-repo.git
+cd my-old-repo.git
+git push --mirror git@github.com:mycompany/my-new-repo.git
+cd ..
+rm -rf my-old-repo.git
+
diff --git a/_posts/2008-01-07-leave-a-collaborative-repo.markdown b/_posts/2008-01-07-leave-a-collaborative-repo.markdown new file mode 100644 index 0000000..10ae198 --- /dev/null +++ b/_posts/2008-01-07-leave-a-collaborative-repo.markdown @@ -0,0 +1,16 @@ +--- +layout: default +title: Leave a collaborative repo +description: Leave a repo you are collaborating on +categories: beginner +--- + +To leave a repository on which you are collaborating: + +_Click "Account Settings"_ > _Click "Repositories"_ + +![](/images/remove_repo.png) + +An "x" will show up in the corner of the repositories you can remove. + +None of your commits will be lost. Only the repository owner can [delete repos](/deleting-a-repo/). diff --git a/_posts/2008-01-08-send-pull-requests.md b/_posts/2008-01-08-send-pull-requests.md new file mode 100644 index 0000000..464ca1b --- /dev/null +++ b/_posts/2008-01-08-send-pull-requests.md @@ -0,0 +1,233 @@ +--- +layout: default +title: Send pull requests +description: How to notify others of your changes using Pull Requests. +categories: beginner +--- + + + +

Pull requests let you tell others about changes you've pushed to a GitHub +repository. Once a pull request is sent, interested parties can review the set +of changes, discuss potential modifications, and even push follow-up commits if +necessary.

+ +

This guide walks through the process of sending a hypothetical pull request and +using the various code review and management tools to take the change to +completion.

+ +## A Quick Note on Collaborative Development Models + +There are two popular models of collaborative development on GitHub: + + 1. The *Fork + Pull Model* lets anyone fork an existing repository and + push changes to their personal fork without requiring access be granted + to the source repository. The changes must then be pulled into the source + repository by the project maintainer. This model reduces the amount of + friction for new contributors and is popular with open source projects + because it allows people to work independently without upfront + coordination. + + 2. The *Shared Repository Model* is more prevalent with small teams and + organizations collaborating on private projects. Everyone is granted push + access to a single shared repository and topic branches are used to isolate + changes. + +Pull requests are especially useful in the *Fork + Pull Model* because they +provide a way to notify project maintainers about changes in your fork. However, +they're also useful in the *Shared Repository Model* where they're used to +initiate code review and general discussion about a set of changes before being +merged into a mainline branch. + +## Before You Begin + +This guide assumes that [you have a GitHub account](http://github.com/signup), +that you've forked an existing repository and pushed your changes. For help with +forking and pushing changes, see the [Forking a project](/forking/) topic. + +## Initiating The Pull Request + +In the following example, **kneath** has completed some work on an error page +for the GitHub Jobs web application, pushed three commits to a topic branch in +his fork, and would like someone to review and merge. + +Navigate to **your repository** with the changes you want someone else to pull and +press the *Pull Request* button. + +![](http://img.skitch.com/20100831-qfk1c9wyt89pfgfxg61bh1r8rn.png) + +Pull requests can be sent from any branch or commit but it's recommended that a +topic branch be used so that follow-up commits can be pushed to update the pull +request if necessary. + +## Previewing The Pull Request + +After pressing the *Pull Request* button, you are presented with a preview page +where you can enter a title and optional description, see exactly what +commits will be included when the pull request is sent, and also see who the +pull request will be sent to: + +![](http://img.skitch.com/20100831-qit9sjhuqk42t4ww91ifm5tm81.png) + +If you're sending from a topic branch, the title is pre-filled based on the name +of the branch. Markdown is supported in the description, so you can embed images +or use preformatted text blocks. + +Switch to the *Commits* tab to ensure that the correct set of changes is being +sent: + +![](http://img.skitch.com/20100831-c9g4pcsjwnfj14csrpytenxyfn.png) + +Review the diff of all changes by switching to the *Files Changed* tab: + +![](http://img.skitch.com/20100831-qpc5bu8grycefnnbaagnuwbckq.png) + +## Changing The Commit Range and Destination Repository + +By default, pull requests are assumed to be based on the parent-most +repository's integration branch. In this case, the `kneath/jobs` repository was +forked from `github/jobs` so the pull request is assumed to be based on the +`master` branch of the `github/jobs` repository. In a great majority of cases, +the defaults will be right; however, if any of this information is incorrect, press +the *Change Commits* button. + +![](http://img.skitch.com/20100831-nm1mgb6n8ng7e4nrdesucqx98h.png) + +The commit range selector will expand, allowing the base repository, base +branch, and head branch to be customized: + +![](http://img.skitch.com/20100831-pwsq1inmr7m7y61dfcyxnhjkkd.png) + +The easiest way of thinking about the commit range is this: the *base branch* is +**where** you think changes should be applied, the *head branch* is **what** you +would like to be applied. + +Changing the base repository changes who is notified of the pull request. +Everyone that can push to the base repository will receive an email notification +and see the new pull request in their dashboard the next time they log in. + +Once you're happy with the commit range, press the *Update Commit Range* button +to update the commit and files changed preview areas. + +## Sending The Pull Request + +Once you've entered the title and description, made any necessary customizations +to the commit range, and reviewed the commits and file changes to be sent, press +the *Send pull request* button. + +![](http://img.skitch.com/20100831-fe6i533swbgsgypgc645f999i.png) + +The pull request is sent immediately. You're taken to the main pull request +discussion and review page. Additionally, all repository collaborators and +followers will see an event in their dashboard: + +![](http://img.skitch.com/20100831-bj3rg8bac4buemstnwqy7wwxq2.png) + +## Managing Pull Requests + +All pull requests sent or received by you are browseable through the pull +request dashboard. + +![](http://img.skitch.com/20100831-xfscxin81wj5j3gwyas2sd398q.png) + +Pull requests for a specific repository are also browseable by anyone with +access by visiting the *Network -> Pull Requests* page. + +![](http://img.skitch.com/20100823-bahbpwpemx3jh2kpke77d2dxtc.png) + +The pull request dashboard and the repository pull request list support a wide +range of filtering and sorting controls. Use them to narrow down the list to +the pull requests you're interested in. + +## Reviewing Proposed Changes + +When you receive a pull request, the first thing to do is review the set of +proposed changes. Pull requests are tightly integrated with the underlying git +repository, so you can see exactly what commits would be merged should the +request be accepted: + +![](http://img.skitch.com/20100831-81im4n771y5tcwg3ryixajtfeg.png) + +You can also review the cumulative diff of all file changes across all commits. + +![](http://img.skitch.com/20100831-enh8t415ryr5b1sw45shq9ier3.png) + +## Pull Request Discussion + +After reviewing the basic description, commits, and cumulative diff, the person +tasked with applying the changes may have questions or comments. Perhaps the +coding style doesn't match project guideline, or the change is missing unit +tests, or maybe everything looks great and some props are in order. The +discussion view is designed to encourage and capture this type of discussion. + +![](http://img.skitch.com/20100831-j7fapxihs2a3i48ai5qmqceskp.png) + +The discussion view starts with the pull request's original title and +description and then captures additional activity to display chronologically +from there. Any of the following types of activity are captured as they happen: + + * Comments left on the pull request itself. + * Additional commits pushed to the pull request's branch. + * File and line notes left on any of the commits included in the pull request's range. + +Pull request comments are Markdown compatible, so you can embed images, use +preformatted text blocks, and other formatting supported by Markdown. + +## Merging a Pull Request + +Once the pull request is deemed satisfactory, someone with push access to the +destination repository must apply the changes and push the updated branch. +There are a variety of ways to accomplish this. Two popular methods are +described below. + +#### Fetch and Merge + +This is the most common method of fetching and applying changes. It requires +adding a remote for the person that sent the pull request, fetching from that +repository, merging the requested branch, fixing any conflicts, and pushing +the newly merged branch back to the repository: + +
+$ git checkout master
+$ git remote add kneath git://github.com/kneath/jobs.git
+$ git fetch kneath
+$ git merge kneath/error-page
+$ git push origin master
+
+ +#### Patch and Apply + +The *fetch and merge* approach works great when you're working on a team or +repeatedly applying changes from the same small group of people. Another +approach that's a bit quicker in one-off cases is to use `git-am`. + +Every pull request has a `.patch` URL where you can grab a textual patch file +to feed into the `git-am` command: + +
+$ git checkout master
+$ curl http://github.com/github/jobs/pull/25.patch | git am
+$ git push origin master
+
+ +## Closing a Pull Request + +Pull Requests are automatically closed when the requested commits are merged +into the destination repository. An event is generated to let all repository +collaborators and followers know that the merge occurred: + +![](http://img.skitch.com/20100831-x9ush35wkyxwmw4sw8yd5sx1eg.png) + +It's also possible to manually close a pull request in cases where the set of +changes are rejected. This is also sometimes necessary if the changes are +applied with `git-cherry-pick` or using some other mechanism that disallows the +merge from being detected. diff --git a/_posts/2008-01-09-set-your-user-name-email-and-github-token.markdown b/_posts/2008-01-09-set-your-user-name-email-and-github-token.markdown new file mode 100644 index 0000000..6eaea57 --- /dev/null +++ b/_posts/2008-01-09-set-your-user-name-email-and-github-token.markdown @@ -0,0 +1,12 @@ +--- +layout: default +title: Set your user name, email and GitHub token +description: Configure your local git installation so that commits are linked to your GitHub account +categories: beginner popular +--- + +

This guide covers basic git settings you should set before making any commits.

+ +

Please note that config changes will only affect future commits. Existing commits will retain the info they were committed with. Also, the environment variables GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL will override git-config settings if they are defined.

+ +{% include email_setup.markdown %} diff --git a/_posts/2008-02-01-change-author-info.markdown b/_posts/2008-02-01-change-author-info.markdown new file mode 100644 index 0000000..045b056 --- /dev/null +++ b/_posts/2008-02-01-change-author-info.markdown @@ -0,0 +1,38 @@ +--- +layout: default +title: Change author info +description: How to modify author info in your repo's history +categories: intermediate +--- + +

If you need to modify the author info in your repo's history, you can do so with this script.

+ +

Big bold warning This action is destructive to your repo's history. It's best to do this on a clone, just in case. Also beware that this should not be performed on a repo that has been shared with others. Use at your own risk.

+ +{% highlight bash %} +#!/bin/sh + +git filter-branch --env-filter ' + +an="$GIT_AUTHOR_NAME" +am="$GIT_AUTHOR_EMAIL" +cn="$GIT_COMMITTER_NAME" +cm="$GIT_COMMITTER_EMAIL" + +if [ "$GIT_COMMITTER_EMAIL" = "your@email.to.match" ] +then + cn="Your New Committer Name" + cm="Your New Committer Email" +fi +if [ "$GIT_AUTHOR_EMAIL" = "your@email.to.match" ] +then + an="Your New Author Name" + am="Your New Author Email" +fi + +export GIT_AUTHOR_NAME="$an" +export GIT_AUTHOR_EMAIL="$am" +export GIT_COMMITTER_NAME="$cn" +export GIT_COMMITTER_EMAIL="$cm" +' +{% endhighlight %} \ No newline at end of file diff --git a/_posts/2008-02-02-deploy-keys.markdown b/_posts/2008-02-02-deploy-keys.markdown new file mode 100644 index 0000000..c5f6812 --- /dev/null +++ b/_posts/2008-02-02-deploy-keys.markdown @@ -0,0 +1,54 @@ +--- +layout: default +title: Deploy keys +description: Do you need a deploy key? +categories: intermediate +--- + +

Deploy keys are a handy yet misunderstood feature here on github. This guide will explain when and how to use them instead of normal user keys.

+ +##Do you even need a deploy key? + +If your deploy process involves sshing into the server you are deploying to, you probably **do not** need to use deploy keys. Instead, you should use ssh-agent forwarding to temporarily allow the server to use your local ssh keys. Not only is this method easier to maintain, since you don't have any extra keys, but it's also more secure as the server never has keys saved to disk in case of a compromise. As always, you should use a [strong passphrase](/working-with-key-passphrases/) on your keys and let ssh-agent manage them for you. + +If your deploy process is remotly triggered and you do not log in to the deploying server via ssh, then you might need deploy keys. Read on to find out if you do. + +##What are deploy keys? + +Deploy keys are ssh keys just like the ones you attach to your account to allow you to push to and pull from your repos. The only difference is that deploy keys are designed to allow access to a single private repo. This will allow your staging or production server to pull in from your repo, most likely using a deploy tool like [Capistrano](http://www.capify.org/). + +Remember, ssh keys are unique, you cannot use the same key on two repos, or on a repo and a user account. + +##When should I use a deploy key? + +Simple, when you have a server that needs pull access to a single private repo. + +###I'm working with public repos, do I still need deploy keys? + +No! You can simply use the public clone URL for the project. + +###My server needs access to many private repos, how do I handle this? + +The simplest way is to add your server's key to the account of the repo owner. This will allow the server access to any private repo that user owns or is a collaborator on. + +If you don't want your deploy server to have access to every repo, you can make an account specifically for the server, attach its key to the account, and add that account as a collaborator to any repo you do want access to. + +## How do I add my deploy key? + +To add your deploy key, you first have to click on one of your repos. Once you've done that: + +1. In your repo, click the "admin" button. + + ![In your repo, click the "admin" button.](/images/deploy_1.jpg) + +2. Click on "deploy keys" + + ![Click on "deploy keys"](/images/deploy_2.jpg) + +3. Click "Add another deploy key" + + ![Click "Add another deploy key"](/images/deploy_3.jpg) + +4. Fill in your info and click "Add key" + + ![Fill in your info and click "Add key"](/images/deploy_4.jpg) \ No newline at end of file diff --git a/_posts/2008-02-03-ignore-files.markdown b/_posts/2008-02-03-ignore-files.markdown new file mode 100644 index 0000000..cc81daa --- /dev/null +++ b/_posts/2008-02-03-ignore-files.markdown @@ -0,0 +1,72 @@ +--- +layout: default +title: Ignore files +description: How to tell git to ignore files +categories: intermediate +--- + +

From time to time there are files you don't want git to track. There are a few methods of telling git what files to ignore.

+ +.gitignore +---------- + +If you create a file in your repo named `.gitignore` git will use its rules when looking at files to commit. Note that git will **not** ignore a file that was already tracked before a rule was added to this file to ignore it. In such a case the file must be un-tracked, usually with `git rm --cached filename` + +This file can be committed into the repo, thus sharing the rule list with any other users that clone the repo. + +Note that you can create a `.gitignore` in any subpath to have its rules applied at that path. Sometimes an empty `.gitignore` file is used as a placeholder for an empty path, for example to force git to generate a `log/` path for your development environment to use. + +Global .gitignore +------------- + +A global .gitignore file can also be used by adding one to your global git config. For example, you might create the file `~/.gitignore_global` and add some rules to it. To add this to your config, run `git config --global core.excludesfile ~/.gitignore_global` + +Some good rules to add to this file: + +
+# Compiled source #
+###################
+*.com
+*.class
+*.dll
+*.exe
+*.o
+*.so
+
+# Packages #
+############
+# it's better to unpack these files and commit the raw source
+# git has its own built in compression methods
+*.7z
+*.dmg
+*.gz
+*.iso
+*.jar
+*.rar
+*.tar
+*.zip
+
+# Logs and databases #
+######################
+*.log
+*.sql
+*.sqlite
+
+# OS generated files #
+######################
+.DS_Store?
+ehthumbs.db
+Icon?
+Thumbs.db
+
+ +Repo exclude +----------- + +Local per-repo rules can be added to the `.git/info/exclude` file in your repo. These rules *are not committed* with the repo so they are not shared with others. This method can be used for locally-generated files that you don't expect other users to generate, like files created by your editor. + +Links +----- + +* [Pro Git](http://progit.org/book/ch2-2.html) +* [gitignore man page](http://www.kernel.org/pub//software/scm/git/docs/gitignore.html) diff --git a/_posts/2008-02-04-import-from-subversion.markdown b/_posts/2008-02-04-import-from-subversion.markdown new file mode 100644 index 0000000..e50ee0a --- /dev/null +++ b/_posts/2008-02-04-import-from-subversion.markdown @@ -0,0 +1,55 @@ +--- +layout: default +title: Import from Subversion +categories: intermediate +--- + +

GitHub can directly import SVN projects. All you need is the repository URL. After creating a repo you can pick "Import a Subversion Repository" option:

+ +![](http://img.skitch.com/20100603-fq9q2b9qu7it37i2axhhntanqc.png) + +Please note that imports that take more than an hour or non-standard repository file structures may fail. This is a one-time import, it will not sync with future commits in the SVN repo. For either of these cases, you'll need to manually import the repo. + +Manual import +------------- + +### svn2git + +[svn2git](http://github.com/nirvdrum/svn2git) is designed to provide a complete svn import. Unlike git-svn, it will create proper git tags from your svn "tags". + +### git-svn + +[git-svn](http://www.kernel.org/pub/software/scm/git/docs/git-svn.html) can be used to import as well. Note that there may be issues if you have branches or tags (they won't be imported over). If you only have a trunk, like many svn repositories, this method should work for you without issue. + +First, be sure to [create your repository on GitHub](http://github.com/repositories/new) + +
$ git svn clone -s SVN_REPO_URL LOCAL_DIR
+$ cd LOCAL_DIR
+$ git remote add origin git@github.com:GITHUB_USERNAME/REPO_NAME.git
+$ git push origin master
+ +Note that the `-s` switch implies that your svn repo is set up with the standard branches/tags/trunk structure. + +git-svn adds a note to every commit message it copies over from svn. To get rid of that note, add `--no-metadata` to the command. + +You can pull in later commits by running `git-svn rebase` from within your repo. If you ever lose your local copy, just run the import again with the same settings and you'll get another working directory with all the necessary git-svn settings saved. + +#### Author mapping + +When migrating a Subversion repository to Git, you can map the Subversion users to Git users. You have to create an authors file which contains the mappings: + + tekkub = Tekkub + +The format is `svnuser = gituser_name `. To automatically generate an authors file, check out [this guide](http://technicalpickles.com/posts/creating-a-svn-authorsfile-when-migrating-from-subversion-to-git/). + +Once your authors file is complete, clone the subversion repository with the authors file: + +
$ git svn --authors-file=path/to/authors_file clone SVN_REPO_URL LOCAL_DIR
+ +Other guides +------------ + +* [Guide by Yuval Kogman](http://blog.woobling.org/2009/06/git-svn-abandon.html) +* [Guide by John Goulah](http://blog.johngoulah.com/2009/11/migrating-svn-to-git) +* [Guide by Jon Maddox](http://www.simplisticcomplexity.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/) -- doesn't deal with branches +* [Guide by Bob McWhirter](http://www.fnokd.com/2008/08/20/mirroring-svn-repository-to-github) -- doesn't deal with branches diff --git a/_posts/2008-02-05-install-git-html-help.markdown b/_posts/2008-02-05-install-git-html-help.markdown new file mode 100644 index 0000000..579096b --- /dev/null +++ b/_posts/2008-02-05-install-git-html-help.markdown @@ -0,0 +1,40 @@ +--- +layout: default +title: Install Git HTML help +description: How to install the local git HTML help files +categories: intermediate +--- + +

This guide will help you install the local git HTML help files and set git to use them by default instead of the man pages.

+ +

Most git installations will install man files for help, but not the HTML help files (the same files seen on git's online documentation). Installing these help files is a fairly simple process.

+ +Windows +------- + +[Msysgit](http://code.google.com/p/msysgit/) installs and sets the HTML help files as the default automatically. You don't need to do anything! + +OSX +--- + +To install web docs we simply need to clone the main git repo to the correct path and check out the "html" branch. Your documentation path may be different, pay attention to the output of `git help --web commit` for where your git is set to look for the HTML files. + +
+$ git help --web commit
+fatal: '/usr/local/git/share/doc/git-doc': not a documentation directory.
+
+$ sudo mkdir -p /usr/local/git/share/doc
+$ cd /usr/local/git/share/doc
+$ sudo git clone git://git.kernel.org/pub/scm/git/git.git git-doc --branch html
+
+ +To verify that the web docs now work, run `git help --web commit`. If your browser launches then you're good to go. You can now set git to default to the web docs by running `git config --global help.format web` + +### Updating the docs + +Updating is a simple matter of pulling: + +
+$ cd /usr/local/git/share/doc
+$ sudo git pull
+
diff --git a/_posts/2008-02-06-manage-multiple-clients.markdown b/_posts/2008-02-06-manage-multiple-clients.markdown new file mode 100644 index 0000000..aba1ce4 --- /dev/null +++ b/_posts/2008-02-06-manage-multiple-clients.markdown @@ -0,0 +1,33 @@ +--- +layout: default +title: Manage multiple clients +description: How to manage multiple clients and their repositories +categories: intermediate +--- + +

Are you a freelance developer working on multiple projects for multiple clients, and want to manage them here on GitHub? Never fear, this guide will detail the most common solutions to this problem.

+ +One account, multiple collaborators +----------------------------------- + +This design lets you retain control over the repos, but still gives your clients access to them. + +This is the simplest (and cheapest) approach. Simply create one account with a plan that provides enough private repos to cover all your projects. If your client needs access to the source code, have them create a free account. You can then add their free account as a collaborator on the projects you wish for them to have access to. + +If you wish, you can even bill your clients for the cost of your account, and maintaining their repos on it! + +Multiple accounts, one collaborator +----------------------------------- + +This design gives the control over the repos (and the bill) to your client, but still allows you to push into all your clients' repos from a single account. + +With this design, have your clients each open their own paid account and create empty repos for each project. Add your account to the repos as a collaborator. You can now push to their repos as if they were your own! + +Multiple accounts, no collaborators +----------------------------------- + +__This is by far the most complicated setup, and should be avoided if at all possible.__ + +If, for whatever reason, you *must* push to each client's repos using _their_ account, this is the setup you will have to use. + +First, generate a second keypair to use for your second account. To create this key follow [this guide](/key-setup-redirect), but specify a path for the key. If you do not specify a path you may overwrite your existing key. For example, you could use `~/.ssh/id_rsa_client`. Once the key has been created, add the new public key to the client's account on GitHub. To configure your local settings, see [this guide](/multiple-keys). diff --git a/_posts/2008-02-07-multiple-ssh-keys.markdown b/_posts/2008-02-07-multiple-ssh-keys.markdown new file mode 100644 index 0000000..827d1ea --- /dev/null +++ b/_posts/2008-02-07-multiple-ssh-keys.markdown @@ -0,0 +1,49 @@ +--- +layout: default +title: Multiple SSH keys +description: How to push using different SSH keys on the same computer +categories: intermediate +--- + +

This guide assumes you have already created two keypairs and attached them to different GitHub user accounts. For this example we will be using ~/.ssh/id_rsa attached to the user joe and ~/.ssh/id_rsa_client attached to the user client.

+ +Adding your keys to SSH +======================= + +The first keypair, `~/.ssh/id_rsa`, uses a default name, so we don't need to do anything special to make SSH use this pair. The second pair, however, is not a default name. Therefore, we need to tell ssh about it so that it can use it: + +
ssh-add ~/.ssh/id_rsa_client
+ +If the keypair has a passphrase on it (it should!), `ssh-add` will ask you to enter the passphrase. After you have done this, the key will be available from ssh-agent so you won't have to re-enter the passphrase every time you use it. + +Configuring SSH +=============== + +Once SSH has access to both keys, you need to tell it which key to use for which server. In most cases you can assume that SSH will fall back to `~/.ssh/id_rsa` by default, but we're going to force it anyway. To begin, open `~/.ssh/config` in your favorite editor. + +{% highlight bash %} +# Default GitHub user (joe) +Host github.com + HostName github.com + User git + IdentityFile /Users/joe/.ssh/id_rsa + +# Client user (client) +Host github-client + HostName github.com + User git + IdentityFile /Users/joe/.ssh/id_rsa_client +{% endhighlight %} + +In short what this does is tells SSH to use the client key when connecting to the server github-client, which is really github.com. + +Using the second key +==================== + +From here on, everything is the same as everyday use except for one component, the domain name. When working on a repo owned by the primary account, we would use a command like: + +
git clone git@github.com:joe/my_repo.git
+ +When we want to use the second account's key, however, we need to change the domain name. Doing so will use the settings in `~/.ssh/config` to override the defaults. + +
git clone git@github-client:client/his_repo.git
diff --git a/_posts/2008-02-08-rebase.markdown b/_posts/2008-02-08-rebase.markdown new file mode 100644 index 0000000..1f4e628 --- /dev/null +++ b/_posts/2008-02-08-rebase.markdown @@ -0,0 +1,154 @@ +--- +layout: default +title: Rebase +description: Using git rebase to restructure a branch +categories: intermediate +--- + +

One often overlooked feature of git is the git rebase command. Rebase allows you to easily change a series of commits, reordering, editing, or squashing commits together into a single commit.

+ +It is considered bad practice to rebase commits which you have already pushed to a remote repo. Doing so may invoke the wrath of the git gods... you have been warned. + +So, you've cloned a repository, and hacked away at it; separated it into logical chunks, and it's now ready to submit! + +So you send your patch series, or publish your branch, and ask for a pull, but a quick review reveals that there are some errors in these patches! + +Now, the maintainer may send these patches back to you, and ask you to fix these, this guide shows several ways on how this can be accomplished. + +Before you start, make sure you have a clean working tree (i.e. no modified files). + +Using rebase -i +--------------- + +This is the most general (and easiest) way to edit history. + +### Invocation + +The syntax is: + +
git rebase -i last_good_commit
+ +For example, to rebase all the commits from master to the current branch's head: + +
git rebase -i master
+ +Another common practice is to rebase the last few commits in your current branch. If our branch is named fix_stuff and we want to rebase the last 5 commits we can run: + +
git rebase -i fix_stuff~5
+ +Running the command with the `-i` flag will invoke your text editor with a file detailing the commits that will be rebased. This will also list the command available: + +
+pick 1fc6c95 Patch A
+pick 6b2481b Patch B
+pick dd1475d something I want to split
+pick fa39187 something to add to patch A
+pick 7b36971 something to move before patch B
+
+# Rebase 41a72e6..7b36971 onto 41a72e6
+#
+# Commands:
+#  p, pick = use commit
+#  e, edit = use commit, but stop for amending
+#  s, squash = use commit, but meld into previous commit
+#
+# If you remove a line here THAT COMMIT WILL BE LOST.
+# However, if you remove everything, the rebase will be aborted.
+#
+
+ +At this point you can edit the file to change the order of the commits. There are three commands available: + +### Pick + +Pick is used to include a commit. By default you will be given a list of the commits you chose to rebase, in order of oldest (top) to newest (bottom). Rearranging the order of the pick commands will change the order of the commits when you begin the rebase. + +### Edit + +Using the edit command on a commit will cause rebase to pick the commit and pause. During this pause you can amend the commit, adding to or removing from it. You can also make more commits before you continue the rebase, this allows you to split a large commit into smaller ones. You should always ensure that your working tree and index are clean before you resume the rebase. + +### Squash + +This command lets you combine two or more commits into a single commit. When used the commit will be picked and then amended into the commit above it. Git will then pause the rebase and open your text editor with the commit messages from both commits. After you have edited the message to your satisfaction save the file and close the editor. Git will resume the rebase. + +### Example + +In this rebase we will cover all 3 commands. We start our rebase with `git rebase -i master~5` and are presented with this file in our editor: + +
+pick 1fc6c95 Patch A
+pick 6b2481b Patch B
+pick dd1475d something I want to split
+pick fa39187 something to add to patch A
+pick 7b36971 something to move before patch B
+
+# Rebase 41a72e6..7b36971 onto 41a72e6
+#
+# Commands:
+#  p, pick = use commit
+#  e, edit = use commit, but stop for amending
+#  s, squash = use commit, but meld into previous commit
+#
+# If you remove a line here THAT COMMIT WILL BE LOST.
+# However, if you remove everything, the rebase will be aborted.
+#
+
+ +There are a few things we want to do here, we want to move the last two commits up before the "Patch B" commit. One of those commits will be squashed into the "Patch A" commit. Finally we want to edit the last commit to split it into two commits. We'll change the file as such: + +
+pick 1fc6c95 Patch A
+squash fa39187 something to add to patch A
+pick 7b36971 something to move before patch B
+pick 6b2481b Patch B
+edit dd1475d something I want to split
+
+ +Now we save and close the editor to begin the rebase. Since the first operation is a squash our editor opens: + +
+# This is a combination of two commits.
+# The first commit's message is:
+
+Patch A
+
+# This is the 2nd commit message:
+
+something to add to patch A
+
+# Please enter the commit message for your changes. Lines starting
+# with '#' will be ignored, and an empty message aborts the commit.
+# Not currently on any branch.
+# Changes to be committed:
+#   (use "git reset HEAD <file>..." to unstage)
+#
+#	modified:   a
+#
+
+ +As usual, edit the file as we wish, save, close the editor. The rebase will proceed until it gets to the edit operation, where it tells us: + +
+You can amend the commit now, with
+
+        git commit --amend
+
+Once you are satisfied with your changes, run
+
+        git rebase --continue
+
+ +At this point we would edit the files we need, do a `git commit --amend`, make our second commit, and ensure that our working tree and index are clean. Now we can tell git to complete the rebase with `git rebase --continue`. You might wish to use `git-gui` for amending commits like this, it can make things much easier by visualizing the changes you are committing. + +Notes +----- + +* If others have branched off of the work you have doing, do _not_ modify any of the commits. The rule in Git is that if you have work that people are working off of, you will make it hell for them if you change it. Rebasing and amending are only for commits where you *know* no one is working off of. +* In the upcoming 1.5.6, there will be new rebase -i commands "tag", "merge", and "reset", as well. + +References +---------- + +* [Git user manual - Cleaning up history](http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#cleaning-up-history) +* [git-rebase documentation](http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html) +* [git-commit documentation](http://www.kernel.org/pub/software/scm/git/docs/git-commit.html) diff --git a/_posts/2008-02-09-remotes.markdown b/_posts/2008-02-09-remotes.markdown new file mode 100644 index 0000000..832c307 --- /dev/null +++ b/_posts/2008-02-09-remotes.markdown @@ -0,0 +1,98 @@ +--- +layout: default +title: Remotes +description: Pushing, fetching, merging and deleting remote branches +categories: intermediate +--- + +

This guide will cover all the basic day-to-day commands you will use with git to interact with remote repos. For push operations you can only interact with repos you own or are a collaborator on. To gain access to a public repo, check out the forking guide.

+ +Managing remotes +---------------- + +Before you can perform any remote operations it is usually best to set up remotes in your repo. If you cloned a repo git will create a remote named "origin" automatically. There are a few commands to help you manage these remotes: + +### add + +This one is pretty straightforward, `git remote add test git://github.com/user/test.git` will create a new remote named "test" pointing to `git://github.com/user/test.git`. If we add a `-f` flag on the end, git will also fetch the remote for us. + +### rename + +Rename a remote and its remote-tracking branches... `git remote rename test example` will rename the "test" remote to "example". + +### rm + +Another basic command, `git remote rm example` will delete the "example" remote and any remote-tracking branches we've fetched. + +### Changing a remote's URL + +There is no direct command to change a remote's URL, so you will usually run `git remote rm` followed by `git remote add` to change a URL. You can also edit the repo's `.git/config` file directly to change the URL without re-fetching the remote. + +Fetching +-------- + +When working with other users' repos there are four basic commands you will need, `git clone`, `git fetch`, `git pull` and `git remote prune`. + +### clone + +To grab a full copy of another user's repo when you do not have a local repo already, you will use `git clone URL`. For public repos, the URL can be a read-only URL like `git://github.com/user/repo.git` or an HTTP read-only URL like `http://github.com/user/repo.git`. For public repos you own or are a collaborator on, and all private repos, you must use a private ssh url like `git@github.com:user/repo.git`. You can find each of the URLs available to you in the header of the repo page: + +![header](http://img.skitch.com/20100201-e6dmj54pgmw6wq7314jtbej31k.jpg) + +Running `git clone URL` will automatically create a new subfolder, fetch the contents of the repo into this subfolder, then create and checkout the default branch (usually "master"). If there are other branches on the remote you will need to create a local branch to work in, for example `git checkout -b fix_stuff origin/fix_stuff` + +### fetch + +If you already have a local repo with a remote set up, you can grab all branches and tags for the remote using `git fetch REMOTENAME`. By default, `git clone` will make a remote named "origin" pointing to the URL you cloned from. Fetch does not make any changes to local branches, so you will need to merge remote branches to bring those changes in. + +### pull + +Similar to `git fetch`, you can use `git pull REMOTENAME BRANCHNAME` to fetch a specific branch and merge it into your current local branch. For on-time pulls from other users' repos you can use a URL instead of a remote name. This will pull from that URL without adding a remote. + +Because pull performs a merge you should ensure that your working tree and index are clean before running the command. If you run into a merge conflict you cannot resolve or decide to abort the merge, you can use `git reset ORIG_HEAD --hard` to take the branch back to the commit it was on before you pulled. + +### prune + +Sometimes branches are deleted from a remote repo. By default, `git fetch` will not remove any remote-tracking branches that have been deleted on the remote repo. Running `git remote prune REMOTENAME` will delete these tracking branches. + +Pushing +------- + +At some point you're going to want to publish commits from your repo into a remote for other users to fetch. This process is fairly straightforward. First you need a repo on github you can push to. Either create a new repo, gain collaborator permissions on someone else's repo, or [fork](/forking) someone else's repo. You can only push to an ssh URL like `git@github.com:user/repo.git`. If you cloned another repo with a read-only URL you can add a second remote for your URL or remove or rename the existing remote. See the [git remote manpage](http://www.kernel.org/pub/software/scm/git/docs/git-remote.html) for more information on changing remotes. + +### Pushing a branch + +To push a local branch to an established remote, you simply need to use `git push REMOTENAME BRANCHNAME` If you don't want to use the same name on the remote branch you can use `git push REMOTENAME LOCALBRANCHNAME:REMOTEBRANCHNAME`. + +#### Dealing with "non-fast-forward" errors + +From time to time you may encounter this error while pushing: + +
+$ git push origin master
+To ../remote/
+ ! [rejected]        master -> master (non-fast forward)
+error: failed to push some refs to '../remote/'
+To prevent you from losing history, non-fast-forward updates were rejected
+Merge the remote changes before pushing again.  See the 'non-fast forward'
+section of 'git push --help' for details.
+
+ +This error can be a bit overwhelming at first, do not fear. Simply put, git cannot make the change on the remote without losing commits, so it refuses the push. Usually this is caused by another user pushing to the same branch. You can remedy this by fetching and merging the remote branch, or using pull to perform both at once. + +In other cases this error is a result of destructive changes made locally by using commands like `git commit --amend` or `git rebase`. While you can override the remote by adding `--force` to the push command, you should only do so if you are absolutely certain this is what you want to do. Force-pushes can cause issues for other users that have fetched the remote branch, and is considered bad practice. When in doubt, don't force-push. + +### Pushing tags + +By default, push will only send the ref you specify. To push a single tag you can simply use `git push REMOTENAME TAGNAME`. To push all tags while pushing another branch, you can use `git push REMOTENAME BRANCHNAME --tags`. + +### Deleting a remote branch or tag + +This command is a bit arcane at first glance... `git push REMOTENAME :BRANCHNAME`. If you look at the advanced push syntax above it should make a bit more sense. You are literally telling git "push _nothing_ into BRANCHNAME on REMOTENAME". + +Links +----- + +* [Pro Git](http://progit.org/book/ch2-5.html) +* [git remote man page](http://www.kernel.org/pub/software/scm/git/docs/git-remote.html) +* [Git user's manual](http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#sharing-development) \ No newline at end of file diff --git a/_posts/2008-02-10-ssh-key-passphrases.textile b/_posts/2008-02-10-ssh-key-passphrases.textile new file mode 100644 index 0000000..c673220 --- /dev/null +++ b/_posts/2008-02-10-ssh-key-passphrases.textile @@ -0,0 +1,125 @@ +--- +layout: default +title: SSH key passphrases +description: SSH key passphrases, why you should use them, and how to avoid re-entering them +categories: intermediate +--- + +

This guide will step you through the process of securing your ssh keys while avoiding re-entry of your passphrase every time you use the key.

+ +h2. Why do I need a passphrase? + +Passwords aren't very secure, you already know this. If you use one that's easy to remember, it's easier to guess or brute-force. If you use one that's random it's hard to remember, and thus you're more inclined to write the password down. Both of these are Very Bad Things™. This is why you're using ssh keys. + +But using a key without a passphrase is basically the same as writing down that random password in a file on your computer. Anyone who gains access to your drive has gained access to every system you use that key with. This is also a Very Bad Thing™. The solution is obvious, add a passphrase. + +h3. But I don't want to enter a long passphrase every time I use the key! + +Neither do I! Thankfully, there's a nifty little tool called @ssh-agent@ that can save your passphrase securely so you don't have to re-enter it. If you're on OSX Leopard or later your keys can be saved in the system's keychain to make your life even easier. Most linux installations will automatically start @ssh-agent@ for you when you log in. + +h2. Adding or changing a passphrase + +Passphrases can be added to an existing key or changed without regenerating the keypair very easily: + +
$ ssh-keygen -p
+Enter file in which the key is (/Users/tekkub/.ssh/id_rsa):
+Key has comment '/Users/tekkub/.ssh/id_rsa'
+Enter new passphrase (empty for no passphrase):
+Enter same passphrase again:
+Your identification has been saved with the new passphrase.
+ +If your key already has a passphrase, you will be prompted to enter it before you can change to a new passphrase. + +h2. Auto-launching ssh-agent on msysgit + +You can run @ssh-agent@ automatically when you open bash by adding the following to your @~/.profile@ or @~/.bashrc@ file: + +{% highlight bash %} +SSH_ENV="$HOME/.ssh/environment" + +# start the ssh-agent +function start_agent { + echo "Initializing new SSH agent..." + # spawn ssh-agent + ssh-agent | sed 's/^echo/#echo/' > "$SSH_ENV" + echo succeeded + chmod 600 "$SSH_ENV" + . "$SSH_ENV" > /dev/null + ssh-add +} + +# test for identities +function test_identities { + # test whether standard identities have been added to the agent already + ssh-add -l | grep "The agent has no identities" > /dev/null + if [ $? -eq 0 ]; then + ssh-add + # $SSH_AUTH_SOCK broken so we start a new proper agent + if [ $? -eq 2 ];then + start_agent + fi + fi +} + +# check for running ssh-agent with proper $SSH_AGENT_PID +if [ -n "$SSH_AGENT_PID" ]; then + ps -ef | grep "$SSH_AGENT_PID" | grep ssh-agent > /dev/null + if [ $? -eq 0 ]; then + test_identities + fi +# if $SSH_AGENT_PID is not properly set, we might be able to load one from +# $SSH_ENV +else + if [ -f "$SSH_ENV" ]; then + . "$SSH_ENV" > /dev/null + fi + ps -ef | grep "$SSH_AGENT_PID" | grep ssh-agent > /dev/null + if [ $? -eq 0 ]; then + test_identities + else + start_agent + fi +fi +{% endhighlight %} + +p(. *Note:* If you don't use the default key names, or store your keys in a different path, you will need to add the path to the @/usr/bin/ssh-add@ line so that ssh knows where to find your key. + +Now when you first run git bash, you will be prompted for your passphrase: + +
Initializing new SSH agent...
+succeeded
+Enter passphrase for /c/Users/Tekkub/.ssh/id_rsa:
+Identity added: /c/Users/Tekkub/.ssh/id_rsa (/c/Users/Tekkub/.ssh/id_rsa)
+Welcome to Git (version 1.6.0.2-preview20080923)
+
+
+Run 'git help git' to display the help index.
+Run 'git help ' to display help for specific commands.
+[Tekkub@KAKU: ~ master]$
+ +The process will continue to run until you log out, shutdown or kill ssh-agent. To kill the process, find its PID with @ps@ then call @kill @: + +
[Tekkub@KAKU: ~ master]$ ps
+        PID    PPID    PGID     WINPID  TTY  UID    STIME COMMAND
+       3796       1    3796       3796    ?  500 18:07:43 /bin/ssh-agent
+       2780       1    2780       2780  con  500 18:10:50 /bin/bash
+       3400    2780    3400        784  con  500 18:13:31 /bin/ps
+[Tekkub@KAKU: ~ master]$ kill 3796
+ +p(. This section was written with help from "this post":http://www.cygwin.com/ml/cygwin/2001-06/msg00537.html. + +h2. Mac OSX Keychain + +If you are on OSX Leopard or later, ssh-agent is run automatically for you. It will also integrate with the keychain, so you can unlock your keys with it. This has some major advantages over a command-line based setup like protecting your input from being copied or spied upon by universal access or low-level keyboard routines. + +The default key files (@.ssh/id_rsa@, @.ssh/id_dsa@ and @.ssh/identity@) should be handled automatically. If you have a key with a different name, you can add it with @ssh-add path/to/my_key@ + +

Make sure that you're using the default OS X ssh-add command and not one installed by macports or some other external source.

+ +When you first try to use the key you will be prompted to enter your passphrase: + +!/images/SecurityAgent.jpg(Keychain prompt)! + +If you choose to save the passphrase with your keychain, you won't have to enter it again. Instead you'll simply need to unlock your keychain. + +

This section was written with help from "this guide":http://www.dribin.org/dave/blog/archives/2007/11/28/ssh_agent_leopard/. If you would like to use more paranoid keychain settings like locking after sleep, check out "this guide":http://www.dribin.org/dave/blog/archives/2007/11/28/securing_ssh_agent/.

diff --git a/_posts/2008-02-15-set-up-git-redirect.markdown b/_posts/2008-02-15-set-up-git-redirect.markdown deleted file mode 100644 index afecf45..0000000 --- a/_posts/2008-02-15-set-up-git-redirect.markdown +++ /dev/null @@ -1,9 +0,0 @@ ---- -layout: os_redirect -title: Set Up Git -description: A quick guide to help you get started with Git -categories: beginner -redirect_win: /win-set-up-git -redirect_mac: /mac-set-up-git -redirect_linux: /linux-set-up-git ---- diff --git a/_posts/2008-02-16-create-a-repo.markdown b/_posts/2008-02-16-create-a-repo.markdown deleted file mode 100644 index f10d79e..0000000 --- a/_posts/2008-02-16-create-a-repo.markdown +++ /dev/null @@ -1,113 +0,0 @@ ---- -layout: default -title: Create A Repo -description: Create the place where your commits will be stored -categories: beginner ---- - -If you’ve found yourself on this page, we’re assuming you’re brand new to Git and GitHub. This guide will walk you through the basics and explain a little bit about how everything works along the way. - -##First: Create A Repo - -Every time you make a commit with Git, it is stored in a repository (a.k.a. “repo”). To put your project up on GitHub, you’ll need to have a GitHub repository for it to live in. - -
-

More about repositories

-
-

- Git stores all of your project files in a repository. If you are able to view hidden files on your system, you’ll see a subdirectory called “.git” in the project directory where you run git init. This is where Git stores all of your commits, as well as everything else it needs. In addition to your local, you can also have remote repositories (like GitHub repos). Remote repositories are the same as your local repo, but stored on a different server or computer for easy collaboration, backup, and general awesomeness. -

-
-
- -1. Create a new repo - - Click [New Repository](https://github.com/repositories/new). - - Click “New Repository - - Fill out the information on this page. When you’re done, click “Create Repository.” - - Fill in the info - - Congratulations! You have successfully created your first repo! - -##Next: Create a README for your repo. - -While a README isn’t a required part of a GitHub repo, it is a good idea to have one. READMEs are a great place to describe your project or add some documentation such as how to install or use your project. - -
-

More about READMEs

-
-

- If you include a file with the filename “README” in your repo, it will automatically be shown on your repo’s front page. Pretty cool, huh? GitHub supports a number of different README formats. The one in this tutorial will result in a basic text file but other formats like .markdown or .textile can be used to render HTML content like links and headers. For more info about the supported markup formats, check out the github markup repo. -

-
-
- -1. Create the README file - - In the prompt, type the following code: - - 
-	$ mkdir ~/Hello-WorldCreates a directory for your project called "Hello-World" in your user directory
-	$ cd ~/Hello-WorldChanges the current working directory to your newly created directory
-	$ git initSets up the necessary Git files
-	Initialized empty Git repository in /Users/your_user_directory/Hello-World/.git/
-	$ touch READMECreates a file called “README” in your Hello-World directory
-
- - Open the new README file found in your Hello-World directory in a text editor and add the text “Hello World!” When you are finished, save and close the file. - -2. Commit your README - - Now that you have your README set up, it“s time to commit it. A commit is essentially a snapshot of all the files in your project at a particular point in time. In the prompt, type the following code: - -
-

More about commits

-
-

- Think of a commit as a snapshot of your project —code, files, everything — at a particular point in time. More accurately, after your first commit, each subsequent commit is only a snapshot of your changes. For code files, this means it only takes a snapshot of the lines of code that have changed. For everything else like music or image files, it saves a new copy of the file. -

-
-
- - 
-	$ git add READMEStages your README file, adding it to the list of files to be committed
-	$ git commit -m 'first commit'Commits your files, adding the message "first commit"
-
- - The code above executes actions locally, meaning you still haven’t done anything on GitHub yet. To connect your local repository to your GitHub account, you will need to set a remote for your repo and push your commits to it: - -
-

More about remotes

-
-

- A remote is a repo stored on another computer, in this case on GitHub’s server. It is standard practice (and also the default in some cases) to give the name origin to the remote that points to your main offsite repo (for example, your GitHub repo). -

-

- Git supports multiple remotes. This is commonly used when forking a repo. -

-
-
- - - 
-	$ git remote add origin git@github.com:username/Hello-World.gitSets the origin for the Hello-World repo
-	$ git push origin masterSends your commit to GitHub
-
- - Now if you look at your repository on GitHub, you will see your README has been added to it. - - Your README has been created - -##Lastly: Celebrate - -Congratulations! You have now created a repository on GitHub, created a README, committed it, and pushed it to GitHub. What do you want to do next? - -
    -
  1. Set Up Git
    2. -
  2. Create A Repository
    3. -
  3. Fork A Repository
    4. -
  4. Be Social
    5. -
\ No newline at end of file diff --git a/_posts/2008-03-01-deploy-capistrano.textile b/_posts/2008-03-01-deploy-capistrano.textile new file mode 100644 index 0000000..8d54682 --- /dev/null +++ b/_posts/2008-03-01-deploy-capistrano.textile @@ -0,0 +1,89 @@ +--- +layout: default +title: Deploy with Capistrano +description: How to set up capistrano to pull from a GitHub repo +categories: advanced +--- + +To prepare your project for "Capistrano":http://www.capify.org/, go into the root directory of that project and run @capify@: + +
+$ cd my_project
+$ capify .
+
+ +h2. Generate Public Key + +It would probably be a good idea to add a special user on your server(s) specifically for deployment. Once created, make sure to generate a public key for the server and add it to your github account. You may also want to add your personal public key to this new user's @~/.ssh/authorized_keys@ to ease deployment. + +For more help with deploy keys, see "this guide":/deploy-keys. + +h2. Settings + +Here are the 5 most notable Capistrano config options (found in deploy.rb): + +{% highlight ruby %} +default_run_options[:pty] = true # Must be set for the password prompt from git to work +set :repository, "git@github.com:vanpelt/rails-app.git" # Your clone URL +set :scm, "git" +set :user, "deployer" # The server's user for deploys +set :scm_passphrase, "p@ssw0rd" # The deploy user's password +{% endhighlight %} + +h3. Agent Forwarding + +If you're using your own private keys for git you might want to tell Capistrano to use agent forwarding with this command. Agent forwarding can make key management much simpler as it uses your local keys instead of keys installed on the server. + +{% highlight ruby %}ssh_options[:forward_agent] = true{% endhighlight %} + +h3. Set Branch + +You need to tell cap the branch to checkout during deployment: + +{% highlight ruby %}set :branch, "master"{% endhighlight %} + +Older versions of cap need the full branch name: + +{% highlight ruby %}set :branch, "origin/master"{% endhighlight %} + +Older versions of git (e.g. 1.4.4.2) don't support @git checkout -q@, this will cause your deployment to fail. To fix either upgrade git or: + +{% highlight ruby %}set :scm_verbose, true{% endhighlight %} + +h3. Remote Cache + +In most cases you want to use this option, otherwise each deploy will do a full repository clone every time. + +{% highlight ruby %}set :deploy_via, :remote_cache{% endhighlight %} + +Remote caching will keep a local git repo on the server you're deploying to and simply run a fetch from that rather than an entire clone. This is probably the best option as it will only fetch the changes since the last. + +h3. Shallow Clone + +As an alternative to the remote cache approach, you can use shallow cloning. + +{% highlight ruby %}set :git_shallow_clone, 1{% endhighlight %} + +Shallow cloning will do a clone each time, but will only get the top commit, not the entire repo. This makes it a bit closer to how an svn checkout works. Be warned, shallow clone won't work well with the @set :branch@ option. + +h3. Submodules + +If you're using git submodules you must tell cap to fetch them. + +{% highlight ruby %}set :git_enable_submodules, 1{% endhighlight %} + +h2. Migrating from SVN + +Migrating from SVN-based deploys? "Check this thread":http://groups.google.com/group/github/browse_frm/thread/c5d2620c541e4e1a if you run into any problems. + +h2. Known Hosts bug + +If you are not using agent forwarding, the first time you deploy may fail due to Capistrano not prompting with this message: + +
+The authenticity of host 'github.com (207.97.227.239)' can't be established.
+RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
+Are you sure you want to continue connecting (yes/no)?
+
+ +To fix this, ssh into your server as the user you will deploy with, run ssh git@github.com and confirm the prompt. diff --git a/_posts/2008-03-02-post-receive-hooks.markdown b/_posts/2008-03-02-post-receive-hooks.markdown new file mode 100644 index 0000000..7ce36d5 --- /dev/null +++ b/_posts/2008-03-02-post-receive-hooks.markdown @@ -0,0 +1,121 @@ +--- +layout: default +title: Post-Receive Hooks +description: Working with GitHub's post-receive web hooks. +categories: advanced +--- + +_For help testing webhooks, see [this guide](/testing-webhooks)_ + +If you supply a post-receive URL, GitHub will POST to that URL when someone uses `git push` on that repository. + +![](http://img.skitch.com/20100620-r8st7468q7q5waf3y85hmpwtqs.png) + +![](http://img.skitch.com/20100620-br6dw5iiyk2643fahkqbi54h36.png) + +What we'll send is JSON containing information about the push and the commits involved. + +Here's the template we use in Ruby to generate the JSON: + +{% highlight ruby %} +{ + :before => before, + :after => after, + :ref => ref, + :commits => [{ + :id => commit.id, + :message => commit.message, + :timestamp => commit.committed_date.xmlschema, + :url => commit_url, + :added => array_of_added_paths, + :removed => array_of_removed_paths, + :modified => array_of_modified_paths, + :author => { + :name => commit.author.name, + :email => commit.author.email + } + }], + :repository => { + :name => repository.name, + :url => repo_url, + :pledgie => repository.pledgie.id, + :description => repository.description, + :homepage => repository.homepage, + :watchers => repository.watchers.size, + :forks => repository.forks.size, + :private => repository.private?, + :owner => { + :name => repository.owner.login, + :email => repository.owner.email + } + } +} +{% endhighlight %} + +This is sent as a POST with a single parameter: 'payload' + +So, for example, you'd do something like this in a [Sinatra](http://sinatra.rubyforge.org/) server: + +{% highlight ruby %} +post '/' do + push = JSON.parse(params[:payload]) + "I got some JSON: #{push.inspect}" +end +{% endhighlight %} + +The `commits` array is ordered with the oldest commit as the first element. The last element is the newest commit and should match the "after" value for the branch. + +Here's an example payload: + +{% highlight javascript %} +{ + "before": "5aef35982fb2d34e9d9d4502f6ede1072793222d", + "repository": { + "url": "http://github.com/defunkt/github", + "name": "github", + "description": "You're lookin' at it.", + "watchers": 5, + "forks": 2, + "private": 1, + "owner": { + "email": "chris@ozmm.org", + "name": "defunkt" + } + }, + "commits": [ + { + "id": "41a212ee83ca127e3c8cf465891ab7216a705f59", + "url": "http://github.com/defunkt/github/commit/41a212ee83ca127e3c8cf465891ab7216a705f59", + "author": { + "email": "chris@ozmm.org", + "name": "Chris Wanstrath" + }, + "message": "okay i give in", + "timestamp": "2008-02-15T14:57:17-08:00", + "added": ["filepath.rb"] + }, + { + "id": "de8251ff97ee194a289832576287d6f8ad74e3d0", + "url": "http://github.com/defunkt/github/commit/de8251ff97ee194a289832576287d6f8ad74e3d0", + "author": { + "email": "chris@ozmm.org", + "name": "Chris Wanstrath" + }, + "message": "update pricing a tad", + "timestamp": "2008-02-15T14:36:34-08:00" + } + ], + "after": "de8251ff97ee194a289832576287d6f8ad74e3d0", + "ref": "refs/heads/master" +} +{% endhighlight %} + +For more information on this technique, see the [Web Hooks Wiki](http://webhooks.pbwiki.com/). + +Links +----- + +* [raggi/github_post_receive_server](http://github.com/raggi/github_post_receive_server/) -- A template Rack server +* [jnewland/github-campfire](http://github.com/jnewland/github-campfire/) +* [webs/irccat](http://github.com/webs/irccat) +* [jnunemaker/github-twitter](http://github.com/jnunemaker/github-twitter/) diff --git a/_posts/2008-03-03-remove-sensitive-data.markdown b/_posts/2008-03-03-remove-sensitive-data.markdown new file mode 100644 index 0000000..8f7b9f3 --- /dev/null +++ b/_posts/2008-03-03-remove-sensitive-data.markdown @@ -0,0 +1,120 @@ +--- +layout: default +title: Remove sensitive data +description: Dealing with accidentally committed passwords or other sensitive information +categories: popular advanced +terminal_pres: true +--- + +

From time to time users accidentally commit data like passwords or keys into a git repo. While you can use git rm to remove the file, it will still be in the repo's history. Fortunately, git makes it fairly simple to remove the file from the entire repo history.

+ +Change your password +-------------------- + +This step should be blatantly obvious, but some users still skip it. If you committed a password, change it! If you committed a key, generate a new one. Once the commit has been pushed you should consider the data to be compromised. Period. + +Purge the file from your repo +----------------------------- + +Now that the password is changed, you want to remove the file from history and add it to the `.gitignore` to ensure it is not accidentally re-committed. For our examples, we're going to remove `Rakefile` from the [GitHub gem](http://github.com/defunkt/github-gem) repo. + +
+tekkub@iSenberg ~/tmp master*
+$ git clone git@github.com:defunkt/github-gem.git
+Initialized empty Git repository in /Users/tekkub/tmp/github-gem/.git/
+remote: Counting objects: 1301, done.
+remote: Compressing objects: 100% (769/769), done.
+remote: Total 1301 (delta 724), reused 910 (delta 522)
+Receiving objects: 100% (1301/1301), 164.39 KiB, done.
+Resolving deltas: 100% (724/724), done.
+
+tekkub@iSenberg ~/tmp master*
+$ cd github-gem/
+
+tekkub@iSenberg ~/tmp/github-gem master
+$ git filter-branch --index-filter 'git rm --cached --ignore-unmatch Rakefile' HEAD
+Rewrite 48dc599c80e20527ed902928085e7861e6b3cbe6 (266/266)
+Ref 'refs/heads/master' was rewritten
+
+ +This command will run the entire history of the master branch and change any commit that involved the file `Rakefile`, and any commits afterwards. Now that we've erased the file from history, lets ensure that we don't accidentally commit it again. + +If you wish to retain tags you must specify `--tag-name-filter "cat"`, but note that *this will overwrite your existing tags*. + +
+tekkub@iSenberg ~/tmp/github-gem master
+$ echo "Rakefile" >> .gitignore
+
+tekkub@iSenberg ~/tmp/github-gem master*
+$ git add .gitignore
+
+tekkub@iSenberg ~/tmp/github-gem master+
+$ git commit -m "Add Rakefile to .gitignore"
+[master 051452f] Add Rakefile to .gitignore
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+
+ +This would be a good time to double-check that you've removed everything that you wanted to from the history. Note that `git filter-branch` only works on one branch at a time, so you may need to perform the cleanup on other branches as well. This could be problematic if the branch has a complex merge history. If we're happy with the state of the repo, we need to force-push the changes to overwrite the remote repo. + +
+tekkub@iSenberg ~/tmp/github-gem master
+$ git push origin master --force
+Counting objects: 1074, done.
+Delta compression using 2 threads.
+Compressing objects: 100% (677/677), done.
+Writing objects: 100% (1058/1058), 148.85 KiB, done.
+Total 1058 (delta 590), reused 602 (delta 378)
+To git@github.com:defunkt/github-gem.git
+ + 48dc599...051452f master -> master (forced update)
+
+ +### Cleanup and reclaiming space + +While `git filter-branch` rewrites the history for you, the objects will remain in your local repo until they've been dereferenced and garbage collected. If you are working in your main repo you might want to force these objects to be purged. + +
+tekkub@iSenberg ~/tmp/github-gem master
+$ rm -rf .git/refs/original/
+
+tekkub@iSenberg ~/tmp/github-gem master
+$ git reflog expire --expire=now --all
+
+tekkub@iSenberg ~/tmp/github-gem master
+$ git gc --prune=now
+Counting objects: 2437, done.
+Delta compression using up to 4 threads.
+Compressing objects: 100% (1378/1378), done.
+Writing objects: 100% (2437/2437), done.
+Total 2437 (delta 1461), reused 1802 (delta 1048)
+
+tekkub@iSenberg ~/tmp/github-gem master
+$ git gc --aggressive --prune=now
+Counting objects: 2437, done.
+Delta compression using up to 4 threads.
+Compressing objects: 100% (2426/2426), done.
+Writing objects: 100% (2437/2437), done.
+Total 2437 (delta 1483), reused 0 (delta 0)
+
+ +Note that pushing the branch to a new or empty GitHub repo and then making a fresh clone from GitHub will have the same effect. + +Dealing with collaborators +-------------------------- + +You may have collaborators that pulled your tainted branch and created their own branches off of it. After they fetch your new branch, they will need to use `git rebase` on their own branches to rebase them on top of the new one. The collab should also ensure that their branch doesn't reintroduce the file, as this will override the `.gitignore` file. *Make sure your collab uses rebase and not merge,* otherwise he will just reintroduce the file and the entire tainted history... and likely encounter some merge conflicts. + +Cached data on GitHub +--------------------- + +Be warned that force-pushing does not erase commits on the remote repo, it simply introduces new ones and moves the branch pointer to point to them. If you are worried about users accessing the bad commits directly via SHA1, you will have to delete the repo and recreate it. If the commits were viewed online the pages may also be cached. Check for cached pages after you recreate the repo, if you find any open a ticket on [GitHub Support](http://support.github.com) and provide links so staff can purge them from the cache. + +Avoiding accidental commits in the future +----------------------------------------- + +There are a few simple tricks to avoid committing things you don't want committed. The first, and simplest, is to use a visual tool like git-gui or [gitx](http://gitx.frim.nl/) to make your commits. This lets you see exactly what you're committing, and ensure that only the files you want are added to the repo. If you're working form the command line, avoid the catch-all commands `git add .` and `git commit -a`, instead use `git add filename` and `git rm filename` to individually stage files. You can also use `git add --interactive` to review each changed file and stage it, or part of it, for commit. If you're working from the command line, you can also use `git diff --cached` to see what changes you have staged for commit. This is the exact diff that your commit will have as long as you commit without the `-a` flag. + +Other reading +------------- + +* [git-filter-branch documentation](http://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html) +* [Git user manual - Cleaning up history](http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#cleaning-up-history) \ No newline at end of file diff --git a/_posts/2008-03-04-split-a-subpath-to-a-new-repo.md b/_posts/2008-03-04-split-a-subpath-to-a-new-repo.md new file mode 100644 index 0000000..608c994 --- /dev/null +++ b/_posts/2008-03-04-split-a-subpath-to-a-new-repo.md @@ -0,0 +1,29 @@ +--- +layout: default +title: Split a subpath into a new repo +description: How to generate a new repo from a subpath, retaining history. +categories: advanced +--- + +

From time to time you may find that you want to make a new repo from a subpath of an existing repo. Perhaps you're moving some code out into a library or just want to have a common submodule across projects. Thanks to git, it's easy to do this without losing the history of that subpath in the process.

+ +The Good Stuff +-------------- + +Splitting a subpath into a repo is a fairly straightforward process, even if the command is hard to remember. For this example, we split lib/ out of the "GitHub gem":http://github.com/defunkt/github-gem repo, removing empty commits but retaining the path's history. + +
[tekkub@tekBook: ~/tmp] $ git clone git://github.com/defunkt/github-gem.git
+Initialized empty Git repository in /Users/tekkub/tmp/github-gem/.git/
+remote: Counting objects: 1301, done.
+remote: Compressing objects: 100% (769/769), done.
+remote: Total 1301 (delta 724), reused 910 (delta 522)
+Receiving objects: 100% (1301/1301), 164.39 KiB | 274 KiB/s, done.
+Resolving deltas: 100% (724/724), done.
+
+[tekkub@tekBook: ~/tmp] $ cd github-gem/
+
+[tekkub@tekBook: ~/tmp/github-gem master] $ git filter-branch --prune-empty --subdirectory-filter lib master
+Rewrite 48dc599c80e20527ed902928085e7861e6b3cbe6 (89/89)
+Ref 'refs/heads/master' was rewritten
+ +Now we have a re-written master branch that contains the files that were in lib/. We can simply add a remote to the new repo and push, or do whatever we want with the repo. diff --git a/_posts/2008-03-05-subtree-merge.markdown b/_posts/2008-03-05-subtree-merge.markdown new file mode 100644 index 0000000..31645e5 --- /dev/null +++ b/_posts/2008-03-05-subtree-merge.markdown @@ -0,0 +1,127 @@ +--- +layout: default +title: Subtree Merge +description: How to use subtree merge to merge one repo into another as a subpath. +categories: advanced +--- + +

There are times when submodules are not adequate for the task at hand. For example, blending multiple repos together into one single repo while still maintaining the history of each repo. To do this, the subtree merge strategy is a better solution.

+ +Setting up and doing the first merge +------------------------------------ + +For this example, we'll make an empty "parent" repo and some other repos into it as subpaths. + +First, set up an empty repo for our example: + +
+[tekkub@tekBook: ~/tmp master*]
+$ mkdir test
+
+[tekkub@tekBook: ~/tmp master*]
+$ cd test
+
+[tekkub@tekBook: ~/tmp/test master*]
+$ git init
+Initialized empty Git repository in /Users/tekkub/tmp/test/.git/
+
+[tekkub@tekBook: ~/tmp/test master#]
+$ touch .gitignore
+
+[tekkub@tekBook: ~/tmp/test master#]
+$ git add .gitignore
+
+[tekkub@tekBook: ~/tmp/test master#]
+$ git commit -m "initial commit"
+[master (root-commit) 3146c2a] initial commit
+ 0 files changed, 0 insertions(+), 0 deletions(-)
+ create mode 100644 .gitignore
+
+ +Now we'll subtree-merge the repo [tekkub/cork](https://github.com/tekkub/cork) into the repo at `cork/` + +
+[tekkub@tekBook: ~/tmp/test master]
+$ git remote add -f cork git://github.com/tekkub/cork.git
+Updating cork
+warning: no common commits
+remote: Counting objects: 1732, done.
+remote: Compressing objects: 100% (750/750), done.
+remote: Total 1732 (delta 1086), reused 1558 (delta 967)
+Receiving objects: 100% (1732/1732), 528.19 KiB | 621 KiB/s, done.
+Resolving deltas: 100% (1086/1086), done.
+From git://github.com/tekkub/cork
+ * [new branch]      lastbuffed -> cork/lastbuffed
+ * [new branch]      lock_n_mount -> cork/lock_n_mount
+ * [new branch]      master     -> cork/master
+ * [new branch]      nothing_to_see_here -> cork/nothing_to_see_here
+
+[tekkub@tekBook: ~/tmp/test master]
+$ git merge -s ours --no-commit cork/master
+Automatic merge went well; stopped before committing as requested
+
+[tekkub@tekBook: ~/tmp/test master|MERGING]
+$ git read-tree --prefix=cork/ -u cork/master
+
+[tekkub@tekBook: ~/tmp/test master+|MERGING]
+$ git commit -m "Subtree merged in cork"
+[master fe0ca25] Subtree merged in cork
+
+ +Next, we'll merge in [tekkub/panda](https://github.com/tekkub/panda) into the path `panda/` + +
+[tekkub@tekBook: ~/tmp/test master]
+$ git remote add -f panda git://github.com/tekkub/panda.git
+Updating panda
+warning: no common commits
+remote: Counting objects: 974, done.
+remote: Compressing objects: 100% (722/722), done.
+remote: Total 974 (delta 616), reused 399 (delta 251)
+Receiving objects: 100% (974/974), 189.56 KiB, done.
+Resolving deltas: 100% (616/616), done.
+From git://github.com/tekkub/panda
+ * [new branch]      master     -> panda/master
+ * [new branch]      transmute  -> panda/transmute
+
+[tekkub@tekBook: ~/tmp/test master]
+$ git merge -s ours --no-commit panda/master
+Automatic merge went well; stopped before committing as requested
+
+[tekkub@tekBook: ~/tmp/test master|MERGING]
+$ git read-tree --prefix=panda/ -u panda/master
+
+[tekkub@tekBook: ~/tmp/test master+|MERGING]
+$ git commit -m "Subtree merged in panda"
+[master 726a2cd] Subtree merged in panda
+
+ +Finally, we're going to merge the subpath `modules/` from tekkub/cork into `cork2/` + +
+tekkub@iSenberg ~/tmp/test master
+$ git merge -s ours --no-commit cork/master
+Automatic merge went well; stopped before committing as requested
+
+tekkub@iSenberg ~/tmp/test master|MERGING
+$ git read-tree --prefix=cork2/ -u cork/master:modules
+
+tekkub@iSenberg ~/tmp/test master+|MERGING
+$ git commit -m "Subtree merged in cork/modules"
+[master f240057] Subtree merged in cork/modules
+
+ +Pulling in changes +------------------ + +If the merged repo changes in the future, you can pull in its changes by simply using the `-s subtree` flag: + +
+[tekkub@tekBook: ~/tmp/test master]
+$ git pull -s subtree panda master
+
+ +Resources +--------- + +* [How to use the subtree merge strategy](http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html) diff --git a/_posts/2008-03-06-test-webhooks.textile b/_posts/2008-03-06-test-webhooks.textile new file mode 100644 index 0000000..cf760ae --- /dev/null +++ b/_posts/2008-03-06-test-webhooks.textile @@ -0,0 +1,65 @@ +--- +layout: default +title: Test webhooks +description: How to test post-receive webhook calls from your repo +categories: advanced +--- + +

Testing that a webhook works can be a bit of a pain. Thankfully with the help of "PostBin":http://www.postbin.org/ the pain can be avoided.

+ +h2. When hooks are fired + +First and foremost, webhooks are not always called when a push is made. Currently hooks only fire when a branch that exists on GitHub is modified. Pushing new branches, deleting branches, and creating tags will not fire a webhook. Forced pushes such as @git push origin master --force@ may not predictably call hooks as well. To ensure your commits are sent to your webhook, always push the branch when it is created before you commit. This way the branch exists on GitHub when you push the commits you want sent to the webhook. + +h2. Setting up + +First, visit "PostBin":http://www.postbin.org/ and click "Make a PostBin". Copy the URL you are sent to: + +!http://img.skitch.com/20091118-jp5jt8gtcxy8dn2w3kk1xkpt8j.jpg! + +Paste this URL into your repo's post-receive URLs setting and save: + +!http://img.skitch.com/20091118-nr8ggc3rgdq8i1r2x8ad1mm57r.jpg! + +h2. Testing the hook is fired + +To test that the hook fires we need an existing branch on the GitHub repo. In this example we create a new repo, push one commit, then make another commit and push it. We only expect the second push to be sent to our PostBin. + +
[tekkub@tekBook: ~/tmp] $ mkdir test_post
+[tekkub@tekBook: ~/tmp] $ cd test_post
+[tekkub@tekBook: ~/tmp/test_post] $ git init
+Initialized empty Git repository in /Users/tekkub/tmp/test_post/.git/
+
+[tekkub@tekBook: ~/tmp/test_post master#] $ touch README
+[tekkub@tekBook: ~/tmp/test_post master#] $ git add README
+[tekkub@tekBook: ~/tmp/test_post master#] $ git commit -m 'first commit'
+[master (root-commit) 94afb6c] first commit
+ 0 files changed, 0 insertions(+), 0 deletions(-)
+ create mode 100644 README
+
+[tekkub@tekBook: ~/tmp/test_post master] $ git remote add origin git@github.com:tekkub/test_post.git
+[tekkub@tekBook: ~/tmp/test_post master] $ git push origin master
+Counting objects: 3, done.
+Writing objects: 100% (3/3), 201 bytes, done.
+Total 3 (delta 0), reused 0 (delta 0)
+To git@github.com:tekkub/test_post.git
+ * [new branch]      master -> master
+
+[tekkub@tekBook: ~/tmp/test_post master] $ echo "This is a real edit" > README
+[tekkub@tekBook: ~/tmp/test_post master*] $ git add README
+[tekkub@tekBook: ~/tmp/test_post master+] $ git commit -m 'second commit'
+[master a58cf12] second commit
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+
+[tekkub@tekBook: ~/tmp/test_post master] $ git push origin master
+Counting objects: 5, done.
+Writing objects: 100% (3/3), 249 bytes, done.
+Total 3 (delta 0), reused 0 (delta 0)
+To git@github.com:tekkub/test_post.git
+   94afb6c..a58cf12  master -> master
+ +Now that we've pushed a commit that should be sent to our webhook, lets check if it did by reloading our PostBin page: + +!http://img.skitch.com/20091118-rgxb1rx3aixqfdk4sm5wtaw4t7.jpg! + +Success! \ No newline at end of file diff --git a/_posts/2008-04-01-common-issues-and-questions.markdown b/_posts/2008-04-01-common-issues-and-questions.markdown new file mode 100644 index 0000000..fc886c0 --- /dev/null +++ b/_posts/2008-04-01-common-issues-and-questions.markdown @@ -0,0 +1,38 @@ +--- +layout: default +title: Common issues and questions +description: Solutions to the most common issues and answers to common questions +categories: troubleshooting popular +--- + +I can't push, "Permission denied (publickey)" +--------------------------------------------- + +Make sure you've [set up an SSH key](/key-setup-redirect) and are using the correct URL (they are case-sensitive). Check [this guide](/troubleshooting-ssh) for more information. + +My commits aren't linked to my user, to the wrong user, or don't have a Gravatar +----------------------------------------------------------------------------------- + +Make sure your [git](/git-email-settings) and [GitHub](https://github.com/account#email_bucket) email settings match. + +You may also need to check your Gravatar account to make sure your Gravatar has a "G" rating. + +I changed my Gravatar but it's not updating +------------------------------------------- + +Gravatar images are cached for a very long time. Clear your browser's cache. + +Syntax highlighting isn't working for my language +------------------------------------------------- + +We use the excellent [pygments](http://pygments.org/) library for our syntax highlighting. Check their list of [supported languages](http://pygments.org/languages/) and learn how to specify a lexer for yours. If you contribute a lexer back to pygments, let us know and we’ll make sure it’s made available here on GitHub. + +Can I use Eclipse/EGit with GitHub? +----------------------------------- + +Yes, see [this writup](http://gist.github.com/423316) for help. + +Are there any screencasts or other resources out there for git? +--------------------------------------------------------------- + +Yes, you can find a *(probably incomplete)* list [here](http://gist.github.com/423320). diff --git a/_posts/2008-04-02-firewalls-and-proxies.markdown b/_posts/2008-04-02-firewalls-and-proxies.markdown new file mode 100644 index 0000000..47647dc --- /dev/null +++ b/_posts/2008-04-02-firewalls-and-proxies.markdown @@ -0,0 +1,19 @@ +--- +layout: default +title: Firewalls and proxies +categories: troubleshooting +--- + +There are a few ways to deal with a draconian firewall or an unruly proxy: + +* [Smart HTTP](http://github.com/blog/642-smart-http-support) -- By far the easiest approach. Available with git v1.7 and later. Works great with proxies and firewalls that block non-HTTP outbound connections. + + * [Not-so-smart HTTP](http://github.com/blog/92-http-cloning) -- For cloning public repos only, on pre-1.7 git clients. Use only if Smart HTTP is not an option. + +* [corkscrew](http://blog.codeslower.com/2008/8/Using-PuTTY-and-SSL-to-securely-access-GitHub-repositories-via-SSH) -- Works best with firewalls, creates an outbound ssh connection on port 80. Proxies may interfere. + + * [another corkscrew guide](http://dilipm79.blogspot.com/2008/11/why-i-love-git-and-github.html) + + * [and another](http://returnbooleantrue.blogspot.com/2009/06/using-github-through-draconian-proxies.html) + +* [ssh forwarding](http://gist.github.com/423642) -- Similar to corkscrew, requires access to an external ssh server. Two slightly different methods are provided. diff --git a/_posts/2008-04-03-fix-a-bad-tree.markdown b/_posts/2008-04-03-fix-a-bad-tree.markdown new file mode 100644 index 0000000..95be750 --- /dev/null +++ b/_posts/2008-04-03-fix-a-bad-tree.markdown @@ -0,0 +1,56 @@ +--- +layout: default +title: Fix a bad tree +description: How to fix the bad tree error on a github repo caused by egit +categories: troubleshooting +--- + +Due to a bug in egit's implementation of the `git rm` command, empty trees may not be removed from the index and result in a "bad tree" error on github: + +![](https://img.skitch.com/20110308-875n82b15ktc8kc34wdaj1euky.jpg) + +Fixing the repo +--------------- + +Fixing this error is fairly simple with the commandline. To fix the error you need to recreate the tree and then remove it using `git rm` to ensure it is removed correctly. + +For example, if the bad tree is at `badtree/` we would run: + +
tekkub@iSenberg ~/tmp/fixing_bad_tree master
+> mkdir badtree
+
+tekkub@iSenberg ~/tmp/fixing_bad_tree master
+> touch badtree/temp
+
+tekkub@iSenberg ~/tmp/fixing_bad_tree master
+> git add badtree/temp
+
+tekkub@iSenberg ~/tmp/fixing_bad_tree master+
+> git commit -m "Fixing bad tree, step one"
+[master dbe6a08] Fixing bad tree, step one
+ 0 files changed, 0 insertions(+), 0 deletions(-)
+ create mode 100644 badtree/temp
+
+tekkub@iSenberg ~/tmp/fixing_bad_tree master
+> git rm badtree/temp
+rm 'badtree/temp'
+
+tekkub@iSenberg ~/tmp/fixing_bad_tree master+
+> git commit -m "Fixing bad tree, step two"
+[master 46ae6d2] Fixing bad tree, step two
+ 0 files changed, 0 insertions(+), 0 deletions(-)
+ delete mode 100644 badtree/temp
+
+ +We can then confirm the tree is removed by making sure it is not listed by `git ls-tree`: + +
tekkub@iSenberg ~/tmp/fixing_bad_tree master
+> git ls-tree -r HEAD | grep badtree
+
+ +If this returns no results, push the repo and everything should be fixed! + +Avoiding future corruption +-------------------------- + +We recommend users avoid using egit to remove files from their repos. Always use `git rm` from the command line. diff --git a/_posts/2008-04-04-fix-egit-corruption.markdown b/_posts/2008-04-04-fix-egit-corruption.markdown new file mode 100644 index 0000000..1c3a6fc --- /dev/null +++ b/_posts/2008-04-04-fix-egit-corruption.markdown @@ -0,0 +1,57 @@ +--- +layout: default +title: Fix egit corruption +description: How to fix corruption in a remote repo caused by egit +categories: troubleshooting +--- + +Due to a bug in the [EGit](http://eclipse.org/egit/)/[JGit](http://eclipse.org/jgit/) implementation of the `git push` command, remote repos can become corrupted due to missing objects: + +
$ git fsck
+broken link from  commit 5b90a930763c442f0fc3d819685083b4eda69f8e
+              to  commit e1ea55d308b7808cb982f509c8dfa199ada4677e
+missing commit e1ea55d308b7808cb982f509c8dfa199ada4677e
+ +This can prevent cloning and fetching from the repo. The objects were never pushed to the remote repo, therefore support cannot recover the repo directly for the user. The only solution is for the user that pushed the commits to push them again from the command line. + +_This issue was fixed in EGit/JGit 0.8.4. We recommend updating and trying the following commands from EGit/JGit before resorting to the commandline._ + +Correcting the remote repo +-------------------------- + +To correct the remote repo the missing objects need to be re-pushed from an uncorrupted repo. This should be done from the command line, not from egit. To start, run `git fsck` on your local repo to ensure it has not been corrupted. If you do not receive any errors about broken links or missing objects, you're clear to continue. + +Re-pushing is a simple matter of deleting the remote branch and then pushing it again. We'll use the first commit in the branch so that we can ensure all the other commits are re-pushed. + +If the branch being deleted is the default branch on the remote you'll need to replace it temporarily. You can do this in the repo's admin page: + +![default](http://img.skitch.com/20100203-jm7pty6kf1c72yfksunyf5g5n9.jpg) + +
$ git log --pretty=oneline | tail -n 1 # Find the first commit
+3b70d98cb968fc35f0c99acfe4d5dfa976ed2536 Initial commit
+$ git branch temp_default 3b70d98cb968fc35f0c99acfe4d5dfa976ed2536
+$ git push origin temp_default
+# Change the remote default branch to temp_default
+$ git push origin :master
+$ git push origin master
+# Set the remote default back to master
+$ git push origin :temp_default
+ +You may need to do this for many branches if the remote repo has more than one branch that was pushed by egit. You can skip `git remote set-head` for these other branches. + +After you've pushed and reset HEAD, testing the repo repo is just a matter of cloning it: + +
$ git clone git://github.com/tekkub/test.git
+Initialized empty Git repository in /Users/tekkub/tmp/test/.git/
+remote: Counting objects: 1815, done.
+remote: Compressing objects: 100% (838/838), done.
+remote: Total 1815 (delta 1139), reused 1552 (delta 961)
+Receiving objects: 100% (1815/1815), 537.69 KiB | 549 KiB/s, done.
+Resolving deltas: 100% (1139/1139), done.
+ +If you have re-pushed all branches in your repo and cloning still fails, please [contact support](http://support.github.com) and open a ticket. Be sure to include a link to your repo and mention that you've already performed the steps on this page. + +Avoiding future corruption +-------------------------- + +We recommend users avoid using EGit/JGit to push their repos if they are using a version prior to 0.8.4. \ No newline at end of file diff --git a/_posts/2008-04-05-line-endings.textile b/_posts/2008-04-05-line-endings.textile new file mode 100644 index 0000000..3a51f09 --- /dev/null +++ b/_posts/2008-04-05-line-endings.textile @@ -0,0 +1,50 @@ +--- +layout: default +title: Line endings +description: How to ensure that line endings are consistent in your repo +categories: troubleshooting +--- + +

Line endings... the scourge of every Windows-based developer that tries to mingle with linux- or mac-based developers. Though most modern text editors can handle both newline types without issue, git is not as graceful.

+ +

For more info on the issue see "Wikipedia":http://en.wikipedia.org/wiki/Newline.

+ +h2. Mac and Linux users, you don't get to sit this one out + +Although you might think you're immune to CRLF-ended files on mac and linux, you are not. It is possible to download files from an external source that use CRLF, and thus commit them into your repo. To be safe, you should set your config to convert line endings on commit so they are always LF in the repo: + +
$ git config --global core.autocrlf input
+ +h2. I just cloned and git says files have changed! + +So, you just cloned a repo on a Windows box, and it says that all of your files have been modified. Huh? You've not touched anything yet! What the... + +The problem is that your @core.autocrlf@ option is likely not enabled. This setting tells git to convert the newlines to the system's standard when checking out files, and to LF newlines when committing in. To turn it on use this command: + +
$ git config --global core.autocrlf true
+ +Once this is set, you need to reset your repos. The best way to do this is wipe out your working tree (all the files except the .git directory) and then restore them: + +
# Remove everything from the index
+$ git rm --cached -r .
+
+# Re-add all the deleted files to the index
+# You should get lots of messages like: "warning: CRLF will be replaced by LF in ."
+$ git diff --cached --name-only -z | xargs -0 git add
+
+# Commit
+$ git commit -m "Fix CRLF"
+
+# If you're doing this on a Unix/Mac OSX clone then optionally remove
+# the working tree and re-check everything out with the correct line endings.
+$ git ls-files -z | xargs -0 rm
+$ git checkout .
+
+ +p(. _Thanks to Charles Bailey's post on "stackoverflow":http://stackoverflow.com/questions/1510798/trying-to-fix-line-endings-with-git-filter-branch-but-having-no-luck/1511273#1511273 for this solution._ + +h2. Moving forward + +Now that you've standardized the newlines in your repo things should be better. However, every person that touches your repo should turn autocrlf on, even non-Windows users. It is possible for them to bring in code from an outside source that has CRLF newlines, and you don't want them saved into the repo like that. + +For more details on the @core.autocrlf@ setting see the "git-config documentation":http://www.kernel.org/pub/software/scm/git/docs/git-config.html. diff --git a/_posts/2008-04-06-ssh-issues.textile b/_posts/2008-04-06-ssh-issues.textile new file mode 100644 index 0000000..45c6caa --- /dev/null +++ b/_posts/2008-04-06-ssh-issues.textile @@ -0,0 +1,94 @@ +--- +layout: default +title: SSH issues +description: Solutions to common SSH issues +categories: troubleshooting popular +main_category: troubleshooting +--- + +

This guide contains the solutions to the most common SSH connection issues encountered on GitHub.

+ +The first step to testing your connection is to run ssh git@github.com. If your key works, you should get a success message: +
$ ssh git@github.com
+Hi username! You've successfully authenticated, but GitHub does not provide shell access.
+ +If this step fails, try running ssh -v git@github.com. This will print out debug info on what ssh is trying to do. In this output you should check that ssh is connecting to the correct server, on the correct port (22). Many firewalls and proxies will block this connection. Also ensure that ssh is reading the correct key files, these are at ~/.ssh/id_rsa, id_dsa and identity by default. If your key is not at this location, you should move it or create an override (see the "SSH config" section below). + +h2. Permission to user/repo2 denied to user/repo1 + +This error occurs when you attach your key as a deploy key on repo1. You can push and pull from that repo without issue, but you won't have access to any other repo with your key. To solve this, remove the key from repo1's deploy keys and attach it on your "account page":https://github.com/account instead. This key will now have access to all repos your account has access to. + +h2. Permission denied (publickey) + +This is usually caused when ssh cannot find your keys. Make sure your key is in the default location, @~/.ssh@. If you run @ssh-keygen@ again and just press enter at all 3 prompts it will be placed here automatically. Then you can add the contents of id_rsa.pub to "your account":https://github.com/account#ssh_bucket. If id_rsa.pub doesn't work try id_dsa.pub. You might need to generate a new dsa key with @ssh-keygen -t dsa@ if you just have an rsa key. + +h3. Finding out what keys ssh is using + +Finding what keys ssh is offering to the server is fairly simple. Run ssh -v git@github.com and look at the output: + +
debug1: Next authentication method: publickey
+debug1: Trying private key: /Users/tekkub/.ssh/identity
+debug1: Trying private key: /Users/tekkub/.ssh/id_rsa
+debug1: Trying private key: /Users/tekkub/.ssh/id_dsa
+debug1: No more authentication methods to try.
+ +In this example, SSH could not find any keys ("Trying" means ssh is trying to find the key on disk). We should either rename our keypair to use a default name, or run @ssh-add path/to/key@ to make SSH aware of the key's existence. + +
debug1: Next authentication method: publickey
+debug1: Offering public key: /Users/tekkub/.ssh/id_rsa
+debug1: Remote: Forced command: gerve tekkub
+...
+ERROR: Hi tekkub! You've successfully authenticated, but GitHub does not provide shell access
+ +Here we've renamed our keypair to @~/.ssh/id_rsa@. SSH finds the key and offers it to the server. This key works and we authenticate as user "tekkub". + +h2. Issues when using sudo + +

You shouldn't run @sudo git@ unless you have a very good reason. If you don't know if you have a good reason to use sudo, it's likely that you do not have one.

+ +If you are using sudo with git commands (e.g. using sudo git clone because you are deploying to a root-owned folder), ensure that you also generated the key using sudo. Otherwise, you will have generated a key for your current user, but when you are doing sudo git, you are actually the root user - thus, the keys will not match. + +Simply put, if you are using sudo git, then also use sudo ssh-keygen. + +h2. SSH config + +If your github authentication information is different from your machine account information, you'll need to modify your ssh configuration file. + +Create or open the file at ~/.ssh/config Add the following lines: + +
Host github.com
+	User git
+	Hostname github.com
+	PreferredAuthentications publickey
+	IdentityFile [local path to private key half of github public key you provided]
+ +You may also need to update the permissions on your .ssh folder and its contents. The SSH application will ignore secret files that are too permissive. + +
$ chmod 700 ~/.ssh
+$ chmod 600 ~/.ssh/*
+ +h2. No supported authentication methods available + +You should be aware of the environment variable GIT_SSH, which is used by git to find your ssh-speaking client, if ssh doesn't work for you. The git install may be using plink.exe (via GIT_SSH) to perform the authentication. If so, make sure you have pageant.exe running, and the key you created for github loaded into it. This provides the key to plink.exe; without it, the above error will occur. + +See "this post":http://groups.google.com/group/github/browse_thread/thread/21fd06fb8c3f43bd/f5c44b2197d1be15 for a longer discussion. + +Especially with cygwin-git+pageant+putty/plink, you might want to set GIT_SSH to your plink.exe location -- unless that doesn't work for you. In certain circumstances (perhaps after a service pack installation), you will find git network operations failing with +this is because plink.exe running from your (cygwin-provided) git command "*can't talk with pageant to get its keys*":http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/cygwin-clobbers-pageant.html . A solution is to set up a script that has: +
/cygdrive/c/ntnot/plink.exe -i "c:\users\you\.ssh\key-file-for-github.ppk" $1 $2
+ +and set GIT_SSH to point to this: + +
declare -x GIT_SSH="c:\path\to\script"
+ +This explicitly provides the key for plink to use, rather than have it talk with pageant. + +This problem occured for me when I used the executable with pageant that came with WinSCP, but a version of plink in a different directory. I have not found the exact cause yet. All versions were plink/pageant 0.60. (Not running under Cygwin) + +p(. I did not have luck with this approach; GIT_SSH was set to plink.exe already; when I tried to create this script and reset the GIT_SSH I got a "could not fork" error back from git even though the script would run happily on its own - elijahsmith 9/11/08 + +p(. I couldn't get the latest versions of plink and pageant (as of 2008-Nov-15) to talk, and I'm not running Cygwin. The only solution was to revert to using open-ssh by setting @GIT_SSH@ to @C:\Program Files\prg\Git\bin\ssh.exe@. -- "dandv":http://github.com/dandv + +h2. On Windows, you can't type "y" to confirm the "Store [server's host] key in cache?" prompt + +This happens because git eats up the ssh client's STDIN output. To work around that, launch @ssh github.com@ or @plink.exe -agent github.com@ standalone and press "y" at the prompt. diff --git a/_posts/2008-05-01-textmate.markdown b/_posts/2008-05-01-textmate.markdown new file mode 100644 index 0000000..9ad9333 --- /dev/null +++ b/_posts/2008-05-01-textmate.markdown @@ -0,0 +1,10 @@ +--- +layout: default +title: Textmate +description: How to use Textmate as your git editor +categories: third_party +--- + +Using Textmate as your git editor is fairly simple, you just need to to make sure Textmate informs git when the document is closed. You can do this by using `mate -w`: + +
git config --global core.editor "mate -w"
diff --git a/_posts/2008-06-01-userscripts-and-bookmarklets.textile b/_posts/2008-06-01-userscripts-and-bookmarklets.textile new file mode 100644 index 0000000..d8b6db6 --- /dev/null +++ b/_posts/2008-06-01-userscripts-and-bookmarklets.textile @@ -0,0 +1,29 @@ +--- +layout: default +title: Userscripts and Bookmarklets +description: Various bits of code to enhance and personalize GitHub +categories: github_resources +--- + +This page contains userscripts and bookmarklets to enhance and customize GitHub. If you have a link to add, please "fork this repo":http://github.com/github/help.github.com. + +Userscripts can be installed by simply visiting the "raw" version of the gist or github page. Your browser should prompt you to install the userscript if it recognizes it. See "this post":http://github.com/blog/302-gist-for-greasemonkey for details. + +Bookmarklets should provide their own installation instructions. + +h2. GitHub + +* "GitHubbub":http://github.com/stephencelis/githubbub - Growl notifications for the dashboard events +* "Dashboard twitter status":http://gist.github.com/225512 - Adds the two most recent, non-reply tweets from @github to your dashboard +* "Augment GitHub":http://github.com/nakajima/augment-github - Bookmarklet that adds follower, fork, and issue counts to your repos on your dashboard +* "User profile gist links":http://gist.github.com/225593 - Adds a link to user profile pages linking to that user's gists +* "GitHub Markdown Preview":http://userscripts.org/scripts/show/65788 - Adds a preview to comment fields, so that you may see how your comment looks with the markdown formatted before sending it. +* "Preview Images":https://github.com/yperevoznikov/Preview-Images-In-Github - Adds a preview of images inside issues + +h2. Gist + +* "Replace page title with filename":http://gist.github.com/93187 +* "Diff for gist":http://gist.github.com/105913 +* "Bespin for gist":http://gist.github.com/463054 - Allows users to quickly replace any textarea you encounter on gist.github.com with a Bespin editor. +* "Gist UserScript Install Link":http://gist.github.com/289492 - If a gist is a userscript, then this userscript will add a "install" link next the the "raw" link, and points the "raw" link to the url using view-source:. +* "Add top pagination to My Gists":http://gist.github.com/339147 - Adds pagination to the top of the "My Gists" page. diff --git a/_posts/2008-07-01-git-cheat-sheets.textile b/_posts/2008-07-01-git-cheat-sheets.textile new file mode 100644 index 0000000..ff97611 --- /dev/null +++ b/_posts/2008-07-01-git-cheat-sheets.textile @@ -0,0 +1,328 @@ +--- +layout: default +title: Git cheat sheets +description: Quick-reference guides to git +categories: git_resources +--- + +h3. Cheat sheets + +* Alexander Zeitler's "Git Cheat Sheet":http://github.com/AlexZeitler/gitcheatsheet +* Zach Rusin's "Git Cheat Sheet":http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html +* "http://cheat.errtheblog.com/s/git/":http://cheat.errtheblog.com/s/git/ +* Nate Murray's "Git Cheat Sheet":http://www.xcombinator.com/2010/09/01/git-cheat-sheet-and-class-notes/ +* "Git - Der Spickzettel":https://github.com/esc/git-cheatsheet-de/ (in German) +* "DZone Git RefCard Cheat Sheet":http://refcardz.dzone.com/refcardz/getting-started-git + +h3. A practical git guide + +_Notes extracted from git screencast at http://www.peepcode.com._ + +h4. Configuration + +identify yourself to git: email and your name + +@git config --global user.name "David Beckwith"@ + +

git config --global user.email "dbitsolutions@gmail.com"

+ +To view all options: + +@git config --list@ + +OR + +@cat .git/config@ + +h4. Set up aliases + +@git config --global alias.co checkout@ + +h4. View your configuration + +@cat .gitconfig@ + +h4. To ignore whitespace (Ruby is whitespace insensitive) + +@git config --global apply.whitespace nowarn@ + +Some nice aliases: + +gb = git branch +gba = git branch -a +gc = git commit -v +gd = git diff | mate +gl = git pull +gp = git push +gst = git status + +h3. Start using git + +@git init@ + +h4. Ignoring files + +Add a file in the root directory called @.gitignore@ and add some files to it: (comments begin with hash) + + *.log + db/schema.rb + db/schema.sql + +Git automatically ignores empty directories. If you want to have a @log/@ directory, but want to ignore all the files in it, add the following lines to the root @.gitignore@: (lines beginning with '!' are exceptions) + +@log/*@ +@!.gitignore@ + +Then add an empty @.gitignore@ in the empty directory: + +@touch log/.gitignore@ + +h4. Scheduling the addition of all files to the next commit + +@git add .@ + +h4. Checking the status of your repository + +@git status@ + +h4. Committing files + +@git commit -m "First import"@ + +h4. Seeing what files have been committed + +@git ls-files@ + +h4. Scheduling deletion of a file + +@git rm [file name]@ + +h4. Committing all changes in a repository + +@git commit -a@ + +h4. Scheduling the addition of an individual file to the next commit + +@git add [file name]@ + +h4. Viewing the difference as you commit + +@git commit -v@ + +h4. Commit and type the message on the command line + +@git commit -m "This is the message describing the commit"@ + +h4. Commit and automatically get any other changes + +@git commit -a@ + +h4. A "normal" commit command + +@git commit -a -v@ + +h4. Viewing a log of your commits + +@git log@ + +h4. Viewing a log of your commits with a graph to show the changes + +@git log --stat@ + +h4. Viewing a log with pagination + +@git log -v@ + +h4. Visualizing git changes + +@gitk --all@ + +h4. Creating a new tag and pushing it to the remote branch + +@git tag "v1.3"@ +@git push --tags@ + +h4. Creating a new branch + +@git branch [name of your new branch]@ + +h4. Pushing the branch to a remote repository + +@git push origin [new-remote]@ + +h4. Pulling a new branch from a remote repository + +@git fetch origin [remote-branch]:[new-local-branch]@ + +h4. Viewing branches + +@git branch@ + +h4. Viewing a list of all existing branches + +@git branch -a@ + +h4. Switching to another branch + +The state of your file system will change after executing this command. + +@git checkout [name of the branch you want to switch to]@ + +OR + +@git co [name of the branch you want to switch to]@ + +h4. Making sure changes on master appear in your branch + +@git rebase master@ + +h4. Merging a branch back into the master branch + +First, switch back to the master branch: + +@git co master@ + +Check to see what changes you're about to merge together, compare the two branches: + +@git diff master xyz@ + +If you're in a branch that's not the @xyz@ branch and want to merge the @xyz@ branch into it: + +@git merge xyz@ + +h4. Reverting changes to before said merge + +@git reset --hard ORIG_HEAD@ + +h4. Resolving conflicts + +Remove the markings, add the file, then commit. + +h4. Creating a branch (and switching to the new branch) in one line + +@git checkout -b [name of new branch]@ + +h4. Creating a stash (like a clipboard) of changes to allow you to switch branches without committing + +@git stash save "Put a message here to remind you of what you're saving to the clipboard"@ + +h4. Switching from the current branch to another + +@git co [branch you want to switch to]@ + +Do whatever +Then switch back to the stashed branch + +@git co [the stashed branch]@ + +h4. Viewing a list of stashes + +@git stash list@ + +h4. Loading back the stash + +@git stash apply@ + +Now you can continue to work where you were previously. + +h4. Deleting a branch (that has been merged back at some point) + +@git branch -d [name of branch you want to delete]@ + +h4. Deleting an unmerged branch + +@git branch -D [name of branch you want to delete]@ + +h4. Deleting a stash + +@git stash clear@ + +h4. Setting up a repository for use on a remote server + +Copy up your repository. e.g.: + +

scp -r my_project deploy@yourbox.com:my_project

+ +Move your files on the remote server to @/var/git/my_project@ +For security make the owner of this project git +On the repository server: + +@sudo chown -R git:git my_project@ + +Then (for security) restrict the "deploy" user to doing git-related things in @/etc/passwd@ with a @git-shell@. + +h4. Checking out a git repository from a remote to your local storage + +

git clone git@yourbox.com:/var/git/my_project

+ +h4. Viewing extra info about a remote repository + +@cat .git/config@ + +By virtue of having cloned the remote repository, your local repository becomes the slave and will track and synchronize with the remote master branch. + +h4. Updating a local branch from the remote server + +@git pull@ + +h4. Downloading a copy of an entire repository (e.g. @laptop@) without merging into your local branch + +@git fetch laptop@ + +h4. Merging two local branches (ie. your local xyz branch with your local master branch) USE MERGE + +@git merge laptop/xyz@ + +This merged the (already copied laptop repository's xyz branch) with the current branch you're sitting in. + +h4. Viewing metadata about a remote repository + +@git remote show laptop@ + +h4. Pushing a committed local change from one local branch to another remote branch + +@git push laptop xyz@ + +h4. Creating a tracking branch (i.e. to link a local branch to a remote branch) + +@git branch --track local_branch remote_branch@ + +You do not need to specify the local branch if you are already sitting in it. + +@git pull@ + +Note: You can track(link) different local branches to different remote machines. For example, you can track your friend's "upgrade" branch with your "bobs_upgrade" branch, and simultaneously you can track the origin's "master" branch (of your main webserver) with your local "master" branch. + +By convention, 'origin' is the local name given to the remote centralized server which is the way SVN is usually set up on a remote server. + +h4. Seeing which local branches are tracking a remote branch + +@git remote show origin@ + +h4. Working with a remote Subversion repository (but with git locally) + +@git-svn clone [http location of an svn repository]@ + +Now you can work with the checked out directory as though it was a git repository. (cuz it is) + + +h4. Pushing (committing) changes to a remote Subversion repository + +@git-svn dcommit@ + +h4. Updating a local git repository from a remote Subversion repository + +@git-svn rebase@ + +NOTE: make sure you have your perl bindings to your local svn installation. + +h4. I screwed up, how do I reset my checkout? + +@git checkout -f@ + +h3. See also + +* "Git for computer scientists. (lots of pictures)":http://eagain.net/articles/git-for-computer-scientists/ +* "Git user's manual":http://www.kernel.org/pub/software/scm/git/docs/user-manual.html +* "Git Magic":http://www-cs-students.stanford.edu/~blynn/gitmagic/ +* "Git Cheat Sheets Collection":http://devcheatsheet.com/tag/git/ on DevCheatSheet.com \ No newline at end of file diff --git a/_posts/2008-08-01-privacy-policy.markdown b/_posts/2008-08-01-privacy-policy.markdown new file mode 100644 index 0000000..248e664 --- /dev/null +++ b/_posts/2008-08-01-privacy-policy.markdown @@ -0,0 +1,46 @@ +--- +layout: default +title: Privacy Policy +categories: site_policy +--- + +General Information +------------------- + +We collect the e-mail addresses of those who communicate with us via e-mail, aggregate information on what pages consumers access or visit, and information volunteered by the consumer (such as survey information and/or site registrations). The information we collect is used to improve the content of our Web pages and the quality of our service, and is not shared with or sold to other organizations for commercial purposes, except to provide products or services you've requested, when we have your permission, or under the following circumstances: + +* It is necessary to share information in order to investigate, prevent, or take action regarding illegal activities, suspected fraud, situations involving potential threats to the physical safety of any person, violations of [Terms of Service](/terms), or as otherwise required by law. +* We transfer information about you if GitHub is acquired by or merged with another company. In this event, GitHub will notify you before information about you is transferred and becomes subject to a different privacy policy. + +Information Gathering and Usage +------------------------------- + +* When you register for GitHub we ask for information such as your name, email address, billing address, credit card information. Members who sign up for the free account are not required to enter a credit card. +* GitHub uses collected information for the following general purposes: products and services provision, billing, identification and authentication, services improvement, contact, and research. + +Cookies +------- + +* A cookie is a small amount of data, which often includes an anonymous unique identifier, that is sent to your browser from a web site's computers and stored on your computer's hard drive. +* Cookies are required to use the GitHub service. +* We use cookies to record current session information, but do not use permanent cookies. You are required to re-login to your GitHub account after a certain period of time has elapsed to protect you against others accidentally accessing your account contents. + +Data Storage +------------ + +GitHub uses third party vendors and hosting partners to provide the necessary hardware, software, networking, storage, and related technology required to run GitHub. Although GitHub owns the code, databases, and all rights to the GitHub application, you retain all rights to your data. + +Disclosure +---------- + +GitHub may disclose personally identifiable information under special circumstances, such as to comply with subpoenas or when your actions violate the [Terms of Service](/terms). + +Changes +------- + +GitHub may periodically update this policy. We will notify you about significant changes in the way we treat personal information by sending a notice to the primary email address specified in your GitHub primary account holder account or by placing a prominent notice on our site. + +Questions +--------- + +Any questions about this Privacy Policy should be addressed to . diff --git a/_posts/2008-08-02-security.markdown b/_posts/2008-08-02-security.markdown new file mode 100644 index 0000000..e398ba7 --- /dev/null +++ b/_posts/2008-08-02-security.markdown @@ -0,0 +1,87 @@ +--- +layout: default +title: Security +categories: site_policy +--- + +

We know your code is extremely important to you and your business and we're very protective of it. After all, GitHub's code is hosted on GitHub, too!

+ +Physical Security +----------------- + +* Data center access limited to Rackspace data center technicians +* Biometric scanning for controlled data center access +* Security camera monitoring at all data center locations +* 24x7 onsite staff provides additional protection against unauthorized entry +* Unmarked facilities to help maintain low profile +* Physical security audited by an independent firm + +System Security +--------------- + +* System installation using hardened, patched OS +* System patching configured by Rackspace to provide ongoing protection from exploits +* Dedicated firewall and VPN services to help block unauthorized system access +* Data protection with Rackspace managed backup solutions +* Dedicated intrusion detection devices to provide an additional layer of protection against unauthorized system access +* Distributed Denial of Service (DDoS) mitigation services based on Rackspace PrevenTier system +* Risk assessment and security consultation by Rackspace professional services teams + +Operational Security +-------------------- + +* ISO17799-based policies and procedures, regularly reviewed as part of the Rackspace SAS70 Type II audit process +* Systems access logged and tracked for auditing purposes +* Secure document-destruction policies for all sensitive information +* Fully documented change-management procedures +* Independently audited disaster recovery and business continuity plans in place for Rackspace headquarters and support services + +Software Security +----------------- + +In addition to Rackspace's system monitoring, we also employ a team of 24/7/365 server specialists at [Anchor Hosting](http://www.anchor.com.au/dedicated-hosting/dedicated-support.py) to keep our software and its dependencies up to date eliminating potential security vulnerabilities. They have also setup a wide range of monitoring solutions for preventing and eliminating attacks to the site. + +Communications +-------------- + +All private data exchanged with GitHub is always transmitted over SSL (which is why your dashboard is served over HTTPS, for instance). All pushing and pulling of private data is done over SSH authenticated with keys, not passwords. + +The SSH login credentials used to push and pull can not be used to access a shell or the filesystem. All users are virtual (meaning they have no user account on our machines) and are access controlled through the peer reviewed, open source git-shell. + +File system and backups +----------------------- + +Every piece of hardware we use has an identical copy ready and waiting for an immediate hot-swap in case of hardware or software failure. Every line of code we store is saved on a minimum of three different servers, including an off-site backup just in case a meteor ever hits the Rackspace datacenter (we'll keep our fingers crossed that doesn't happen). We do not retroactively remove repositories from backups when deleted by the user, as we may need to restore the repo for the user if it was removed accidentally. + +We do not encrypt repositories on disk because it would not be any more secure: the website and git back-end would need to decrypt the repositories on demand, slowing down response times. Any user with shell access to the file system would have access to the decryption routine, thus negating any security it provides. Therefore, we focus on making our machines and network as secure as possible. + +Employee access +--------------- + +No GitHub employees ever access private repositories unless required to for support reasons. Staff working directly in the file store access the compressed Git database, your code is never present as plaintext files like it would be in a local clone. Support staff may log into your account to access settings related to your support issue. In rare cases staff may need to pull a clone of your code, this will only be done with your consent. Support staff does not have direct access to clone any repo, he will need to temporarily attach his SSH key to your account to pull a clone. When working a support issue we do our best to respect your privacy as much as possible, we only access the files and settings needed to resolve your issue. All cloned repos are deleted as soon as the support issue has been resolved. + +Maintaining security +-------------------- + +We protect your login from brute force attacks with rate limiting. All passwords are filtered from all our logs and encrypted. Login information is always sent over SSL. + +We keep a security consultant on retainer to help identify and prevent new attack vectors. We always test new features in order to cut out potential attacks, such as XSS-protecting wikis, and ensuring that Pages cannot access cookies. + +We also maintain relationships with reputable security firms to perform regular penetration tests and ongoing audits of GitHub and its code. These firms include [nGenuity](http://www.ngenuity-is.com) and [Matasano Security](http://www.matasano.com). + +We're extremely concerned and active about security, but we're aware that many companies are not comfortable hosting code outside their firewall. For these companies we offer our [Firewall Install](http://fi.github.com/), a version of GitHub that can be installed to a server within the company's network. + +Credit card safety +------------------ + +When you sign up for a paid account on GitHub, we do not store any of your card information on our servers. It's handed off to [Braintree Payment Solutions](http://braintreepaymentsolutions.com), a company dedicated to storing your sensitive data on [PCI-Compliant](http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard) servers. + +Contact Us +---------- + +Have a question, concern, or comment about GitHub security? Please email for general inquiries and for emergencies. + +Need to report something? +------------------------- + +Please email us immediately at , this will go directly to one or more of the GitHub founders and will receive our full attention. If we don't respond immediately, there's a good chance we're trying to fix it first. diff --git a/_posts/2008-08-03-terms-of-service.markdown b/_posts/2008-08-03-terms-of-service.markdown new file mode 100644 index 0000000..00b6082 --- /dev/null +++ b/_posts/2008-08-03-terms-of-service.markdown @@ -0,0 +1,127 @@ +--- +layout: default +title: Terms of Service +categories: site_policy +--- + +

By using the GitHub.com web site ("Service"), or any services of GitHub Inc ("GitHub"), you are agreeing to be bound by the following terms and conditions ("Terms of Service"). IF YOU ARE ENTERING INTO THIS AGREEMENT ON BEHALF OF A COMPANY OR OTHER LEGAL ENTITY, YOU REPRESENT THAT YOU HAVE THE AUTHORITY TO BIND SUCH ENTITY, ITS AFFILIATES AND ALL USERS WHO ACCESS OUR SERVICES THROUGH YOUR ACCOUNT TO THESE TERMS AND CONDITIONS, IN WHICH CASE THE TERMS "YOU" OR "YOUR" SHALL REFER TO SUCH ENTITY, ITS AFFILIATES AND USERS ASSOCIATED WITH IT. IF YOU DO NOT HAVE SUCH AUTHORITY, OR IF YOU DO NOT AGREE WITH THESE TERMS AND CONDITIONS, YOU MUST NOT ACCEPT THIS AGREEMENT AND MAY NOT USE THE SERVICES.

+ +

GitHub reserves the right to update and change the Terms of Service from time to time without notice. Any new features that augment or enhance the current Service, including the release of new tools and resources, shall be subject to the Terms of Service. Continued use of the Service after any such changes shall constitute your consent to such changes. You can review the most current version of the Terms of Service at any time at: http://github.com/site/terms

+ +

Violation of any of the terms below will result in the termination of your Account. While GitHub prohibits such conduct and Content on the Service, you understand and agree that GitHub cannot be responsible for the Content posted on the Service and you nonetheless may be exposed to such materials. You agree to use the Service at your own risk.

+ +A. Account Terms +---------------- + +1. You must be 13 years or older to use this Service. + +2. You must be a human. Accounts registered by "bots" or other automated methods are not permitted. + +3. You must provide your legal full name, a valid email address, and any other information requested in order to complete the signup process. + +4. Your login may only be used by one person - a single login shared by multiple people is not permitted. You may create separate logins for as many people as your plan allows. + +5. You are responsible for maintaining the security of your account and password. GitHub cannot and will not be liable for any loss or damage from your failure to comply with this security obligation. + +6. You are responsible for all Content posted and activity that occurs under your account (even when Content is posted by others who have accounts under your account). + +7. One person or legal entity may not maintain more than one free account. + +8. You may not use the Service for any illegal or unauthorized purpose. You must not, in the use of the Service, violate any laws in your jurisdiction (including but not limited to copyright or trademark laws). + + +B. API Terms +------------ + +Customers may access their GitHub account data via an API (Application Program Interface). Any use of the API, including use of the API through a third-party product that accesses GitHub, is bound by these Terms of Service plus the following specific terms: + +1. You expressly understand and agree that GitHub shall not be liable for any direct, indirect, incidental, special, consequential or exemplary damages, including but not limited to, damages for loss of profits, goodwill, use, data or other intangible losses (even if GitHub has been advised of the possibility of such damages), resulting from your use of the API or third-party products that access data via the API. + +2. Abuse or excessively frequent requests to GitHub via the API may result in the temporary or permanent suspension of your account's access to the API. GitHub, in its sole discretion, will determine abuse or excessive usage of the API. GitHub will make a reasonable attempt via email to warn the account owner prior to suspension. + +3. GitHub reserves the right at any time to modify or discontinue, temporarily or permanently, your access to the API (or any part thereof) with or without notice. + + +C. Payment, Refunds, Upgrading and Downgrading Terms +---------------------------------------------------- + +1. All paid plans must enter a valid credit card. Free accounts are not required to provide a credit card number. + +2. __An upgrade from the free plan to any paying plan will immediately bill you.__ + +3. __The Service is billed in advance on a monthly basis and is non-refundable. There will be no refunds or credits for partial months of service, upgrade/downgrade refunds, or refunds for months unused with an open account. In order to treat everyone equally, no exceptions will be made.__ + +4. All fees are exclusive of all taxes, levies, or duties imposed by taxing authorities, and you shall be responsible for payment of all such taxes, levies, or duties, excluding only United States (federal or state) taxes. + +5. For any upgrade or downgrade in plan level, your credit card that you provided will automatically be charged the new rate on your next billing cycle. + +6. Downgrading your Service may cause the loss of Content, features, or capacity of your Account. GitHub does not accept any liability for such loss. + + +D. Cancellation and Termination +------------------------------- + +1. __You are solely responsible for properly canceling your account. An email or phone request to cancel your account is not considered cancellation. You can cancel your account at any time by clicking on the Account link in the global navigation bar at the top of the screen. The Account screen provides a simple no questions asked cancellation link.__ + +2. All of your Content will be immediately deleted from the Service upon cancellation. This information can not be recovered once your account is cancelled. + +3. If you cancel the Service before the end of your current paid up month, your cancellation will take effect immediately and you will not be charged again. + +4. GitHub, in its sole discretion, has the right to suspend or terminate your account and refuse any and all current or future use of the Service, or any other GitHub service, for any reason at any time. Such termination of the Service will result in the deactivation or deletion of your Account or your access to your Account, and the forfeiture and relinquishment of all Content in your Account. GitHub reserves the right to refuse service to anyone for any reason at any time. + + +E. Modifications to the Service and Prices +------------------------------------------ + +1. GitHub reserves the right at any time and from time to time to modify or discontinue, temporarily or permanently, the Service (or any part thereof) with or without notice. + +2. Prices of all Services, including but not limited to monthly subscription plan fees to the Service, are subject to change upon 30 days notice from us. Such notice may be provided at any time by posting the changes to the GitHub Site ([github.com](http://github.com)) or the Service itself. + +3. GitHub shall not be liable to you or to any third party for any modification, price change, suspension or discontinuance of the Service. + + +F. Copyright and Content Ownership +---------------------------------- + +1. We claim no intellectual property rights over the material you provide to the Service. Your profile and materials uploaded remain yours. However, by setting your pages to be viewed publicly, you agree to allow others to view your Content. By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories. + +2. GitHub does not pre-screen Content, but GitHub and its designee have the right (but not the obligation) in their sole discretion to refuse or remove any Content that is available via the Service. + +3. You shall defend GitHub against any claim, demand, suit or proceeding made or brought against GitHub by a third party alleging that Your Content, or Your use of the Service in violation of this Agreement, infringes or misappropriates the intellectual property rights of a third party or violates applicable law, and shall indemnify GitHub for any damages finally awarded against, and for reasonable attorney’s fees incurred by, GitHub in connection with any such claim, demand, suit or proceeding; provided, that GitHub (a) promptly gives You written notice of the claim, demand, suit or proceeding; (b) gives You sole control of the defense and settlement of the claim, demand, suit or proceeding (provided that You may not settle any claim, demand, suit or proceeding unless the settlement unconditionally releases GitHub of all liability); and (c) provides to You all reasonable assistance, at Your expense. + +4. The look and feel of the Service is copyright ©{{ site.time | date: "%Y" }} GitHub Inc. All rights reserved. You may not duplicate, copy, or reuse any portion of the HTML/CSS, Javascript, or visual design elements or concepts without express written permission from GitHub. + + +G. General Conditions +--------------------- + +1. Your use of the Service is at your sole risk. The service is provided on an "as is" and "as available" basis. + +2. Technical support is only provided to paying account holders and is only available via email. Support is only available in English. + +3. You understand that GitHub uses third party vendors and hosting partners to provide the necessary hardware, software, networking, storage, and related technology required to run the Service. + +4. You must not modify, adapt or hack the Service or modify another website so as to falsely imply that it is associated with the Service, GitHub, or any other GitHub service. + +5. You agree not to reproduce, duplicate, copy, sell, resell or exploit any portion of the Service, use of the Service, or access to the Service without the express written permission by GitHub. + +6. We may, but have no obligation to, remove Content and Accounts containing Content that we determine in our sole discretion are unlawful, offensive, threatening, libelous, defamatory, pornographic, obscene or otherwise objectionable or violates +any party's intellectual property or these Terms of Service. + +7. Verbal, physical, written or other abuse (including threats of abuse or retribution) of any GitHub customer, employee, member, or officer will result in immediate account termination. + +8. You understand that the technical processing and transmission of the Service, including your Content, may be transfered unencrypted and involve (a) transmissions over various networks; and (b) changes to conform and adapt to technical requirements of connecting networks or devices. + +9. You must not upload, post, host, or transmit unsolicited email, SMSs, or "spam" messages. + +10. You must not transmit any worms or viruses or any code of a destructive nature. + +11. If your bandwidth usage significantly exceeds the average bandwidth usage (as determined solely by GitHub) of other GitHub customers, we reserve the right to immediately disable your account or throttle your file hosting until you can reduce your bandwidth consumption. + +12. GitHub does not warrant that (i) the service will meet your specific requirements, (ii) the service will be uninterrupted, timely, secure, or error-free, (iii) the results that may be obtained from the use of the service will be accurate or reliable, (iv) the quality of any products, services, information, or other material purchased or obtained by you through the service will meet your expectations, and (v) any errors in the Service will be corrected. + +13. You expressly understand and agree that GitHub shall not be liable for any direct, indirect, incidental, special, consequential or exemplary damages, including but not limited to, damages for loss of profits, goodwill, use, data or other intangible losses (even if GitHub has been advised of the possibility of such damages), resulting from: (i) the use or the inability to use the service; (ii) the cost of procurement of substitute goods and services resulting from any goods, data, information or services purchased or obtained or messages received or transactions entered into through or from the service; (iii) unauthorized access to or alteration of your transmissions or data; (iv) statements or conduct of any third party on the service; (v) or any other matter relating to the service. + +14. The failure of GitHub to exercise or enforce any right or provision of the Terms of Service shall not constitute a waiver of such right or provision. The Terms of Service constitutes the entire agreement between you and GitHub and govern your use of the Service, superceding any prior agreements between you and GitHub (including, but not limited to, any prior versions of the Terms of Service). You agree that these Terms of Service and Your use of the Service are governed under California law. + +15. Questions about the Terms of Service should be sent to . diff --git a/_posts/2008-08-04-dmca-takedown.markdown b/_posts/2008-08-04-dmca-takedown.markdown new file mode 100644 index 0000000..3efab6a --- /dev/null +++ b/_posts/2008-08-04-dmca-takedown.markdown @@ -0,0 +1,71 @@ +--- +layout: default +title: DMCA Takedown +categories: site_policy +--- + +

GitHub, Inc. ("GitHub") supports the protection of intellectual property and asks the users of the website GitHub.com to do the same. It is the policy of GitHub to respond to all notices of alleged copyright infringement.

+ +

Notice is specifically given that GitHub is not responsible for the content on other websites that any user may find or access when using GitHub.com. This notice describes the information that should be provided in notices alleging copyright infringement found specifically on GitHub.com, and this notice is designed to make alleged infringement notices to GitHub as straightforward as possible and, at the same time, minimize the number of notices that GitHub receives that are spurious or difficult to verify. The form of notice set forth below is consistent with the form suggested by the United States Digital Millennium Copyright Act ("DMCA") which may be found at the U.S. Copyright official website: http://www.copyright.gov.

+ +

It is the policy of GitHub, in appropriate circumstances and in its sole discretion, to disable and/or terminate the accounts of users of GitHub.com who may infringe upon the copyrights or other intellectual property rights of GitHub and/or others.

+ +

Our response to a notice of alleged copyright infringement may result in removing or disabling access to material claimed to be a copyright infringement and/or termination of the subscriber. If GitHub removes or disables access in response to such a notice, we will make a reasonable effort to contact the responsible party of our decision so that they may make an appropriate response.

+ +

To file a notice of an alleged copyright infringement with us, you are required to provide a written communication only by email or postal mail. Notice is also given that you may be liable for damages (including costs and attorney fees) if you materially misrepresent that a product or activity is infringing upon your copyright.

+ +A. Copyright Claims +=================== + +To expedite our handling of your notice, please use the following format or refer to Section 512(c)(3) of the Copyright Act. + +1. Identify in sufficient detail the copyrighted work you believe has been infringed upon. This includes identification of the web page or specific posts, as opposed to entire sites. Posts must be referenced by either the dates in which they appear or by the permalink of the post. Include the URL to the concerned material infringing your copyright (URL of a website or URL to a post, with title, date, name of the emitter), or link to initial post with sufficient data to find it. + +2. Identify the material that you allege is infringing upon the copyrighted work listed in Item #1 above. Include the name of the concerned litigious material (all images or posts if relevant) with its complete reference. + +3. Provide information on which GitHub may contact you, including your email address, name, telephone number and physical address. + +4. Provide the address, if available, to allow GitHub to notify the owner/administrator of the allegedly infringing webpage or other content, including email address. + +5. Also include a statement of the following: "I have a good faith belief that use of the copyrighted materials described above on the infringing web pages is not authorized by the copyright owner, or its agent, or the law." + +6. Also include the following statement: "I swear, under penalty of perjury, that the information in this notification is accurate and that I am the copyright owner, or am authorized to act on behalf of the owner, of an exclusive right that is allegedly infringed." + +7. Your physical or electronic signature + +Send the written notification via regular postal mail to the following: + +> GitHub Inc
+> Attn: DMCA takedown
+> 589 Howard St., 4th Floor
+> San Francisco, CA. 94105 + +or email notification to + +B. Counter-Notification Policy +============================== + +To be effective, a Counter-Notification must be a written communication by the alleged infringer provided to GitHub’s Designated Agent (as set forth above) that includes substantially the following: + +1. A physical or electronic signature of the Subscriber; + +2. Identification of the material that has been removed or to which access has been disabled and the location at which the material appeared before it was removed or access to it was disabled; + +3. A statement under penalty of perjury that the Subscriber has a good faith belief that the material was removed or disabled as a result of a mistake or misidentification of the material to be removed or disabled; + +4. The Subscriber's name, address, and telephone number, and a statement that the Subscriber consents to the jurisdiction of Federal District Court for the judicial district of California, or if the Subscriber's address is outside of the United States, for any judicial district in which GitHub may be found, and that the Subscriber will accept service of process from the person who provided notification or an agent of such person. + +Upon receipt of a Counter Notification containing the information as outlined in 1 through 4 above: + +* GitHub shall promptly provide the Complaining Party with a copy of the Counter Notification; + +* GitHub shall inform the Complaining Party that it will replace the removed material or cease disabling access to it within ten (10) business days; + +* GitHub shall replace the removed material or cease disabling access to the material within ten (10) to fourteen (14) business days following receipt of the Counter Notification, provided GitHub’s Designated Agent has not received notice from the Complaining Party that an action has been filed seeking a court order to restrain Subscriber from engaging in infringing activity relating to the material on GitHub's system. + +Finally Notices and Counter-Notices with respect to this website must meet then current statutory requirements imposed by the DMCA; see for details. + +C. Disclosure +============= + +Please note that in addition to being forwarded to the person who provided the allegedly infringing content, a copy of this legal notice (with your personal information removed) will be published at . You can see an example of such a publication at . A link to your published letter may be displayed in place of the removed content. diff --git a/_posts/2009-01-01-set-up-git-redirect.markdown b/_posts/2009-01-01-set-up-git-redirect.markdown new file mode 100644 index 0000000..afecf45 --- /dev/null +++ b/_posts/2009-01-01-set-up-git-redirect.markdown @@ -0,0 +1,9 @@ +--- +layout: os_redirect +title: Set Up Git +description: A quick guide to help you get started with Git +categories: beginner +redirect_win: /win-set-up-git +redirect_mac: /mac-set-up-git +redirect_linux: /linux-set-up-git +--- diff --git a/_posts/2009-01-30-forking.markdown b/_posts/2009-01-30-forking.markdown new file mode 100644 index 0000000..aaf8b5b --- /dev/null +++ b/_posts/2009-01-30-forking.markdown @@ -0,0 +1,6 @@ +--- +layout: redirect +title: Forking a project +description: How to fork a project, submit changes, and pull from other repos in the fork network +redirect_to: /fork-a-repo +--- diff --git a/_posts/2009-06-11-forking.markdown b/_posts/2009-06-11-forking.markdown deleted file mode 100644 index aaf8b5b..0000000 --- a/_posts/2009-06-11-forking.markdown +++ /dev/null @@ -1,6 +0,0 @@ ---- -layout: redirect -title: Forking a project -description: How to fork a project, submit changes, and pull from other repos in the fork network -redirect_to: /fork-a-repo ---- diff --git a/_posts/2009-06-13-fork-a-repo.markdown b/_posts/2009-06-13-fork-a-repo.markdown deleted file mode 100644 index eccf8df..0000000 --- a/_posts/2009-06-13-fork-a-repo.markdown +++ /dev/null @@ -1,160 +0,0 @@ ---- -layout: default -title: Fork A Repo -description: Copy a repo to create a new, unique project from its contents. -categories: beginner ---- - -If you’ve found yourself on this page, we’re assuming you’re brand new to Git and GitHub. This guide will walk you through the basics and explain a little bit about how everything works along the way. - -##First: Fork A Repo - -At some point you may find yourself wanting to contribute to someone else's project, or would like to use someone's project as the starting point for your own. This is known as “forking.” For this tutorial, we’ll be using the Spoon-Knife project. - -1. Fork the “Spoon-Knife ” repo - - To fork this project, click the “Fork” button. - - Click “Fork - -##Next: Set Up Your Local Repo - -You’ve successfully forked the Spoon-Knife repo, but so far it only exists on GitHub. To be able to work on the project, you will need to clone it to your local machine. - -1. Clone the “Spoon-Knife” project - - Run the following code: - - 
-	$ git clone git@github.com:username/Spoon-Knife.gitClones your copy of the repo into the current directory in terminal
-
- -2. Configure remotes - - When a repo is cloned, it has a default remote called `origin` that points to your fork on GitHub, not the original repo it was forked from. To keep track of the original repo, you need to add another remote named `upstream`: - -
-

More about remotes

-
-

- A remote is a repo stored on another computer, in this case on GitHub’s server. It is standard practice (and also the default in some cases) to give the name origin to the remote that points to your main offsite repo (for example, your GitHub repo). -

-

- Git supports multiple remotes. This is commonly used when forking a repo. -

-
-
- - 
-	$ cd Spoon-KnifeChanges the active directory in the prompt to the newly cloned "Spoon-Knife" directory
-	$ git remote add upstream git://github.com/octocat/Spoon-Knife.gitAssigns the original repo to a remote called "upstream"
-	$ git fetch upstreamPulls in any changes not present in your local repository, but doesn't modify your working files
-
- -##Then: More Things You Can Do - -You’ve successfully forked a repo, but get a load of these other cool things you can do: - -- Push commits - - Once you’ve made some commits to a forked repo and want to push it to your forked project, you do it the same way you would with a regular repo: - -
-

More about commits

-
-

- Think of a commit as a snapshot of your project —code, files, everything — at a particular point in time. More accurately, after your first commit, each subsequent commit is only a snapshot of your changes. For code files, this means it only takes a snapshot of the lines of code that have changed. For everything else like music or image files, it saves a new copy of the file. -

-
-
- - 
-	$ git push origin masterPushes commits to your remote repo stored on GitHub
-
- -- Pull in upstream changes - - If the original repo you forked your project from gets updated, you can add those updates to your fork by running the following code: - - 
-	$ git fetch upstreamFetches any new changes from the original repo
-	$ git merge upstream/masterMerges any changes fetched into your working files
-
- -
-

What is the difference between fetch and pull?

-
-

- There are two ways to get commits from a remote repo or branch: fetch and pull. While they might seem similar at first, there are distinct differences you should consider. -

-

Pull

- 
-					$ git pull upstreamPulls commits from 'upstream' and adds them to the local repo
-
-

When you use pull, Git tries to automatically do your work for you. It is context sensitive, so Git will merge any pulled commits into the branch you are currently working in. One thing to keep in mind is that pull automatically merges the commits without letting you review them first. If you don’t closely manage your branches you may run into frequent conflicts.

- -

Fetch/Merge

- 
-					$ git fetch upstreamFetches any new commits from the original repo
-					$ git merge upstream/masterMerges any commits fetched into your working files
-
-

When you fetch, Git gathers any commits from the target branch that do not exist in your current branch and stores them in your local repo. However, it does not merge them with your current branch. This is particularly useful if you need to keep your repo up to date but are working on something that might break if you update your files. To integrate the commits into your master branch, you use merge. This combines the specified branches and prompts you if there are any conflicts.

-
-
- -- Work with branches - - Branching allows you to build new features or test out ideas without putting your main project at risk. A Git branch is a small file that references the commit it was spawned from. This makes Git branches very small and easy to work with. - -
-

How do I use branches?

-
- -

- Branches are pretty easy to work with and will save you a lot of headaches, especially when working with multiple people. To create a branch and begin working in it, use the following script: -

- - 
-				$ git branch mybranchCreates a new branch called "mybranch"
-				$ git checkout mybranchMakes "mybranch" the active branch
-
- -

Alternatively, you can use the shortcut:

- - 
-				$ git checkout -b mybranchCreates a new branch called "mybranch" and makes it the active branch
-
- -

To switch between branches, use checkout.

- - 
-				$ git checkout masterMakes "master" the active branch
-				$ git checkout mybranchMakes "mybranch" the active branch
-
- -

Once you’re finished working on your branch and are ready to combine it back into the master branch, use merge.

- - 
-				$ git checkout masterMakes "master" the active branch
-				$ git merge mybranchMerges the commits from "mybranch" into "master"
-				$ git branch -d mybranchDeletes the "mybranch" branch
-
- -
-
- - -- Pull requests - - If you are hoping to contribute back to the original fork, you can send the original author a [pull request](/pull-requests/). - -##Lastly: Celebrate - -You have now created forked a repo. What do you want to do next? - -
    -
  1. Set Up Git
    2. -
  2. Create A Repository
    3. -
  3. Fork A Repository
    4. -
  4. Be Social
    5. -
\ No newline at end of file diff --git a/_posts/2009-06-13-linux-set-up-git.markdown b/_posts/2009-06-13-linux-set-up-git.markdown deleted file mode 100644 index 474df21..0000000 --- a/_posts/2009-06-13-linux-set-up-git.markdown +++ /dev/null @@ -1,92 +0,0 @@ ---- -layout: default -title: Set Up Git (Linux) -description: A quick guide to help you get started with Git ---- - -If you’ve found yourself on this page, we’re assuming you’re brand new to Git and GitHub. This guide will walk you through the basics and explain a little bit about how everything works along the way. - -##First: Download and Install Git - -At the heart of GitHub is an open source version control system (VCS) called Git*. Created by the same dudes that created Linux, Git is responsible for everything GitHub related that happens locally on your computer. - -_*If you don’t already know what Git is, take a crash course._ - -1. Download and install the latest version of Git with Synaptic. - - We suggest you install git-core, git-gui, and git-doc. - - Open Synaptic - Mark git-core, git-gui, and git-doc for installation - git-core, git-gui, and git-doc are selected - - When you’ve selected git-core, git-gui, and git-doc, hit “Apply” to install them. - - Click Apply - - If you don’t have a package manager like Synaptic, or you’d rather install the necessary git components from the command line, you can alternatively run the script below: - - 
-		$ sudo apt-get install git-core git-gui git-docInstalls git-core, git-gui, and git-doc on your system
-
- - __*Note*__ Don’t worry that you don’t see an icon when it’s done. It’s not that kind of application. - -##Next: Set Up SSH Keys - -We use SSH keys to establish a secure connection between your computer and GitHub. Setting them up is fairly easy, but does involve a number of steps. - -To make sure you generate a brand new key, you need to check if one already exists. First, you need to open an app called Terminal. - -Open the terminal - -
-

Need a quick lesson about Terminal?

-
-

Code blocks like those on this page are part of a scripting language called Bash. To use Bash scripts, we need to use an application that comes with Linux called Terminal.

- -

Input

- 
-			$ echo 'This is input text'This tooltip tells you what's going on.
-
- -

A line that begins with the dollar sign ($) indicates a line of Bash script you need to type. To enter it, type the text that follows the $, hitting the return key at the end of each line. You can hover your mouse over each line for an explanation of what the script is doing.

- -

Output

- 
-			This is output text.
-
- -

A line that does not begin with a $ is output text that is intended to give you information or tell you what to do next. We’ve colored output text green in these bootcamp tutorials.

- -

User Specific Input

- 
-			$ echo 'username'Outputs the text in the quotation marks.
-
- -

Areas of yellow text represent your own personal info, repos, etc. If it is part of an input ($) line, you should replace your it with your own info when you type it. If it is part of output text, it is just for your reference. It will automatically show your own info in Terminal.

- -

Good to know: There will be times when you type code, hit return, and all you are given is another prompt. Some actions that you execute in Terminal don’t have any output. Don’t worry, if there is ever a problem with your code, Terminal will let you know.

- -

Good to know: For security reasons, Terminal will not display what you type when entering passwords. Just type your password and hit the return key.

-
-
- -{% include ssh_setup.markdown %} - -##Then: Set Up Your Info - -Now that you have Git set up and your SSH keys entered into GitHub, it’s time to configure your personal info. - -{% include email_setup.markdown %} - -##Lastly: Celebrate - -Congratulations, you now have Git and GitHub all set up! What do you want to do next? - -
    -
  1. Set Up Git
    2. -
  2. Create A Repository
    3. -
  3. Fork A Repository
    4. -
  4. Be Social
    5. -
\ No newline at end of file diff --git a/_posts/2009-06-13-mac-set-up-git.markdown b/_posts/2009-06-13-mac-set-up-git.markdown deleted file mode 100644 index bf270d5..0000000 --- a/_posts/2009-06-13-mac-set-up-git.markdown +++ /dev/null @@ -1,76 +0,0 @@ ---- -layout: default -title: Set Up Git (OSX) -description: A quick guide to help you get started with Git ---- - -If you’ve found yourself on this page, we’re assuming you’re brand new to Git and GitHub. This guide will walk you through the basics and explain a little bit about how everything works along the way. - -##First: Download and Install Git - -At the heart of GitHub is an open source version control system (VCS) called Git*. Created by the same dudes that created Linux, Git is responsible for everything GitHub related that happens locally on your computer. - -_*If you don’t already know what Git is, take a crash course._ - -1. Download and install the latest version of Git. - - __*Note*__ Don’t worry that you don’t see an icon when it’s done. It’s not that kind of application. - -##Next: Set Up SSH Keys - -We use SSH keys to establish a secure connection between your computer and GitHub. Setting them up is fairly easy, but does involve a number of steps. - -To make sure you generate a brand new key, you need to check if one already exists. First, you need to open Terminal.app, usually found at /Applications/Utilities. - -Open the terminal - -
-

Need a quick lesson about Terminal?

-
-

Code blocks like those on this page are part of a scripting language called Bash. To use Bash scripts, we need to use an application that comes with your Mac called Terminal.

- -

Input

- 
-			$ echo 'This is input text'This tooltip tells you what's going on.
-
- -

A line that begins with the dollar sign ($) indicates a line of Bash script you need to type. To enter it, type the text that follows the $, hitting the return key at the end of each line. You can hover your mouse over each line for an explanation of what the script is doing.

- -

Output

- 
-			This is output text.
-
- -

A line that does not begin with a $ is output text that is intended to give you information or tell you what to do next. We’ve colored output text green in these bootcamp tutorials.

- -

User Specific Input

- 
-			$ echo 'username'Outputs the text in the quotation marks.
-
- -

Areas of yellow text represent your own personal info, repos, etc. If it is part of an input ($) line, you should replace it with your own info when you type it. If it is part of output text, it is just for your reference. It will automatically show your own info in Terminal.

- -

Good to know: There will be times when you type code, hit return, and all you are given is another prompt. Some actions that you execute in Terminal don’t have any output. Don’t worry, if there is ever a problem with your code, Terminal will let you know.

- -

Good to know: For security reasons, Terminal will not display what you type when entering passwords. Just type your password and hit the return key.

-
-
- -{% include ssh_setup.markdown %} - -##Then: Set Up Your Info - -Now that you have Git set up and your SSH keys entered into GitHub, it’s time to configure your personal info. - -{% include email_setup.markdown %} - -##Lastly: Celebrate - -Congratulations, you now have Git and GitHub all set up! What do you want to do next? - -
    -
  1. Set Up Git
    2. -
  2. Create A Repository
    3. -
  3. Fork A Repository
    4. -
  4. Be Social
    5. -
\ No newline at end of file diff --git a/_posts/2009-06-13-win-set-up-git.markdown b/_posts/2009-06-13-win-set-up-git.markdown deleted file mode 100644 index 91e6bd2..0000000 --- a/_posts/2009-06-13-win-set-up-git.markdown +++ /dev/null @@ -1,92 +0,0 @@ ---- -layout: default -title: Set Up Git (Windows) -description: A quick guide to help you get started with Git ---- - -If you’ve found yourself on this page, we’re assuming you’re brand new to Git and GitHub. This guide will walk you through the basics and explain a little bit about how everything works along the way. - -##First: Download and Install Git - -At the heart of GitHub is an open source version control system (VCS) called Git*. Created by the same dudes that created Linux, Git is responsible for everything GitHub related that happens locally on your computer. - -_*If you don’t already know what Git is, take a crash course._ - -1. Download and install the latest version of msysgit. - - Use the default options for each step. - - Welcome page - Information - Select destination location - Select start menu folder - Select components - Adjusting your PATH environment - Configuring the line ending conversions - Installing - Installation complete - - - __Do not use PuTTY if you are given the option. GitHub only provides support for openssh.__ - -##Next: Set Up SSH Keys - -We use SSH keys to establish a secure connection between your computer and GitHub. Setting them up is fairly easy, but does involve a number of steps. - -To make sure you generate a brand new key, you need to check if one already exists. First, you need to open Git Bash (not the Windows command line), found in the start menu in the git. - -Open the terminal - -
-

Need a quick lesson about Git Bash?

-
-

Code blocks like those on this page are part of a scripting language called Bash. To use Bash scripts, we need to use an application that was installed with Git called Git Bash.

- -

Input

- 
-			$ echo 'This is input text'This tooltip tells you what's going on.
-
- -

A line that begins with the dollar sign ($) indicates a line of Bash script you need to type. To enter it, type the text that follows the $, hitting the return key at the end of each line. You can hover your mouse over each line for an explanation of what the script is doing.

- -

Output

- 
-			This is output text.
-
- -

A line that does not begin with a $ is output text that is intended to give you information or tell you what to do next. We’ve colored output text green in these bootcamp tutorials.

- -

User Specific Input

- 
-			$ echo 'username'Outputs the text in the quotation marks.
-
- -

Areas of yellow text represent your own personal info, repos, etc. If it is part of an input ($) line, you should replace it with your own info when you type it. If it is part of output text, it is just for your reference. It will automatically show your own info in Git Bash.

- -

Good to know: There will be times when you type code, hit return, and all you are given is another prompt. Some actions that you execute in Git Bash don’t have any output. Don’t worry, if there is ever a problem with your code, Git Bash will let you know.

- -

Good to know: For security reasons, Git Bash will not display what you type when entering passwords. Just type your password and hit the return key.

-
-
- -{% include ssh_setup.markdown %} - -##Then: Set Up Your Info - -Now that you have Git set up and your SSH keys entered into GitHub, it’s time to configure your personal info. - -{% include email_setup.markdown %} - -##Lastly: Celebrate - -Congratulations, you now have Git and GitHub all set up! What do you want to do next? - -
    -
  1. Set Up Git
    2. -
  2. Create A Repository
    3. -
  3. Fork A Repository
    4. -
  4. Be Social
    5. -
- \ No newline at end of file diff --git a/_posts/2009-06-16-troubleshooting-common-issues.markdown b/_posts/2009-06-16-troubleshooting-common-issues.markdown deleted file mode 100644 index fc886c0..0000000 --- a/_posts/2009-06-16-troubleshooting-common-issues.markdown +++ /dev/null @@ -1,38 +0,0 @@ ---- -layout: default -title: Common issues and questions -description: Solutions to the most common issues and answers to common questions -categories: troubleshooting popular ---- - -I can't push, "Permission denied (publickey)" ---------------------------------------------- - -Make sure you've [set up an SSH key](/key-setup-redirect) and are using the correct URL (they are case-sensitive). Check [this guide](/troubleshooting-ssh) for more information. - -My commits aren't linked to my user, to the wrong user, or don't have a Gravatar ------------------------------------------------------------------------------------ - -Make sure your [git](/git-email-settings) and [GitHub](https://github.com/account#email_bucket) email settings match. - -You may also need to check your Gravatar account to make sure your Gravatar has a "G" rating. - -I changed my Gravatar but it's not updating -------------------------------------------- - -Gravatar images are cached for a very long time. Clear your browser's cache. - -Syntax highlighting isn't working for my language -------------------------------------------------- - -We use the excellent [pygments](http://pygments.org/) library for our syntax highlighting. Check their list of [supported languages](http://pygments.org/languages/) and learn how to specify a lexer for yours. If you contribute a lexer back to pygments, let us know and we’ll make sure it’s made available here on GitHub. - -Can I use Eclipse/EGit with GitHub? ------------------------------------ - -Yes, see [this writup](http://gist.github.com/423316) for help. - -Are there any screencasts or other resources out there for git? ---------------------------------------------------------------- - -Yes, you can find a *(probably incomplete)* list [here](http://gist.github.com/423320). diff --git a/_posts/2009-06-17-troubleshooting-ssh.textile b/_posts/2009-06-17-troubleshooting-ssh.textile deleted file mode 100644 index 7e58cf8..0000000 --- a/_posts/2009-06-17-troubleshooting-ssh.textile +++ /dev/null @@ -1,94 +0,0 @@ ---- -layout: default -title: Troubleshooting SSH issues -description: Solutions to common SSH issues -categories: troubleshooting popular -main_category: troubleshooting ---- - -

This guide contains the solutions to the most common SSH connection issues encountered on GitHub.

- -The first step to testing your connection is to run ssh git@github.com. If your key works, you should get a success message: -
$ ssh git@github.com
-Hi username! You've successfully authenticated, but GitHub does not provide shell access.
- -If this step fails, try running ssh -v git@github.com. This will print out debug info on what ssh is trying to do. In this output you should check that ssh is connecting to the correct server, on the correct port (22). Many firewalls and proxies will block this connection. Also ensure that ssh is reading the correct key files, these are at ~/.ssh/id_rsa, id_dsa and identity by default. If your key is not at this location, you should move it or create an override (see the "SSH config" section below). - -h2. Permission to user/repo2 denied to user/repo1 - -This error occurs when you attach your key as a deploy key on repo1. You can push and pull from that repo without issue, but you won't have access to any other repo with your key. To solve this, remove the key from repo1's deploy keys and attach it on your "account page":https://github.com/account instead. This key will now have access to all repos your account has access to. - -h2. Permission denied (publickey) - -This is usually caused when ssh cannot find your keys. Make sure your key is in the default location, @~/.ssh@. If you run @ssh-keygen@ again and just press enter at all 3 prompts it will be placed here automatically. Then you can add the contents of id_rsa.pub to "your account":https://github.com/account#ssh_bucket. If id_rsa.pub doesn't work try id_dsa.pub. You might need to generate a new dsa key with @ssh-keygen -t dsa@ if you just have an rsa key. - -h3. Finding out what keys ssh is using - -Finding what keys ssh is offering to the server is fairly simple. Run ssh -v git@github.com and look at the output: - -
debug1: Next authentication method: publickey
-debug1: Trying private key: /Users/tekkub/.ssh/identity
-debug1: Trying private key: /Users/tekkub/.ssh/id_rsa
-debug1: Trying private key: /Users/tekkub/.ssh/id_dsa
-debug1: No more authentication methods to try.
- -In this example, SSH could not find any keys ("Trying" means ssh is trying to find the key on disk). We should either rename our keypair to use a default name, or run @ssh-add path/to/key@ to make SSH aware of the key's existence. - -
debug1: Next authentication method: publickey
-debug1: Offering public key: /Users/tekkub/.ssh/id_rsa
-debug1: Remote: Forced command: gerve tekkub
-...
-ERROR: Hi tekkub! You've successfully authenticated, but GitHub does not provide shell access
- -Here we've renamed our keypair to @~/.ssh/id_rsa@. SSH finds the key and offers it to the server. This key works and we authenticate as user "tekkub". - -h2. Issues when using sudo - -

You shouldn't run @sudo git@ unless you have a very good reason. If you don't know if you have a good reason to use sudo, it's likely that you do not have one.

- -If you are using sudo with git commands (e.g. using sudo git clone because you are deploying to a root-owned folder), ensure that you also generated the key using sudo. Otherwise, you will have generated a key for your current user, but when you are doing sudo git, you are actually the root user - thus, the keys will not match. - -Simply put, if you are using sudo git, then also use sudo ssh-keygen. - -h2. SSH config - -If your github authentication information is different from your machine account information, you'll need to modify your ssh configuration file. - -Create or open the file at ~/.ssh/config Add the following lines: - -
Host github.com
-	User git
-	Hostname github.com
-	PreferredAuthentications publickey
-	IdentityFile [local path to private key half of github public key you provided]
- -You may also need to update the permissions on your .ssh folder and its contents. The SSH application will ignore secret files that are too permissive. - -
$ chmod 700 ~/.ssh
-$ chmod 600 ~/.ssh/*
- -h2. No supported authentication methods available - -You should be aware of the environment variable GIT_SSH, which is used by git to find your ssh-speaking client, if ssh doesn't work for you. The git install may be using plink.exe (via GIT_SSH) to perform the authentication. If so, make sure you have pageant.exe running, and the key you created for github loaded into it. This provides the key to plink.exe; without it, the above error will occur. - -See "this post":http://groups.google.com/group/github/browse_thread/thread/21fd06fb8c3f43bd/f5c44b2197d1be15 for a longer discussion. - -Especially with cygwin-git+pageant+putty/plink, you might want to set GIT_SSH to your plink.exe location -- unless that doesn't work for you. In certain circumstances (perhaps after a service pack installation), you will find git network operations failing with -this is because plink.exe running from your (cygwin-provided) git command "*can't talk with pageant to get its keys*":http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/cygwin-clobbers-pageant.html . A solution is to set up a script that has: -
/cygdrive/c/ntnot/plink.exe -i "c:\users\you\.ssh\key-file-for-github.ppk" $1 $2
- -and set GIT_SSH to point to this: - -
declare -x GIT_SSH="c:\path\to\script"
- -This explicitly provides the key for plink to use, rather than have it talk with pageant. - -This problem occured for me when I used the executable with pageant that came with WinSCP, but a version of plink in a different directory. I have not found the exact cause yet. All versions were plink/pageant 0.60. (Not running under Cygwin) - -p(. I did not have luck with this approach; GIT_SSH was set to plink.exe already; when I tried to create this script and reset the GIT_SSH I got a "could not fork" error back from git even though the script would run happily on its own - elijahsmith 9/11/08 - -p(. I couldn't get the latest versions of plink and pageant (as of 2008-Nov-15) to talk, and I'm not running Cygwin. The only solution was to revert to using open-ssh by setting @GIT_SSH@ to @C:\Program Files\prg\Git\bin\ssh.exe@. -- "dandv":http://github.com/dandv - -h2. On Windows, you can't type "y" to confirm the "Store [server's host] key in cache?" prompt - -This happens because git eats up the ssh client's STDIN output. To work around that, launch @ssh github.com@ or @plink.exe -agent github.com@ standalone and press "y" at the prompt. diff --git a/_posts/2009-06-20-git-email-settings.markdown b/_posts/2009-06-20-git-email-settings.markdown deleted file mode 100644 index e29eec5..0000000 --- a/_posts/2009-06-20-git-email-settings.markdown +++ /dev/null @@ -1,12 +0,0 @@ ---- -layout: default -title: Setting user name, email and GitHub token -description: Configure your local git installation so that commits are linked to your GitHub account -categories: troubleshooting popular ---- - -

This guide covers basic git settings you should set before making any commits.

- -

Please note that config changes will only affect future commits. Existing commits will retain the info they were committed with. Also, the environment variables GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL will override git-config settings if they are defined.

- -{% include email_setup.markdown %} diff --git a/_posts/2009-06-23-security.markdown b/_posts/2009-06-23-security.markdown deleted file mode 100644 index b136465..0000000 --- a/_posts/2009-06-23-security.markdown +++ /dev/null @@ -1,87 +0,0 @@ ---- -layout: default -title: GitHub Security -categories: site_policy ---- - -

We know your code is extremely important to you and your business and we're very protective of it. After all, GitHub's code is hosted on GitHub, too!

- -Physical Security ------------------ - -* Data center access limited to Rackspace data center technicians -* Biometric scanning for controlled data center access -* Security camera monitoring at all data center locations -* 24x7 onsite staff provides additional protection against unauthorized entry -* Unmarked facilities to help maintain low profile -* Physical security audited by an independent firm - -System Security ---------------- - -* System installation using hardened, patched OS -* System patching configured by Rackspace to provide ongoing protection from exploits -* Dedicated firewall and VPN services to help block unauthorized system access -* Data protection with Rackspace managed backup solutions -* Dedicated intrusion detection devices to provide an additional layer of protection against unauthorized system access -* Distributed Denial of Service (DDoS) mitigation services based on Rackspace PrevenTier system -* Risk assessment and security consultation by Rackspace professional services teams - -Operational Security --------------------- - -* ISO17799-based policies and procedures, regularly reviewed as part of the Rackspace SAS70 Type II audit process -* Systems access logged and tracked for auditing purposes -* Secure document-destruction policies for all sensitive information -* Fully documented change-management procedures -* Independently audited disaster recovery and business continuity plans in place for Rackspace headquarters and support services - -Software Security ------------------ - -In addition to Rackspace's system monitoring, we also employ a team of 24/7/365 server specialists at [Anchor Hosting](http://www.anchor.com.au/dedicated-hosting/dedicated-support.py) to keep our software and its dependencies up to date eliminating potential security vulnerabilities. They have also setup a wide range of monitoring solutions for preventing and eliminating attacks to the site. - -Communications --------------- - -All private data exchanged with GitHub is always transmitted over SSL (which is why your dashboard is served over HTTPS, for instance). All pushing and pulling of private data is done over SSH authenticated with keys, not passwords. - -The SSH login credentials used to push and pull can not be used to access a shell or the filesystem. All users are virtual (meaning they have no user account on our machines) and are access controlled through the peer reviewed, open source git-shell. - -File system and backups ------------------------ - -Every piece of hardware we use has an identical copy ready and waiting for an immediate hot-swap in case of hardware or software failure. Every line of code we store is saved on a minimum of three different servers, including an off-site backup just in case a meteor ever hits the Rackspace datacenter (we'll keep our fingers crossed that doesn't happen). We do not retroactively remove repositories from backups when deleted by the user, as we may need to restore the repo for the user if it was removed accidentally. - -We do not encrypt repositories on disk because it would not be any more secure: the website and git back-end would need to decrypt the repositories on demand, slowing down response times. Any user with shell access to the file system would have access to the decryption routine, thus negating any security it provides. Therefore, we focus on making our machines and network as secure as possible. - -Employee access ---------------- - -No GitHub employees ever access private repositories unless required to for support reasons. Staff working directly in the file store access the compressed Git database, your code is never present as plaintext files like it would be in a local clone. Support staff may log into your account to access settings related to your support issue. In rare cases staff may need to pull a clone of your code, this will only be done with your consent. Support staff does not have direct access to clone any repo, he will need to temporarily attach his SSH key to your account to pull a clone. When working a support issue we do our best to respect your privacy as much as possible, we only access the files and settings needed to resolve your issue. All cloned repos are deleted as soon as the support issue has been resolved. - -Maintaining security --------------------- - -We protect your login from brute force attacks with rate limiting. All passwords are filtered from all our logs and encrypted. Login information is always sent over SSL. - -We keep a security consultant on retainer to help identify and prevent new attack vectors. We always test new features in order to cut out potential attacks, such as XSS-protecting wikis, and ensuring that Pages cannot access cookies. - -We also maintain relationships with reputable security firms to perform regular penetration tests and ongoing audits of GitHub and its code. These firms include [nGenuity](http://www.ngenuity-is.com) and [Matasano Security](http://www.matasano.com). - -We're extremely concerned and active about security, but we're aware that many companies are not comfortable hosting code outside their firewall. For these companies we offer our [Firewall Install](http://fi.github.com/), a version of GitHub that can be installed to a server within the company's network. - -Credit card safety ------------------- - -When you sign up for a paid account on GitHub, we do not store any of your card information on our servers. It's handed off to [Braintree Payment Solutions](http://braintreepaymentsolutions.com), a company dedicated to storing your sensitive data on [PCI-Compliant](http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard) servers. - -Contact Us ----------- - -Have a question, concern, or comment about GitHub security? Please email for general inquiries and for emergencies. - -Need to report something? -------------------------- - -Please email us immediately at , this will go directly to one or more of the GitHub founders and will receive our full attention. If we don't respond immediately, there's a good chance we're trying to fix it first. diff --git a/_posts/2009-06-25-deleting-a-repo.markdown b/_posts/2009-06-25-deleting-a-repo.markdown deleted file mode 100644 index 05da252..0000000 --- a/_posts/2009-06-25-deleting-a-repo.markdown +++ /dev/null @@ -1,18 +0,0 @@ ---- -layout: default -title: Deleting a repo -description: How to remove a repo from your GitHub account -categories: beginner ---- - -

Deleting a private repo will delete all forks of the repo. Deleting a public repo will not.

- -Go to the repository homepage → Admin: - -![](http://img.skitch.com/20100110-jps511wbqpmjpgp16m8g17iiut.jpg) - -At the bottom of the page there is a button to delete the repo: - -![](http://img.skitch.com/20100527-fgtcuthgr5xrbcyqmxgiue5jwb.png) - -Collaborators can not delete repos, but they can [leave them](/leave-a-repo). diff --git a/_posts/2009-06-25-moving-a-repo.markdown b/_posts/2009-06-25-moving-a-repo.markdown deleted file mode 100644 index 3f33ac5..0000000 --- a/_posts/2009-06-25-moving-a-repo.markdown +++ /dev/null @@ -1,63 +0,0 @@ ---- -layout: default -title: Moving a repo -description: How to move a repo from one account to another -categories: beginner ---- - -This guide details the process of moving a repo to another account. - -Direct move ------------ - -If you wish to move a repo between users or organizations, please [contact support](http://support.github.com/) following the details below. - -**What to check before creating the support request** - -1. Make sure that there is not a repo with the same name on the destination account. - -2. Make sure the destination account has unused private repos available if the repo being moved is private. - -3. **Please** make sure you login with the account that owns the repositories you want support to move for you. If the repositories belong to different accounts, please create one support request per account. - -**What to include in your support request** - -1. List the repositories you want support to move. - -2. Tell us the destination account (the username) - -**Example** - -*Subject:* Move repositories - -*Repositories* - - myaccount/repoA - myaccount/repoB - myaccount/repoC - -*Destination* - - destinationaccount - -Existing forks --------------- - -If a fork of the repo you wish to move already exists on the target account, you can [contact support](http://support.github.com/) to have the roots switched. Note that deleting the root repo will either delete all forks if the repo is private, or automatically pick a new root if the repo is public. You cannot pick which repo will become the root, so please contact support if you want a specific repo to become the new root. - -Note that if the repo is private the new owner will need a paid plan to support the repo. Issues, wikis, pages, commits comments and non-repo downloads **will not** be transferred to the new root. Make sure you do not delete your old repo if you have any of these you wish to keep. - -Manual clone and push ---------------------- - -If you have a repo on an external server that you wish to move to GitHub, you can move it with a special clone and push. This method will create an exact mirror of the repo into the new repo. - -First, create a new repo on the target account. Next, create a mirror that includes all branches and tags. To do this you need to do a bare-clone followed by a mirror-push: - -
-git clone --bare url/for/my-old-repo.git
-cd my-old-repo.git
-git push --mirror git@github.com:mycompany/my-new-repo.git
-cd ..
-rm -rf my-old-repo.git
-
diff --git a/_posts/2009-07-04-git-html-help.markdown b/_posts/2009-07-04-git-html-help.markdown deleted file mode 100644 index 6c268b0..0000000 --- a/_posts/2009-07-04-git-html-help.markdown +++ /dev/null @@ -1,40 +0,0 @@ ---- -layout: default -title: Installing Git HTML help -description: How to install the local git HTML help files -categories: intermediate ---- - -

This guide will help you install the local git HTML help files and set git to use them by default instead of the man pages.

- -

Most git installations will install man files for help, but not the HTML help files (the same files seen on git's online documentation). Installing these help files is a fairly simple process.

- -Windows -------- - -[Msysgit](http://code.google.com/p/msysgit/) installs and sets the HTML help files as the default automatically. You don't need to do anything! - -OSX ---- - -To install web docs we simply need to clone the main git repo to the correct path and check out the "html" branch. Your documentation path may be different, pay attention to the output of `git help --web commit` for where your git is set to look for the HTML files. - -
-$ git help --web commit
-fatal: '/usr/local/git/share/doc/git-doc': not a documentation directory.
-
-$ sudo mkdir -p /usr/local/git/share/doc
-$ cd /usr/local/git/share/doc
-$ sudo git clone git://git.kernel.org/pub/scm/git/git.git git-doc --branch html
-
- -To verify that the web docs now work, run `git help --web commit`. If your browser launches then you're good to go. You can now set git to default to the web docs by running `git config --global help.format web` - -### Updating the docs - -Updating is a simple matter of pulling: - -
-$ cd /usr/local/git/share/doc
-$ sudo git pull
-
diff --git a/_posts/2009-09-03-working-with-key-passphrases.textile b/_posts/2009-09-03-working-with-key-passphrases.textile deleted file mode 100644 index 8a0bfc6..0000000 --- a/_posts/2009-09-03-working-with-key-passphrases.textile +++ /dev/null @@ -1,125 +0,0 @@ ---- -layout: default -title: Working with SSH key passphrases -description: SSH key passphrases, why you should use them, and how to avoid re-entering them -categories: troubleshooting ---- - -

This guide will step you through the process of securing your ssh keys while avoiding re-entry of your passphrase every time you use the key.

- -h2. Why do I need a passphrase? - -Passwords aren't very secure, you already know this. If you use one that's easy to remember, it's easier to guess or brute-force. If you use one that's random it's hard to remember, and thus you're more inclined to write the password down. Both of these are Very Bad Things™. This is why you're using ssh keys. - -But using a key without a passphrase is basically the same as writing down that random password in a file on your computer. Anyone who gains access to your drive has gained access to every system you use that key with. This is also a Very Bad Thing™. The solution is obvious, add a passphrase. - -h3. But I don't want to enter a long passphrase every time I use the key! - -Neither do I! Thankfully, there's a nifty little tool called @ssh-agent@ that can save your passphrase securely so you don't have to re-enter it. If you're on OSX Leopard or later your keys can be saved in the system's keychain to make your life even easier. Most linux installations will automatically start @ssh-agent@ for you when you log in. - -h2. Adding or changing a passphrase - -Passphrases can be added to an existing key or changed without regenerating the keypair very easily: - -
$ ssh-keygen -p
-Enter file in which the key is (/Users/tekkub/.ssh/id_rsa):
-Key has comment '/Users/tekkub/.ssh/id_rsa'
-Enter new passphrase (empty for no passphrase):
-Enter same passphrase again:
-Your identification has been saved with the new passphrase.
- -If your key already has a passphrase, you will be prompted to enter it before you can change to a new passphrase. - -h2. Auto-launching ssh-agent on msysgit - -You can run @ssh-agent@ automatically when you open bash by adding the following to your @~/.profile@ or @~/.bashrc@ file: - -{% highlight bash %} -SSH_ENV="$HOME/.ssh/environment" - -# start the ssh-agent -function start_agent { - echo "Initializing new SSH agent..." - # spawn ssh-agent - ssh-agent | sed 's/^echo/#echo/' > "$SSH_ENV" - echo succeeded - chmod 600 "$SSH_ENV" - . "$SSH_ENV" > /dev/null - ssh-add -} - -# test for identities -function test_identities { - # test whether standard identities have been added to the agent already - ssh-add -l | grep "The agent has no identities" > /dev/null - if [ $? -eq 0 ]; then - ssh-add - # $SSH_AUTH_SOCK broken so we start a new proper agent - if [ $? -eq 2 ];then - start_agent - fi - fi -} - -# check for running ssh-agent with proper $SSH_AGENT_PID -if [ -n "$SSH_AGENT_PID" ]; then - ps -ef | grep "$SSH_AGENT_PID" | grep ssh-agent > /dev/null - if [ $? -eq 0 ]; then - test_identities - fi -# if $SSH_AGENT_PID is not properly set, we might be able to load one from -# $SSH_ENV -else - if [ -f "$SSH_ENV" ]; then - . "$SSH_ENV" > /dev/null - fi - ps -ef | grep "$SSH_AGENT_PID" | grep ssh-agent > /dev/null - if [ $? -eq 0 ]; then - test_identities - else - start_agent - fi -fi -{% endhighlight %} - -p(. *Note:* If you don't use the default key names, or store your keys in a different path, you will need to add the path to the @/usr/bin/ssh-add@ line so that ssh knows where to find your key. - -Now when you first run git bash, you will be prompted for your passphrase: - -
Initializing new SSH agent...
-succeeded
-Enter passphrase for /c/Users/Tekkub/.ssh/id_rsa:
-Identity added: /c/Users/Tekkub/.ssh/id_rsa (/c/Users/Tekkub/.ssh/id_rsa)
-Welcome to Git (version 1.6.0.2-preview20080923)
-
-
-Run 'git help git' to display the help index.
-Run 'git help ' to display help for specific commands.
-[Tekkub@KAKU: ~ master]$
- -The process will continue to run until you log out, shutdown or kill ssh-agent. To kill the process, find its PID with @ps@ then call @kill @: - -
[Tekkub@KAKU: ~ master]$ ps
-        PID    PPID    PGID     WINPID  TTY  UID    STIME COMMAND
-       3796       1    3796       3796    ?  500 18:07:43 /bin/ssh-agent
-       2780       1    2780       2780  con  500 18:10:50 /bin/bash
-       3400    2780    3400        784  con  500 18:13:31 /bin/ps
-[Tekkub@KAKU: ~ master]$ kill 3796
- -p(. This section was written with help from "this post":http://www.cygwin.com/ml/cygwin/2001-06/msg00537.html. - -h2. Mac OSX Keychain - -If you are on OSX Leopard or later, ssh-agent is run automatically for you. It will also integrate with the keychain, so you can unlock your keys with it. This has some major advantages over a command-line based setup like protecting your input from being copied or spied upon by universal access or low-level keyboard routines. - -The default key files (@.ssh/id_rsa@, @.ssh/id_dsa@ and @.ssh/identity@) should be handled automatically. If you have a key with a different name, you can add it with @ssh-add path/to/my_key@ - -

Make sure that you're using the default OS X ssh-add command and not one installed by macports or some other external source.

- -When you first try to use the key you will be prompted to enter your passphrase: - -!/images/SecurityAgent.jpg(Keychain prompt)! - -If you choose to save the passphrase with your keychain, you won't have to enter it again. Instead you'll simply need to unlock your keychain. - -

This section was written with help from "this guide":http://www.dribin.org/dave/blog/archives/2007/11/28/ssh_agent_leopard/. If you would like to use more paranoid keychain settings like locking after sleep, check out "this guide":http://www.dribin.org/dave/blog/archives/2007/11/28/securing_ssh_agent/.

diff --git a/_posts/2009-09-09-removing-sensitive-data.markdown b/_posts/2009-09-09-removing-sensitive-data.markdown deleted file mode 100644 index c7719ce..0000000 --- a/_posts/2009-09-09-removing-sensitive-data.markdown +++ /dev/null @@ -1,120 +0,0 @@ ---- -layout: default -title: Removing sensitive data -description: Dealing with accidentally committed passwords or other sensitive information -categories: popular advanced -terminal_pres: true ---- - -

From time to time users accidentally commit data like passwords or keys into a git repo. While you can use git rm to remove the file, it will still be in the repo's history. Fortunately, git makes it fairly simple to remove the file from the entire repo history.

- -Change your password --------------------- - -This step should be blatantly obvious, but some users still skip it. If you committed a password, change it! If you committed a key, generate a new one. Once the commit has been pushed you should consider the data to be compromised. Period. - -Purge the file from your repo ------------------------------ - -Now that the password is changed, you want to remove the file from history and add it to the `.gitignore` to ensure it is not accidentally re-committed. For our examples, we're going to remove `Rakefile` from the [GitHub gem](http://github.com/defunkt/github-gem) repo. - -
-tekkub@iSenberg ~/tmp master*
-$ git clone git@github.com:defunkt/github-gem.git
-Initialized empty Git repository in /Users/tekkub/tmp/github-gem/.git/
-remote: Counting objects: 1301, done.
-remote: Compressing objects: 100% (769/769), done.
-remote: Total 1301 (delta 724), reused 910 (delta 522)
-Receiving objects: 100% (1301/1301), 164.39 KiB, done.
-Resolving deltas: 100% (724/724), done.
-
-tekkub@iSenberg ~/tmp master*
-$ cd github-gem/
-
-tekkub@iSenberg ~/tmp/github-gem master
-$ git filter-branch --index-filter 'git rm --cached --ignore-unmatch Rakefile' HEAD
-Rewrite 48dc599c80e20527ed902928085e7861e6b3cbe6 (266/266)
-Ref 'refs/heads/master' was rewritten
-
- -This command will run the entire history of the master branch and change any commit that involved the file `Rakefile`, and any commits afterwards. Now that we've erased the file from history, lets ensure that we don't accidentally commit it again. - -If you wish to retain tags you must specify `--tag-name-filter "cat"`, but note that *this will overwrite your existing tags*. - -
-tekkub@iSenberg ~/tmp/github-gem master
-$ echo "Rakefile" >> .gitignore
-
-tekkub@iSenberg ~/tmp/github-gem master*
-$ git add .gitignore
-
-tekkub@iSenberg ~/tmp/github-gem master+
-$ git commit -m "Add Rakefile to .gitignore"
-[master 051452f] Add Rakefile to .gitignore
- 1 files changed, 1 insertions(+), 0 deletions(-)
-
- -This would be a good time to double-check that you've removed everything that you wanted to from the history. Note that `git filter-branch` only works on one branch at a time, so you may need to perform the cleanup on other branches as well. This could be problematic if the branch has a complex merge history. If we're happy with the state of the repo, we need to force-push the changes to overwrite the remote repo. - -
-tekkub@iSenberg ~/tmp/github-gem master
-$ git push origin master --force
-Counting objects: 1074, done.
-Delta compression using 2 threads.
-Compressing objects: 100% (677/677), done.
-Writing objects: 100% (1058/1058), 148.85 KiB, done.
-Total 1058 (delta 590), reused 602 (delta 378)
-To git@github.com:defunkt/github-gem.git
- + 48dc599...051452f master -> master (forced update)
-
- -### Cleanup and reclaiming space - -While `git filter-branch` rewrites the history for you, the objects will remain in your local repo until they've been dereferenced and garbage collected. If you are working in your main repo you might want to force these objects to be purged. - -
-tekkub@iSenberg ~/tmp/github-gem master
-$ rm -rf .git/refs/original/
-
-tekkub@iSenberg ~/tmp/github-gem master
-$ git reflog expire --expire=now --all
-
-tekkub@iSenberg ~/tmp/github-gem master
-$ git gc --prune=now
-Counting objects: 2437, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (1378/1378), done.
-Writing objects: 100% (2437/2437), done.
-Total 2437 (delta 1461), reused 1802 (delta 1048)
-
-tekkub@iSenberg ~/tmp/github-gem master
-$ git gc --aggressive --prune=now
-Counting objects: 2437, done.
-Delta compression using up to 4 threads.
-Compressing objects: 100% (2426/2426), done.
-Writing objects: 100% (2437/2437), done.
-Total 2437 (delta 1483), reused 0 (delta 0)
-
- -Note that pushing the branch to a new or empty GitHub repo and then making a fresh clone from GitHub will have the same effect. - -Dealing with collaborators --------------------------- - -You may have collaborators that pulled your tainted branch and created their own branches off of it. After they fetch your new branch, they will need to use `git rebase` on their own branches to rebase them on top of the new one. The collab should also ensure that their branch doesn't reintroduce the file, as this will override the `.gitignore` file. *Make sure your collab uses rebase and not merge,* otherwise he will just reintroduce the file and the entire tainted history... and likely encounter some merge conflicts. - -Cached data on GitHub ---------------------- - -Be warned that force-pushing does not erase commits on the remote repo, it simply introduces new ones and moves the branch pointer to point to them. If you are worried about users accessing the bad commits directly via SHA1, you will have to delete the repo and recreate it. If the commits were viewed online the pages may also be cached. Check for cached pages after you recreate the repo, if you find any open a ticket on [GitHub Support](http://support.github.com) and provide links so staff can purge them from the cache. - -Avoiding accidental commits in the future ------------------------------------------ - -There are a few simple tricks to avoid committing things you don't want committed. The first, and simplest, is to use a visual tool like git-gui or [gitx](http://gitx.frim.nl/) to make your commits. This lets you see exactly what you're committing, and ensure that only the files you want are added to the repo. If you're working form the command line, avoid the catch-all commands `git add .` and `git commit -a`, instead use `git add filename` and `git rm filename` to individually stage files. You can also use `git add --interactive` to review each changed file and stage it, or part of it, for commit. If you're working from the command line, you can also use `git diff --cached` to see what changes you have staged for commit. This is the exact diff that your commit will have as long as you commit without the `-a` flag. - -Other reading -------------- - -* [git-filter-branch documentation](http://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html) -* [Git user manual - Cleaning up history](http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#cleaning-up-history) \ No newline at end of file diff --git a/_posts/2009-09-27-splitting-a-subpath-to-a-new-repo.md b/_posts/2009-09-27-splitting-a-subpath-to-a-new-repo.md deleted file mode 100644 index 1b051a0..0000000 --- a/_posts/2009-09-27-splitting-a-subpath-to-a-new-repo.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -layout: default -title: Splitting a subpath out into a new repo -description: How to generate a new repo from a subpath, retaining history. -categories: advanced ---- - -

From time to time you may find that you want to make a new repo from a subpath of an existing repo. Perhaps you're moving some code out into a library or just want to have a common submodule across projects. Thanks to git, it's easy to do this without losing the history of that subpath in the process.

- -The Good Stuff --------------- - -Splitting a subpath into a repo is a fairly straightforward process, even if the command is hard to remember. For this example, we split lib/ out of the "GitHub gem":http://github.com/defunkt/github-gem repo, removing empty commits but retaining the path's history. - -
[tekkub@tekBook: ~/tmp] $ git clone git://github.com/defunkt/github-gem.git
-Initialized empty Git repository in /Users/tekkub/tmp/github-gem/.git/
-remote: Counting objects: 1301, done.
-remote: Compressing objects: 100% (769/769), done.
-remote: Total 1301 (delta 724), reused 910 (delta 522)
-Receiving objects: 100% (1301/1301), 164.39 KiB | 274 KiB/s, done.
-Resolving deltas: 100% (724/724), done.
-
-[tekkub@tekBook: ~/tmp] $ cd github-gem/
-
-[tekkub@tekBook: ~/tmp/github-gem master] $ git filter-branch --prune-empty --subdirectory-filter lib master
-Rewrite 48dc599c80e20527ed902928085e7861e6b3cbe6 (89/89)
-Ref 'refs/heads/master' was rewritten
- -Now we have a re-written master branch that contains the files that were in lib/. We can simply add a remote to the new repo and push, or do whatever we want with the repo. diff --git a/_posts/2009-10-05-dealing-with-lineendings.textile b/_posts/2009-10-05-dealing-with-lineendings.textile deleted file mode 100644 index 77f0572..0000000 --- a/_posts/2009-10-05-dealing-with-lineendings.textile +++ /dev/null @@ -1,50 +0,0 @@ ---- -layout: default -title: Dealing with line endings -description: How to ensure that line endings are consistent in your repo -categories: troubleshooting ---- - -

Line endings... the scourge of every Windows-based developer that tries to mingle with linux- or mac-based developers. Though most modern text editors can handle both newline types without issue, git is not as graceful.

- -

For more info on the issue see "Wikipedia":http://en.wikipedia.org/wiki/Newline.

- -h2. Mac and Linux users, you don't get to sit this one out - -Although you might think you're immune to CRLF-ended files on mac and linux, you are not. It is possible to download files from an external source that use CRLF, and thus commit them into your repo. To be safe, you should set your config to convert line endings on commit so they are always LF in the repo: - -
$ git config --global core.autocrlf input
- -h2. I just cloned and git says files have changed! - -So, you just cloned a repo on a Windows box, and it says that all of your files have been modified. Huh? You've not touched anything yet! What the... - -The problem is that your @core.autocrlf@ option is likely not enabled. This setting tells git to convert the newlines to the system's standard when checking out files, and to LF newlines when committing in. To turn it on use this command: - -
$ git config --global core.autocrlf true
- -Once this is set, you need to reset your repos. The best way to do this is wipe out your working tree (all the files except the .git directory) and then restore them: - -
# Remove everything from the index
-$ git rm --cached -r .
-
-# Re-add all the deleted files to the index
-# You should get lots of messages like: "warning: CRLF will be replaced by LF in ."
-$ git diff --cached --name-only -z | xargs -0 git add
-
-# Commit
-$ git commit -m "Fix CRLF"
-
-# If you're doing this on a Unix/Mac OSX clone then optionally remove
-# the working tree and re-check everything out with the correct line endings.
-$ git ls-files -z | xargs -0 rm
-$ git checkout .
-
- -p(. _Thanks to Charles Bailey's post on "stackoverflow":http://stackoverflow.com/questions/1510798/trying-to-fix-line-endings-with-git-filter-branch-but-having-no-luck/1511273#1511273 for this solution._ - -h2. Moving forward - -Now that you've standardized the newlines in your repo things should be better. However, every person that touches your repo should turn autocrlf on, even non-Windows users. It is possible for them to bring in code from an outside source that has CRLF newlines, and you don't want them saved into the repo like that. - -For more details on the @core.autocrlf@ setting see the "git-config documentation":http://www.kernel.org/pub/software/scm/git/docs/git-config.html. diff --git a/_posts/2009-10-10-subtree-merge.markdown b/_posts/2009-10-10-subtree-merge.markdown deleted file mode 100644 index 3c50e76..0000000 --- a/_posts/2009-10-10-subtree-merge.markdown +++ /dev/null @@ -1,127 +0,0 @@ ---- -layout: default -title: Working with subtree merge -description: How to use subtree merge to merge one repo into another as a subpath. -categories: advanced ---- - -

There are times when submodules are not adequate for the task at hand. For example, blending multiple repos together into one single repo while still maintaining the history of each repo. To do this, the subtree merge strategy is a better solution.

- -Setting up and doing the first merge ------------------------------------- - -For this example, we'll make an empty "parent" repo and some other repos into it as subpaths. - -First, set up an empty repo for our example: - -
-[tekkub@tekBook: ~/tmp master*]
-$ mkdir test
-
-[tekkub@tekBook: ~/tmp master*]
-$ cd test
-
-[tekkub@tekBook: ~/tmp/test master*]
-$ git init
-Initialized empty Git repository in /Users/tekkub/tmp/test/.git/
-
-[tekkub@tekBook: ~/tmp/test master#]
-$ touch .gitignore
-
-[tekkub@tekBook: ~/tmp/test master#]
-$ git add .gitignore
-
-[tekkub@tekBook: ~/tmp/test master#]
-$ git commit -m "initial commit"
-[master (root-commit) 3146c2a] initial commit
- 0 files changed, 0 insertions(+), 0 deletions(-)
- create mode 100644 .gitignore
-
- -Now we'll subtree-merge the repo [tekkub/cork](https://github.com/tekkub/cork) into the repo at `cork/` - -
-[tekkub@tekBook: ~/tmp/test master]
-$ git remote add -f cork git://github.com/tekkub/cork.git
-Updating cork
-warning: no common commits
-remote: Counting objects: 1732, done.
-remote: Compressing objects: 100% (750/750), done.
-remote: Total 1732 (delta 1086), reused 1558 (delta 967)
-Receiving objects: 100% (1732/1732), 528.19 KiB | 621 KiB/s, done.
-Resolving deltas: 100% (1086/1086), done.
-From git://github.com/tekkub/cork
- * [new branch]      lastbuffed -> cork/lastbuffed
- * [new branch]      lock_n_mount -> cork/lock_n_mount
- * [new branch]      master     -> cork/master
- * [new branch]      nothing_to_see_here -> cork/nothing_to_see_here
-
-[tekkub@tekBook: ~/tmp/test master]
-$ git merge -s ours --no-commit cork/master
-Automatic merge went well; stopped before committing as requested
-
-[tekkub@tekBook: ~/tmp/test master|MERGING]
-$ git read-tree --prefix=cork/ -u cork/master
-
-[tekkub@tekBook: ~/tmp/test master+|MERGING]
-$ git commit -m "Subtree merged in cork"
-[master fe0ca25] Subtree merged in cork
-
- -Next, we'll merge in [tekkub/panda](https://github.com/tekkub/panda) into the path `panda/` - -
-[tekkub@tekBook: ~/tmp/test master]
-$ git remote add -f panda git://github.com/tekkub/panda.git
-Updating panda
-warning: no common commits
-remote: Counting objects: 974, done.
-remote: Compressing objects: 100% (722/722), done.
-remote: Total 974 (delta 616), reused 399 (delta 251)
-Receiving objects: 100% (974/974), 189.56 KiB, done.
-Resolving deltas: 100% (616/616), done.
-From git://github.com/tekkub/panda
- * [new branch]      master     -> panda/master
- * [new branch]      transmute  -> panda/transmute
-
-[tekkub@tekBook: ~/tmp/test master]
-$ git merge -s ours --no-commit panda/master
-Automatic merge went well; stopped before committing as requested
-
-[tekkub@tekBook: ~/tmp/test master|MERGING]
-$ git read-tree --prefix=panda/ -u panda/master
-
-[tekkub@tekBook: ~/tmp/test master+|MERGING]
-$ git commit -m "Subtree merged in panda"
-[master 726a2cd] Subtree merged in panda
-
- -Finally, we're going to merge the subpath `modules/` from tekkub/cork into `cork2/` - -
-tekkub@iSenberg ~/tmp/test master
-$ git merge -s ours --no-commit cork/master
-Automatic merge went well; stopped before committing as requested
-
-tekkub@iSenberg ~/tmp/test master|MERGING
-$ git read-tree --prefix=cork2/ -u cork/master:modules
-
-tekkub@iSenberg ~/tmp/test master+|MERGING
-$ git commit -m "Subtree merged in cork/modules"
-[master f240057] Subtree merged in cork/modules
-
- -Pulling in changes ------------------- - -If the merged repo changes in the future, you can pull in its changes by simply using the `-s subtree` flag: - -
-[tekkub@tekBook: ~/tmp/test master]
-$ git pull -s subtree panda master
-
- -Resources ---------- - -* [How to use the subtree merge strategy](http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html) diff --git a/_posts/2009-10-16-post-receive-hooks.markdown b/_posts/2009-10-16-post-receive-hooks.markdown deleted file mode 100644 index 7ce36d5..0000000 --- a/_posts/2009-10-16-post-receive-hooks.markdown +++ /dev/null @@ -1,121 +0,0 @@ ---- -layout: default -title: Post-Receive Hooks -description: Working with GitHub's post-receive web hooks. -categories: advanced ---- - -_For help testing webhooks, see [this guide](/testing-webhooks)_ - -If you supply a post-receive URL, GitHub will POST to that URL when someone uses `git push` on that repository. - -![](http://img.skitch.com/20100620-r8st7468q7q5waf3y85hmpwtqs.png) - -![](http://img.skitch.com/20100620-br6dw5iiyk2643fahkqbi54h36.png) - -What we'll send is JSON containing information about the push and the commits involved. - -Here's the template we use in Ruby to generate the JSON: - -{% highlight ruby %} -{ - :before => before, - :after => after, - :ref => ref, - :commits => [{ - :id => commit.id, - :message => commit.message, - :timestamp => commit.committed_date.xmlschema, - :url => commit_url, - :added => array_of_added_paths, - :removed => array_of_removed_paths, - :modified => array_of_modified_paths, - :author => { - :name => commit.author.name, - :email => commit.author.email - } - }], - :repository => { - :name => repository.name, - :url => repo_url, - :pledgie => repository.pledgie.id, - :description => repository.description, - :homepage => repository.homepage, - :watchers => repository.watchers.size, - :forks => repository.forks.size, - :private => repository.private?, - :owner => { - :name => repository.owner.login, - :email => repository.owner.email - } - } -} -{% endhighlight %} - -This is sent as a POST with a single parameter: 'payload' - -So, for example, you'd do something like this in a [Sinatra](http://sinatra.rubyforge.org/) server: - -{% highlight ruby %} -post '/' do - push = JSON.parse(params[:payload]) - "I got some JSON: #{push.inspect}" -end -{% endhighlight %} - -The `commits` array is ordered with the oldest commit as the first element. The last element is the newest commit and should match the "after" value for the branch. - -Here's an example payload: - -{% highlight javascript %} -{ - "before": "5aef35982fb2d34e9d9d4502f6ede1072793222d", - "repository": { - "url": "http://github.com/defunkt/github", - "name": "github", - "description": "You're lookin' at it.", - "watchers": 5, - "forks": 2, - "private": 1, - "owner": { - "email": "chris@ozmm.org", - "name": "defunkt" - } - }, - "commits": [ - { - "id": "41a212ee83ca127e3c8cf465891ab7216a705f59", - "url": "http://github.com/defunkt/github/commit/41a212ee83ca127e3c8cf465891ab7216a705f59", - "author": { - "email": "chris@ozmm.org", - "name": "Chris Wanstrath" - }, - "message": "okay i give in", - "timestamp": "2008-02-15T14:57:17-08:00", - "added": ["filepath.rb"] - }, - { - "id": "de8251ff97ee194a289832576287d6f8ad74e3d0", - "url": "http://github.com/defunkt/github/commit/de8251ff97ee194a289832576287d6f8ad74e3d0", - "author": { - "email": "chris@ozmm.org", - "name": "Chris Wanstrath" - }, - "message": "update pricing a tad", - "timestamp": "2008-02-15T14:36:34-08:00" - } - ], - "after": "de8251ff97ee194a289832576287d6f8ad74e3d0", - "ref": "refs/heads/master" -} -{% endhighlight %} - -For more information on this technique, see the [Web Hooks Wiki](http://webhooks.pbwiki.com/). - -Links ------ - -* [raggi/github_post_receive_server](http://github.com/raggi/github_post_receive_server/) -- A template Rack server -* [jnewland/github-campfire](http://github.com/jnewland/github-campfire/) -* [webs/irccat](http://github.com/webs/irccat) -* [jnunemaker/github-twitter](http://github.com/jnunemaker/github-twitter/) diff --git a/_posts/2009-11-03-userscripts-and-bookmarklets.textile b/_posts/2009-11-03-userscripts-and-bookmarklets.textile deleted file mode 100644 index d8b6db6..0000000 --- a/_posts/2009-11-03-userscripts-and-bookmarklets.textile +++ /dev/null @@ -1,29 +0,0 @@ ---- -layout: default -title: Userscripts and Bookmarklets -description: Various bits of code to enhance and personalize GitHub -categories: github_resources ---- - -This page contains userscripts and bookmarklets to enhance and customize GitHub. If you have a link to add, please "fork this repo":http://github.com/github/help.github.com. - -Userscripts can be installed by simply visiting the "raw" version of the gist or github page. Your browser should prompt you to install the userscript if it recognizes it. See "this post":http://github.com/blog/302-gist-for-greasemonkey for details. - -Bookmarklets should provide their own installation instructions. - -h2. GitHub - -* "GitHubbub":http://github.com/stephencelis/githubbub - Growl notifications for the dashboard events -* "Dashboard twitter status":http://gist.github.com/225512 - Adds the two most recent, non-reply tweets from @github to your dashboard -* "Augment GitHub":http://github.com/nakajima/augment-github - Bookmarklet that adds follower, fork, and issue counts to your repos on your dashboard -* "User profile gist links":http://gist.github.com/225593 - Adds a link to user profile pages linking to that user's gists -* "GitHub Markdown Preview":http://userscripts.org/scripts/show/65788 - Adds a preview to comment fields, so that you may see how your comment looks with the markdown formatted before sending it. -* "Preview Images":https://github.com/yperevoznikov/Preview-Images-In-Github - Adds a preview of images inside issues - -h2. Gist - -* "Replace page title with filename":http://gist.github.com/93187 -* "Diff for gist":http://gist.github.com/105913 -* "Bespin for gist":http://gist.github.com/463054 - Allows users to quickly replace any textarea you encounter on gist.github.com with a Bespin editor. -* "Gist UserScript Install Link":http://gist.github.com/289492 - If a gist is a userscript, then this userscript will add a "install" link next the the "raw" link, and points the "raw" link to the url using view-source:. -* "Add top pagination to My Gists":http://gist.github.com/339147 - Adds pagination to the top of the "My Gists" page. diff --git a/_posts/2009-11-16-egit-corruption.markdown b/_posts/2009-11-16-egit-corruption.markdown deleted file mode 100644 index eb6f95c..0000000 --- a/_posts/2009-11-16-egit-corruption.markdown +++ /dev/null @@ -1,57 +0,0 @@ ---- -layout: default -title: Fixing egit corruption -description: How to fix corruption in a remote repo caused by egit -categories: troubleshooting ---- - -Due to a bug in the [EGit](http://eclipse.org/egit/)/[JGit](http://eclipse.org/jgit/) implementation of the `git push` command, remote repos can become corrupted due to missing objects: - -
$ git fsck
-broken link from  commit 5b90a930763c442f0fc3d819685083b4eda69f8e
-              to  commit e1ea55d308b7808cb982f509c8dfa199ada4677e
-missing commit e1ea55d308b7808cb982f509c8dfa199ada4677e
- -This can prevent cloning and fetching from the repo. The objects were never pushed to the remote repo, therefore support cannot recover the repo directly for the user. The only solution is for the user that pushed the commits to push them again from the command line. - -_This issue was fixed in EGit/JGit 0.8.4. We recommend updating and trying the following commands from EGit/JGit before resorting to the commandline._ - -Correcting the remote repo --------------------------- - -To correct the remote repo the missing objects need to be re-pushed from an uncorrupted repo. This should be done from the command line, not from egit. To start, run `git fsck` on your local repo to ensure it has not been corrupted. If you do not receive any errors about broken links or missing objects, you're clear to continue. - -Re-pushing is a simple matter of deleting the remote branch and then pushing it again. We'll use the first commit in the branch so that we can ensure all the other commits are re-pushed. - -If the branch being deleted is the default branch on the remote you'll need to replace it temporarily. You can do this in the repo's admin page: - -![default](http://img.skitch.com/20100203-jm7pty6kf1c72yfksunyf5g5n9.jpg) - -
$ git log --pretty=oneline | tail -n 1 # Find the first commit
-3b70d98cb968fc35f0c99acfe4d5dfa976ed2536 Initial commit
-$ git branch temp_default 3b70d98cb968fc35f0c99acfe4d5dfa976ed2536
-$ git push origin temp_default
-# Change the remote default branch to temp_default
-$ git push origin :master
-$ git push origin master
-# Set the remote default back to master
-$ git push origin :temp_default
- -You may need to do this for many branches if the remote repo has more than one branch that was pushed by egit. You can skip `git remote set-head` for these other branches. - -After you've pushed and reset HEAD, testing the repo repo is just a matter of cloning it: - -
$ git clone git://github.com/tekkub/test.git
-Initialized empty Git repository in /Users/tekkub/tmp/test/.git/
-remote: Counting objects: 1815, done.
-remote: Compressing objects: 100% (838/838), done.
-remote: Total 1815 (delta 1139), reused 1552 (delta 961)
-Receiving objects: 100% (1815/1815), 537.69 KiB | 549 KiB/s, done.
-Resolving deltas: 100% (1139/1139), done.
- -If you have re-pushed all branches in your repo and cloning still fails, please [contact support](http://support.github.com) and open a ticket. Be sure to include a link to your repo and mention that you've already performed the steps on this page. - -Avoiding future corruption --------------------------- - -We recommend users avoid using EGit/JGit to push their repos if they are using a version prior to 0.8.4. \ No newline at end of file diff --git a/_posts/2009-11-17-testing-webhooks.textile b/_posts/2009-11-17-testing-webhooks.textile deleted file mode 100644 index 6f4fb50..0000000 --- a/_posts/2009-11-17-testing-webhooks.textile +++ /dev/null @@ -1,65 +0,0 @@ ---- -layout: default -title: Testing webhooks -description: How to test post-receive webhook calls from your repo -categories: advanced ---- - -

Testing that a webhook works can be a bit of a pain. Thankfully with the help of "PostBin":http://www.postbin.org/ the pain can be avoided.

- -h2. When hooks are fired - -First and foremost, webhooks are not always called when a push is made. Currently hooks only fire when a branch that exists on GitHub is modified. Pushing new branches, deleting branches, and creating tags will not fire a webhook. Forced pushes such as @git push origin master --force@ may not predictably call hooks as well. To ensure your commits are sent to your webhook, always push the branch when it is created before you commit. This way the branch exists on GitHub when you push the commits you want sent to the webhook. - -h2. Setting up - -First, visit "PostBin":http://www.postbin.org/ and click "Make a PostBin". Copy the URL you are sent to: - -!http://img.skitch.com/20091118-jp5jt8gtcxy8dn2w3kk1xkpt8j.jpg! - -Paste this URL into your repo's post-receive URLs setting and save: - -!http://img.skitch.com/20091118-nr8ggc3rgdq8i1r2x8ad1mm57r.jpg! - -h2. Testing the hook is fired - -To test that the hook fires we need an existing branch on the GitHub repo. In this example we create a new repo, push one commit, then make another commit and push it. We only expect the second push to be sent to our PostBin. - -
[tekkub@tekBook: ~/tmp] $ mkdir test_post
-[tekkub@tekBook: ~/tmp] $ cd test_post
-[tekkub@tekBook: ~/tmp/test_post] $ git init
-Initialized empty Git repository in /Users/tekkub/tmp/test_post/.git/
-
-[tekkub@tekBook: ~/tmp/test_post master#] $ touch README
-[tekkub@tekBook: ~/tmp/test_post master#] $ git add README
-[tekkub@tekBook: ~/tmp/test_post master#] $ git commit -m 'first commit'
-[master (root-commit) 94afb6c] first commit
- 0 files changed, 0 insertions(+), 0 deletions(-)
- create mode 100644 README
-
-[tekkub@tekBook: ~/tmp/test_post master] $ git remote add origin git@github.com:tekkub/test_post.git
-[tekkub@tekBook: ~/tmp/test_post master] $ git push origin master
-Counting objects: 3, done.
-Writing objects: 100% (3/3), 201 bytes, done.
-Total 3 (delta 0), reused 0 (delta 0)
-To git@github.com:tekkub/test_post.git
- * [new branch]      master -> master
-
-[tekkub@tekBook: ~/tmp/test_post master] $ echo "This is a real edit" > README
-[tekkub@tekBook: ~/tmp/test_post master*] $ git add README
-[tekkub@tekBook: ~/tmp/test_post master+] $ git commit -m 'second commit'
-[master a58cf12] second commit
- 1 files changed, 1 insertions(+), 0 deletions(-)
-
-[tekkub@tekBook: ~/tmp/test_post master] $ git push origin master
-Counting objects: 5, done.
-Writing objects: 100% (3/3), 249 bytes, done.
-Total 3 (delta 0), reused 0 (delta 0)
-To git@github.com:tekkub/test_post.git
-   94afb6c..a58cf12  master -> master
- -Now that we've pushed a commit that should be sent to our webhook, lets check if it did by reloading our PostBin page: - -!http://img.skitch.com/20091118-rgxb1rx3aixqfdk4sm5wtaw4t7.jpg! - -Success! \ No newline at end of file diff --git a/_posts/2010-01-12-privacy.markdown b/_posts/2010-01-12-privacy.markdown deleted file mode 100644 index d83ac0c..0000000 --- a/_posts/2010-01-12-privacy.markdown +++ /dev/null @@ -1,46 +0,0 @@ ---- -layout: default -title: GitHub Privacy Policy -categories: site_policy ---- - -General Information -------------------- - -We collect the e-mail addresses of those who communicate with us via e-mail, aggregate information on what pages consumers access or visit, and information volunteered by the consumer (such as survey information and/or site registrations). The information we collect is used to improve the content of our Web pages and the quality of our service, and is not shared with or sold to other organizations for commercial purposes, except to provide products or services you've requested, when we have your permission, or under the following circumstances: - -* It is necessary to share information in order to investigate, prevent, or take action regarding illegal activities, suspected fraud, situations involving potential threats to the physical safety of any person, violations of [Terms of Service](/terms), or as otherwise required by law. -* We transfer information about you if GitHub is acquired by or merged with another company. In this event, GitHub will notify you before information about you is transferred and becomes subject to a different privacy policy. - -Information Gathering and Usage -------------------------------- - -* When you register for GitHub we ask for information such as your name, email address, billing address, credit card information. Members who sign up for the free account are not required to enter a credit card. -* GitHub uses collected information for the following general purposes: products and services provision, billing, identification and authentication, services improvement, contact, and research. - -Cookies -------- - -* A cookie is a small amount of data, which often includes an anonymous unique identifier, that is sent to your browser from a web site's computers and stored on your computer's hard drive. -* Cookies are required to use the GitHub service. -* We use cookies to record current session information, but do not use permanent cookies. You are required to re-login to your GitHub account after a certain period of time has elapsed to protect you against others accidentally accessing your account contents. - -Data Storage ------------- - -GitHub uses third party vendors and hosting partners to provide the necessary hardware, software, networking, storage, and related technology required to run GitHub. Although GitHub owns the code, databases, and all rights to the GitHub application, you retain all rights to your data. - -Disclosure ----------- - -GitHub may disclose personally identifiable information under special circumstances, such as to comply with subpoenas or when your actions violate the [Terms of Service](/terms). - -Changes -------- - -GitHub may periodically update this policy. We will notify you about significant changes in the way we treat personal information by sending a notice to the primary email address specified in your GitHub primary account holder account or by placing a prominent notice on our site. - -Questions ---------- - -Any questions about this Privacy Policy should be addressed to . diff --git a/_posts/2010-01-12-terms.markdown b/_posts/2010-01-12-terms.markdown deleted file mode 100644 index 5e484c0..0000000 --- a/_posts/2010-01-12-terms.markdown +++ /dev/null @@ -1,127 +0,0 @@ ---- -layout: default -title: GitHub Terms of Service -categories: site_policy ---- - -

By using the GitHub.com web site ("Service"), or any services of GitHub Inc ("GitHub"), you are agreeing to be bound by the following terms and conditions ("Terms of Service"). IF YOU ARE ENTERING INTO THIS AGREEMENT ON BEHALF OF A COMPANY OR OTHER LEGAL ENTITY, YOU REPRESENT THAT YOU HAVE THE AUTHORITY TO BIND SUCH ENTITY, ITS AFFILIATES AND ALL USERS WHO ACCESS OUR SERVICES THROUGH YOUR ACCOUNT TO THESE TERMS AND CONDITIONS, IN WHICH CASE THE TERMS "YOU" OR "YOUR" SHALL REFER TO SUCH ENTITY, ITS AFFILIATES AND USERS ASSOCIATED WITH IT. IF YOU DO NOT HAVE SUCH AUTHORITY, OR IF YOU DO NOT AGREE WITH THESE TERMS AND CONDITIONS, YOU MUST NOT ACCEPT THIS AGREEMENT AND MAY NOT USE THE SERVICES.

- -

GitHub reserves the right to update and change the Terms of Service from time to time without notice. Any new features that augment or enhance the current Service, including the release of new tools and resources, shall be subject to the Terms of Service. Continued use of the Service after any such changes shall constitute your consent to such changes. You can review the most current version of the Terms of Service at any time at: http://github.com/site/terms

- -

Violation of any of the terms below will result in the termination of your Account. While GitHub prohibits such conduct and Content on the Service, you understand and agree that GitHub cannot be responsible for the Content posted on the Service and you nonetheless may be exposed to such materials. You agree to use the Service at your own risk.

- -A. Account Terms ----------------- - -1. You must be 13 years or older to use this Service. - -2. You must be a human. Accounts registered by "bots" or other automated methods are not permitted. - -3. You must provide your legal full name, a valid email address, and any other information requested in order to complete the signup process. - -4. Your login may only be used by one person - a single login shared by multiple people is not permitted. You may create separate logins for as many people as your plan allows. - -5. You are responsible for maintaining the security of your account and password. GitHub cannot and will not be liable for any loss or damage from your failure to comply with this security obligation. - -6. You are responsible for all Content posted and activity that occurs under your account (even when Content is posted by others who have accounts under your account). - -7. One person or legal entity may not maintain more than one free account. - -8. You may not use the Service for any illegal or unauthorized purpose. You must not, in the use of the Service, violate any laws in your jurisdiction (including but not limited to copyright or trademark laws). - - -B. API Terms ------------- - -Customers may access their GitHub account data via an API (Application Program Interface). Any use of the API, including use of the API through a third-party product that accesses GitHub, is bound by these Terms of Service plus the following specific terms: - -1. You expressly understand and agree that GitHub shall not be liable for any direct, indirect, incidental, special, consequential or exemplary damages, including but not limited to, damages for loss of profits, goodwill, use, data or other intangible losses (even if GitHub has been advised of the possibility of such damages), resulting from your use of the API or third-party products that access data via the API. - -2. Abuse or excessively frequent requests to GitHub via the API may result in the temporary or permanent suspension of your account's access to the API. GitHub, in its sole discretion, will determine abuse or excessive usage of the API. GitHub will make a reasonable attempt via email to warn the account owner prior to suspension. - -3. GitHub reserves the right at any time to modify or discontinue, temporarily or permanently, your access to the API (or any part thereof) with or without notice. - - -C. Payment, Refunds, Upgrading and Downgrading Terms ----------------------------------------------------- - -1. All paid plans must enter a valid credit card. Free accounts are not required to provide a credit card number. - -2. __An upgrade from the free plan to any paying plan will immediately bill you.__ - -3. __The Service is billed in advance on a monthly basis and is non-refundable. There will be no refunds or credits for partial months of service, upgrade/downgrade refunds, or refunds for months unused with an open account. In order to treat everyone equally, no exceptions will be made.__ - -4. All fees are exclusive of all taxes, levies, or duties imposed by taxing authorities, and you shall be responsible for payment of all such taxes, levies, or duties, excluding only United States (federal or state) taxes. - -5. For any upgrade or downgrade in plan level, your credit card that you provided will automatically be charged the new rate on your next billing cycle. - -6. Downgrading your Service may cause the loss of Content, features, or capacity of your Account. GitHub does not accept any liability for such loss. - - -D. Cancellation and Termination -------------------------------- - -1. __You are solely responsible for properly canceling your account. An email or phone request to cancel your account is not considered cancellation. You can cancel your account at any time by clicking on the Account link in the global navigation bar at the top of the screen. The Account screen provides a simple no questions asked cancellation link.__ - -2. All of your Content will be immediately deleted from the Service upon cancellation. This information can not be recovered once your account is cancelled. - -3. If you cancel the Service before the end of your current paid up month, your cancellation will take effect immediately and you will not be charged again. - -4. GitHub, in its sole discretion, has the right to suspend or terminate your account and refuse any and all current or future use of the Service, or any other GitHub service, for any reason at any time. Such termination of the Service will result in the deactivation or deletion of your Account or your access to your Account, and the forfeiture and relinquishment of all Content in your Account. GitHub reserves the right to refuse service to anyone for any reason at any time. - - -E. Modifications to the Service and Prices ------------------------------------------- - -1. GitHub reserves the right at any time and from time to time to modify or discontinue, temporarily or permanently, the Service (or any part thereof) with or without notice. - -2. Prices of all Services, including but not limited to monthly subscription plan fees to the Service, are subject to change upon 30 days notice from us. Such notice may be provided at any time by posting the changes to the GitHub Site ([github.com](http://github.com)) or the Service itself. - -3. GitHub shall not be liable to you or to any third party for any modification, price change, suspension or discontinuance of the Service. - - -F. Copyright and Content Ownership ----------------------------------- - -1. We claim no intellectual property rights over the material you provide to the Service. Your profile and materials uploaded remain yours. However, by setting your pages to be viewed publicly, you agree to allow others to view your Content. By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories. - -2. GitHub does not pre-screen Content, but GitHub and its designee have the right (but not the obligation) in their sole discretion to refuse or remove any Content that is available via the Service. - -3. You shall defend GitHub against any claim, demand, suit or proceeding made or brought against GitHub by a third party alleging that Your Content, or Your use of the Service in violation of this Agreement, infringes or misappropriates the intellectual property rights of a third party or violates applicable law, and shall indemnify GitHub for any damages finally awarded against, and for reasonable attorney’s fees incurred by, GitHub in connection with any such claim, demand, suit or proceeding; provided, that GitHub (a) promptly gives You written notice of the claim, demand, suit or proceeding; (b) gives You sole control of the defense and settlement of the claim, demand, suit or proceeding (provided that You may not settle any claim, demand, suit or proceeding unless the settlement unconditionally releases GitHub of all liability); and (c) provides to You all reasonable assistance, at Your expense. - -4. The look and feel of the Service is copyright ©{{ site.time | date: "%Y" }} GitHub Inc. All rights reserved. You may not duplicate, copy, or reuse any portion of the HTML/CSS, Javascript, or visual design elements or concepts without express written permission from GitHub. - - -G. General Conditions ---------------------- - -1. Your use of the Service is at your sole risk. The service is provided on an "as is" and "as available" basis. - -2. Technical support is only provided to paying account holders and is only available via email. Support is only available in English. - -3. You understand that GitHub uses third party vendors and hosting partners to provide the necessary hardware, software, networking, storage, and related technology required to run the Service. - -4. You must not modify, adapt or hack the Service or modify another website so as to falsely imply that it is associated with the Service, GitHub, or any other GitHub service. - -5. You agree not to reproduce, duplicate, copy, sell, resell or exploit any portion of the Service, use of the Service, or access to the Service without the express written permission by GitHub. - -6. We may, but have no obligation to, remove Content and Accounts containing Content that we determine in our sole discretion are unlawful, offensive, threatening, libelous, defamatory, pornographic, obscene or otherwise objectionable or violates -any party's intellectual property or these Terms of Service. - -7. Verbal, physical, written or other abuse (including threats of abuse or retribution) of any GitHub customer, employee, member, or officer will result in immediate account termination. - -8. You understand that the technical processing and transmission of the Service, including your Content, may be transfered unencrypted and involve (a) transmissions over various networks; and (b) changes to conform and adapt to technical requirements of connecting networks or devices. - -9. You must not upload, post, host, or transmit unsolicited email, SMSs, or "spam" messages. - -10. You must not transmit any worms or viruses or any code of a destructive nature. - -11. If your bandwidth usage significantly exceeds the average bandwidth usage (as determined solely by GitHub) of other GitHub customers, we reserve the right to immediately disable your account or throttle your file hosting until you can reduce your bandwidth consumption. - -12. GitHub does not warrant that (i) the service will meet your specific requirements, (ii) the service will be uninterrupted, timely, secure, or error-free, (iii) the results that may be obtained from the use of the service will be accurate or reliable, (iv) the quality of any products, services, information, or other material purchased or obtained by you through the service will meet your expectations, and (v) any errors in the Service will be corrected. - -13. You expressly understand and agree that GitHub shall not be liable for any direct, indirect, incidental, special, consequential or exemplary damages, including but not limited to, damages for loss of profits, goodwill, use, data or other intangible losses (even if GitHub has been advised of the possibility of such damages), resulting from: (i) the use or the inability to use the service; (ii) the cost of procurement of substitute goods and services resulting from any goods, data, information or services purchased or obtained or messages received or transactions entered into through or from the service; (iii) unauthorized access to or alteration of your transmissions or data; (iv) statements or conduct of any third party on the service; (v) or any other matter relating to the service. - -14. The failure of GitHub to exercise or enforce any right or provision of the Terms of Service shall not constitute a waiver of such right or provision. The Terms of Service constitutes the entire agreement between you and GitHub and govern your use of the Service, superceding any prior agreements between you and GitHub (including, but not limited to, any prior versions of the Terms of Service). You agree that these Terms of Service and Your use of the Service are governed under California law. - -15. Questions about the Terms of Service should be sent to . diff --git a/_posts/2010-01-15-dmca.markdown b/_posts/2010-01-15-dmca.markdown deleted file mode 100644 index 3efab6a..0000000 --- a/_posts/2010-01-15-dmca.markdown +++ /dev/null @@ -1,71 +0,0 @@ ---- -layout: default -title: DMCA Takedown -categories: site_policy ---- - -

GitHub, Inc. ("GitHub") supports the protection of intellectual property and asks the users of the website GitHub.com to do the same. It is the policy of GitHub to respond to all notices of alleged copyright infringement.

- -

Notice is specifically given that GitHub is not responsible for the content on other websites that any user may find or access when using GitHub.com. This notice describes the information that should be provided in notices alleging copyright infringement found specifically on GitHub.com, and this notice is designed to make alleged infringement notices to GitHub as straightforward as possible and, at the same time, minimize the number of notices that GitHub receives that are spurious or difficult to verify. The form of notice set forth below is consistent with the form suggested by the United States Digital Millennium Copyright Act ("DMCA") which may be found at the U.S. Copyright official website: http://www.copyright.gov.

- -

It is the policy of GitHub, in appropriate circumstances and in its sole discretion, to disable and/or terminate the accounts of users of GitHub.com who may infringe upon the copyrights or other intellectual property rights of GitHub and/or others.

- -

Our response to a notice of alleged copyright infringement may result in removing or disabling access to material claimed to be a copyright infringement and/or termination of the subscriber. If GitHub removes or disables access in response to such a notice, we will make a reasonable effort to contact the responsible party of our decision so that they may make an appropriate response.

- -

To file a notice of an alleged copyright infringement with us, you are required to provide a written communication only by email or postal mail. Notice is also given that you may be liable for damages (including costs and attorney fees) if you materially misrepresent that a product or activity is infringing upon your copyright.

- -A. Copyright Claims -=================== - -To expedite our handling of your notice, please use the following format or refer to Section 512(c)(3) of the Copyright Act. - -1. Identify in sufficient detail the copyrighted work you believe has been infringed upon. This includes identification of the web page or specific posts, as opposed to entire sites. Posts must be referenced by either the dates in which they appear or by the permalink of the post. Include the URL to the concerned material infringing your copyright (URL of a website or URL to a post, with title, date, name of the emitter), or link to initial post with sufficient data to find it. - -2. Identify the material that you allege is infringing upon the copyrighted work listed in Item #1 above. Include the name of the concerned litigious material (all images or posts if relevant) with its complete reference. - -3. Provide information on which GitHub may contact you, including your email address, name, telephone number and physical address. - -4. Provide the address, if available, to allow GitHub to notify the owner/administrator of the allegedly infringing webpage or other content, including email address. - -5. Also include a statement of the following: "I have a good faith belief that use of the copyrighted materials described above on the infringing web pages is not authorized by the copyright owner, or its agent, or the law." - -6. Also include the following statement: "I swear, under penalty of perjury, that the information in this notification is accurate and that I am the copyright owner, or am authorized to act on behalf of the owner, of an exclusive right that is allegedly infringed." - -7. Your physical or electronic signature - -Send the written notification via regular postal mail to the following: - -> GitHub Inc
-> Attn: DMCA takedown
-> 589 Howard St., 4th Floor
-> San Francisco, CA. 94105 - -or email notification to - -B. Counter-Notification Policy -============================== - -To be effective, a Counter-Notification must be a written communication by the alleged infringer provided to GitHub’s Designated Agent (as set forth above) that includes substantially the following: - -1. A physical or electronic signature of the Subscriber; - -2. Identification of the material that has been removed or to which access has been disabled and the location at which the material appeared before it was removed or access to it was disabled; - -3. A statement under penalty of perjury that the Subscriber has a good faith belief that the material was removed or disabled as a result of a mistake or misidentification of the material to be removed or disabled; - -4. The Subscriber's name, address, and telephone number, and a statement that the Subscriber consents to the jurisdiction of Federal District Court for the judicial district of California, or if the Subscriber's address is outside of the United States, for any judicial district in which GitHub may be found, and that the Subscriber will accept service of process from the person who provided notification or an agent of such person. - -Upon receipt of a Counter Notification containing the information as outlined in 1 through 4 above: - -* GitHub shall promptly provide the Complaining Party with a copy of the Counter Notification; - -* GitHub shall inform the Complaining Party that it will replace the removed material or cease disabling access to it within ten (10) business days; - -* GitHub shall replace the removed material or cease disabling access to the material within ten (10) to fourteen (14) business days following receipt of the Counter Notification, provided GitHub’s Designated Agent has not received notice from the Complaining Party that an action has been filed seeking a court order to restrain Subscriber from engaging in infringing activity relating to the material on GitHub's system. - -Finally Notices and Counter-Notices with respect to this website must meet then current statutory requirements imposed by the DMCA; see for details. - -C. Disclosure -============= - -Please note that in addition to being forwarded to the person who provided the allegedly infringing content, a copy of this legal notice (with your personal information removed) will be published at . You can see an example of such a publication at . A link to your published letter may be displayed in place of the removed content. diff --git a/_posts/2010-01-16-deploy-keys.markdown b/_posts/2010-01-16-deploy-keys.markdown deleted file mode 100644 index d08573a..0000000 --- a/_posts/2010-01-16-deploy-keys.markdown +++ /dev/null @@ -1,54 +0,0 @@ ---- -layout: default -title: Understanding deploy keys -description: Do you need a deploy key? -categories: intermediate ---- - -

Deploy keys are a handy yet misunderstood feature here on github. This guide will explain when and how to use them instead of normal user keys.

- -##Do you even need a deploy key? - -If your deploy process involves sshing into the server you are deploying to, you probably **do not** need to use deploy keys. Instead, you should use ssh-agent forwarding to temporarily allow the server to use your local ssh keys. Not only is this method easier to maintain, since you don't have any extra keys, but it's also more secure as the server never has keys saved to disk in case of a compromise. As always, you should use a [strong passphrase](/working-with-key-passphrases/) on your keys and let ssh-agent manage them for you. - -If your deploy process is remotly triggered and you do not log in to the deploying server via ssh, then you might need deploy keys. Read on to find out if you do. - -##What are deploy keys? - -Deploy keys are ssh keys just like the ones you attach to your account to allow you to push to and pull from your repos. The only difference is that deploy keys are designed to allow access to a single private repo. This will allow your staging or production server to pull in from your repo, most likely using a deploy tool like [Capistrano](http://www.capify.org/). - -Remember, ssh keys are unique, you cannot use the same key on two repos, or on a repo and a user account. - -##When should I use a deploy key? - -Simple, when you have a server that needs pull access to a single private repo. - -###I'm working with public repos, do I still need deploy keys? - -No! You can simply use the public clone URL for the project. - -###My server needs access to many private repos, how do I handle this? - -The simplest way is to add your server's key to the account of the repo owner. This will allow the server access to any private repo that user owns or is a collaborator on. - -If you don't want your deploy server to have access to every repo, you can make an account specifically for the server, attach its key to the account, and add that account as a collaborator to any repo you do want access to. - -## How do I add my deploy key? - -To add your deploy key, you first have to click on one of your repos. Once you've done that: - -1. In your repo, click the "admin" button. - - ![In your repo, click the "admin" button.](/images/deploy_1.jpg) - -2. Click on "deploy keys" - - ![Click on "deploy keys"](/images/deploy_2.jpg) - -3. Click "Add another deploy key" - - ![Click "Add another deploy key"](/images/deploy_3.jpg) - -4. Fill in your info and click "Add key" - - ![Fill in your info and click "Add key"](/images/deploy_4.jpg) \ No newline at end of file diff --git a/_posts/2010-01-17-capistrano.textile b/_posts/2010-01-17-capistrano.textile deleted file mode 100644 index 44073b6..0000000 --- a/_posts/2010-01-17-capistrano.textile +++ /dev/null @@ -1,89 +0,0 @@ ---- -layout: default -title: Deploying with Capistrano -description: How to set up capistrano to pull from a GitHub repo -categories: advanced ---- - -To prepare your project for "Capistrano":http://www.capify.org/, go into the root directory of that project and run @capify@: - -
-$ cd my_project
-$ capify .
-
- -h2. Generate Public Key - -It would probably be a good idea to add a special user on your server(s) specifically for deployment. Once created, make sure to generate a public key for the server and add it to your github account. You may also want to add your personal public key to this new user's @~/.ssh/authorized_keys@ to ease deployment. - -For more help with deploy keys, see "this guide":/deploy-keys. - -h2. Settings - -Here are the 5 most notable Capistrano config options (found in deploy.rb): - -{% highlight ruby %} -default_run_options[:pty] = true # Must be set for the password prompt from git to work -set :repository, "git@github.com:vanpelt/rails-app.git" # Your clone URL -set :scm, "git" -set :user, "deployer" # The server's user for deploys -set :scm_passphrase, "p@ssw0rd" # The deploy user's password -{% endhighlight %} - -h3. Agent Forwarding - -If you're using your own private keys for git you might want to tell Capistrano to use agent forwarding with this command. Agent forwarding can make key management much simpler as it uses your local keys instead of keys installed on the server. - -{% highlight ruby %}ssh_options[:forward_agent] = true{% endhighlight %} - -h3. Set Branch - -You need to tell cap the branch to checkout during deployment: - -{% highlight ruby %}set :branch, "master"{% endhighlight %} - -Older versions of cap need the full branch name: - -{% highlight ruby %}set :branch, "origin/master"{% endhighlight %} - -Older versions of git (e.g. 1.4.4.2) don't support @git checkout -q@, this will cause your deployment to fail. To fix either upgrade git or: - -{% highlight ruby %}set :scm_verbose, true{% endhighlight %} - -h3. Remote Cache - -In most cases you want to use this option, otherwise each deploy will do a full repository clone every time. - -{% highlight ruby %}set :deploy_via, :remote_cache{% endhighlight %} - -Remote caching will keep a local git repo on the server you're deploying to and simply run a fetch from that rather than an entire clone. This is probably the best option as it will only fetch the changes since the last. - -h3. Shallow Clone - -As an alternative to the remote cache approach, you can use shallow cloning. - -{% highlight ruby %}set :git_shallow_clone, 1{% endhighlight %} - -Shallow cloning will do a clone each time, but will only get the top commit, not the entire repo. This makes it a bit closer to how an svn checkout works. Be warned, shallow clone won't work well with the @set :branch@ option. - -h3. Submodules - -If you're using git submodules you must tell cap to fetch them. - -{% highlight ruby %}set :git_enable_submodules, 1{% endhighlight %} - -h2. Migrating from SVN - -Migrating from SVN-based deploys? "Check this thread":http://groups.google.com/group/github/browse_frm/thread/c5d2620c541e4e1a if you run into any problems. - -h2. Known Hosts bug - -If you are not using agent forwarding, the first time you deploy may fail due to Capistrano not prompting with this message: - -
-The authenticity of host 'github.com (207.97.227.239)' can't be established.
-RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
-Are you sure you want to continue connecting (yes/no)?
-
- -To fix this, ssh into your server as the user you will deploy with, run ssh git@github.com and confirm the prompt. diff --git a/_posts/2010-01-19-managing-clients.markdown b/_posts/2010-01-19-managing-clients.markdown deleted file mode 100644 index 6c2e4d5..0000000 --- a/_posts/2010-01-19-managing-clients.markdown +++ /dev/null @@ -1,33 +0,0 @@ ---- -layout: default -title: Managing multiple clients -description: How to manage multiple clients and their repositories -categories: intermediate ---- - -

Are you a freelance developer working on multiple projects for multiple clients, and want to manage them here on GitHub? Never fear, this guide will detail the most common solutions to this problem.

- -One account, multiple collaborators ------------------------------------ - -This design lets you retain control over the repos, but still gives your clients access to them. - -This is the simplest (and cheapest) approach. Simply create one account with a plan that provides enough private repos to cover all your projects. If your client needs access to the source code, have them create a free account. You can then add their free account as a collaborator on the projects you wish for them to have access to. - -If you wish, you can even bill your clients for the cost of your account, and maintaining their repos on it! - -Multiple accounts, one collaborator ------------------------------------ - -This design gives the control over the repos (and the bill) to your client, but still allows you to push into all your clients' repos from a single account. - -With this design, have your clients each open their own paid account and create empty repos for each project. Add your account to the repos as a collaborator. You can now push to their repos as if they were your own! - -Multiple accounts, no collaborators ------------------------------------ - -__This is by far the most complicated setup, and should be avoided if at all possible.__ - -If, for whatever reason, you *must* push to each client's repos using _their_ account, this is the setup you will have to use. - -First, generate a second keypair to use for your second account. To create this key follow [this guide](/key-setup-redirect), but specify a path for the key. If you do not specify a path you may overwrite your existing key. For example, you could use `~/.ssh/id_rsa_client`. Once the key has been created, add the new public key to the client's account on GitHub. To configure your local settings, see [this guide](/multiple-keys). diff --git a/_posts/2010-01-19-multiple-keys.markdown b/_posts/2010-01-19-multiple-keys.markdown deleted file mode 100644 index 827d1ea..0000000 --- a/_posts/2010-01-19-multiple-keys.markdown +++ /dev/null @@ -1,49 +0,0 @@ ---- -layout: default -title: Multiple SSH keys -description: How to push using different SSH keys on the same computer -categories: intermediate ---- - -

This guide assumes you have already created two keypairs and attached them to different GitHub user accounts. For this example we will be using ~/.ssh/id_rsa attached to the user joe and ~/.ssh/id_rsa_client attached to the user client.

- -Adding your keys to SSH -======================= - -The first keypair, `~/.ssh/id_rsa`, uses a default name, so we don't need to do anything special to make SSH use this pair. The second pair, however, is not a default name. Therefore, we need to tell ssh about it so that it can use it: - -
ssh-add ~/.ssh/id_rsa_client
- -If the keypair has a passphrase on it (it should!), `ssh-add` will ask you to enter the passphrase. After you have done this, the key will be available from ssh-agent so you won't have to re-enter the passphrase every time you use it. - -Configuring SSH -=============== - -Once SSH has access to both keys, you need to tell it which key to use for which server. In most cases you can assume that SSH will fall back to `~/.ssh/id_rsa` by default, but we're going to force it anyway. To begin, open `~/.ssh/config` in your favorite editor. - -{% highlight bash %} -# Default GitHub user (joe) -Host github.com - HostName github.com - User git - IdentityFile /Users/joe/.ssh/id_rsa - -# Client user (client) -Host github-client - HostName github.com - User git - IdentityFile /Users/joe/.ssh/id_rsa_client -{% endhighlight %} - -In short what this does is tells SSH to use the client key when connecting to the server github-client, which is really github.com. - -Using the second key -==================== - -From here on, everything is the same as everyday use except for one component, the domain name. When working on a repo owned by the primary account, we would use a command like: - -
git clone git@github.com:joe/my_repo.git
- -When we want to use the second account's key, however, we need to change the domain name. Doing so will use the settings in `~/.ssh/config` to override the defaults. - -
git clone git@github-client:client/his_repo.git
diff --git a/_posts/2010-01-19-textmate.markdown b/_posts/2010-01-19-textmate.markdown deleted file mode 100644 index 9ad9333..0000000 --- a/_posts/2010-01-19-textmate.markdown +++ /dev/null @@ -1,10 +0,0 @@ ---- -layout: default -title: Textmate -description: How to use Textmate as your git editor -categories: third_party ---- - -Using Textmate as your git editor is fairly simple, you just need to to make sure Textmate informs git when the document is closed. You can do this by using `mate -w`: - -
git config --global core.editor "mate -w"
diff --git a/_posts/2010-01-27-remotes.markdown b/_posts/2010-01-27-remotes.markdown deleted file mode 100644 index 99ebf51..0000000 --- a/_posts/2010-01-27-remotes.markdown +++ /dev/null @@ -1,98 +0,0 @@ ---- -layout: default -title: Working with remotes -description: Pushing, fetching, merging and deleting remote branches -categories: intermediate ---- - -

This guide will cover all the basic day-to-day commands you will use with git to interact with remote repos. For push operations you can only interact with repos you own or are a collaborator on. To gain access to a public repo, check out the forking guide.

- -Managing remotes ----------------- - -Before you can perform any remote operations it is usually best to set up remotes in your repo. If you cloned a repo git will create a remote named "origin" automatically. There are a few commands to help you manage these remotes: - -### add - -This one is pretty straightforward, `git remote add test git://github.com/user/test.git` will create a new remote named "test" pointing to `git://github.com/user/test.git`. If we add a `-f` flag on the end, git will also fetch the remote for us. - -### rename - -Rename a remote and its remote-tracking branches... `git remote rename test example` will rename the "test" remote to "example". - -### rm - -Another basic command, `git remote rm example` will delete the "example" remote and any remote-tracking branches we've fetched. - -### Changing a remote's URL - -There is no direct command to change a remote's URL, so you will usually run `git remote rm` followed by `git remote add` to change a URL. You can also edit the repo's `.git/config` file directly to change the URL without re-fetching the remote. - -Fetching --------- - -When working with other users' repos there are four basic commands you will need, `git clone`, `git fetch`, `git pull` and `git remote prune`. - -### clone - -To grab a full copy of another user's repo when you do not have a local repo already, you will use `git clone URL`. For public repos, the URL can be a read-only URL like `git://github.com/user/repo.git` or an HTTP read-only URL like `http://github.com/user/repo.git`. For public repos you own or are a collaborator on, and all private repos, you must use a private ssh url like `git@github.com:user/repo.git`. You can find each of the URLs available to you in the header of the repo page: - -![header](http://img.skitch.com/20100201-e6dmj54pgmw6wq7314jtbej31k.jpg) - -Running `git clone URL` will automatically create a new subfolder, fetch the contents of the repo into this subfolder, then create and checkout the default branch (usually "master"). If there are other branches on the remote you will need to create a local branch to work in, for example `git checkout -b fix_stuff origin/fix_stuff` - -### fetch - -If you already have a local repo with a remote set up, you can grab all branches and tags for the remote using `git fetch REMOTENAME`. By default, `git clone` will make a remote named "origin" pointing to the URL you cloned from. Fetch does not make any changes to local branches, so you will need to merge remote branches to bring those changes in. - -### pull - -Similar to `git fetch`, you can use `git pull REMOTENAME BRANCHNAME` to fetch a specific branch and merge it into your current local branch. For on-time pulls from other users' repos you can use a URL instead of a remote name. This will pull from that URL without adding a remote. - -Because pull performs a merge you should ensure that your working tree and index are clean before running the command. If you run into a merge conflict you cannot resolve or decide to abort the merge, you can use `git reset ORIG_HEAD --hard` to take the branch back to the commit it was on before you pulled. - -### prune - -Sometimes branches are deleted from a remote repo. By default, `git fetch` will not remove any remote-tracking branches that have been deleted on the remote repo. Running `git remote prune REMOTENAME` will delete these tracking branches. - -Pushing -------- - -At some point you're going to want to publish commits from your repo into a remote for other users to fetch. This process is fairly straightforward. First you need a repo on github you can push to. Either create a new repo, gain collaborator permissions on someone else's repo, or [fork](/forking) someone else's repo. You can only push to an ssh URL like `git@github.com:user/repo.git`. If you cloned another repo with a read-only URL you can add a second remote for your URL or remove or rename the existing remote. See the [git remote manpage](http://www.kernel.org/pub/software/scm/git/docs/git-remote.html) for more information on changing remotes. - -### Pushing a branch - -To push a local branch to an established remote, you simply need to use `git push REMOTENAME BRANCHNAME` If you don't want to use the same name on the remote branch you can use `git push REMOTENAME LOCALBRANCHNAME:REMOTEBRANCHNAME`. - -#### Dealing with "non-fast-forward" errors - -From time to time you may encounter this error while pushing: - -
-$ git push origin master
-To ../remote/
- ! [rejected]        master -> master (non-fast forward)
-error: failed to push some refs to '../remote/'
-To prevent you from losing history, non-fast-forward updates were rejected
-Merge the remote changes before pushing again.  See the 'non-fast forward'
-section of 'git push --help' for details.
-
- -This error can be a bit overwhelming at first, do not fear. Simply put, git cannot make the change on the remote without losing commits, so it refuses the push. Usually this is caused by another user pushing to the same branch. You can remedy this by fetching and merging the remote branch, or using pull to perform both at once. - -In other cases this error is a result of destructive changes made locally by using commands like `git commit --amend` or `git rebase`. While you can override the remote by adding `--force` to the push command, you should only do so if you are absolutely certain this is what you want to do. Force-pushes can cause issues for other users that have fetched the remote branch, and is considered bad practice. When in doubt, don't force-push. - -### Pushing tags - -By default, push will only send the ref you specify. To push a single tag you can simply use `git push REMOTENAME TAGNAME`. To push all tags while pushing another branch, you can use `git push REMOTENAME BRANCHNAME --tags`. - -### Deleting a remote branch or tag - -This command is a bit arcane at first glance... `git push REMOTENAME :BRANCHNAME`. If you look at the advanced push syntax above it should make a bit more sense. You are literally telling git "push _nothing_ into BRANCHNAME on REMOTENAME". - -Links ------ - -* [Pro Git](http://progit.org/book/ch2-5.html) -* [git remote man page](http://www.kernel.org/pub/software/scm/git/docs/git-remote.html) -* [Git user's manual](http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#sharing-development) \ No newline at end of file diff --git a/_posts/2010-01-28-git-ignore.markdown b/_posts/2010-01-28-git-ignore.markdown deleted file mode 100644 index 2c2ad40..0000000 --- a/_posts/2010-01-28-git-ignore.markdown +++ /dev/null @@ -1,72 +0,0 @@ ---- -layout: default -title: Ignoring files -description: How to tell git to ignore files -categories: intermediate ---- - -

From time to time there are files you don't want git to track. There are a few methods of telling git what files to ignore.

- -.gitignore ----------- - -If you create a file in your repo named `.gitignore` git will use its rules when looking at files to commit. Note that git will **not** ignore a file that was already tracked before a rule was added to this file to ignore it. In such a case the file must be un-tracked, usually with `git rm --cached filename` - -This file can be committed into the repo, thus sharing the rule list with any other users that clone the repo. - -Note that you can create a `.gitignore` in any subpath to have its rules applied at that path. Sometimes an empty `.gitignore` file is used as a placeholder for an empty path, for example to force git to generate a `log/` path for your development environment to use. - -Global .gitignore -------------- - -A global .gitignore file can also be used by adding one to your global git config. For example, you might create the file `~/.gitignore_global` and add some rules to it. To add this to your config, run `git config --global core.excludesfile ~/.gitignore_global` - -Some good rules to add to this file: - -
-# Compiled source #
-###################
-*.com
-*.class
-*.dll
-*.exe
-*.o
-*.so
-
-# Packages #
-############
-# it's better to unpack these files and commit the raw source
-# git has its own built in compression methods
-*.7z
-*.dmg
-*.gz
-*.iso
-*.jar
-*.rar
-*.tar
-*.zip
-
-# Logs and databases #
-######################
-*.log
-*.sql
-*.sqlite
-
-# OS generated files #
-######################
-.DS_Store?
-ehthumbs.db
-Icon?
-Thumbs.db
-
- -Repo exclude ------------ - -Local per-repo rules can be added to the `.git/info/exclude` file in your repo. These rules *are not committed* with the repo so they are not shared with others. This method can be used for locally-generated files that you don't expect other users to generate, like files created by your editor. - -Links ------ - -* [Pro Git](http://progit.org/book/ch2-2.html) -* [gitignore man page](http://www.kernel.org/pub//software/scm/git/docs/gitignore.html) diff --git a/_posts/2010-01-29-rebase.markdown b/_posts/2010-01-29-rebase.markdown deleted file mode 100644 index 1f4e628..0000000 --- a/_posts/2010-01-29-rebase.markdown +++ /dev/null @@ -1,154 +0,0 @@ ---- -layout: default -title: Rebase -description: Using git rebase to restructure a branch -categories: intermediate ---- - -

One often overlooked feature of git is the git rebase command. Rebase allows you to easily change a series of commits, reordering, editing, or squashing commits together into a single commit.

- -It is considered bad practice to rebase commits which you have already pushed to a remote repo. Doing so may invoke the wrath of the git gods... you have been warned. - -So, you've cloned a repository, and hacked away at it; separated it into logical chunks, and it's now ready to submit! - -So you send your patch series, or publish your branch, and ask for a pull, but a quick review reveals that there are some errors in these patches! - -Now, the maintainer may send these patches back to you, and ask you to fix these, this guide shows several ways on how this can be accomplished. - -Before you start, make sure you have a clean working tree (i.e. no modified files). - -Using rebase -i ---------------- - -This is the most general (and easiest) way to edit history. - -### Invocation - -The syntax is: - -
git rebase -i last_good_commit
- -For example, to rebase all the commits from master to the current branch's head: - -
git rebase -i master
- -Another common practice is to rebase the last few commits in your current branch. If our branch is named fix_stuff and we want to rebase the last 5 commits we can run: - -
git rebase -i fix_stuff~5
- -Running the command with the `-i` flag will invoke your text editor with a file detailing the commits that will be rebased. This will also list the command available: - -
-pick 1fc6c95 Patch A
-pick 6b2481b Patch B
-pick dd1475d something I want to split
-pick fa39187 something to add to patch A
-pick 7b36971 something to move before patch B
-
-# Rebase 41a72e6..7b36971 onto 41a72e6
-#
-# Commands:
-#  p, pick = use commit
-#  e, edit = use commit, but stop for amending
-#  s, squash = use commit, but meld into previous commit
-#
-# If you remove a line here THAT COMMIT WILL BE LOST.
-# However, if you remove everything, the rebase will be aborted.
-#
-
- -At this point you can edit the file to change the order of the commits. There are three commands available: - -### Pick - -Pick is used to include a commit. By default you will be given a list of the commits you chose to rebase, in order of oldest (top) to newest (bottom). Rearranging the order of the pick commands will change the order of the commits when you begin the rebase. - -### Edit - -Using the edit command on a commit will cause rebase to pick the commit and pause. During this pause you can amend the commit, adding to or removing from it. You can also make more commits before you continue the rebase, this allows you to split a large commit into smaller ones. You should always ensure that your working tree and index are clean before you resume the rebase. - -### Squash - -This command lets you combine two or more commits into a single commit. When used the commit will be picked and then amended into the commit above it. Git will then pause the rebase and open your text editor with the commit messages from both commits. After you have edited the message to your satisfaction save the file and close the editor. Git will resume the rebase. - -### Example - -In this rebase we will cover all 3 commands. We start our rebase with `git rebase -i master~5` and are presented with this file in our editor: - -
-pick 1fc6c95 Patch A
-pick 6b2481b Patch B
-pick dd1475d something I want to split
-pick fa39187 something to add to patch A
-pick 7b36971 something to move before patch B
-
-# Rebase 41a72e6..7b36971 onto 41a72e6
-#
-# Commands:
-#  p, pick = use commit
-#  e, edit = use commit, but stop for amending
-#  s, squash = use commit, but meld into previous commit
-#
-# If you remove a line here THAT COMMIT WILL BE LOST.
-# However, if you remove everything, the rebase will be aborted.
-#
-
- -There are a few things we want to do here, we want to move the last two commits up before the "Patch B" commit. One of those commits will be squashed into the "Patch A" commit. Finally we want to edit the last commit to split it into two commits. We'll change the file as such: - -
-pick 1fc6c95 Patch A
-squash fa39187 something to add to patch A
-pick 7b36971 something to move before patch B
-pick 6b2481b Patch B
-edit dd1475d something I want to split
-
- -Now we save and close the editor to begin the rebase. Since the first operation is a squash our editor opens: - -
-# This is a combination of two commits.
-# The first commit's message is:
-
-Patch A
-
-# This is the 2nd commit message:
-
-something to add to patch A
-
-# Please enter the commit message for your changes. Lines starting
-# with '#' will be ignored, and an empty message aborts the commit.
-# Not currently on any branch.
-# Changes to be committed:
-#   (use "git reset HEAD <file>..." to unstage)
-#
-#	modified:   a
-#
-
- -As usual, edit the file as we wish, save, close the editor. The rebase will proceed until it gets to the edit operation, where it tells us: - -
-You can amend the commit now, with
-
-        git commit --amend
-
-Once you are satisfied with your changes, run
-
-        git rebase --continue
-
- -At this point we would edit the files we need, do a `git commit --amend`, make our second commit, and ensure that our working tree and index are clean. Now we can tell git to complete the rebase with `git rebase --continue`. You might wish to use `git-gui` for amending commits like this, it can make things much easier by visualizing the changes you are committing. - -Notes ------ - -* If others have branched off of the work you have doing, do _not_ modify any of the commits. The rule in Git is that if you have work that people are working off of, you will make it hell for them if you change it. Rebasing and amending are only for commits where you *know* no one is working off of. -* In the upcoming 1.5.6, there will be new rebase -i commands "tag", "merge", and "reset", as well. - -References ----------- - -* [Git user manual - Cleaning up history](http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#cleaning-up-history) -* [git-rebase documentation](http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html) -* [git-commit documentation](http://www.kernel.org/pub/software/scm/git/docs/git-commit.html) diff --git a/_posts/2010-03-02-changing-author-info.markdown b/_posts/2010-03-02-changing-author-info.markdown deleted file mode 100644 index dff42f9..0000000 --- a/_posts/2010-03-02-changing-author-info.markdown +++ /dev/null @@ -1,38 +0,0 @@ ---- -layout: default -title: Changing author info -description: How to modify author info in your repo's history -categories: intermediate ---- - -

If you need to modify the author info in your repo's history, you can do so with this script.

- -

Big bold warning This action is destructive to your repo's history. It's best to do this on a clone, just in case. Also beware that this should not be performed on a repo that has been shared with others. Use at your own risk.

- -{% highlight bash %} -#!/bin/sh - -git filter-branch --env-filter ' - -an="$GIT_AUTHOR_NAME" -am="$GIT_AUTHOR_EMAIL" -cn="$GIT_COMMITTER_NAME" -cm="$GIT_COMMITTER_EMAIL" - -if [ "$GIT_COMMITTER_EMAIL" = "your@email.to.match" ] -then - cn="Your New Committer Name" - cm="Your New Committer Email" -fi -if [ "$GIT_AUTHOR_EMAIL" = "your@email.to.match" ] -then - an="Your New Author Name" - am="Your New Author Email" -fi - -export GIT_AUTHOR_NAME="$an" -export GIT_AUTHOR_EMAIL="$am" -export GIT_COMMITTER_NAME="$cn" -export GIT_COMMITTER_EMAIL="$cm" -' -{% endhighlight %} \ No newline at end of file diff --git a/_posts/2010-06-02-svn-importing.markdown b/_posts/2010-06-02-svn-importing.markdown deleted file mode 100644 index 59956a8..0000000 --- a/_posts/2010-06-02-svn-importing.markdown +++ /dev/null @@ -1,55 +0,0 @@ ---- -layout: default -title: Importing from Subversion -categories: intermediate ---- - -

GitHub can directly import SVN projects. All you need is the repository URL. After creating a repo you can pick "Import a Subversion Repository" option:

- -![](http://img.skitch.com/20100603-fq9q2b9qu7it37i2axhhntanqc.png) - -Please note that imports that take more than an hour or non-standard repository file structures may fail. This is a one-time import, it will not sync with future commits in the SVN repo. For either of these cases, you'll need to manually import the repo. - -Manual import -------------- - -### svn2git - -[svn2git](http://github.com/nirvdrum/svn2git) is designed to provide a complete svn import. Unlike git-svn, it will create proper git tags from your svn "tags". - -### git-svn - -[git-svn](http://www.kernel.org/pub/software/scm/git/docs/git-svn.html) can be used to import as well. Note that there may be issues if you have branches or tags (they won't be imported over). If you only have a trunk, like many svn repositories, this method should work for you without issue. - -First, be sure to [create your repository on GitHub](http://github.com/repositories/new) - -
$ git svn clone -s SVN_REPO_URL LOCAL_DIR
-$ cd LOCAL_DIR
-$ git remote add origin git@github.com:GITHUB_USERNAME/REPO_NAME.git
-$ git push origin master
- -Note that the `-s` switch implies that your svn repo is set up with the standard branches/tags/trunk structure. - -git-svn adds a note to every commit message it copies over from svn. To get rid of that note, add `--no-metadata` to the command. - -You can pull in later commits by running `git-svn rebase` from within your repo. If you ever lose your local copy, just run the import again with the same settings and you'll get another working directory with all the necessary git-svn settings saved. - -#### Author mapping - -When migrating a Subversion repository to Git, you can map the Subversion users to Git users. You have to create an authors file which contains the mappings: - - tekkub = Tekkub - -The format is `svnuser = gituser_name `. To automatically generate an authors file, check out [this guide](http://technicalpickles.com/posts/creating-a-svn-authorsfile-when-migrating-from-subversion-to-git/). - -Once your authors file is complete, clone the subversion repository with the authors file: - -
$ git svn --authors-file=path/to/authors_file clone SVN_REPO_URL LOCAL_DIR
- -Other guides ------------- - -* [Guide by Yuval Kogman](http://blog.woobling.org/2009/06/git-svn-abandon.html) -* [Guide by John Goulah](http://blog.johngoulah.com/2009/11/migrating-svn-to-git) -* [Guide by Jon Maddox](http://www.simplisticcomplexity.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/) -- doesn't deal with branches -* [Guide by Bob McWhirter](http://www.fnokd.com/2008/08/20/mirroring-svn-repository-to-github) -- doesn't deal with branches diff --git a/_posts/2010-06-03-firewalls-and-proxies.markdown b/_posts/2010-06-03-firewalls-and-proxies.markdown deleted file mode 100644 index ab06515..0000000 --- a/_posts/2010-06-03-firewalls-and-proxies.markdown +++ /dev/null @@ -1,19 +0,0 @@ ---- -layout: default -title: Dealing with firewalls and proxies -categories: troubleshooting ---- - -There are a few ways to deal with a draconian firewall or an unruly proxy: - -* [Smart HTTP](http://github.com/blog/642-smart-http-support) -- By far the easiest approach. Available with git v1.7 and later. Works great with proxies and firewalls that block non-HTTP outbound connections. - - * [Not-so-smart HTTP](http://github.com/blog/92-http-cloning) -- For cloning public repos only, on pre-1.7 git clients. Use only if Smart HTTP is not an option. - -* [corkscrew](http://blog.codeslower.com/2008/8/Using-PuTTY-and-SSL-to-securely-access-GitHub-repositories-via-SSH) -- Works best with firewalls, creates an outbound ssh connection on port 80. Proxies may interfere. - - * [another corkscrew guide](http://dilipm79.blogspot.com/2008/11/why-i-love-git-and-github.html) - - * [and another](http://returnbooleantrue.blogspot.com/2009/06/using-github-through-draconian-proxies.html) - -* [ssh forwarding](http://gist.github.com/423642) -- Similar to corkscrew, requires access to an external ssh server. Two slightly different methods are provided. diff --git a/_posts/2010-08-29-pull-requests.md b/_posts/2010-08-29-pull-requests.md deleted file mode 100644 index f212460..0000000 --- a/_posts/2010-08-29-pull-requests.md +++ /dev/null @@ -1,233 +0,0 @@ ---- -layout: default -title: Sending pull requests -description: How to notify others of your changes using Pull Requests. -categories: beginner ---- - - - -

Pull requests let you tell others about changes you've pushed to a GitHub -repository. Once a pull request is sent, interested parties can review the set -of changes, discuss potential modifications, and even push follow-up commits if -necessary.

- -

This guide walks through the process of sending a hypothetical pull request and -using the various code review and management tools to take the change to -completion.

- -## A Quick Note on Collaborative Development Models - -There are two popular models of collaborative development on GitHub: - - 1. The *Fork + Pull Model* lets anyone fork an existing repository and - push changes to their personal fork without requiring access be granted - to the source repository. The changes must then be pulled into the source - repository by the project maintainer. This model reduces the amount of - friction for new contributors and is popular with open source projects - because it allows people to work independently without upfront - coordination. - - 2. The *Shared Repository Model* is more prevalent with small teams and - organizations collaborating on private projects. Everyone is granted push - access to a single shared repository and topic branches are used to isolate - changes. - -Pull requests are especially useful in the *Fork + Pull Model* because they -provide a way to notify project maintainers about changes in your fork. However, -they're also useful in the *Shared Repository Model* where they're used to -initiate code review and general discussion about a set of changes before being -merged into a mainline branch. - -## Before You Begin - -This guide assumes that [you have a GitHub account](http://github.com/signup), -that you've forked an existing repository and pushed your changes. For help with -forking and pushing changes, see the [Forking a project](/forking/) topic. - -## Initiating The Pull Request - -In the following example, **kneath** has completed some work on an error page -for the GitHub Jobs web application, pushed three commits to a topic branch in -his fork, and would like someone to review and merge. - -Navigate to **your repository** with the changes you want someone else to pull and -press the *Pull Request* button. - -![](http://img.skitch.com/20100831-qfk1c9wyt89pfgfxg61bh1r8rn.png) - -Pull requests can be sent from any branch or commit but it's recommended that a -topic branch be used so that follow-up commits can be pushed to update the pull -request if necessary. - -## Previewing The Pull Request - -After pressing the *Pull Request* button, you are presented with a preview page -where you can enter a title and optional description, see exactly what -commits will be included when the pull request is sent, and also see who the -pull request will be sent to: - -![](http://img.skitch.com/20100831-qit9sjhuqk42t4ww91ifm5tm81.png) - -If you're sending from a topic branch, the title is pre-filled based on the name -of the branch. Markdown is supported in the description, so you can embed images -or use preformatted text blocks. - -Switch to the *Commits* tab to ensure that the correct set of changes is being -sent: - -![](http://img.skitch.com/20100831-c9g4pcsjwnfj14csrpytenxyfn.png) - -Review the diff of all changes by switching to the *Files Changed* tab: - -![](http://img.skitch.com/20100831-qpc5bu8grycefnnbaagnuwbckq.png) - -## Changing The Commit Range and Destination Repository - -By default, pull requests are assumed to be based on the parent-most -repository's integration branch. In this case, the `kneath/jobs` repository was -forked from `github/jobs` so the pull request is assumed to be based on the -`master` branch of the `github/jobs` repository. In a great majority of cases, -the defaults will be right; however, if any of this information is incorrect, press -the *Change Commits* button. - -![](http://img.skitch.com/20100831-nm1mgb6n8ng7e4nrdesucqx98h.png) - -The commit range selector will expand, allowing the base repository, base -branch, and head branch to be customized: - -![](http://img.skitch.com/20100831-pwsq1inmr7m7y61dfcyxnhjkkd.png) - -The easiest way of thinking about the commit range is this: the *base branch* is -**where** you think changes should be applied, the *head branch* is **what** you -would like to be applied. - -Changing the base repository changes who is notified of the pull request. -Everyone that can push to the base repository will receive an email notification -and see the new pull request in their dashboard the next time they log in. - -Once you're happy with the commit range, press the *Update Commit Range* button -to update the commit and files changed preview areas. - -## Sending The Pull Request - -Once you've entered the title and description, made any necessary customizations -to the commit range, and reviewed the commits and file changes to be sent, press -the *Send pull request* button. - -![](http://img.skitch.com/20100831-fe6i533swbgsgypgc645f999i.png) - -The pull request is sent immediately. You're taken to the main pull request -discussion and review page. Additionally, all repository collaborators and -followers will see an event in their dashboard: - -![](http://img.skitch.com/20100831-bj3rg8bac4buemstnwqy7wwxq2.png) - -## Managing Pull Requests - -All pull requests sent or received by you are browseable through the pull -request dashboard. - -![](http://img.skitch.com/20100831-xfscxin81wj5j3gwyas2sd398q.png) - -Pull requests for a specific repository are also browseable by anyone with -access by visiting the *Network -> Pull Requests* page. - -![](http://img.skitch.com/20100823-bahbpwpemx3jh2kpke77d2dxtc.png) - -The pull request dashboard and the repository pull request list support a wide -range of filtering and sorting controls. Use them to narrow down the list to -the pull requests you're interested in. - -## Reviewing Proposed Changes - -When you receive a pull request, the first thing to do is review the set of -proposed changes. Pull requests are tightly integrated with the underlying git -repository, so you can see exactly what commits would be merged should the -request be accepted: - -![](http://img.skitch.com/20100831-81im4n771y5tcwg3ryixajtfeg.png) - -You can also review the cumulative diff of all file changes across all commits. - -![](http://img.skitch.com/20100831-enh8t415ryr5b1sw45shq9ier3.png) - -## Pull Request Discussion - -After reviewing the basic description, commits, and cumulative diff, the person -tasked with applying the changes may have questions or comments. Perhaps the -coding style doesn't match project guideline, or the change is missing unit -tests, or maybe everything looks great and some props are in order. The -discussion view is designed to encourage and capture this type of discussion. - -![](http://img.skitch.com/20100831-j7fapxihs2a3i48ai5qmqceskp.png) - -The discussion view starts with the pull request's original title and -description and then captures additional activity to display chronologically -from there. Any of the following types of activity are captured as they happen: - - * Comments left on the pull request itself. - * Additional commits pushed to the pull request's branch. - * File and line notes left on any of the commits included in the pull request's range. - -Pull request comments are Markdown compatible, so you can embed images, use -preformatted text blocks, and other formatting supported by Markdown. - -## Merging a Pull Request - -Once the pull request is deemed satisfactory, someone with push access to the -destination repository must apply the changes and push the updated branch. -There are a variety of ways to accomplish this. Two popular methods are -described below. - -#### Fetch and Merge - -This is the most common method of fetching and applying changes. It requires -adding a remote for the person that sent the pull request, fetching from that -repository, merging the requested branch, fixing any conflicts, and pushing -the newly merged branch back to the repository: - -
-$ git checkout master
-$ git remote add kneath git://github.com/kneath/jobs.git
-$ git fetch kneath
-$ git merge kneath/error-page
-$ git push origin master
-
- -#### Patch and Apply - -The *fetch and merge* approach works great when you're working on a team or -repeatedly applying changes from the same small group of people. Another -approach that's a bit quicker in one-off cases is to use `git-am`. - -Every pull request has a `.patch` URL where you can grab a textual patch file -to feed into the `git-am` command: - -
-$ git checkout master
-$ curl http://github.com/github/jobs/pull/25.patch | git am
-$ git push origin master
-
- -## Closing a Pull Request - -Pull Requests are automatically closed when the requested commits are merged -into the destination repository. An event is generated to let all repository -collaborators and followers know that the merge occurred: - -![](http://img.skitch.com/20100831-x9ush35wkyxwmw4sw8yd5sx1eg.png) - -It's also possible to manually close a pull request in cases where the set of -changes are rejected. This is also sometimes necessary if the changes are -applied with `git-cherry-pick` or using some other mechanism that disallows the -merge from being detected. diff --git a/_posts/2010-10-14-git-cheat-sheets.textile b/_posts/2010-10-14-git-cheat-sheets.textile deleted file mode 100644 index ff97611..0000000 --- a/_posts/2010-10-14-git-cheat-sheets.textile +++ /dev/null @@ -1,328 +0,0 @@ ---- -layout: default -title: Git cheat sheets -description: Quick-reference guides to git -categories: git_resources ---- - -h3. Cheat sheets - -* Alexander Zeitler's "Git Cheat Sheet":http://github.com/AlexZeitler/gitcheatsheet -* Zach Rusin's "Git Cheat Sheet":http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html -* "http://cheat.errtheblog.com/s/git/":http://cheat.errtheblog.com/s/git/ -* Nate Murray's "Git Cheat Sheet":http://www.xcombinator.com/2010/09/01/git-cheat-sheet-and-class-notes/ -* "Git - Der Spickzettel":https://github.com/esc/git-cheatsheet-de/ (in German) -* "DZone Git RefCard Cheat Sheet":http://refcardz.dzone.com/refcardz/getting-started-git - -h3. A practical git guide - -_Notes extracted from git screencast at http://www.peepcode.com._ - -h4. Configuration - -identify yourself to git: email and your name - -@git config --global user.name "David Beckwith"@ - -

git config --global user.email "dbitsolutions@gmail.com"

- -To view all options: - -@git config --list@ - -OR - -@cat .git/config@ - -h4. Set up aliases - -@git config --global alias.co checkout@ - -h4. View your configuration - -@cat .gitconfig@ - -h4. To ignore whitespace (Ruby is whitespace insensitive) - -@git config --global apply.whitespace nowarn@ - -Some nice aliases: - -gb = git branch -gba = git branch -a -gc = git commit -v -gd = git diff | mate -gl = git pull -gp = git push -gst = git status - -h3. Start using git - -@git init@ - -h4. Ignoring files - -Add a file in the root directory called @.gitignore@ and add some files to it: (comments begin with hash) - - *.log - db/schema.rb - db/schema.sql - -Git automatically ignores empty directories. If you want to have a @log/@ directory, but want to ignore all the files in it, add the following lines to the root @.gitignore@: (lines beginning with '!' are exceptions) - -@log/*@ -@!.gitignore@ - -Then add an empty @.gitignore@ in the empty directory: - -@touch log/.gitignore@ - -h4. Scheduling the addition of all files to the next commit - -@git add .@ - -h4. Checking the status of your repository - -@git status@ - -h4. Committing files - -@git commit -m "First import"@ - -h4. Seeing what files have been committed - -@git ls-files@ - -h4. Scheduling deletion of a file - -@git rm [file name]@ - -h4. Committing all changes in a repository - -@git commit -a@ - -h4. Scheduling the addition of an individual file to the next commit - -@git add [file name]@ - -h4. Viewing the difference as you commit - -@git commit -v@ - -h4. Commit and type the message on the command line - -@git commit -m "This is the message describing the commit"@ - -h4. Commit and automatically get any other changes - -@git commit -a@ - -h4. A "normal" commit command - -@git commit -a -v@ - -h4. Viewing a log of your commits - -@git log@ - -h4. Viewing a log of your commits with a graph to show the changes - -@git log --stat@ - -h4. Viewing a log with pagination - -@git log -v@ - -h4. Visualizing git changes - -@gitk --all@ - -h4. Creating a new tag and pushing it to the remote branch - -@git tag "v1.3"@ -@git push --tags@ - -h4. Creating a new branch - -@git branch [name of your new branch]@ - -h4. Pushing the branch to a remote repository - -@git push origin [new-remote]@ - -h4. Pulling a new branch from a remote repository - -@git fetch origin [remote-branch]:[new-local-branch]@ - -h4. Viewing branches - -@git branch@ - -h4. Viewing a list of all existing branches - -@git branch -a@ - -h4. Switching to another branch - -The state of your file system will change after executing this command. - -@git checkout [name of the branch you want to switch to]@ - -OR - -@git co [name of the branch you want to switch to]@ - -h4. Making sure changes on master appear in your branch - -@git rebase master@ - -h4. Merging a branch back into the master branch - -First, switch back to the master branch: - -@git co master@ - -Check to see what changes you're about to merge together, compare the two branches: - -@git diff master xyz@ - -If you're in a branch that's not the @xyz@ branch and want to merge the @xyz@ branch into it: - -@git merge xyz@ - -h4. Reverting changes to before said merge - -@git reset --hard ORIG_HEAD@ - -h4. Resolving conflicts - -Remove the markings, add the file, then commit. - -h4. Creating a branch (and switching to the new branch) in one line - -@git checkout -b [name of new branch]@ - -h4. Creating a stash (like a clipboard) of changes to allow you to switch branches without committing - -@git stash save "Put a message here to remind you of what you're saving to the clipboard"@ - -h4. Switching from the current branch to another - -@git co [branch you want to switch to]@ - -Do whatever -Then switch back to the stashed branch - -@git co [the stashed branch]@ - -h4. Viewing a list of stashes - -@git stash list@ - -h4. Loading back the stash - -@git stash apply@ - -Now you can continue to work where you were previously. - -h4. Deleting a branch (that has been merged back at some point) - -@git branch -d [name of branch you want to delete]@ - -h4. Deleting an unmerged branch - -@git branch -D [name of branch you want to delete]@ - -h4. Deleting a stash - -@git stash clear@ - -h4. Setting up a repository for use on a remote server - -Copy up your repository. e.g.: - -

scp -r my_project deploy@yourbox.com:my_project

- -Move your files on the remote server to @/var/git/my_project@ -For security make the owner of this project git -On the repository server: - -@sudo chown -R git:git my_project@ - -Then (for security) restrict the "deploy" user to doing git-related things in @/etc/passwd@ with a @git-shell@. - -h4. Checking out a git repository from a remote to your local storage - -

git clone git@yourbox.com:/var/git/my_project

- -h4. Viewing extra info about a remote repository - -@cat .git/config@ - -By virtue of having cloned the remote repository, your local repository becomes the slave and will track and synchronize with the remote master branch. - -h4. Updating a local branch from the remote server - -@git pull@ - -h4. Downloading a copy of an entire repository (e.g. @laptop@) without merging into your local branch - -@git fetch laptop@ - -h4. Merging two local branches (ie. your local xyz branch with your local master branch) USE MERGE - -@git merge laptop/xyz@ - -This merged the (already copied laptop repository's xyz branch) with the current branch you're sitting in. - -h4. Viewing metadata about a remote repository - -@git remote show laptop@ - -h4. Pushing a committed local change from one local branch to another remote branch - -@git push laptop xyz@ - -h4. Creating a tracking branch (i.e. to link a local branch to a remote branch) - -@git branch --track local_branch remote_branch@ - -You do not need to specify the local branch if you are already sitting in it. - -@git pull@ - -Note: You can track(link) different local branches to different remote machines. For example, you can track your friend's "upgrade" branch with your "bobs_upgrade" branch, and simultaneously you can track the origin's "master" branch (of your main webserver) with your local "master" branch. - -By convention, 'origin' is the local name given to the remote centralized server which is the way SVN is usually set up on a remote server. - -h4. Seeing which local branches are tracking a remote branch - -@git remote show origin@ - -h4. Working with a remote Subversion repository (but with git locally) - -@git-svn clone [http location of an svn repository]@ - -Now you can work with the checked out directory as though it was a git repository. (cuz it is) - - -h4. Pushing (committing) changes to a remote Subversion repository - -@git-svn dcommit@ - -h4. Updating a local git repository from a remote Subversion repository - -@git-svn rebase@ - -NOTE: make sure you have your perl bindings to your local svn installation. - -h4. I screwed up, how do I reset my checkout? - -@git checkout -f@ - -h3. See also - -* "Git for computer scientists. (lots of pictures)":http://eagain.net/articles/git-for-computer-scientists/ -* "Git user's manual":http://www.kernel.org/pub/software/scm/git/docs/user-manual.html -* "Git Magic":http://www-cs-students.stanford.edu/~blynn/gitmagic/ -* "Git Cheat Sheets Collection":http://devcheatsheet.com/tag/git/ on DevCheatSheet.com \ No newline at end of file diff --git a/_posts/2011-02-18-be-social.markdown b/_posts/2011-02-18-be-social.markdown deleted file mode 100644 index 47a7c62..0000000 --- a/_posts/2011-02-18-be-social.markdown +++ /dev/null @@ -1,95 +0,0 @@ ---- -layout: default -title: Be Social -description: Follow a friend. Watch a project. -categories: beginner ---- - -If you’ve found yourself on this page, we’re assuming you’re brand new to Git and GitHub. This guide will walk you through the basics and explain a little bit about how everything works along the way. - -##First: Follow A Friend - -One of the great features on GitHub is the ability to see what other people are working on and who they are connecting with. When you follow someone, you will get notifications on your dashboard about their GitHub activity. - -1. Pick a friend. - - Why not follow one of these cool people? -
- - -

Tom Preston-Werner

-

mojombo

- - - -

Chris Wanstrath

-

defunkt

- - - -

PJ Hyett

-

pjhyett

- - - -

Scott Chacon

-

schacon

- -
- - Who are these fine fellows? Why the founders of GitHub, of course! - -2. Follow a friend - - Once you are on one of their pages, click the “follow” button. - - Click “Follow - - Congratulations! You are now following a friend. - -##Next: Watch A Project - -At some point you may want to stay up-to-date with a specific project. We’ve made this easy to do. - -1. Watch a project - - Our friend the Octocat has a project called Hello World that we’d like to watch. - - Once you are in the project page, you will notice there is a “watch” button at the top of the page. Click on it. - - Click “Watch - - Congratulations! You are now watching the the Hello World project. If the Octocat updates it, you will see what happened in your dashboard. - -##Then: More Things You Can Do - -You’ve done some of the most basic social interaction GitHub has to offer, but don’t stop there! Check out these other social features: - -- Pull Requests - - Pull Requests - - You may find yourself wanting to contribute to someone else’s project, whether to add features or to fix bugs. After making changes, you can let the original author know about them by sending a [pull request](/pull-requests/). - -- Issues - - Issues - - When you are collaborating on a project with someone, you some times come across problems that need to be fixed. To help you keep track of these problems, each GitHub repo has a section called Issues. For an example, check out the [issues](https://github.com/octocat/Spoon-Knife/issues) for the Spoon-Knife repo. - -- Organizations - - Organizations - - Have you found yourself wishing you could collaborate with multiple developers on one project? You can manage everyone with Organizations! With an organization you can establish teams with special permissions, have a public organization profile, and keep track of activity within the organization. - -##Lastly: Celebrate - -Congratulations! You are quite the socialite. What do you want to do next? - -
    -
  1. Set Up Git
    2. -
  2. Create A Repository
    3. -
  3. Fork A Repository
    4. -
  4. Be Social
    5. -
\ No newline at end of file diff --git a/_posts/2011-03-07-egit-bad-tree.markdown b/_posts/2011-03-07-egit-bad-tree.markdown deleted file mode 100644 index 42341dc..0000000 --- a/_posts/2011-03-07-egit-bad-tree.markdown +++ /dev/null @@ -1,56 +0,0 @@ ---- -layout: default -title: Fixing bad tree -description: How to fix the bad tree error on a github repo caused by egit -categories: troubleshooting ---- - -Due to a bug in egit's implementation of the `git rm` command, empty trees may not be removed from the index and result in a "bad tree" error on github: - -![](https://img.skitch.com/20110308-875n82b15ktc8kc34wdaj1euky.jpg) - -Fixing the repo ---------------- - -Fixing this error is fairly simple with the commandline. To fix the error you need to recreate the tree and then remove it using `git rm` to ensure it is removed correctly. - -For example, if the bad tree is at `badtree/` we would run: - -
tekkub@iSenberg ~/tmp/fixing_bad_tree master
-> mkdir badtree
-
-tekkub@iSenberg ~/tmp/fixing_bad_tree master
-> touch badtree/temp
-
-tekkub@iSenberg ~/tmp/fixing_bad_tree master
-> git add badtree/temp
-
-tekkub@iSenberg ~/tmp/fixing_bad_tree master+
-> git commit -m "Fixing bad tree, step one"
-[master dbe6a08] Fixing bad tree, step one
- 0 files changed, 0 insertions(+), 0 deletions(-)
- create mode 100644 badtree/temp
-
-tekkub@iSenberg ~/tmp/fixing_bad_tree master
-> git rm badtree/temp
-rm 'badtree/temp'
-
-tekkub@iSenberg ~/tmp/fixing_bad_tree master+
-> git commit -m "Fixing bad tree, step two"
-[master 46ae6d2] Fixing bad tree, step two
- 0 files changed, 0 insertions(+), 0 deletions(-)
- delete mode 100644 badtree/temp
-
- -We can then confirm the tree is removed by making sure it is not listed by `git ls-tree`: - -
tekkub@iSenberg ~/tmp/fixing_bad_tree master
-> git ls-tree -r HEAD | grep badtree
-
- -If this returns no results, push the repo and everything should be fixed! - -Avoiding future corruption --------------------------- - -We recommend users avoid using egit to remove files from their repos. Always use `git rm` from the command line. diff --git a/_posts/2011-04-04-leave-a-repo.markdown b/_posts/2011-04-04-leave-a-repo.markdown deleted file mode 100644 index 5e424d9..0000000 --- a/_posts/2011-04-04-leave-a-repo.markdown +++ /dev/null @@ -1,16 +0,0 @@ ---- -layout: default -title: Leave a repo -description: Leave a repo you are collaborating on -categories: beginner ---- - -To leave a repository on which you are collaborating: - -_Click "Account Settings"_ > _Click "Repositories"_ - -![](/images/remove_repo.png) - -An "x" will show up in the corner of the repositories you can remove. - -None of your commits will be lost. Only the repository owner can [delete repos](/deleting-a-repo/). -- cgit v1.3.1