Git: CVS equivalent operations: Difference between revisions

From genomewiki
Jump to navigationJump to search
m (correction to step 12)
No edit summary
Line 1: Line 1:
1. check out a source tree: cvs co kent
==Check out a source tree: cvs co kent==


cd $HOME
cd $HOME
Line 7: Line 7:




2. update a source tree: cvs up
==Update a source tree: cvs up==


git pull  # often this is all you need to do on your master branch
git pull  # often this is all you need to do on your master branch
Line 19: Line 19:




3. check in a changed file: cvs commit
==Check in a changed file: cvs commit==


git add changed-file
git add changed-file
Line 53: Line 53:
pushing them into shared history.
pushing them into shared history.


4. review the history of a file: cvs log
==Review the history of a file: cvs log==


git log
git log
Line 81: Line 81:




5. show who changed what: cvs ann
==Show who changed what: cvs ann==


git blame somefile
git blame somefile
Line 88: Line 88:




6. rename files (no cvs equivalent)
==Rename files (no cvs equivalent)==


git mv path newpath
git mv path newpath
Line 101: Line 101:




7. local branches and tags and merging and change branches
==Local branches and tags and merging and change branches==


more on this in future
more on this in future




8. remotes and remote branches and tags and tracking branches:
==Remotes and remote branches and tags and tracking branches==
configuration and use with pushing and pulling.


more on this in future
configuration and use with pushing and pulling.  More on this in future.




9. Oops, I'm stuck with half-baked changes.
==Oops, I'm stuck with half-baked changes==
I want to just utterly lose all the uncommitted changes
I want to just utterly lose all the uncommitted changes
in my sandbox and return to my former self.
in my sandbox and return to my former self.
Line 121: Line 120:




10. Oops, I just want to totally throw away all staged changes,
==Oops, I just want to totally throw away all staged changes==
but keep my working dir as it is.
but keep my working dir as it is.


Line 127: Line 126:




11. How to unstage just one file
==How to unstage just one file==


git rm --cached somefile
git rm --cached somefile
Line 135: Line 134:




12. How to reset just one file
==How to reset just one file==


git checkout HEAD somefile
git checkout HEAD somefile
Line 155: Line 154:




13. Diffing.
==Diffing==


git diff has many flexible options.
git diff has many flexible options.

Revision as of 17:55, 14 June 2010

Check out a source tree: cvs co kent

cd $HOME mv kent kent-cvs-old # only if you have an existing cvs kent sandbox git clone yourlogin@hgwdev.cse.ucsc.edu:/data/git/kent.git/ kent cd kent


Update a source tree: cvs up

git pull # often this is all you need to do on your master branch

or

git fetch

fetch allows getting updates and comparing without merging. pull = fetch + merge.


Check in a changed file: cvs commit

git add changed-file git status git commit -m 'I fixed something important'

Note that git commit -a is very dangerous since it will grab any change anywhere in your entire directory tree and commit it. Do not use.

Instead, use this to add only tracked files at or below the current directory. This makes it behave like cvs commit which is relative to the current dir:

git add . -u # DO NOT FORGET THE -u or you will be sorry.

At least with this method you can still use git status to check what you have.

git push

 (may need to do another git pull if someone else has pushed more 

changes recently).

This is a fool-hardy alias:

 alias gcpp "git add \!*; git commit; git pull; git push"

!!! Committing and pushing are times of reflection. !!! This is your chance to catch problems before they escalate.

It is much better to group related changes together into a single commit with a well-written commit message. And test the changes before pushing them into shared history.

Review the history of a file: cvs log

git log git log somefile

It lists the changes from newest to oldest.

There are tons of options with this command. It pipes it into more by default. You can pipe it into tig, or you can use -N where N is the number of lines to output before stopping.

There are also ways to filter the output by user. And you can specify a directory and get it and all subdirectories. And you could specify the time-frame. So you could say, show me everything that Hiram changed under kent/src/hg/lib in the last 3 weeks.

cd ~/kent; git log --stat --author=hiram --since="3 weeks ago" src/hg/lib

You can also specify changes in terms of tags and branch-tags, using tree-ish. (See the genomewiki, search for git)


Show who changed what: cvs ann

git blame somefile

git blame is reasonably fast and very powerful.


Rename files (no cvs equivalent)

git mv path newpath git commit -m 'renamed path to newpath for some good reason'

You can add -C to git blame or git log to track renames.

There is a lot of new-found freedom to fix poorly chosen names or do other larger re-arrangements of the directories and files now, but before doing anything major you should check with others.


Local branches and tags and merging and change branches

more on this in future


Remotes and remote branches and tags and tracking branches

configuration and use with pushing and pulling. More on this in future.


Oops, I'm stuck with half-baked changes

I want to just utterly lose all the uncommitted changes in my sandbox and return to my former self.

git reset --hard

This uses the HEAD by default.


Oops, I just want to totally throw away all staged changes

but keep my working dir as it is.

git reset


How to unstage just one file

git rm --cached somefile

This removes it from your stage but not from your working dir.


How to reset just one file

git checkout HEAD somefile

This will nuke any changes regarding somefile from the stage and also reset it in the working directory so it matches your HEAD commit.

After a plain git reset to unstage everything, you can also recursively reset any edited files at your level and below with this:

git checkout HEAD


Even when you can use git reset --hard without paths, be careful because it resets ALL modified tracked files at every subdirectory level, i.e. the entire directory tree. So if you do a trick like modifying ~/kent/src/inc/common.mk to turn on extra debugging, and you don't check it in because you don't want to make it the default for everybody, then you would lose that tweak after a reset --hard.

git reset --hard somefile

This will nuke any changes regarding somefile from the stage and also reset it in the working directory so it matches your HEAD commit.


Diffing

git diff has many flexible options. You can use branch-tags, tags, tree-ish. You can specify entire commit states, you can limit it to a specific file or directory.

git diff # diffs working dir to stage git diff --cached # diffs stage to HEAD commit. git diff A B # A and B can be any branches, tags, commit-ids, tree-ish.