Note: These are mostly notes for myself. Use with caution, as there is likely to be errors.
Creating local git repository
$ cd (project-directory) $ git init $ (create some files) $ git add . $ git commit -m 'Initial commit'
Pushing local git repository to github
(create empty github repository) $ cd <local_git_repo> $ git remote add origin email@example.com:<username>/<repo_name>.git $ git push origin master
Git on Mac OSX is also a good basic intro.
Ignoring files -> .gitignore, & git rm --cached filename when you forgot
git clone PATH DIR git pull --rebase ... work work work ... git pull --rebase ... fix conflicts ... git push
Note: using --rebase is controversial, as it discards all the change information in the local repository, lumping all your local changes as if they'd just been made to the contents of the remote repository.
When git pull says "Cannot merge":
git checkout -m -b temporary_branch git commit -a git merge origin master #resolve conflicts git commit -a
or something like that
Only run git add on new files just before committing. Otherwise, you'll commit the wrong contents of the file. .... The only way around it is to start using the index more. For example, when you have to commit only some of the changes in the working tree, or when you are adding new files to the tree, you could not use the command line tools. Instead, fire git citool which is a graphical user interface to examine changes, stage them, and finally commit them. It is powerful, easy to use, and will provide a gentle introduction to the concept of a staging area. It also will catch mistakes such as the above one.
Here is how you go solving conflicts after git pull --rebase has failed: * git diff will show you changes in the conflicted files; * since git add will stop showing a file in git diff (until you change it again), you can use it to mark a file as resolved; * at the end, your git diff should be empty, since you should have resolved the conflicts; * now, use git commit (without -a) to commit the result of the merge. Why no -a? Because the result of the merge is already in the index; and without any parameters, git commit transforms the index into a commit.
* git diff shows you the differences from index to working tree * git diff HEAD shows you the differences from trunk to working tree * git diff --cached shows you the differences from trunk to index
git status has output that is very different from svn status, but the latter can be very useful. Luckily, you can obtain subversion-like output with the invocation git diff --name-status -r; since this is quite a mouthful, you can add this to your ~/.gitconfig file: [alias] changes=diff --name-status -r You have now created a git changes command that knows about all of git diff's option. In particular the three invocations git changes, git changes HEAD, or git changes --cached, will have the same meaning as the git diff commands above. Since you are at it, add this to ~/.gitconfig too: [diff] renames = true and also tell git about your identity like this: [user] name = Paolo Bonzini email = firstname.lastname@example.org The name and e-mail address will be used to identify you in commits.
If you ever want to overwrite any of your local modifications, you can do another checkout with the -f option to bring you back to a clean slate: $ git-checkout -f