【Git】git的高级用法
来源:互联网 发布:java架构师视频百度云 编辑:程序博客网 时间:2024/06/06 02:47
- 合并多个提交
假设要合并最后的2个提交,可以按如下命令进行:
1. git rebase –i HEAD~2
运行完该命令,会出现如下所示内容:
2. 将第二个pick修改为squash或者s,然后输入":wq”退出。
3. 这时git会自动第二个提交合并到第一个中去。并提示输入新的message(就是我们常说的comments),如下:
4. 编辑输入新的message,然后输入":wq"退出
5. 此时本地的(HEAD中)最后两次提交已经被合并为一个。git log可以查看。
6. 如果需要提交到远端,运行git push --force origin master即可。
- 修改提交日志
git commit --amend
然后会打开一个编辑器,你可以修改以前的提交日志信息了。
修改作者:git commit --amend --reset-author
但这个只以修改最后一个提交的信息。如何修以前的信息?
git rebase -i HEAD~3
会打开一个编辑器,把将要修改日志前面改成 edit,然后退出。
再运行:
git commit --amend
编辑完后,再恢复:
git commit --continue
- git放弃本地更改然后更新
当使用
git pull
命令的时候如果提示有本地文件修改了,无法合并的时候,我们可以放弃本地修改,然后再更新;如果不想放弃本地修改,可以先提交,然后再更新:
提交
git commit
如果要放弃本地修改后更新:
git reset --hard
git pull - 制作补丁
- git diff
我们可以首先用git diff制作一个patch。本文示例的工作目录里最初有一个文件a,内容是“This is the file a.”,放置在master分支中。为了修改代码,我们一般的做法是建立一个新分支:
sweetdum@sweetdum-ASUS:~/GitEx$ git branch Fix
sweetdum@sweetdum-ASUS:~/GitEx$ git checkout Fix
Switched to branch 'Fix'接下来我们在a文件里面追加一行,然后执行git diff。
sweetdum@sweetdum-ASUS:~/GitEx$ echo 'Fix!!!'>>a
sweetdum@sweetdum-ASUS:~/GitEx$ git diff
diff --git a/a b/a
index 4add65f..0d295ac 100644
--- a/a
+++ b/a
@@ -1 +1,2 @@
This is the file a.
+Fix!!!我们看到了Git diff的输出,这是一个非常典型的Patch式diff。这样我们可以直接把这个输出变为一个Patch:
sweetdum@sweetdum-ASUS:~/GitEx$ git commit -a -m "Fix"
[Fix b88c46b] Fix
1 files changed, 1 insertions(+), 0 deletions(-)
sweetdum@sweetdum-ASUS:~/GitEx$ git diff master > patch
sweetdum@sweetdum-ASUS:~/GitEx$ git checkout master
Switched to branch 'master'当然,用这种方法,你不用提交,也可以直接导出patch
git diff > patch
我们现在有一个patch文件,并且签出了master,接下来我们可以使用git apply来应用这个patch。当然了,实际应用中,我们不会这样在一个分支建patch,到另一个分支去应用,因为只有merge一下就好了。我们现 在权当没有这个Fix分支。一般情况下,为了保护master,我们会建立一个专门处理新交来的patch的分支:
sweetdum@sweetdum-ASUS:~/GitEx$ git branch PATCH
sweetdum@sweetdum-ASUS:~/GitEx$ git checkout PATCH
Switched to branch 'PATCH'
sweetdum@sweetdum-ASUS:~/GitEx$ git apply patch
sweetdum@sweetdum-ASUS:~/GitEx$ git commit -a -m "Patch Apply"
[PATCH 9740af8] Patch Apply
1 files changed, 1 insertions(+), 0 deletions(-)看,现在我们在PATCH分支中应用了这个补丁,我们可以把PATCH分支和Fix比对一下,结果肯定是什么也没有,说明PATCH分支和Fix分支完全一样。patch应用成功。即使有多个文件git diff 也能生成一个patch。
- git format-patch
- 命令中”Changes to be committed“中所列的内容是在Index中的内容,commit之后进入Git Directory。
- 命令中“Changed but not updated”中所列的内容是在Working Directory中的内容,add之后将进入Index。
- 命令中“Untracked files”中所列的内容是尚未被Git跟踪的内容,add之后进入Index。
- git diff [<path>...]:这个命令最常用,在每次add进入index前会运行这个命令,查看即将add进入index时所做的内容修改,即working directory和index的差异。
- git diff --cached [<path>...]:这个命令初学者不太常用,却非常有用,它表示查看已经add进入index但是尚未commit的内容同最后一次commit时的内容的差异。即index和git directory的差异。
- git diff --cached [<commit>] [<path>...]:这个命令初学者用的更少,也非常有用,它表示查看已经add进入index但是尚未commit的内容同指定的<commit>之间的差异,和上面一条很相似,差别仅仅<commit>,即index和git directory中指定版本的差异。
- git diff <commit> [<path>...]:这个命令用来查看工作目录和指定<commit>的commit之间的差别,如果要和Git directory中最新版比较差别,则<commit>=HEAD。如果要和某一个branch比较差别,<commit>=分支名字
- git diff <commit> <commit> [<path>...]:这个命令用来比较git directory中任意两个<commit>之间的差别,如果想比较任意一个<commit>和最新版的差别,把其中一个<commit>换成HEAD即可。
- 在一般使用中,如果发现错误的将不想staging的文件add进入index之后,想回退取消,则可以使用命令:git reset HEAD <file>...,同时git add完毕之后,git也会做相应的提示,比如:引用# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: Test.scala - git reset [--hard|soft|mixed|merge|keep] [<commit>或HEAD]:将当前的分支重设(reset)到指定的<commit>或者HEAD(默认,如果不显示指定commit,默认是HEAD,即最新的一次提交),并且根据[mode]有可能更新index和working directory。mode的取值可以是hard、soft、mixed、merged、keep。下面来详细说明每种模式的意义和效果。 A).--hard:重设(reset)index和working directory,自从<commit>以来在working directory中的任何改变都被丢弃,并把HEAD指向<commit>。
B). --soft:index和working directory中的内容不作任何改变,仅仅把HEAD指向<commit>。这个模式的效果是,执行完毕后,自从<commit>以来的所有改变都会显示在git status的"Changes to be committed"中。
C). --mixed:仅reset index,但是不reset working directory。这个模式是默认模式,即当不显示告知git reset模式时,会使用mixed模式。这个模式的效果是,working directory中文件的修改都会被保留,不会丢弃,但是也不会被标记成"Changes to be committed",但是会打出什么还未被更新的报告。报告如下:引用Unstaged changes after reset:
M Test.Scala
M test.txt
D). --merge和--keep用的不多,在下面的例子中说明。 $ git clone <url>
#克隆远程版本库$ git init
#初始化本地版本库$ git status
#查看状态$ git diff
#查看变更内容$ git add .
#跟踪所有改动过的文件$ git add <file>
#跟踪指定的文件$ git mv <old> <new>
#文件改名$ git rm <file>
#删除文件$ git rm --cached <file>
#停止跟踪文件但不删除$ git commit -m “commit message”
#提交所有更新过的文件$ git commit --amend
#修改最后一次提交$ git log
#查看提交历史$ git log -p <file>
#查看指定文件的提交历史$ git blame <file>
#以列表方式查看指定文件的提交历史$ git reset --hard HEAD
#撤消工作目录中所有未提交文件的修改内容$ git checkout HEAD <file>
#撤消指定的未提交文件的修改内容$ git revert <commit>
#撤消指定的提交$ git branch
#显示所有本地分支$ git checkout <branch/tag>
#切换到指定分支或标签$ git branch <new-branch>
#创建新分支$ git branch -d <branch>
#删除本地分支$ git tag
#列出所有本地标签$ git tag <tagname>
#基于最新提交创建标签$ git tag -d <tagname>
#删除标签$ git merge <branch>
#合并指定分支到当前分支- $ git diff #查看冲突
$ git rebase <branch>
#衍合指定分支到当前分支$ git remote -v
#查看远程版本库信息$ git remote show <remote>
#查看指定远程版本库信息$ git remote add <remote> <url>
#添加远程版本库$ git fetch <remote>
#从远程库获取代码$ git pull <remote> <branch>
#下载代码及快速合并$ git push <remote> <branch>
#上传代码及快速合并$ git push <remote> :<branch/tag-name>
#删除远程分支或标签- $ git push <remote> --delete <branchName> #删除远程分支或标签
$ git push --tags
#上传所有标签- $ git push <remote> --delete tag <tagname> #删除远程标签
制作补丁有两种方式:
我们同样用上面那个例子的工作目录,这次,我们在Fix分支中的a添加了新行之后,用git format-patch生成一个patch。
sweetdum@sweetdum-ASUS:~/GitEx$ git checkout Fix
Switched to branch 'Fix'
sweetdum@sweetdum-ASUS:~/GitEx$ echo 'Fix!!!'>>a
sweetdum@sweetdum-ASUS:~/GitEx$ git commit -a -m "Fix1"
[Fix 6991743] Fix1
1 files changed, 1 insertions(+), 0 deletions(-)
sweetdum@sweetdum-ASUS:~/GitEx$ git format-patch -M master
0001-Fix1.patch
git format-patch的-M选项表示这个patch要和那个分支比对。现在它生成了一个patch文件,我们看看那是什么:
sweetdum@sweetdum-ASUS:~/GitEx$ cat 0001-Fix1.patch
From 6991743354857c9a6909a253e859e886165b0d90 Mon Sep 17 00:00:00 2001
From: Sweetdumplings <linmx0130@163.com>
Date: Mon, 29 Aug 2011 14:06:12 +0800
Subject: [PATCH] Fix1
---
a | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/a b/a
index 4add65f..0d295ac 100644
--- a/a
+++ b/a
@@ -1 +1,2 @@
This is the file a.
+Fix!!!
--
1.7.4.1
看,这次多了好多东西,不仅有diff的信息,还有提交者,时间等等,仔细一看你会发现,这是个E-mail的文件,你可以直接用git send-email发送它!
git send-email用法:http://www.kernel.org/pub/software/scm/git/docs/git-send-email.html
中文:http://www.cnblogs.com/wwang/archive/2011/04/01/1951742.html
这种patch,我们要用git am来应用。
sweetdum@sweetdum-ASUS:~/GitEx$ git checkout master
Switched to branch 'master'
sweetdum@sweetdum-ASUS:~/GitEx$ git branch PATCH
sweetdum@sweetdum-ASUS:~/GitEx$ git checkout PATCH
sweetdum@sweetdum-ASUS:~/GitEx$ git am 0001-Fix1.patch
Applying: Fix1
sweetdum@sweetdum-ASUS:~/GitEx$ git commit -a -m "PATCH apply"
在提交了补丁之后,我们可以再看看目前文件a的情况:
sweetdum@sweetdum-ASUS:~/GitEx$ cat a
This is the file a.
Fix!!!
果然,多了一个Fix!!!
不过要注意的是,如果master与Fix分支中间有多次提交,它会针对每次提交生成一个patch。
当前分支所有超前master的提交:
git format-patch -M master
某次提交以后的所有patch:
git format-patch 4e16 --4e16指的是commit名
从根到指定提交的所有patch:
git format-patch --root 4e16
某两次提交之间的所有patch:
git format-patch 365a..4e16 --365a和4e16分别对应两次提交的名称
某次提交(含)之前的几次提交:
git format-patch –n 07fe --n指patch数,07fe对应提交的名称
故,单次提交即为:
git format-patch -1 07fe
git format-patch生成的补丁文件默认从1开始顺序编号,并使用对应提交信息中的第一行作为文件名。如果使用了-- numbered-files选项,则文件名只有编号,不包含提交信息;如果指定了--stdout选项,可指定输出位置,如当所有patch输出到一个文件;可指定-o <dir>指定patch的存放目录;
2应用patch:
先检查patch文件:git apply --stat newpatch.patch
检查能否应用成功:git apply --check newpatch.patch
打补丁:git am --signoff < newpatch.patch
(使用-s或--signoff选项,可以commit信息中加入Signed-off-by信息)
如果应用patch出现问题:参考git am PATCH 失败的处理方法http://blog.csdn.net/sunnylgz/article/details/7660638
参考资料:
git-format-patch(1) - Linux man page http://linux.die.net/man/1/git-format-patch
How to create and apply a patch with Git http://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git
在日常使用GIT过程中,经常会出错,比如无意间丢失了未提交的数据,回退版本时丢失了工作目录,等等。经过思考发现,所有这些错误都是因为对GIT中一些基本的概念模糊而导致,因为对一些基本概念不清晰,导致对GIT每一条命令将会产生的结果不符合预期。下面我就梳理以下我经常碰到的问题相关的基本概念。
1. Working Directory(工作目录)
Git的工作目录是保存当前正在工作的文件所在的目录,和working tree是相同的意思。在这个目录中的文件可能会在切换branch时被GIT删除或者替换。这个目录是个临时目录,临时存储你从GIT库中取出的文件,这些文件一直会被保存,直到下次提交。
2. GIT Directory(GIT库目录)
项目的所有历史提交都被保存在了GIT库目录中,只要你不作回滚操作,它应该不会丢失。
3. GIT Index(Git索引)
Git index 可以看作是工作目录和Git库目录之间的暂存区,和staging area是相同的意思。可以使用Git index构建一组你准备一起提交的改变。Git Index和Git Staging area是同一个意思,都是指已经被add的但尚未commit的那些内容所在的区域。最简单的查看目前什么内容在index中的方法是使用git status命令。
哪些操作能够改变git index中的内容?
A). git add <path>...会将working directory中的内容添加进入git index。
B). git reset HEAD <path>...会将git index中path内容删除,重新放回working directory中。
4. git diff
git diff可以比较working tree同index之间,index和git directory之间,working tree和git directory之间,git directory中不同commit之间的差异,
5. 如何merge不同的分支
在git中,在执行任何命令时你一定要清楚,你在哪?对谁执行这个命令?
比如在创建新的branch时,执行命令:git branch 1.0-beta,这个命令是说在当前branch上,以当前branch为基准,创建一个新的branch,名叫1.0-beta。
在比如,当merge不同的branch时:
git merge master
首先切换到1.0-beta branch上,然后将主干(master)上的代码合并到当前1.0-beta分支上。
merge完后,可能会由冲突,按照git的提示,编辑标识为"CONFLICT (content)"的文件,解决冲突后再次将冲突的文件add,commit后,merge完毕。
你可以使用 git diff 查看哪些文件产生了冲突。然后编辑冲突文件。
6. git reset
下面列出一些git reset的典型的应用场景:
A) 回滚add操纵
$ git add frotz.c filfre.c
$ mailx (2)
$ git reset (3)
$ git pull git://info.example.com/ nitfol (4)
(1) 编辑文件frotz.c, filfre.c,做了些更改,并把更改添加到了index
(2) 查看邮件,发现某人要你pull,有一些改变需要你merge下来
(3) 然而,你已经把index搞乱了,因为index同HEAD commit不匹配了,但是你知道,即将pull的东西不会影响已经修改的frotz.c和filfre.c,因此你可以revert这两个文件的改变。revert后,那些改变应该依旧在working directory中,因此执行git reset。
(4) 然后,执行了pull之后,自动merge,frotz.c和filfre.c这些改变依然在working directory中。
B) 回滚最近一次commit
$ git reset --soft HEAD^ (1)
$ edit (2)
$ git commit -a -c ORIG_HEAD (3)
(1) 当提交了之后,你又发现代码没有提交完整,或者你想重新编辑一下提交的comment,执行git reset --soft HEAD^,让working tree还跟reset之前一样,不作任何改变。
HEAD^指向HEAD之前最近的一次commit。
(2) 对working tree下的文件做修改
(3) 然后使用reset之前那次commit的注释、作者、日期等信息重新提交。注意,当执行git reset命令时,git会把老的HEAD拷贝到文件.git/ORIG_HEAD中,在命令中可以使用ORIG_HEAD引用这个commit。commit 命令中-a 参数的意思是告诉git,自动把所有修改的和删除的文件都放进stage area,未被git跟踪的新建的文件不受影响。commit命令中-c <commit> 或者-C <commit>意思是拿已经提交的commit对象中的信息(作者,提交者,注释,时间戳等)提交,那么这条commit命令的意思就非常清晰了,把所有更改的文件加入stage area,并使用上次的提交信息重新提交。
C) 回滚最近几次commit,并把这几次commit放到叫做topic的branch上去。
$ git reset --hard HEAD~3 (2)
$ git checkout topic/wip (3)
(1) 你已经提交了一些commit,但是此时发现这些commit还不够成熟,不能进入master分支,但你希望在新的branch上润色这些commit改动。因此执行了git branch命令在当前的HEAD上建立了新的叫做 topic/wip的分支。
(2) 然后回滚master branch上的最近三次提交。HEAD~3指向当前HEAD-3个commit的commit,git reset --hard HEAD~3即删除最近的三个commit(删除HEAD, HEAD^, HEAD~2),将HEAD指向HEAD~3。
D) 永久删除最后几个commit
$ git reset --hard HEAD~3 (1)
(1) 最后三个commit(即HEAD, HEAD^和HEAD~2)提交有问题,你想永久删除这三个commit。
E) 回滚merge和pull操作
Auto-merging nitfol
CONFLICT (content): Merge conflict in nitfol
Automatic merge failed; fix conflicts and then commit the result.
$ git reset --hard (2)
$ git pull . topic/branch (3)
Updating from 41223... to 13134...
Fast-forward
$ git reset --hard ORIG_HEAD (4)
(1) 从origin拉下来一些更新,但是产生了很多冲突,你暂时没有这么多时间去解决这些冲突,因此你决定稍候有空的时候再重新pull。
(2) 由于pull操作产生了冲突,因此所有pull下来的改变尚未提交,仍然再stage area中,这种情况下git reset --hard 与git reset --hard HEAD意思相同,即都是清除index和working tree中被搞乱的东西。
(3) 将topic/branch合并到当前的branch,这次没有产生冲突,并且合并后的更改自动提交。
(4) 但是此时你又发现将topic/branch合并过来为时尚早,因此决定退滚merge,执行git reset --hard ORIG_HEAD回滚刚才的pull/merge操作。说明:前面讲过,执行git reset时,git会把reset之前的HEAD放入.git/ORIG_HEAD文件中,命令行中使用ORIG_HEAD引用这个commit。同样的,执行pull和merge操作时,git都会把执行操作前的HEAD放入ORIG_HEAD中,以防回滚操作。
F) 在被污染的working tree中回滚merge或者pull
Auto-merging nitfol
Merge made by recursive.
nitfol | 20 +++++----
...
$ git reset --merge ORIG_HEAD (2)
(1) 即便你已经在本地更改了一些你的working tree,你也可安全的git pull,前提是你知道将要pull的内容不会覆盖你的working tree中的内容。
(2) git pull完后,你发现这次pull下来的修改不满意,想要回滚到pull之前的状态,从前面的介绍知道,我们可以执行git reset --hard ORIG_HEAD,但是这个命令有个副作用就是清空你的working tree,即丢弃你的本地未add的那些改变。为了避免丢弃working tree中的内容,可以使用git reset --merge ORIG_HEAD,注意其中的--hard 换成了 --merge,这样就可以避免在回滚时清除working tree。
G) 被中断的工作流程
在实际开发中经常出现这样的情形:你正在开发一个大的feature,此时来了一个紧急的bug需要修复,但是目前在working tree中的内容还没有成型,还不足以commit,但是你又必须切换的另外的branch去fix bug。请看下面的例子
$ work work work ;# got interrupted
$ git commit -a -m "snapshot WIP" (1)
$ git checkout master
$ fix fix fix
$ git commit ;# commit with real log
$ git checkout feature
$ git reset --soft HEAD^ ;# go back to WIP state (2)
$ git reset (3)
(1) 这次属于临时提交,因此随便添加一个临时注释即可。
(2) 这次reset删除了WIP commit,并且把working tree设置成提交WIP快照之前的状态。
(3) 此时,在index中依然遗留着“snapshot WIP”提交时所做的uncommit changes,git reset将会清理index成为尚未提交"snapshot WIP"时的状态便于接下来继续工作。
(H) Reset单独的一个文件
假设你已经添加了一个文件进入index,但是而后又不打算把这个文件提交,此时可以使用git reset把这个文件从index中去除。
$ git commit -m "Commit files in index" (2)
$ git add frotz.c (3)
(1) 把文件frotz.c从index中去除,
(2) 把index中的文件提交
(3) 再次把frotz.c加入index
(I) 保留working tree并丢弃一些之前的commit
假设你正在编辑一些文件,并且已经提交,接着继续工作,但是现在你发现当前在working tree中的内容应该属于另一个branch,与这之前的commit没有什么关系。此时,你可以开启一个新的branch,并且保留着working tree中的内容。
$ git checkout -b branch1
$ edit
$ git commit ... (1)
$ edit
$ git checkout -b branch2 (2)
$ git reset --keep start (3)
(1) 这次是把在branch1中的改变提交了。
(2) 此时发现,之前的提交不属于这个branch,此时你新建了branch2,并切换到了branch2上。
(3) 此时你可以用reset --keep把在start之后的commit清除掉,但是保持working tree不变。
7. git revert
git revert用于回滚一些commit。对于一个或者多个已经存在的commit,去除由这些commit引入的改变,并且用一个新的commit来记录这个回滚操作。这个命令要求working tree必须是干净的。
git revert和git reset的功能很相似,但是有区别,具体如下。
git revert用于用一个commit来记录并回滚早前的commit,经常是一些错误的提交。如果你想干脆扔掉working tree中的东西,可以使用git reset --hard
比如
A) git revert HEAD~3:丢弃最近的三个commit,把状态恢复到最近的第四个commit,并且提交一个新的commit来记录这次改变。
B) git revert -n master~5..master~2:丢弃从最近的第五个commit(包含)到第二个(不包含),但是不自动生成commit,这个revert仅仅修改working tree和index。
8. git revert 和 git reset的区别
1. git revert是用一次新的commit来回滚之前的commit,git reset是直接删除指定的commit。
2. 在回滚这一操作上看,效果差不多。但是在日后继续merge以前的老版本时有区别。因为git revert是用一次逆向的commit“中和”之前的提交,因此日后合并老的branch时,导致这部分改变不会再次出现,但是git reset是之间把某些commit在某个branch上删除,因而和老的branch再次merge时,这些被回滚的commit应该还会被引入。
3. git reset 是把HEAD向后移动了一下,而git revert是HEAD继续前进,只是新的commit的内容和要revert的内容正好相反,能够抵消要被revert的内容。
9. 如何删除远程分支
删除远程分支就是将本地的空分支push到远程即可。
#查看远程分支
$ git ls-remote idc
Password:
fa7dc3cd254c6fff683e20722284565b92d869ff HEAD
14a62709ecadd11a266d234d19955f4679fa95ab refs/heads/cpp-1.0
34b38625bce0aa4d4a4e266e20bba3e0ccd1b97e refs/heads/cpp-1.0.RC1
3f40a21f20f51aaa74e2a6954b64d82506cd4adf refs/heads/cpp-1.1
2f795085d57b6784a6358d97dbd0d1227891b01a refs/heads/distri
#删除远程叫做diftri的分支
$ git push idc :distri
Password:
To xxx@192.168.4.40:Project.git
- [deleted] distri
#确认远程分支被删除
$ git ls-remote idc
Password:
fa7dc3cd254c6fff683e20722284565b92d869ff HEAD
14a62709ecadd11a266d234d19955f4679fa95ab refs/heads/cpp-1.0
34b38625bce0aa4d4a4e266e20bba3e0ccd1b97e refs/heads/cpp-1.0.RC1
3f40a21f20f51aaa74e2a6954b64d82506cd4adf refs/heads/cpp-1.1
9. 如何删除本地分支
使用git branch命令就可以删除本地分支,比如
10. 如何clone(克隆)远程仓库中的指定分支,而非默认的master分支
在git clone 命令中使用-b参数指定分支名字即可,比如将远端aiotrade.git上的levelIISZ-1.1分支克隆下来:
git clone -b levelIISZ-1.1 username@192.168.4.40:aiotrade.git
参考文献:
1. http://book.git-scm.com/3_basic_branching_and_merging.html
2. git reset --help
3. git revert --help
Git 常用命令速查表
Git Cheat Sheet < CN > (#Version 0.1)
PDF 版本下载 /PNG图片下载
创建版本库
修改和提交
查看提交历史
撤消
分支与标签
合并与衍合
远程操作
- 【Git】git的高级用法
- git高级用法
- git高级用法
- git高级用法
- Git log 高级用法
- 3.Git(版本控制的高级用法)
- Git中文手册 - 高级用法
- Git中文手册 - 高级用法
- Git之版本控制工具的高级用法
- git内容整理--版本控制工具的高级用法
- Git 时间,版本控制工具的高级用法
- Git 时间,版本控制工具的高级用法
- git log的高级使用
- git的基本用法
- git的用法
- git的用法
- git diff的用法
- git 的patch用法
- Python3从入门到放弃
- 接上文,终于解决了mamp安装扩展的问题.
- ssh中难理解的问题总结(一)-关于hibernate中的sessionFactory与http中的session
- 链表中倒数第k个结点
- JSP——了解Jsp技术
- 【Git】git的高级用法
- FTP连接时出现“227 Entering Passive Mode”
- ADT
- 卷积神经网络CNN
- Python—itchat小程序之——景点信息获取
- Jquery初识及用法
- jquery对象与dom对象
- Jedis介绍和入门案例
- 栈