diff options
Diffstat (limited to '_posts')
| -rwxr-xr-x | _posts/2009-06-11-forking.markdown | 67 | ||||
| -rw-r--r-- | _posts/2009-07-04-git-html-help.markdown | 2 | ||||
| -rw-r--r-- | _posts/2009-09-03-working-with-key-passphrases.textile | 2 | ||||
| -rw-r--r-- | _posts/2009-09-09-removing-sensitive-data.markdown | 112 | ||||
| -rw-r--r-- | _posts/2009-09-09-removing-sensitive-data.textile | 85 | ||||
| -rw-r--r-- | _posts/2009-10-10-subtree-merge.markdown | 99 | ||||
| -rw-r--r-- | _posts/2009-10-10-subtree-merge.textile | 74 | ||||
| -rw-r--r-- | _posts/2009-10-16-post-receive-hooks.markdown | 85 | ||||
| -rw-r--r-- | _posts/2009-11-03-userscripts-and-bookmarklets.textile | 6 | ||||
| -rw-r--r-- | _posts/2010-01-19-multiple-keys.markdown | 14 | ||||
| -rwxr-xr-x | _posts/2010-01-27-remotes.markdown | 2 | ||||
| -rw-r--r-- | _posts/2010-03-02-changing-author-info.markdown | 7 | ||||
| -rw-r--r-- | _posts/2010-08-29-pull-requests.md | 234 | ||||
| -rw-r--r-- | _posts/2010-10-14-git-cheat-sheets.textile | 326 |
14 files changed, 926 insertions, 189 deletions
diff --git a/_posts/2009-06-11-forking.markdown b/_posts/2009-06-11-forking.markdown index db011a8..dc99a4a 100755 --- a/_posts/2009-06-11-forking.markdown +++ b/_posts/2009-06-11-forking.markdown @@ -6,64 +6,93 @@ categories: collaborating popular main_category: collaborating --- -This guide will step you through the process of forking, pushing your changes, and pulling in changes from the upstream repo. +This guide will step you through the process of forking, pushing your changes, +and pulling in changes from the upstream repo. -In this guide, we will use [github-services](http://github.com/pjhyett/github-services) as an example to fork, submit a change, and re-sync with the forked repo. All the examples on this page assume you're working in the "master" branch. +We'll use [github-services](http://github.com/pjhyett/github-services) as an +example to fork, submit a change, and re-sync with the forked repo. -Note that this works for pulling from a forked repository to the original, as well. +All of the examples on this page assume you're working in the `master` branch. + +Note that this works for pulling from a forked repository to the original as well. Setting up ---------- -Naturally, the first thing you must do is create your fork. To do this, you simply click the "fork" button on the project's page. When the fork has completed, you will be presented with your new repo information. +First, create your fork. Click the *Fork* button on the project's page. You +will be presented with the information for your newly forked repository:  -Now you need to clone the fork. Make sure you use the Private URL and __not__ the Public one. +Now clone the fork locally. Make sure you use the *Private URL*, __not__ the +*Public URL*. + <pre class="terminal">$ git clone git@github.com:billyanyteen/github-services.git</pre> -Once the clone is complete your repo will have a remote named "origin" that points to your fork on github. Don't let the name confuse you, this __does not__ point to the original repo you forked from. To help you keep track of that repo we will add another remote named "upstream" +Once the clone is complete your repo will have a remote named "origin" that +points to your fork on github. Don't let the name confuse you, this __does +not__ point to the original repo you forked from. To help you keep track of +that repo we will add another remote named "upstream": + <pre class="terminal">$ cd github-services $ git remote add upstream git://github.com/pjhyett/github-services.git -$ git fetch upstream</pre> +$ git fetch upstream +</pre> -Note that we used the public clone URL for upstream, so we can't push changes directly to it. We probably don't have permission to do that anyway, which is why we're creating a fork in the first place. If the upstream repo is private, you must use its private URL. +Note that we used the public clone URL for upstream, so we can't push changes +directly to it. We probably don't have permission to do that anyway, which is +why we're creating a fork in the first place. If the upstream repo is private, +you must use its private URL. Pushing your changes -------------------- -Now that we've got our fork, we need to make a few changes and commit them locally. Once you've done this, it's time to push your updated branch. -<pre class="terminal">$ git push origin master</pre> +Now that we've got our fork, we need to make a few changes and commit them +locally. Once you've done this, it's time to push your updated branch: -After you've pushed your commit(s) you need to inform the project owner of the changes so they can pull them into their repo. From your project's page, click the "pull request" button. Fill in a note and pick who to send the request to. In large projects it is important that you __do not__ send the request to every person who's touched the project. Make sure you're only sending to the people who care, the user(s) that manage the core project repo. +<pre class="terminal">$ git push origin master</pre> -_Note that some projects do not accept pull requests. Make sure you submit your request to the place they want it, or you will probably just be ignored._ +Once you've pushed your commit(s), inform the project owner of the changes so +they can pull them into their repo. The best way to do this is by [sending a +pull request](/pull-requests/). Pulling in upstream changes --------------------------- -Some time has passed, the upstream repo has changed and you want to update your fork before you submit a new patch. There are two ways to do this: +Some time has passed, the upstream repo has changed and you want to update your +fork before you submit a new patch. There are two ways to do this: + <pre class="terminal">$ git fetch upstream $ git merge upstream/master</pre> <pre class="terminal">$ git pull upstream master</pre> -`git pull` is a more direct way, but the merge it performs can be confusing if the user doesn't expect it and a merge conflict results. `git fetch` will also grab all branches, where `git pull` will only grab the one specified. +`git pull` is a more direct way, but the merge it performs can be confusing if +the user doesn't expect it and a merge conflict results. `git fetch` will also +grab all branches, where `git pull` grabs only the one specified. -If you have local commits that are not in the upstream branch, a normal merge will occur. If your local commits are in the upstream branch, a fast-forward merge will be done, moving your local branch to the same commit as upstream/master. If both repos have edits to the same location in the same file, you may run into a merge conflict. Conflicts must be resolved by hand and a commit made to complete the merge. +If you have local commits that are not in the upstream branch, a normal merge +will occur. If your local commits are in the upstream branch, a fast-forward +merge will be done, moving your local branch to the same commit as +upstream/master. If both repos have edits to the same location in the same +file, you may run into a merge conflict. Conflicts must be resolved by hand and +a commit made to complete the merge. -Now that your local branch has been updated, you can commit, push, and send a pull request. +Now that your local branch has been updated, commit your changes, push, and +[send a pull request](/pull-requests/). -You may wish to do the fetch and merge manually, instead of letting git-pull do it for you. This can sometimes help avoid headaches caused by mysterious merge conflicts. +You may wish to do the fetch and merge manually, instead of letting git-pull do +it for you. This can help avoid headaches caused by mysterious merge conflicts. Deleting the forked repository ------------------------------ -To remove the fork, just delete it like any repo: click the "Admin" button next to "Unwatch", then at the bottom of the page there will be a "Delete This Repository…" link. +To remove the fork, delete it like any repo: click the *Admin* button, then the +*Delete This Repository…* button. Additional resources -------------------- * [hub](http://github.com/defunkt/hub) * [github-gem](http://github.com/defunkt/github-gem) -* [Rails on the Run forking tutorial](http://railsontherun.com/2008/3/3/how-to-use-github-and-submit-a-patch)
\ No newline at end of file +* [Rails on the Run forking tutorial](http://railsontherun.com/2008/3/3/how-to-use-github-and-submit-a-patch) diff --git a/_posts/2009-07-04-git-html-help.markdown b/_posts/2009-07-04-git-html-help.markdown index dae6fd4..b945edb 100644 --- a/_posts/2009-07-04-git-html-help.markdown +++ b/_posts/2009-07-04-git-html-help.markdown @@ -2,7 +2,7 @@ layout: default title: Installing Git HTML help description: How to install the local git HTML help files -categories: setup +categories: other --- 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. diff --git a/_posts/2009-09-03-working-with-key-passphrases.textile b/_posts/2009-09-03-working-with-key-passphrases.textile index 19e45bd..988e66b 100644 --- a/_posts/2009-09-03-working-with-key-passphrases.textile +++ b/_posts/2009-09-03-working-with-key-passphrases.textile @@ -59,7 +59,7 @@ function test_identities { if [ $? -eq 2 ];then start_agent fi - fi + fi } # check for running ssh-agent with proper $SSH_AGENT_PID diff --git a/_posts/2009-09-09-removing-sensitive-data.markdown b/_posts/2009-09-09-removing-sensitive-data.markdown new file mode 100644 index 0000000..776b086 --- /dev/null +++ b/_posts/2009-09-09-removing-sensitive-data.markdown @@ -0,0 +1,112 @@ +--- +layout: default +title: Removing sensitive data +description: Dealing with accidentally committed passwords or other sensitive information +categories: popular git_ninjutsu +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-09-removing-sensitive-data.textile b/_posts/2009-09-09-removing-sensitive-data.textile deleted file mode 100644 index 185dfd2..0000000 --- a/_posts/2009-09-09-removing-sensitive-data.textile +++ /dev/null @@ -1,85 +0,0 @@ ---- -layout: default -title: Removing sensitive data -description: Dealing with accidentally committed passwords or other sensitive information -categories: popular git_ninjutsu ---- - -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. - -h2. 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. - -h2. 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. - -<pre class="terminal">[tekkub@tekBook: ~/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@tekBook: ~/tmp master*] $ cd github-gem/ - -[tekkub@tekBook: ~/tmp/github-gem master] $ git filter-branch --index-filter 'git update-index --remove Rakefile' master -Rewrite 48dc599c80e20527ed902928085e7861e6b3cbe6 (266/266) -Ref 'refs/heads/master' was rewritten</pre> - -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 <code>--tag-name-filter "cat"</code>, but note that *this will overwrite your existing tags*. - -<pre class="terminal">[tekkub@tekBook: ~/tmp/github-gem master] $ echo "Rakefile" >> .gitignore - -[tekkub@tekBook: ~/tmp/github-gem master*] $ git add .gitignore - -[tekkub@tekBook: ~/tmp/github-gem master+] $ git commit -m "Add Rakefile to .gitignore" -[master 051452f] Add Rakefile to .gitignore - 1 files changed, 1 insertions(+), 0 deletions(-)</pre> - -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. - -<pre class="terminal">[tekkub@tekBook: ~/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)</pre> - -h3. 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. - -<pre class="terminal">[tekkub@tekBook: ~/tmp/github-gem master] $ rm -rf .git/refs/original/ -[tekkub@tekBook: ~/tmp/github-gem master] $ git reflog expire --all -[tekkub@tekBook: ~/tmp/github-gem master] $ git gc --aggressive --prune -Counting objects: 1746, done. -Delta compression using 2 threads. -Compressing objects: 100% (1736/1736), done. -Writing objects: 100% (1746/1746), done. -Total 1746 (delta 993), reused 0 (delta 0)</pre> - -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. - -h2. 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. - -h2. 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. - -h2. 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. - -h2. 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-10-10-subtree-merge.markdown b/_posts/2009-10-10-subtree-merge.markdown new file mode 100644 index 0000000..79b4a45 --- /dev/null +++ b/_posts/2009-10-10-subtree-merge.markdown @@ -0,0 +1,99 @@ +--- +layout: default +title: Working with subtree merge +description: How to use subtree merge to merge one repo into another as a subpath. +categories: git_ninjutsu +--- + +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 merge two other repos into it as subpaths. + + [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 + + [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 merge in cork" + + [master fe0ca25] Subtree merge in cork + + [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 merge in panda" + [master 726a2cd] Subtree merge in panda + +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-10-subtree-merge.textile b/_posts/2009-10-10-subtree-merge.textile deleted file mode 100644 index c2b3fd3..0000000 --- a/_posts/2009-10-10-subtree-merge.textile +++ /dev/null @@ -1,74 +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: git_ninjutsu ---- - -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 histor of each repo. To do this, the subtree merge strategy is a better solution. - -h2. Setting up and doing the first merge - -For this example, we'll make an empty "parent" repo and merge two other repos into it as subpaths. - -<pre class="terminal">[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 - -[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 merge in cork" -[master fe0ca25] Subtree merge in cork - -[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 merge in panda" -[master 726a2cd] Subtree merge in panda</pre> - -h2. Pulling in changes - -If the merged repo changes in the future, you can pull in its changes by simply using the @-s subtree@ flag: - -<pre class="terminal">[tekkub@tekBook: ~/tmp/test master] $ git pull -s subtree panda master</pre> - -h2. Resources - -* "How to use the subtree merge strategy":http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
\ No newline at end of file diff --git a/_posts/2009-10-16-post-receive-hooks.markdown b/_posts/2009-10-16-post-receive-hooks.markdown index c971a31..25db1e8 100644 --- a/_posts/2009-10-16-post-receive-hooks.markdown +++ b/_posts/2009-10-16-post-receive-hooks.markdown @@ -17,19 +17,98 @@ What we'll send is JSON containing information about the push and the commits in Here's the template we use in Ruby to generate the JSON: -<script src="http://gist.github.com/212213.js"> </script> +{% 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: -<script src="http://gist.github.com/212212.js"> </script> +{% highlight ruby %} +post '/' do + push = JSON.parse(params[:payload]) + "I got some JSON: #{push.inspect}" +end +{% endhighlight %} The `commits` array is ordered with the most recent commit as the first element. The last element, therefor, is the oldest commit. Here's an example payload: -<script src="http://gist.github.com/212211.js"> </script> +{% 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/). diff --git a/_posts/2009-11-03-userscripts-and-bookmarklets.textile b/_posts/2009-11-03-userscripts-and-bookmarklets.textile index 8457075..34f8c9e 100644 --- a/_posts/2009-11-03-userscripts-and-bookmarklets.textile +++ b/_posts/2009-11-03-userscripts-and-bookmarklets.textile @@ -5,7 +5,7 @@ description: Various bits of code to enhance and personalize GitHub categories: other --- -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/help/help.github.com. +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. @@ -17,8 +17,12 @@ h2. GitHub * "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. 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/2010-01-19-multiple-keys.markdown b/_posts/2010-01-19-multiple-keys.markdown index fc82d5f..bea4b6b 100644 --- a/_posts/2010-01-19-multiple-keys.markdown +++ b/_posts/2010-01-19-multiple-keys.markdown @@ -21,7 +21,19 @@ 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. -<script src="http://gist.github.com/281414.js?file=config"> </script> +{% 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. diff --git a/_posts/2010-01-27-remotes.markdown b/_posts/2010-01-27-remotes.markdown index 7dafa2c..2682832 100755 --- a/_posts/2010-01-27-remotes.markdown +++ b/_posts/2010-01-27-remotes.markdown @@ -5,7 +5,7 @@ description: Pushing, fetching, merging and deleting remote branches categories: everyday_git --- -This guide will cover all the basic day-to-day commends 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](/forking). +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](/forking). Managing remotes ---------------- diff --git a/_posts/2010-03-02-changing-author-info.markdown b/_posts/2010-03-02-changing-author-info.markdown index 099aaf3..c567aef 100644 --- a/_posts/2010-03-02-changing-author-info.markdown +++ b/_posts/2010-03-02-changing-author-info.markdown @@ -9,8 +9,8 @@ If you need to modify the author info in your repo's history, you can do so with __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. -<script src="http://gist.github.com/262686.js?file=history_rewrite.sh"> </script> -<noscript><pre>#!/bin/sh +{% highlight bash %} +#!/bin/sh git filter-branch --env-filter ' @@ -34,4 +34,5 @@ export GIT_AUTHOR_NAME="$an" export GIT_AUTHOR_EMAIL="$am" export GIT_COMMITTER_NAME="$cn" export GIT_COMMITTER_EMAIL="$cm" -'</pre></noscript>
\ No newline at end of file +' +{% endhighlight %}
\ No newline at end of file diff --git a/_posts/2010-08-29-pull-requests.md b/_posts/2010-08-29-pull-requests.md new file mode 100644 index 0000000..6453331 --- /dev/null +++ b/_posts/2010-08-29-pull-requests.md @@ -0,0 +1,234 @@ +--- +layout: default +title: Sending pull requests +description: How to notify others of your changes using Pull Requests. +categories: collaborating +main_category: collaborating +--- + +<style type="text/css"> +.main img { + border:1px solid #eee; + padding:5px; +} +.main img.inline { + vertical-align:middle; + border:0; +} +</style> + +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. + + + +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: + + + +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: + + + +Review the diff of all changes by switching to the *Files Changed* tab: + + + +## 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. + + + +The commit range selector will expand, allowing the base repository, base +branch, and head branch to be customized: + + + +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. + + + +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: + + + +## Managing Pull Requests + +All pull requests sent or received by you are browseable through the pull +request dashboard. + + + +Pull requests for a specific repository are also browseable by anyone with +access by visiting the *Network -> Pull Requests* page. + + + +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: + + + +You can also review the cumulative diff of all file changes across all commits. + + + +## 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. + + + +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 compatibility, 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: + +<pre class="console"> +<span>$</span> git checkout master +<span>$</span> git remote add kneath git://github.com/kneath/jobs.git +<span>$</span> git fetch kneath +<span>$</span> git merge kneath/error-page +<span>$</span> git push origin master +</pre> + +#### 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: + +<pre class="console"> +<span>$</span> git checkout master +<span>$</span> curl http://github.com/github/jobs/pull/25.patch | git am +<span>$</span> git push origin master +</pre> + +## 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: + + + +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 new file mode 100644 index 0000000..1eb0b45 --- /dev/null +++ b/_posts/2010-10-14-git-cheat-sheets.textile @@ -0,0 +1,326 @@ +--- +layout: default +title: Git cheat sheets +description: Quick-reference guides to git +categories: everyday_git +--- + +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/ + +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 |