Changes for page Getting Started with Git

Summary

• Page properties (2 modified, 0 added, 0 removed)

Details

Page properties

Author

...	...	@@ -1,1 +1,1 @@
1		-XWiki.kieran
	1	+XWiki.avendasora

Content

...	...	@@ -1,63 +1,40 @@
1		-{{toc}}{{/toc}}
	1	+= Got Git? If not, Get Git here =
2	2
3		-= Got Git? No? Get Git =
	3	+Just pick the latest release for your Mac architecture here:
	4	+[[OS X dmg Installer>>http://code.google.com/p/git-osx-installer/]]
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/]]
	6	+= Learning About git =
9	9
10		-= Learn About Git =
	8	+Start here:
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
	10	+* [[Excellent Concept Tutorial on Git>>http://www.eecs.harvard.edu/~~cduan/technical/git/]]
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/]]
	12	+Have a Good Laugh here as Linus Torvalds Evangelizes git:
	13	+//this is more fun than learning, but gives you insight into the motivation behind git!//
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]]
23		-
24		-* Git Cheat Sheets
25		-** [[http://cheat.errtheblog.com/s/git/]]
26		-** [[http://ktown.kde.org/%7Ezrusin/git/git-cheat-sheet-medium.png]]
27		-
28	28	* [[Linus Torvalds talks about git>>http://www.youtube.com/watch?v=4XpnKHJAok8]]
29		-Have a Good Laugh here as Linus Torvalds Evangelizes git. //NOTE: This isn't really learning, but it is way more fun and gives you insight into the motivation behind git.//
30	30
31		-= Get Started with Project Wonder =
	17	+Learn the basics here:
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 code
	19	+* [[Everyday GIT With 20 Commands Or So>>http://www.kernel.org/pub/software/scm/git/docs/everyday.html]]
	20	+* [[Free Online Pro Git book>>http://progit.org/book/]]
34	34
35		-* [[Downloading Wonder>>http://wiki.objectstyle.org/confluence/display/WONDER/Getting+the+Wonder+Source+Code]] Wiki Page
	22	+Get the Detailed Reference Materials Here:
36	36
37		-= Use Git with a Subversion Project =
	24	+* [[Git User Manual>>http://www.kernel.org/pub/software/scm/git/docs/user-manual.html]]
	25	+* [[Git Reference>>http://gitref.org/index.html]]
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
	27	+Git Cheat Sheets
40	40
41		-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]].
	29	+* [[http://cheat.errtheblog.com/s/git/]]
	30	+* [[http://ktown.kde.org/%7Ezrusin/git/git-cheat-sheet-medium.png]]
42	42
43		-= Git Goodies for WebObjects Developers =
	32	+Checkout (Clone) Wonder Source Code, Build and Install
44	44
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
	34	+* [[Instructions>>WOCOM:20110325Project Wonder is now on Github!]]
46	46
47		-=== EGit ===
	36	+= Git Goodies =
48	48
49		-EGit is a plugin for Eclipse 3.6. It's not as good as Tower or GitX, but you can use it for most tasks (add, commit, push, pull).
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.
60		-
61	61	=== Git Bash Completion ===
62	62
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:
...	...	@@ -72,65 +72,16 @@
72	72
73	73	[[Open In GitX Finder Droplet>>http://code.google.com/p/git-osx-installer/wiki/OpenInGitX]]
74	74
75		-=== Git Tower ===
	52	+== Git Tower ==
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.
	54	+For those of you who just get panic attacks at the thought of using the Terminal, there is a commercial app for that:
	55	+[[Git Tower>>http://www.git-tower.com/]]
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
	57	+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.
	58	+- Miguel Arroz
81	81
82		-= Unique Git Concepts =
	60	+= Using git locally on a Subversion Working Copy =
83	83
84		-=== Rebasing ===
	62	+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!
85	85
86		-Rebasing is unique to git. There is no counterpart in Subversion.
87		-
88		-Rebasing cuts down on the spaghetti history of merging and helps to keep history nice and linear.
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.
91		-
92		-However before using it on work that is shared with others you MUST follow the these rules, otherwise you will screw everyone else on the project.
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
101		-
102		-=== Push/Pull vs Commit/Update ===
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.
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.
107		-
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		-
110		-=== Versions? or Diffs? ===
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		-
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.
125		-
126		-= Git Annoyances =
127		-
128		-=== How to revert? ===
129		-
130		-Reverting is easy:
131		-
132		-{{code}}
133		-
134		-git reset --hard
135		-
136		-{{/code}}
	64	+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]].