svn checkout or svn co. This command is used to pull an SVN tree such as svn://linuxfromscratch.org/BLFS/trunk/BOOK (the BLFS Development book) from the server.

svn add. When you are creating a new file or directory, you need to tell the SVN server about it. This command does that. Note that the file won't appear in the repository until you do an svn commit (see below).

svn propset. When you are creating a new file or directory, you generally need to tell the SVN to apply properties to the file in places that have keywords in a special format such as $Date: 2012-07-29 17:46:27 -0600 (Sun, 29 Jul 2012) $. Note that the keyword value won't appear in the file until you do an svn commit (see below).

Normally, the command you want is

svn propset svn:keywords "Date LastChangedBy" /path/to/filename.xml

svn delete. This does what it says! When you do an svn commit the file will be deleted from your local sand box immediately as well as from the repository after committing.

svn status. This command prints the status of working directories and files. If you have made local changes, it'll show your locally modified items. If you use the –verbose switch, it will show revision information on every item. With the –show-updates (-u) switch, it will show any server out-of-date information.

You should always do a manual svn status –show-updates before trying to commit changes in order to check that everything is OK and ready to go.

svn update or svn up. svn update brings changes from the repository into your working copy. If no revision given, it brings your working copy up-to-date with the HEAD revision. Otherwise, it synchronizes the working copy to the revision given by the –revision switch. As part of the synchronization, svn update also removes any stale locks (see the section called “svn cleanup”) found in the working copy.

svn commit or svn ci. This command recursively sends your changes to the SVN server. It will commit changed files, added files, and deleted files. Note that you can commit a change to an individual file or changes to files in a specific directory path by adding the name of the file/directory to the end of the command. The -m option should always be used to pass a log message to the command. Please don't use empty log messages (see later in this document the policy which governs the log messages).

svn diff. This is useful for two different purposes. First, those without write access to the BLFS SVN server can use it to generate patches to send to the BLFS-Dev mailing list. To do this, simply edit the files in your local sand box then run svn diff > FILE.patch from the root of your BLFS directory. You can then attach this file to a message to the BLFS-Dev mailing list where someone with editing rights can pick it up and apply it to the book. The second use is to find out what has changed between two revisions using: svn diff -r revision1:revision2 FILENAME. For example: svn diff -r 168:169 index.xml will output a diff showing the changes between revisions 168 and 169 of index.xml.

svn move SRC DEST or svn mv SRC DEST or svn rename SRC DEST or svn ren SRC DEST. This command moves a file from one directory to another or renames a file. The file will be moved on your local sand box immediately as well as on the repository after committing.

check file log.

svn log file

reverse file back to a version.

svn up -r r12332 file.py

$ mkdir learngit
$ cd learngit
$ pwd
/Users/michael/learngit
# 通过git init命令把这个目录变成Git可以管理的仓库：
$ git init
Initialized empty Git repository in /Users/michael/learngit/.git/

千万不要使用Windows自带的记事本编辑任何文本文件。原因是Microsoft开发记事本的团队使用了一个非常弱智的行为来保存UTF-8编码的文件，他们自作聪明地在每个文件开头添加了0xefbbbf（十六进制）的字符，你会遇到很多不可思议的问题，比如，网页第一行可能会显示一个“?”，明明正确的程序一编译就报语法错误，等等，都是由记事本的弱智行为带来的。

• HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset –hard commit_id
• 用git log可以查看提交历史，以便确定要回退到哪个版本。
• 用git reflog查看命令历史，以便确定要回到未来的哪个版本。

$ git log --pretty=oneline # 如果嫌输出信息太多，看得眼花缭乱的，可以试试加上--pretty=oneline参数：
3628164fb26d48395383f8f31179f24e0882e1e0 append GPL
ea34578d5496d7dd233c827ed32a8cd576c5ee85 add distributed
cb926e7ea50ad11b8f9e909c05226233bf755030 wrote a readme file

$ git reset --hard HEAD^
HEAD is now at ea34578 add distributed

• push the editted previous version

$ git push -f origin

$ git checkout -- readme.txt

用命令git reset HEAD file可以把暂存区的修改撤销掉（unstage），重新放回工作区：

$ git reset HEAD readme.txt
Unstaged changes after reset:
M       readme.txt

• give up unstaged or modified files.

git clean -df
git checkout -- .

用带参数的git log也可以看到分支的合并情况：

$ git log --graph --pretty=oneline --abbrev-commit
   59bc1cb conflict fixed
|\
| * 75a857c AND simple
 | 400b400 & simple
|/
 fec145a branch test
...

准备合并dev分支，请注意–no-ff参数，表示禁用Fast forward：

$ git merge --no-ff -m "merge with no-ff" dev

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

• 当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交：
• 并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？

幸好，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

• 首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：

$ git stash
Saved working directory and index state WIP on dev: 6224937 add merge
HEAD is now at 6224937 add merge
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
$ git checkout -b issue-101
Switched to a new branch 'issue-101'
$ git add readme.txt
$ git commit -m "fix bug 101"
[issue-101 cc17032] fix bug 101
 1 file changed, 1 insertion(+), 1 deletion(-)

• 修复完成后，切换到master分支，并完成合并，最后删除issue-101分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 2 commits.
$ git merge --no-ff -m "merged bug fix 101" issue-101
Merge made by the 'recursive' strategy.
 readme.txt |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git branch -d issue-101
Deleted branch issue-101 (was cc17032).

• 工作区是干净的，刚才的工作现场存到哪去了？用git stash list命令看看：

$ git checkout dev
Switched to branch 'dev'
$ git status
# On branch dev
nothing to commit (working directory clean)
$ git stash list
stash@{0}: WIP on dev: 6224937 add merge

需要恢复一下，有两个办法：

一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；

另一种方式是用git stash pop，恢复的同时把stash内容也删了：

推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送.

git remote rm xxx

opposite operation:

git remote add origin git@github.git

# 1.
git submodule add https://github.com/chaconinc/DbConnector
# 2. Cloning a Project with Submodules
git clone https://github.com/chaconinc/MainProject

• Removal

To remove a submodule you need to:

Delete the relevant line from the .gitmodules file.
Delete the relevant section from .git/config.
Run git rm --cached path_to_submodule (no trailing slash).
Commit the superproject.
Delete the now untracked submodule files.