git add .

git rm --cached xxx

git add -u


git push

把Google Code项目从Subversion转到Git

Google Code开始支持Git了。那么如何把已有项目从Subversion转到Git呢?以GNU ps为例,先要在项目管理界面把VCS改成Git。然后安装git-svn,从服务器端把仓库复制下来:

git svn clone gnups.git

增加Google Code的remote并push上去:

cd gnups.git

git remote add origin

git push origin master


git svn clone


git remote add origin

git push origin master


git log查看commit的log,然后用git diff [commit hash]...来比较。


git pull

其实是git fetchgit merge的合并。


You asked me to pull without telling me which branch you

want to merge with, and 'branch.master.merge' in

your configuration file does not tell me, either. Please

specify which branch you want to use on the command line and

try again (e.g. 'git pull <repository> <refspec>').

See git-pull(1) for details.

If you often merge with the same branch, you may want to

use something like the following in your configuration file:

[branch "master"]

remote = <nickname>

merge = <remote-ref>

[remote "<nickname>"]

url = <url>

fetch = <refspec>

See git-config(1) for details.

那要指定branch,可以用git fetch之后再git merge origin/master试试。



Global setup:

Set up git git config --global "Your Name" git config --global your@email.address

Next steps:

mkdir gnups cd gnups git init touch README git add README git commit -m 'first commit' git remote add origin git push -u origin master

Existing Git Repo?

cd existing_git_repo git remote add origin git push -u origin master

Importing a Subversion Repo?

Check out the guide for step by step instructions.


git push origin :branch



$ git diff


diff --git a/doc/index.html b/doc/index.html

old mode 100644

new mode 100755


如果在Windows下push,那么在Linux下fetch,就会发现文件权限都变化了。所以最佳实践就是,在Windows下可以修改,但是不要add(stage), commit, 更不要push。这样让Dropbox把吧Windows下的改动同步到Linux下,然后在Linux下add, commitpush


这是对Pro Git一书中关于rebase的疑问的解答。


<fossilet> I have a question about rebasing in the book Pro Git.


<jast> all right, last answer for today ;) what's the question?

<fossilet> In the last but two paragraph, it says both the C4 and C4’ commits, which have different SHA-1 hashes but introduce the same work

<fossilet> If the author meant C6 and C4´

<fossilet> not C4 and C4´

<jast> C6 is the merge commit that got created in the original history... where the other guy made C4 and C5 independently and the merge C6 referenced both of them

<jast> later, the same guy decided to recreate the history so that, instead, the two sets of changes would be in the history without any merge, perhaps because he decided that that would look nicer

<jast> the result of that is that C5 remains completely unchanged, but rebase had to recreate C4 (by replaying the changes in it on top of C5)

<jast> since C4 now has C5 as its parent, rather than C1, the commit object must change, even if the changes are the same

<jast> remember that a commit is a reference to a parent commit plus a commit/authorship timestamp/name plus a snapshot of all the files

<jast> so, by necessity of how git's object IDs work, C4 must be recreated. the result is called C4' to make clear that it's the same logical changeset (with the same commit message and authorship date) but a different commit object and a probably a different set of file snapshots

<jast> the *contents* (snapshot-wise) of C4' and C6 are identical as you said

<jast> but C4 and C4' are the ones that have the same commit message and authorship timestamp

<jast> and the same set of changes, if you generate a diff relative to their respective parents

<jast> (git generates diffs on the fly; try "git show <commit ID>" to see)

<fossilet> you mean diff c4 c1 and diff c4' c5 is the same?

<jast> actually "diff c1 c4" and "diff c5 c4'", but yeah :)

<jast> they aren't *always*

<jast> because there might be conflicts involved

<fossilet> o yeah, diff c1 c4.

<jast> but if the changes in c5 and c4 are reasonably easily separable, it's very likely that the diffs would be identical

<jast> and if they aren't, chances are that the diffs would represent the same "work" done by a user, if that makes sense

<fossilet> The author says C4 and C4' ´introduces the same work´. I understood it as ´they are essentially the same object´. In fact, he means they introduces the same patch. right?

<jast> yes

<jast> exactly

<jast> they are most certainly not the same object because the ID is different

<fossilet> Thank you, jast, mist cleared ;)

<jast> great


git ci --amend --date=


git remote rm origin

git remote add origin git@sys-git01:ops.git

git branch --set-upstream master origin/master


在合并出现冲突的时候,貌似用git commit -a可以直接解决,采用了对方的(theirs)版本?