前篇文章玩转Git入门篇我们已经对Git有了一个大概的了解,接下来我们学习下Git的如何管理项目的。
Repository(仓库)包含的内容 - Git的目标是管理一个工程,或者说是一些文件的集合,以跟踪它们的变化。Git使用Repository来存储这些信息。一个仓库主要包含以下内容(也包括其他内容):
在使用Repository(仓库)之前,我们首先需要创建仓库,创建仓库有很多种,这里常见的有如下几种:
这里使用第三方托管平台作为讲解,以 http://git.oschina.net 为例,注册过程就省略。
点击红色箭头指向的”+“号,以创建一个仓库,如下所示 –
这样,一个公开的仓库就创建完成了。要记住上面图片创建的路径:
https://gitee.com/guanzzh/git-start.git
方法一:从一个服务器克隆一个现有的 Git 仓库。
方法二:在现有项目或目录下导入所有文件到 Git 中;
如果你想获得一份已经存在了的 Git 仓库的拷贝,比如说,想为某个开源项目贡献自己的一份力,这时就要用到 git clone
命令。当你执行 git clone
命令的时候,默认配置下远程 Git 仓库中的每一个文件的每一个版本都将被拉取下来。
在安装了Git 的 Windows系统上,在一个目录(本示例是:D:\Git_Repository)中,单击右键,在弹出的菜单中选择“Git Bash”。
克隆仓库的命令格式是 git clone [url] 。 比如,要克隆 Git 的上面创建的仓库 git-start.git,可以用下面的命令:
$ git clone https://gitee.com/guanzzh/git-start.git
这会在当前目录下创建一个名为 “git-start.git
” 的目录,并在这个目录下初始化一个 .git
文件夹,从远程仓库拉取下所有数据放入 .git
文件夹,然后从中读取最新版本的文件的拷贝。
如果想在克隆远程仓库的时候,自定义本地仓库的名字,可以使用如下命令:
$ git clone https://gitee.com/guanzzh/git-start.git mygit-start
Git 支持多种数据传输协议。 上面的例子使用的是 https://
协议,不过也可以使用 git://
协议或者使用 SSH 传输协议,比如 user@server_ip-or-host:path/to/repo.git
。在服务器上搭建 Git 将会介绍所有这些协议在服务器端如何配置使用,以及各种方式之间的利弊。
如果不克隆现有的仓库,而是打算使用 Git 来对现有的项目进行管理。假设有一个项目的目录是:D:\Git_Repository\demo-sample
,进入该目录并输入:
$ git init
git init
命令创建一个空的Git仓库或重新初始化一个现有仓库。
该命令将创建一个名为 .git
的子目录,这个子目录含有初始化的 Git 仓库中所有的必须文件,仅仅是做了一个初始化的操作,项目里的文件还没有被跟踪。此时可通过 git add
命令来实现对指定文件的跟踪,然后执行 git commit
提交。
假设在目录 D:\Git_Repository\demo-sample
中有一些代码需要跟踪(版本控制),可通过 git add
命令来实现对HelloWorld.java文件的跟踪 –
$ git add
HelloWorld.java
$ git commit -m ‘initial project version‘
工作目录下的每一个文件都不外乎这两种状态:已跟踪或未跟踪。 已跟踪的文件是指那些被纳入了版本控制的文件,在上一次快照中有它们的记录,在工作一段时间后,它们的状态可能处于未修改,已修改或已放入暂存区。工作目录中除已跟踪文件以外的所有其它文件都属于未跟踪文件,它们既不存在于上次快照的记录中,也没有放入暂存区。 初次克隆某个仓库的时候,工作目录中的所有文件都属于已跟踪文件,并处于未修改状态。
编辑过某些文件之后,由于自上次提交后你对它们做了修改,Git 将它们标记为已修改文件。 我们逐步将这些修改过的文件放入暂存区,然后提交所有暂存了的修改,如此反复。所以使用 Git 时文件的生命周期如下:
要查看哪些文件处于什么状态,可以用 git status
命令。
$ git status
在项目中新建不存在文件
mytext.txt,
使用 git status
命令,将看到一个新的未跟踪文件:
若使用 git status -s 命令或 git status --short 命令,将得到一种更为紧凑的格式输出。
??标识未跟踪,新增A,修改M,同时出现MM,右M标识文件被修改未放入暂存区,左M标识该文件被修改并放入暂存区。
git diff
将通过文件补丁的格式显示具体哪些行发生了改变。
请注意,git diff
本身只显示尚未暂存的改动,而不是自上次提交以来所做的所有改动。 所以有时候你一下子暂存了所有更新过的文件后,运行 git diff
后却什么也没有,就是这个原因。
然后用 git diff --cached
查看已经暂存起来的变化:(--staged
和 --cached
是同义词)
git difftool
命令来用 Araxis
,emerge
或 vimdiff
等软件输出 diff
分析结果。
:
qa!
退出窗口
使用命令 git add
开始跟踪一个文件。 (添加内容到下一次提交中)
$ git add mytext.txt
此时再运行 git status
命令,会看到 mytext.txt
文件已被跟踪,并处于暂存状态:
只要在 Changes to be committed 这行下面的,就说明是已暂存状态。 如果此时提交,那么该文件此时此刻的版本将被留存在历史记录中。git add
命令使用文件或目录的路径作为参数;如果参数是目录的路径,该命令将递归地跟踪该目录下的所有文件。
修改一个已被跟踪的文件。然后运行 git status
命令,会看到下面内容:
出现在 Changes not staged for commit 这行下面,说明已跟踪文件的内容发生了变化,但还没有放到暂存区。要暂存这次更新,需要运行 git add
命令。 这是个多功能命令:可以用它开始跟踪新文件,或者把已跟踪的文件放到暂存区,还能用于合并时把有冲突的文件标记为已解决状态等。
先修改README.md文件,git add之后,现在两个文件都已暂存,下次提交时就会一并记录到仓库。 假设此时,修改README.md,再运行 git status
:
README.md
文件同时出现在暂存区和非暂存区。实际上 Git 只不过暂存了运行 git add
命令时的版本, 如果现在提交,README.md
的版本是最后一次运行 git add
命令时的那个版本,而不是运行 git commit
时,在工作目录中的当前版本。运行了 git add
之后又作了修订的文件,需要重新运行 git add
把最新版本重新暂存起来:
一般我们总会有些文件无需纳入 Git 的管理,也不希望它们总出现在未跟踪文件列表。在这种情况下,我们可以创建一个名为 .gitignore
的文件,列出要忽略的文件模式。
$ cat .gitignore
*.[oa]
*~
忽略所有以 .o
或 .a
结尾的文件。
忽略所有以波浪符(~
)结尾的文件,
.gitignore 的格式规范如下:
提示:GitHub 有一个十分详细的针对数十种项目及编程语言的 .gitignore
文件列表,你可以在 http://github.com/github/gitignore 找到它。
每次准备提交前,先用 git status
看下,是不是都已暂存起来了,如果没有暂存起来则要先使用命令:git add .
将所有文件暂存起来, 然后再运行提交命令 git commit
:
$ git status
$ git add .
$ git commit
提交后它会告诉你,当前是在哪个分支(master
)提交的,本次提交的完整 SHA-1 校验和是什么(463dc4f
)
请记住,提交时记录的是放在暂存区域的快照。任何还未暂存的仍然保持已修改状态,可以在下次提交时纳入版本管理。 每一次运行提交操作,都是对你项目作一次快照,以后可以回到这个状态,或者进行比较。
跳过使用暂存区域
git commit
加上 -a
选项,Git 就会自动把所有已经跟踪过的文件暂存起来一并提交,从而跳过 git add
步骤:
$ git commit -a -m ‘added new benchmarks‘
Git
隐藏(stash)操作
在Git中,隐藏操作将使您能够修改跟踪文件,阶段更改,并将其保存在一系列未完成的更改中,并可以随时重新应用。要将一个新的存根推到堆栈上,运行git stash
命令。
$ git stash
Saved working directory and index state WIP on master: ef07ab5 synchronized with the remote repository
HEAD is now at ef07ab5 synchronized with the remote repository
通过使用git stash list
命令来查看已存在更改的列表。
$ git stash list
stash@{0}: WIP on master: ef07ab5 synchronized with the remote repository
想要重新开始新的功能的代码编写,查找上次没有写完成的代码,只需执行git stash pop
命令即可从堆栈中删除更改并将其放置在当前工作目录中。
要从 Git 中移除某个文件,就必须要从已跟踪文件清单中移除(确切地说,是从暂存区域移除),然后提交。 可以用 git rm
命令完成此项工作。
$ rm mytext.txt
已经存放到暂存区,则必须要用强制删除选项 -f
(注:即 force
的首字母)。
git rm
命令后面可以列出文件或者目录的名字,也可以使用 glob
模式。 比方说:
$ git rm log/\*.log
Git 并不显式跟踪文件移动操作。在 Git 中对文件改名,命令如下:
$ git mv file_from file_to
相当于如下三个命令:
$ mv README.md README
$ git rm README.md
$ git add README
查看提交历史,git log
命令。默认不用任何参数的话,git log
会按提交时间列出所有的更新,最近的更新排在最上面。
一个常用的选项是 -p
,用来显示每次提交的内容差异。 你也可以加上 -2
来仅显示最近两次提交:
想看到每次提交的简略的统计信息,可以使用 --stat
选项:
另外一个常用的选项是 --pretty
。 这个选项可以指定使用不同于默认格式的方式展示提交历史。 这个选项有一些内建的子选项供你使用。 比如用 oneline
将每个提交放在一行显示,查看的提交数很大时非常有用。 另外还有 short
,full
和 fuller
可以用,展示的信息或多或少有些不同。
有时候我们提交完了才发现漏掉了几个文件没有添加,或者提交信息写错了。 此时,可以运行带有 --amend
选项的提交命令尝试重新提交:
$ git commit --amend
这个命令会将暂存区中的文件提交。 如果自上次提交以来你还未做任何修改(例如,在上次提交后马上执行了此命令),那么快照会保持不变,而你所修改的只是提交信息。
使用 git reset HEAD <file>...
来取消暂存。
$ git reset HEAD mytext.txt
reset强调,撤销
用Git复位移动头指针
经过少量更改后,可以决定删除这些更改。 git reset
命令用于复位或恢复更改。 我们可以执行三种不同类型的复位操作。语法:git reset [<mode>] [<commit>]
下图显示了git reset
命令的图示。
git reset
命令之前 -
git reset
命令之后 -
—soft选项
每个分支都有一个HEAD
指针,它指向最新的提交。 如果用--soft
选项后跟提交ID的Git reset
命令,那么它将仅重置HEAD
指针而不会破坏任何东西。
.git/refs/heads/master
文件存储HEAD
指针的提交ID。 使用git reset --soft [comittedID]命令。可使用git log -1
命令验证它。
$ git reset --soft 931280a3ec004120c4cee372f45cf7c0b4fed1bc
使用--mixed
选项的Git重置将从尚未提交的暂存区域还原这些更改。它仅从暂存区域恢复更改。对文件的工作副本进行的实际更改不受影响。 默认Git复位等效于执行git reset -- mixed
。
如果使用--hard
选项与Git重置命令,它将清除分段区域; 它会将HEAD指针重置为特定提交ID的最新提交,并删除本地文件更改。
用暂存区的内容替换工作区的文件。使用 git checkout -- <file>...
来撤消之前所做的修改。(未加入暂存区)
$ git checkout -- mytext.txt
加入暂存区撤销修改
当执行添加操作时,文件将从本地存储库移动到暂存区域。 如果用户意外修改文件并将其添加到暂存区域,则可以使用git checkout
命令恢复其更改。
在Git中,有一个HEAD
指针总是指向最新的提交。 如果要从分段区域撤消更改,则可以使用git checkout
命令,但是使用checkout
命令,必须提供一个附加参数,即HEAD
指针。 附加的提交指针参数指示git checkout
命令重置工作树,并删除分段更改。
$ git checkout head -- mytext.txt
休息片刻,接下来我们将在Git快速入门进阶篇中继续探讨Git是如何管理项目的。
原文:https://www.cnblogs.com/guanzhyan/p/8996607.html