This tutorial walks you through how to set up Git on various platforms so you can be reading and writing YUI code in no time. Once your environment is set up, be sure to read Tutorial: Contribute Code to YUI to learn how to clone YUI source code to your local development environment, and submit a CLA to contribute to YUI.
git --versiongit version 1.7.4.4git --versiongit version 1.7.6.1/usr/local/bin to your $PATH
vim ~/.bashrcexport PATH=$PATH:/usr/local/bingit --versiongit version 1.7.6.1If you have Mac Ports installed, do the following:
git-core packagesudo port install git-coregit --versiongit version 1.6.0Git is in the unstable tree in Fink, and I couldn't get it to install. You should pick another method
For Fedora 7 and later.
git-core packagesudo yum install git-coregit --versiongit version 1.7.6.1For Fedora 6 and older, git-core is part of Fedora Extras (http://fedoraproject.org/wiki/Extras).
For users of Red Hat Enterprise Linux and its clones (such as CentOS and Scientific Linux), users will have to build git by hand. Source available here: http://git.or.cz/
git-core packagesudo apt-get install git-coregit --versiongit version 1.7.0.4git --versiongit version 1.7.6.1git config --global core.autocrlf trueSetting user.name and user.email are the minimum configuration options that need to be set so your name and email will show up in your commit messages.
git config --global user.name "Dav Glass" git config --global user.email dav.glass@yahoo.com
Use your name and email of course; there are many other configuration options you can set. These configs should be written to this file (same for Windows, when working in Git Bash): ~/.gitconfig. My current ~/.gitconfig looks like this:
[merge]
tool = opendiff
[core]
excludesfile = /Users/davglass/.gitignore
[alias]
st = status
ci = commit
co = checkout
br = branch
[color]
ui = auto
status = auto
branch = auto
diff = never
[user]
name = Dav Glass
email = dav.glass@yahoo.com
And my ~/.gitignore file
.DS_Store ._* .svn .hg .*.swp
GitHub has several helpful tutorials on setting up SSH for use with git. Click the links below for more information:
Git is a little different than CVS, every person has a copy of the repository on their local machine. So you can commit to it as much as you like. No build will be triggered.
Most of the built in aliases for git will help because they are similar to CVS.
git pull This will pull a fresh copy of the repository.git commit This will commit changes to your local repository (not the server).git add This is a little different, you use git add to add a file to the commit index. It's not just for new files.git push This is what moves your local repository to the server you checked out from.git status Shows you the status of your repository.git diff Gives you a diff of the file.git rm This lets you remove files and directories.git add This example shows using git add to add each file to the commit index before committing.
$ cd /my/working/directory $ vim README # Edit the file $ git add README $ git commit -m "Updated the README file" # Then you will see something like this: Created commit 794a86f: Updated the README file 1 files changed, 1 insertions(+), 0 deletions(-)
git commit all This example shows using git -a to commit all changed files
$ cd util/dd/src/js $ vim drag.js # Edit the file $ git commit -a # At this point git will open your default editor and ask for a commit message # Then you will see something like this: Created commit ed16907: fixed #2345: patched file to fix something 1 files changed, 2 insertions(+), 0 deletions(-)
If you encounter a (non-fast forward) error on push:
To git@github.com:username/yui3.git ! [rejected] master -> master (non-fast foward) error: failed to push some refs to 'git@github.com:username/yui3.git'
Generally that means that your tree is now out of sync with the main repository. You need to cd projectroot and do a git pull. This should bring your tree into sync with the repository and then it will allow you to git push.
To revert modified files in your working tree (the equivalent of cvs co -C ):
$ git checkout -- path/to/file
A git status will give you a list of files in your working tree which are modified.
NOTE: This method does not require you to switch to the local branch in order to push it to the remove server.
Create the local branch (from the branch you're currently in (generally "master")):
$ git branch [branch name]
Push it to the origin server:
$ git push origin [branch name]
Users will then be able to checkout the remote branch by using:
$ git checkout -b [local branch name] origin/[branch name]
Which will create a new local branch, which tracks against the remote branch, and also change the working tree to the local branch (so any changes you make, you're making to the branch).
Users can then switch between branches as required using:
$ git checkout [branch name] # Switching back to "master", which is a tracking branch itself, works the same way... git checkout "master"
Based on the yui3 project and pulling the tag v3.4.0
From your cloned repo:
# Get up to date $ git pull origin master # Reset head to the tag $ git checkout v3.4.0 # Should print something like this: Note: checking out 'v3.4.0'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b new_branch_name HEAD is now at d617041... Bump package.json version to 3.4.0. # Now create a local branch for easy task switching: $ git checkout -b branch-3.4.0 # You can check this by calling: $ git log -n1 # That commit should be the one listed above: commit d6170413cd7404cb54e207cd9341dbc0ff16e358 Date: Thu Jul 28 11:25:42 2011 -0700 Bump package.json version to 3.4.0. # Now you can switch between master and this tag like this: $ git checkout master # Back to the master branch $ git checkout branch-3.4.0 # Back to this tag
rebase and merge to Keep Your Development Branch in SyncUse rebase to apply commits downstream onto your development branch. Use merge to apply commits from your dev branch back upstream: http://sites.google.com/a/insoshi.com/insoshi-guides/Git-Guides/merge-vs-rebase
$ git checkout mybranch // checkout my dev branch $ vi workingfiles.js // make some changes $ git commit -a -m "edits" // commit my changes $ git checkout master // checkout my upstream branch $ git pull // pull from origin $ git rebase master mybranch // apply commits from origin to dev branch # at this point I'm in mybranch so I can keep working... #... or I can push my commits to origin/master $ git checkout master // back to the upstream branch $ git merge mybranch // integrate my changes $ git push // push my changes