This is an old revision of the document!


git walkthrough

  • (introduce yourself to git)
    git config --global user.name "Your Name"
    git config --global user.email "youremail@example.com"
  • start with an existing project (export one from svn if you want)
  • cd inside the project root, then create a repository:
    git init
  • (notice that a .git directory will be created at project root)
  • add all content to the index (some call it the cache, it means what is staged for the next commit)
    git add .
  • commit the added content with an initial message
    git commit -m "initial import"
  • (modify some files)
  • commit the changes
    git commit -a
    
    (the -a switch will tell git to add and commit all changed files)
  • create an experimental branch
    git branch experimental
  • show current branches; notice * is on master, which is the default
    git branch
  • switch to the experimental branch
    git checkout experimental
  • show branches again, with the * on experimental, indicating the current branch
    git branch
  • (modify some files)
  • commit all changes
    git commit -a
  • switch back to the master branch
    git checkout master
  • edit one of the files that you changed on the experimental branch, and you will see that it does not reflect those changes, because they were made while on the experimental branch and you are currently on the master branch
  • merge the active branch (master) with the experimental branch
    git merge experimental
  • this begins a merge operation with the experimental branch. if there are no conflicts, your merge is complete and is ready to commit. if there are conflicts, your files will be modified with markers designating the changes between each branch. you can quickly see these conflicts by running git diff. here is an example:
    	 
    <<<<<<< HEAD
    exit("\nLine Count Total: $lineCount\n\n");
    =======
    exit("\nLine Counts: $lineCount\n\n");
    >>>>>>> experimental
  • note that git will allow you to commit the files with conflicts in them!
  • once the conflicts are resolved, commit the merge with git commit -a
  • (modify one file)
  • view diff of changes
    git diff
  • contrary to svn, where we would run svn revert <filename>, when using git we use git checkout <filename or path> to restore the last commited state of a file, and lose any working copy changes
  • you can delete a branch with git branch -d <branch name>, and this will ensure the changes are in the current branch
  • if you want to throw away a junk branch entirely, you can use
    git branch -D <branch name>
  • to “go back in time” and review a project at the point of a previous commit, you can do so by creating a branch at that point and then checking it out
    git branch old 53067
    git checkout 53067
    
    (when finished, delete the branch)
    git branch -D old
  • you can work, including stage/unstage, commit and other items with a nice graphical representation of your changes with
    git gui
  • you can view a nice graphical representation of the repository with gitk; note that gitk has other possible switches/parameters
  • you can view the history of all branches with gitk –all
  • if you screw up and commit something that totally shouldn't be there, git allows you to fix it by running git reset <commit id>; note that it is much easier to use gitk and right click on a certain commit to reset
  • Mac frontend alternative is GitX: http://gitx.frim.nl/index.html
  • docs/git/git_walkthrough.1258348272.txt.gz
  • Last modified: 2009/11/15 22:11
  • by billh