Changes for page Getting Started with Git
Last modified by Bastian Triller on 2013/05/21 17:24
From version 180.1
edited by Kieran Kelleher
on 2011/07/25 18:06
on 2011/07/25 18:06
Change comment:
There is no comment for this version
To version 202.1
edited by Kieran Kelleher
on 2012/01/03 10:24
on 2012/01/03 10:24
Change comment:
There is no comment for this version
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -7,16 +7,25 @@ 7 7 ** MacOS X [[.dmg Binary Installers>>http://code.google.com/p/git-osx-installer/]] 8 8 ** Microsoft Windows [[.exe Binary Installers>>http://code.google.com/p/msysgit/]] 9 9 10 +{{info title="Git is included with XCode 4.x"}} 11 + 12 +XCode 4.x installs a copy of git in /usr/bin/git 13 + 14 +{{/info}} 15 + 10 10 = Learn About Git = 11 11 12 12 * Learn the concepts. 19 +** Scott Chacon (of GitHub) Video Intro [[http://www.youtube.com/watch?v=ZDR433b0HJY]] 13 13 ** [[This>>http://www.eecs.harvard.edu/~~cduan/technical/git/]] is an excellent tutorial on the basic concepts behind Git 14 - 21 +** [[Git for Computer Scientists>>http://eagain.net/articles/git-for-computer-scientists/]] gives another good view on the underlying concepts 15 15 * Learn the basics. 16 16 ** [[Everyday GIT With 20 Commands Or So>>http://www.kernel.org/pub/software/scm/git/docs/everyday.html]] 17 17 ** [[Free Online Pro Git book>>http://progit.org/book/]] 25 +*** There is even a free epub version for your iPad/iPhone [[https://github.s3.amazonaws.com/media/progit.epub]] 18 18 19 19 * Get familiar with the reference materials available online 28 +** [[Git Community Book>>http://book.git-scm.com/]] 20 20 ** Official [[Git Documentation>>http://git-scm.com/documentation]] Site 21 21 ** Official [[Git User Manual>>http://www.kernel.org/pub/software/scm/git/docs/user-manual.html]] 22 22 ** [[Git Reference>>http://gitref.org/index.html]] ... ... @@ -30,16 +30,19 @@ 30 30 31 31 = Get Started with Project Wonder = 32 32 33 -The best way to learn a new concept is to actually use it, and what better way than to do something practical like clone (checkout) the Project Wonder source code42 +The best way to learn a new concept is to actually use it, and what better way than to do something practical like clone the Project Wonder git source code repository 34 34 35 35 * [[Downloading Wonder>>http://wiki.objectstyle.org/confluence/display/WONDER/Getting+the+Wonder+Source+Code]] Wiki Page 36 36 37 37 = Use Git with a Subversion Project = 38 38 39 -OK, so you want to use Git but you are working on a team project that is hosted in a subversion repository ... and it is making you depressed :-( . Well, you can still use Git to manage your local SVN working copy and be happy again 48 +OK, so you want to use Git but you are working on a team project that is hosted in a subversion repository ... and it is making you depressed :-( . Well, you can still use Git to manage your local SVN working copy and be almost happy again (Either way, you won't be 100% happy unless the repository is a git one.) 40 40 41 - Irecommendyou justusethe [[git+svnprotocol>>http://www.lostechies.com/blogs/derickbailey/archive/2010/02/03/branch-per-feature-how-i-manage-subversion-with-git-branches.aspx]].50 +There are a couple ways of doing this. Two of them are: 42 42 52 +* Follow these [[Instructions>>http://www.lostechies.com/blogs/derickbailey/archive/2010/02/03/branch-per-feature-how-i-manage-subversion-with-git-branches.aspx]] to manually set up the integration. 53 +* Use [[SourceTree>>http://itunes.apple.com/us/app/sourcetree-git-hg/id411678673?mt=12]] which can clone your SVN repository locally as a full Git repository including all historical SVN commits and their metadata. 54 + 43 43 = Git Goodies for WebObjects Developers = 44 44 45 45 This is a list of tools that other WebObjects developers have found to be helpful. It's not a comprehensive list, and if you find things not listed here please add them ... ... @@ -63,11 +63,20 @@ 63 63 This is really an absolute necessity and a **huge** productivity improvement. Basically you need the bash completion script from the source tarball and use your shell profile to include it whenever you open a shell. See the **Auto-Completion** section on this page: 64 64 [[Git Bash Auto-Completion>>http://progit.org/book/ch2-7.html]] 65 65 66 -=== GitXgitGUI===78 +=== SourceTree by Atlassian === 67 67 68 -GitX is an awesome FREE history viewer made for OS X. It is a better way to visualize your branch and commit history of your git repository. However, power users (aka "cool kids") will probably only use it for history viewing while they continue to use the terminal command line for checkouts, branching, staging, rebasing and committing. 69 -[[GitX Home Page>>http://gitx.frim.nl/]] 80 +SourceTree is a free Git/Mercurial GUI for OS X. A key feature is that it can use git-svn to "Clone" a SVN repository into a standard Git repository with your full SVN commit history and maintains a link back to the SVN repository. This allows you to easily use Git locally for development but still do your final commits to SVN. 70 70 82 +* [[SourceTree on AppStore>>http://itunes.apple.com/us/app/sourcetree-git-hg/id411678673?mt=12]] 83 +* [[SourceTree Home Page>>http://www.sourcetreeapp.com/]] 84 + 85 +=== GitX (L) git GUI === 86 + 87 +While most (if not all) Git GUI apps will never be able to emulate all the intricate functionality of Git, one advantage of a GUI app is more convenient and faster browsing/visualization of history and inter-relationships of branches. While development on the original open source GitX.app has waned, this fork of the original has continued to mature into a nice Git client, and is useful for common every day Git operations. However, power users (aka "cool kids") will probably only use it for history viewing while they continue to use the terminal command line for checkouts, branching, staging, rebasing and committing. 88 +[[GitX (L) Home Page>>http://gitx.laullon.com/]] 89 + 90 +Note this app replaces the original [[GitX>>http://gitx.frim.nl/]] by Pieter de Bie. 91 + 71 71 === Open in GitX === 72 72 73 73 [[Open In GitX Finder Droplet>>http://code.google.com/p/git-osx-installer/wiki/OpenInGitX]] ... ... @@ -79,6 +79,20 @@ 79 79 I use Tower (bought it), but only for committing and fixing merge conflicts. I think Tower misses quite a bit of the flagship feature of GIT: branches. You can't see a branch tree graphically, like you can with gitX or even the command line (git log -graph -color, IIRC). But it's cool for committing. For everything else I use command line. 80 80 Miguel Arroz 81 81 103 +=== Gitolite - A Git Repository Server === 104 + 105 +Need a way to host a few dozen or hundred repositories with dead simple administration? Look no further than the free and open-source [[gitolite>>http://sitaramc.github.com/gitolite/]]. You just need a single dedicated user account on some unix based OS. Once installed and configured, you can perform administration tasks such as adding users, adding repositories and setting fine-grained user access privileges all from your own desktop. 106 + 107 +The best place to start is probably the ProGit chapter on gitolite, which is maintained by the author of gitolite, and is right here: 108 +[[Pro Got Gitolite Chapter>>https://github.com/sitaramc/gitolite/blob/pu/doc/progit-article.mkd]] 109 + 110 +Some tips/gotchas to keep in mind when setting up gitolite 111 + 112 +* Make sure you give the gitolite user ownership of the admin public ssh key after copying the key over! 113 +* Rename your public keyname to username.pub, where username is the name you want to use to identify yourself when configuring gitolite access control to repositories. 114 +* During setup, gitolite creates the file ,,/.ssh/authorized//keys in the gitolite user account. Ensure it has permissions of 600. If not change it!//,, 115 +* If other system users such as apache, chiliproject or redmine need [[read access to the gitolite repositories to allow integration>>http://www.giocc.com/public-repositories-in-gitolite-with-umasks.html]], then you probably want to change the $REPO//MASK configuration value from 0077 to 0027 in the [[gitolite configuration file>>http://sitaramc.github.com/gitolite/rc.html]]// 116 + 82 82 = Unique Git Concepts = 83 83 84 84 === Rebasing === ... ... @@ -107,13 +107,15 @@ 107 107 108 108 What if one wants to generate a pull request the origin and also push to a fork? You would do this if you were not a Wonder committer but wanted to share code. You organize your changes in your local repository/branch and, from the clean repository or branch, generate the pull request and, separately, push the changes to your fork. 109 109 110 -=== Versions?orDiffs?===145 +=== Testing a Pull-Request === 111 111 112 - One satorithatI had while speaking tomygit guru(thanks,Kieran)isthis.Subversion is allaboutversions.CVS wasall aboutversions.Wehave beenworking with thesealongtimeandtheideasareicky.Git is //not// aboutversions.Itboutdiffs.Diffsre the main thing.If youthinkaboutit,thismakessense.Youhavethoughtsandmakechangesand thosediffsare theproductof your work.Ifyougetthosediffsintosomething,that isgood, but thek productwas the diffs.147 +It may not be obvious how to do this. If one is a committer, there is a button one can push to automatically accept a pull-request. But is this really a safe thing to do? But how can you get the diffs being suggested? It seems more complicated than it needs to be to merge the branch the pull-request was made from. One can actually use a URL that specifies just the diff. If the pull-request is at [[https://github.com/projectwonder/wonder/pull/43]], one can do: 113 113 114 -All this rebasing and such may seem odd. But the main thing is the diffs. I have edits from a two-week old repository. What do I do? I move the diffs so that they are diffs from the latest code. That is a rebase. When we make edits, we are used to being over-concerned about merge conflicts. But they do not happen all that often and are actually easy to deal with when they do, if the tools are oriented to making them easy to deal with. If we are worrying about the versions and not the diffs, we are paying attention to the paper we write on and not to the words we are putting down. 149 +{{code}} 150 +curl 'https://github.com/projectwonder/wonder/pull/43.patch' | git am 151 +{{/code}} 115 115 116 - Internally,git keeps track of text fragmentsand notfiles. Why isthis? Because theversionsare notthepoint. Thediffs are.I can imaginehowLinus Torvalds hadthis idea.He was lookingat allthe versionsof allthefilesin Linux and all the-mailsof allthe diffs. Thesearetwoseparateworlds.Itis conceptuallypainful to look at everydiff, find itssourceandsee howitmapstowhatnowexists.Atsome point,hemust have realized that all heneeded washe e-mails.Ifhe hadnofiles any longer, but all the e-mails,he could alwaysreconstruct thefiles. He wouldnot have to make the conceptualswitchfromthediffs totheversions and back. Collectively, thosee-mails withthediffs defined everything that needed tobesaid. Quod eratdemonstrandum.153 +The curl fetches the diff. Take off the "git am" to just see the diffs. The "git am" merges the diffs. Then you may build and test the pull-request. A normal push will push the code into the repository. 117 117 118 118 === How Easy Are Branches? === 119 119 ... ... @@ -123,11 +123,15 @@ 123 123 124 124 Keep in mind that the difficult part of what you do should be the thinking. Git makes it easy to organize and share your thoughts as branches. Your local copies may be messy or not. They are the thoughts you have in your head and lots of those thoughts will stay there and never see the light of day and that is ok. But when you have clarified your thoughts, git will make it easy to share them. 125 125 163 +=== Finding the List of All Git Commands === 164 + 165 +The "git help" command gives one the list of commonly used git commands. How does one find the others, since some of them turn out to be very useful? I tried "git help v". That was wrong. It would have been better to try "git help help", but this did tell me about the -all flag, which actually lists out all of the commands, and there are quite a few of them. So, good hunting. 166 + 126 126 = Git Everyday Tasks = 127 127 128 128 === How to revert? === 129 129 130 -Reverting is easy. The following command removes all modifications to files in your w qorking copy and brings them back to the HEAD.171 +Reverting is easy. The following command removes all modifications to files in your working copy and brings them back to the HEAD. 131 131 132 132 {{code}} 133 133