Changes for page Getting Started with Git
Last modified by Bastian Triller on 2013/05/21 17:24
From version 171.1
edited by Ray Kiddy
on 2011/07/04 19:09
on 2011/07/04 19:09
Change comment:
added some "unique concept" bits
To version 164.1
edited by Kieran Kelleher
on 2011/03/29 16:24
on 2011/03/29 16:24
Change comment:
There is no comment for this version
Summary
-
Page properties (3 modified, 0 added, 0 removed)
Details
- Page properties
-
- Title
-
... ... @@ -1,1 +1,1 @@ 1 - GettingStarted with Git1 +git - Author
-
... ... @@ -1,1 +1,1 @@ 1 -XWiki.ki ddyr1 +XWiki.kieran - Content
-
... ... @@ -1,124 +1,119 @@ 1 - {{toc}}{{/toc}}1 += Learning About git = 2 2 3 -= Got Git? No? Get Git = 3 +[[Excellent Concept Tutorial on Git>>http://www.eecs.harvard.edu/~~cduan/technical/git/]] 4 +[[Free Online Pro Git book>>http://progit.org/book/]] 5 +[[Git User Manual>>http://www.kernel.org/pub/software/scm/git/docs/user-manual.html]] 6 +[[Git Reference>>http://gitref.org/index.html]] 7 +[[Linus Torvalds talks about git>>http://www.youtube.com/watch?v=4XpnKHJAok8]] 4 4 5 -* Official Download Site: [[http://git-scm.com/download]] 6 -* Direct Download Links: 7 -** MacOS X [[.dmg Binary Installers>>http://code.google.com/p/git-osx-installer/]] 8 -** Microsoft Windows [[.exe Binary Installers>>http://code.google.com/p/msysgit/]] 9 += Install Git = 9 9 10 - =Learn AboutGit=11 +[[OS X dmg Installer>>http://code.google.com/p/git-osx-installer/]] 11 11 12 -* Learn the concepts. 13 -** [[This>>http://www.eecs.harvard.edu/~~cduan/technical/git/]] is an excellent tutorial on the basic concepts behind Git 13 += Git Goodies = 14 14 15 -* Learn the basics. 16 -** [[Everyday GIT With 20 Commands Or So>>http://www.kernel.org/pub/software/scm/git/docs/everyday.html]] 17 -** [[Free Online Pro Git book>>http://progit.org/book/]] 15 +=== Git Bash Completion === 18 18 19 -* Get familiar with the reference materials available online 20 -** Official [[Git Documentation>>http://git-scm.com/documentation]] Site 21 -** Official [[Git User Manual>>http://www.kernel.org/pub/software/scm/git/docs/user-manual.html]] 22 -** [[Git Reference>>http://gitref.org/index.html]] 17 +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: 18 +[[Git Bash Auto-Completion>>http://progit.org/book/ch2-7.html]] 23 23 24 -* Git Cheat Sheets 25 -** [[http://cheat.errtheblog.com/s/git/]] 26 -** [[http://ktown.kde.org/%7Ezrusin/git/git-cheat-sheet-medium.png]] 20 +=== GitX git GUI === 27 27 28 - *[[LinusTorvalds talks aboutgit>>http://www.youtube.com/watch?v=4XpnKHJAok8]]29 - Have aGood Laugh here as LinusTorvaldsEvangelizes git.//NOTE: This isn't really learning, butitis way morefun and gives you insight into themotivation behind git.//22 +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. 23 +[[GitX Home Page>>http://gitx.frim.nl/]] 30 30 31 -= GetStartedwithProject Wonder=25 +=== Open in GitX === 32 32 33 - Thebest way to learnanewconceptistoactually useit, andwhat betterwaythantosomething practicalclone (checkout) the Project Wonder source code27 +[[Open In GitX Finder Droplet>>http://code.google.com/p/git-osx-installer/wiki/OpenInGitX]] 34 34 35 - *[[DownloadingWonder>>http://wiki.objectstyle.org/confluence/display/WONDER/Getting+the+Wonder+Source+Code]]Wiki Page29 +== Git Tower == 36 36 37 -= Use Git with a Subversion Project = 31 +For those of you who just get panic attacks at the thought of using the Terminal, there is a commercial app for that: 32 +[[Git Tower>>http://www.git-tower.com/]] 38 38 39 - OK,so you want to use Git but you are workingon ateamproject thatis hosted in asubversionrepository ... and it is making you depressed :-( .Well, you can still use Git to manage yourlocal SVN workingcopyand be happy again34 += Using git locally on a Subversion Working Copy = 40 40 41 - Irecommendyoujust usethe[[git+svn protocol>>http://www.lostechies.com/blogs/derickbailey/archive/2010/02/03/branch-per-feature-how-i-manage-subversion-with-git-branches.aspx]].36 +OK, so you are addicted to git, and now you have to work on a team project that is hosted in a remote subversion repository ... and it is making you depressed :-(. Well, you can use manage your local svn working copy using git and be happy again! 42 42 43 - =GitGoodies forWebObjectsDevelopers=38 +There is a git-svn tool (type man git-svn in the terminal for details), but that adds yet another tool into the mix that you have to learn. So while you could use it and YMMV for projects tht are going to be on svn forever, I recommend you just use the [[git+svn protocol>>http://www.lostechies.com/blogs/derickbailey/archive/2010/02/03/branch-per-feature-how-i-manage-subversion-with-git-branches.aspx]] instead, especially if you are typically working on one particular branch of the remote svn repository. 44 44 45 - Thisisalistoftoolsthat other WebObjects developers have foundtobehelpful. It's not a comprehensivelist,andif you findthingsnotlisted here pleaseadd them40 += I want to learn git before I switch from Subversion = 46 46 47 -=== EGit === 42 +(This kind of repeats some of the previous section, but that's on purpose so we can condition you brain to start using git right now ;-) ) 43 +Even while you are working with svn repositories, you can start learning and taking advantage of git right now by making your local svn working copy an actual local git repository. The idea is to use the appropriate ignore feature of each SCM system to ignore the hidden files of the other system. The concept is described here: 48 48 49 - EGitisa pluginforEclipse 3.6. It's notasgood asToweror GitX,butyoucanuseitformost tasks(add, commit, push, pull).45 +[[**git+svn** Working Protocol>>http://www.lostechies.com/blogs/derickbailey/archive/2010/02/03/branch-per-feature-how-i-manage-subversion-with-git-branches.aspx]] 50 50 51 -* [[EGit/Git For Eclipse Users>>http://wiki.eclipse.org/EGit/Git_For_Eclipse_Users]] 52 -* [[User Guide>>http://wiki.eclipse.org/EGit/User_Guide]] 53 -* Installation 54 -*1. In Eclipse, select //Help > Install New Sofware...// 55 -*1. Select the "Helios" download site from the Work with: combo box 56 -*1. Expand the "Collaboration" group 57 -*1. Select the EGit plugin, click Next 58 -*1. Complete the install process and agree to the license, etc. 59 -*1. Restart Eclipse. 47 +When you first learn about git and you google "git svn" you will learn about a command line tool git-svn which works directly with remote svn repos. Unless you want to use git locally to switch between svn branches, I don't recommend it. Use the **git+svn** approach outlined in above blog post instead. 60 60 61 - ===GitBashCompletion===49 +Once you start using git, it becomes addictive ....... you can never go back ...... really, it's that good ...... and it is not hard. 62 62 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 -[[Git Bash Auto-Completion>>http://progit.org/book/ch2-7.html]] 51 +Some tips for Eclipse setup and general workflow when using git locally on svn working copies, 65 65 66 -=== GitX git GUI === 53 +* check out the entire svn branch that you work on using the command line, then LINK (import no copy) the projects you want in your workspace using the Subclipse import tool, and 54 +* Do your git operations (status, staging, commit, diff, branching, checkouts, rebase and merge using the terminal). git on the terminal is efficient... honest. 55 +* Do all your local work and cimmits on branches other than the master branch. 56 +* Switch to master branch to update from svn and commit those svn updates on the master branch. 57 +* Merge your working branch(es) with or rebase your working branch(es) from the master and just keep on working. 58 +* Switch to master branch before synchronizing with remote svn repo. 59 +* You can use ##git stash## to temporarily put aside your uncommitted changes before doing an svn update. Then use ##git stash pop## to replay those uncommitted changes onto the working copy. 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/]] 61 +{{code title="Mechanics of an svn update operation on a git-managed svn working copy"}} 70 70 71 -=== Open in GitX === 72 72 73 -[[Open In GitX Finder Droplet>>http://code.google.com/p/git-osx-installer/wiki/OpenInGitX]] 64 +# Assume you are currently on a working branch. Verify this and check for uncommitted changes. 65 +git status 74 74 75 -=== Git Tower === 67 +# Either commit your local changes to your working branch 68 +# using 'git add' + 'git commit', or temporarily stash 69 +# them using 'git stash' 70 +git stash 76 76 77 -[[Git Tower>>http://www.git-tower.com/]] is a commerical app for those of you who just get panic attacks at the thought of using the Terminal. 72 +# Switch to master branch 73 +git checkout master 78 78 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 - Miguel Arroz 75 +# Ensure there are no changes either from an svn perspective 76 +# or a git perspective on the master branch. 77 +git status 78 +svn status 81 81 82 -= Unique Git Concepts = 80 +# Update the master branch from remote svn repo 81 +svn update 83 83 84 -=== Rebasing === 83 +# Commit those updates to git repo 84 +git commit -a -m "updated from remote svn repo" 85 85 86 -Rebasing is unique to git. There is no counterpart in Subversion. 86 +# Switch to your working branch 87 +git checkout workingbranch 87 87 88 -Rebasing cuts down on the spaghetti history of merging and helps to keep history nice and linear. 89 +# Merge or rebase your working branch off of the updated master. 90 +# This rewinds your branch commits back to the common commit ancestor 91 +# shared between your working branch and the master branch. Then it 92 +# applies the master branch commits (the svn updates) so that this 93 +# working branch becomes identical to the master. After that it 'replays' 94 +# your working branch commits on top of the updated branch. 95 +# This ensures a clean linear progression. Rebasing is a very cool feature of git. 96 +rebase master 89 89 90 -Conceptually, when I rebase my current branch A on another branch B, git removes all my branch A commits back to the common ancestor of A and B, stashes those commits away temporarily, moves the head of the current branch A to the tip of the other branch B, and then re-applys all my stashed commits as **new commit** patches to my branch B. 98 +# Now if you stashed uncommitted changes earlier, you can pop them back into 99 +# the working copy 100 +git stash pop 91 91 92 - However before using it on work that is sharedwith others you MUST follow the these rules, otherwise you will screw everyone else on the project.102 +{{/code}} 93 93 94 -* If you don't understand rebasing, don't use it You can learn more about it here: 95 -** [[http://progit.org/book/ch3-6.html]] 96 -** [[http://www.eecs.harvard.edu/~~cduan/technical/git/git-5.shtml]] 97 -** [[http://book.git-scm.com/4_rebasing.html]] 98 -** [[http://blip.tv/file/4094727]] 99 -* Use rebase only on **private** branches 100 -* Use rebase only for commits that have **not been pushed** to a remote repo 104 +{{code title="Mechanics of an svn commit operation from a git-managed svn working copy"}} 101 101 102 - ===Push/PullvsCommit/Update===106 +# First perform an svn update as outlined above in the previous section 103 103 104 -It may be helpful to separate "push/pull" in your mind from "commit/update". Say that I have a bunch of changes that I want to --commit to Wonder-- share with the community. I am not going to push my changes. I am going to check in my changes to my repository (either a clone or a fork) and then push from my repository or generate a pull request from my repository. My repository should be fully checked in before I do this. 108 +# Switch to the master branch 109 +git checkout master 105 105 106 -Say that I do not want to check in all of the changes I am looking at. The answer seems to be that you create a branch, take the changes you want to share, commit them and then share from that branch. And, again, before one generates the pull request or does the push, the branch should be clean and all changes in it should be committed. 111 +# Merge your working branch with the master 112 +git merge workingbranch 107 107 108 - Whatif onewants to generate a pull requestthe origin and also push to a fork? You woulddo thisif you werenota Wondercommitterbutwanted tosharecode. You organizeyour changesin your local repository/branchand, fromthecleanrepository or branch, generatethe pull request and,separately,pushthe changes toyourfork.114 +# Use svn status, svn add and svn commit to commit your changes to the remote svn repository 109 109 110 - ===Versions?orDiffs?===116 +# Switch back to your workingbranch and get back to work. 111 111 112 -One satori that I had while speaking to my git guru (thanks, Kieran!) is this. Subversion is all about versions. CVS was all about versions. We have been working with these a long time and the ideas are sticky. Git is //not// about versions. It is about diffs. Diffs are the main thing. If you think about it, this makes sense. You have thoughts and make changes and those diffs are the product of your work. If you get those diffs into something, that is good, but the work product was the diffs. 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. 115 - 116 -Internally, git keeps track of text fragments and not files. Why is this? Because the versions are not the point. The diffs are. I can imagine how Linus Torvalds had this idea. He was looking at all the versions of all the files in Linux and all the e-mails of all the diffs. These are two separate worlds. It is conceptually painful to look at every diff, find its source and see how it maps to what now exists. At some point, he must have realized that all he needed was the e-mails. If he had no files any longer, but all the e-mails, he could always reconstruct the files. He would not have to make the conceptual switch from the diffs to the versions and back. Collectively, those e-mails with the diffs defined everything that needed to be said. Quod erat demonstrandum. 117 - 118 -=== How Easy Are Branches? === 119 - 120 -It may be helpful to realize this. You should become comfortable with branching. In svn, branching is hard but it is not hard in git. If you have a thought, mull over that thought for a few minutes and jot something down, you have done enough to justify a branch and the branch will be not much harder than finding the post-its on your desk, and perhaps easier. Think about when you would have created a branch in svn. For that amount of work and to establish that level of separation, in git you would create a fork, or create a new repository. 121 - 122 -Might you end up with too many branches? Perhaps. How messy is your desk? If you are a clean-desk person, you will probably not have too many branches. You will organize and combine your branches. You will rebase your branches. You may delete your branches. After all, you had the thought. You can write the code again. If it is too distracting to keep the branch relevant, tuck the thought into the back of your head, delete the branch, let it go and move on. If you are a messy-desk person, you will probably have lots of branches. It would probably be a good thing to clean up, merge and rebase your branches before you try to share your changes. But that is obvious. Nobody wants to see how messy your desk is. 123 - 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. 119 +{{/code}}