git add .
git rm --cached xxx
git add -u
Google Code开始支持Git了。那么如何把已有项目从Subversion转到Git呢？以GNU ps为例，先要在项目管理界面把VCS改成Git。然后安装git-svn，从服务器端把仓库复制下来：
git svn clone https://gnups.googlecode.com/svn/ gnups.git
git remote add origin https://firstname.lastname@example.org/p/gnups/
git push origin master
git svn clone https://gnups.googlecode.com/svn/wiki gnups.wiki
git remote add origin https://email@example.com/p/gnups.wiki/
git push origin master
git log查看commit的log，然后用git diff [commit hash]...来比较。
其实是git fetch和git 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:
remote = <nickname>
merge = <remote-ref>
url = <url>
fetch = <refspec>
See git-config(1) for details.
那要指定branch，可以用git fetch之后再git merge origin/master试试。
Set up git git config --global user.name "Your Name" git config --global user.email firstname.lastname@example.org
mkdir gnups cd gnups git init touch README git add README git commit -m 'first commit' git remote add origin email@example.com:fossilet/gnups.git git push -u origin master
cd existing_git_repo git remote add origin firstname.lastname@example.org:fossilet/gnups.git 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, commit和push。
<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> they are most certainly not the same object because the ID is different
<fossilet> Thank you, jast, mist cleared ;)
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）版本？