您的位置:首页 > 其它

Git的使用

2017-07-08 11:38 148 查看
通过之前的博文,我们已经下载安装好了Git,并且已经学习了Git原理后,我们可以开始正式学习怎么来使用Git了。

config

首先,我们需要配置下自己的Git工作环境,配置工作只需要一次,以后升级还会沿用现在的配置,如果需要更改,你可以随时使用相同的命令修改。我们可以通过config命令来配置或读取相应的工作环境变量,而正是由这些环境变量,决定了Git在各个环节的具体工作方式和行为。这些变量可以存放在以下三个不同的地方:

●/etc/gitconfig
 文件:系统中对所有用户都普遍适用的配置。若使用 
git
config
 时用
--system
 选项,读写的就是这个文件。

●~/.gitconfig
 文件:用户目录下的配置文件只适用于该用户。若使用 
git
config
 时用
--global
 选项,读写的就是这个文件。

●当前项目的 git 目录中的配置文件(也就是工作目录中的 
.git/config
 文件):这里的配置仅仅针对当前项目有效。每一个级别的配置都会覆盖上层的相同配置,所以
.git/config
 里的配置会覆盖
/etc/gitconfig
 中的同名变量。



使用gif config命令能够看到指定设置级别的三个参数--system,--global,--local,这三个级别范围从大到小,后面的都能覆盖前面的。


配置用户信息

配置user.name和user.email很重要,每次Git提交都会引用这两条信息,这对你的工作的产权也很重要。



查看配置信息

使用git config --list命令能够检查已有的配置信息。



有时候会看到重复的变量名,那就说明它们来自不同的配置文件(比如/etc/gitconfig和~/.gitconfig),不过最终Git实际采用的是最后一个。当然我们也可以直接查看某个环境变量的设定,只要把特定的环境变量名跟在后面即可,类似git config user.name。

行尾和字体颜色的设置

行尾之所以重要,是因为不同平台任然有区别:Mac,Linux,Windows,CR与CRLF,LF,Git将帮助标准化那些那些正在被check的文件到存储库,通过设置比如core.autocrlf

git config --global core.autocrlf ture        git config --global core.autocrlf input

而对于颜色来说,通过颜色我们能够很直观的得到某些信息。如果某个字体是红色的,我们可能知道那仍在处理,相反如果某个东西是绿色的,意味着它运行正常。我们后面要学的分支以颜色列出,状态以颜色列出,历史记录日志以颜色列出,几乎每个Git命令以红色,绿色,黄色和其他颜色为补充,来指示该代码的状态,该分支或那次提交

文本编辑器

Git需要你输入一些额外消息的时候,会自动调用一个外部文本编辑器给你用。默认会使用操作系统指定的默认编辑器,一般可能会是Vi或者Vim.当然如果你有其他偏好,可以重新设置,例如:  git config --global core.editor emacs

差异化分析工具

还有一个比较常用的是,在解决合并冲突时候使用哪种差异分析工具。比如改用vimdiff:  git config --global merge.tool vimdiff

init

一种情况是你已经完成了一个项目,但是你要用Git来管理它。你需要来到你这个项目的目录下,使用命令git init即可,你会发现初始化后,当前目录会多出一个名为.git的目录,所有Git需要的数据和资源都存放在这个目录下,如果还记得之前讲过的原理部分,你就会明白其实就是在工作目录下建立了一个git仓库。



我们还可以使用git status命令来查看当前的状态。我们明显看到它们都是untracked files,没有被Git追踪的文件。



也许在创建项目之前,你就已经考虑好要用Git来管理。那你就只需要输入git  init website, 其中website是你的项目名称。

我们还可以从现有的仓库克隆,克隆仓库的命令格式为git clone

git add后面可以指明跟踪的文件或目录路径。如果是目录,说明要递归跟踪该目录下的所有文件。接下来我们修改下已跟踪的文件login.html,然后再查看状态。



之前的信息没有改变,多出了一些信息,发现login.html出现在了红色的字modified后面,说明已跟踪文件的内容发生了改变,但是还没有放在暂存区。我们需要再次使用add命令暂存这次更新。add命令是一个多功能命令,根据目标文件的状态不同,此命令的效果也不同,可以用它开始跟踪新文件,或者把已跟踪但更新了的文件放到暂存区,还能用于合并时把有冲突的文件标记为已解决状态等。所以记住,每次修改了文件,都需要使用add命令再次把它放到暂存区,才可以提交。

commit

暂存区域里面的东西可以用commit命令进行提交了,尽量在每次提交之前,先用git status查看,是不是都已经暂存起来了。使用commit进行提交的时候一定要加上一个清晰的描述信息,以便让其他人可以理解。命令格式形如:git
commit -m  "message" ,message为你的描述信息。



提交后它会显示,当前是在哪个分支(master)提交的,本次提交的SHA-1校验和适什么(71020de),然后是描述信息,以及本次提交中有多少文件更新了,多少行添加和删改过。

如果直接使用git commit命令,Git实际上将打开一个文本编辑器,并让你输入一个描述信息,所以输入描述信息是无法避免的。

跳过暂存区域

是不是感觉每次修改后都要add进暂存区特别麻烦,Git提供了一个跳过使用暂存区域的方式,只要在提交的时候,给git commit加上-a选项,Git就会自动把所有已经跟踪过的文件暂存起来一并提交,从而跳过git add步骤。



可以看到开始状态处于红色的modified,说明没有在暂存区中,但是提交成功了。

ignore

ignore用来避免提交那些不应该在你仓库中出现的文件,我们总会有些文件不需要Git的管理,也不希望它们总是出现在未跟踪文件列表。通常都是些自动生成的文件,比如日志文件,或者编译过程中创建的临时文件等。我们可以创建一个名为.gitignore的文件,列出要忽略的文件模式。如果.gitignore文件中什么不写,它会把当前路径下的所所有文件包含进去,也就是所有文件都不会被纳入到Git的版本管理中去,这不是我们所期望的。



所以我们应该在.gitignore文件中指定哪些文件你不想被git管理,通常使用glob模式,是指shell所使用的简化了的正则表达式。

星号(
*
)匹配零个或多个任意字符;
[abc]
 匹配任何一个列在方括号中的字符(这个例子要么匹配一个
a,要么匹配一个 b,要么匹配一个 c);问号(
?
)只匹配一个任意字符;如果在方括号中使用短划线分隔两个字符,表示所有在这两个字符范围内的都可以匹配(比如
[0-9]
 表示匹配所有
0 到 9 的数字)。




diff

如果你做了一个简单的改动,然后马上提交了它,你并不需要Git来告诉你你做了什么,你可能在你的脑子里记录了它。但是有许多时候,你会需要检验内容发生了怎样的变化。这里有三种使用diff的情况。

1.现在,假设你改动了一个文件,然后被从电脑前叫出来去了一小会儿然后回来,然后你已经忘记自己改了什么地方了。也就是说你已经修改了文件,但是还没有把文件add进入暂存区或者也没有跨越暂存区直接提交,这时候你想知道你改动了哪里,只需要输入git diff。减号代表之前的文件,红色的文字。加号代表更新后的文件,绿色的文字。



2.接着上面的情况讲,你已经修改了某文件,并且你也已经把修改后的文件加入了暂存区但是还没有提交。只需要输入git diff --staged,然后你就能看到这些改动了。



3.还是接着上面的情况,我们继续修改login.html,也就是说我们继续修改暂存区中的文件。对暂存区中的同一个文件修改了多次,我们可以使用git diff HEAD命令来将你的工作树和头一次提交相比较。

上面每次都是包括了改动信息的一整行,很多时候我们只有一点小改动,并且我们想直观快速的定位到我们的改动位置。因此我们可以在diff后面添加参数--color-words和--word-diff



我们还可以使用git diff --stat 来锁定某个被修改过的特定文件。

remove

 如果你只有一个文件需要删除,使用git rm命令即可。它真正的从文件系统中删除了文件,并且它会暂存这个文件已经被删除的事实,如果你提交了,这个文件不会从之前的历史中消失,但是会从未来的提交中消失



从图中可以看到绿色的deleted表示login.html这个文件已经被删除的事实被记录到了暂存区中,提交之后,该文件就不再纳入版本管理中了。同时工作目录下也不存在这个文件了。

如果只是简单地从工作目录中手工的删除文件,运行git status时就会发现deleted是红色的,表明它在未暂存清单中,我们需要再次运行git rm login.html才能把此次移除文件的操作记录到暂存区。

如果删除之前修改过并且已经刚到了暂存区域的话,则必须要用强制删除选项-f,以防误删除文件后丢失修改的内容。还有一种情况是,我们想把文件从Git仓库中删除(即从暂存区移除),但是仍然希望保留在当前工作目录,意思是我不希望删除这个文件,只是希望它从跟踪清单中删除。比如一些大型日志文件不小心纳入仓库后,要移除跟踪但是不删除文件,这个时候我们使用--cached选项即可。

move

在git中,重命名和移动文件是同一件事情,基本语法如下图所示



如果你直接使用mv命令而忘记了告诉git,查看状态,你会发现你已经把原来的文件给删除了,但是删除的状态没存入暂存区域,同时新的文件也没有被跟踪。



所以我们接下来做的就是:



log

log可以查看我们的提交日志,最简单的是,直接输入git log



这些记录都是按照提交的时间顺序排列的,最新的在最上面。每一个提交记录都有一串40个字符的十六进制码,这是唯一标识符或者是git生成的提交引用。然后下面第一行由你或者提交者的用户名和邮件地址,紧接着是提交的时间,最后是你的提交描述。如果你的仓库中有许多次提交,在你屏幕的左下角部分,你将会看到一个冒号,你可以使用上下方向键来滚动查看这些提交记录。

但是有时候我们不需要查看所有的提交信息,可以使用一个选项,过滤得到更加具体的内容。

git log --oneline命令每次提交只列出一行信息,这行信息包括提交标识码和提交描述信息。

git log --stat命令能够更加详细的列出每次提交修改的文件信息。

git log --patch命令能够了解提交之间哪些内容改变了,它会展示不同的地方和后续的提交作对比,如果在两次提交之间内容改变以及增加了,你将会看到使用绿色列出来并且会看到一些加法符号。如果是一些东西被移除了,你将会看到红色的减号展示。

注意你可以根据你的实际需要,通过组合上面的命令,来进行日志输出。

branch

当开始一个新项目或者打开一个已经存在的项目的时候,我们一开始就要新建一个分支,这是非常重要的。很多人认为master分支是许多工作代码所在的地方的,但是我们在提交的时候要十分小心,因为它就是对产品特性的一种呈现。要开始一个新分支,直接输入git branch,接着是新分支的名字,这就可以创建一个我们后面可以切换的分支,我们想删除一个分支,只需要输入git
branch -d 分支名字即可。现在,如果它没有完全被合并,将为给你一个warning,告诉你把-d替换为-D。注意我们肯定不能够删除正在使用额分支,所以我们需要切换分支。切换分支使用git  checkout  分支名字 



从图中可以看到,任何出现在面板区的工作或者工作目录都跟着转过来了。但是要注意如果我们处于这个活动目录或者面板区的文件被覆盖的话,是无法切换到新分支上面去的。最后一点,你可能看到文件消失又重现,在进行切换分支的时候。不用担心这些文件和它们的改变,它们会待在各自的分支里,直到你合并他们为止,分支是Git和Git流程中的一个关键元素,如果你想更详细的了解branch,请参考这个链接:《Pro
Git》

checkout

让我们来看看checkout除了上面的切换分支,它还能干什么。checkout能够把你项目下的工作树、目录和文件等东西,做一个更加详细的commit,为了做到这个,我们可以使用git checkout 提交引用(40位的十六进制码)。这样我们的工作树就会在commit提交的那个时间点被覆盖了。当我们看到这个状态时,注意我们正处于detached
head状态,这不是一个我们想commit的地方,这只是一种显示我们的工作树、目录和文件看起来是什么样子的方式,一旦你已经了解了detached head状态之后,一定要回去检查你的分支,使用这种方式,你将不会丢失掉任何东西。



git checkout的另外一个用法是撤销或者丢弃编辑的内容。可能,我们有许多文件,但是只有一个是正确的,如果我们想丢掉这些改变,我们可以使用命令:

git checkout -- 文件名

这个可以为我们做到的是它会清理掉最后一次commit的内容。

checkout的最后一个小技巧是可以创建一个分支并且直接切换到这个分支上去。

git checkout -b 新分支名字

merge

分支是每个Git工作流的关键部分,把这些改变汇聚起来也是非常重要的,这个工作可以通过merge来完成。通过merge我们可以把两个或者更多分支的历史汇聚起来,然后再工作树中展示所有这些分支中全部commit的累积结果。对于一个典型的工作流,我们会切换到master分支,然后确认该分支有我们想要合并的commit,使用命令git merge
加上我们想要的commit的分支名字。

在合并过程中可能会遇到冲突的情况,比如你在master分支里修改了一个index文件提交了,然后在另外的分支中也修改了这个index文件,合并的时候就会出现冲突。



可以看到合并时候出现冲突,指出了冲突的文件,使用git status还能发现index.html出现了未合并的路径。打开index.html文件



文件里面已经加入了冲突的标识符号了。我们都知道HEAD指针指向当前分支,所以<<<<<<< HEAD 和=======之间是当前分支修改提交的内容,而=======和>>>>>>>
web-app之间是要合并分支web-app修改提交的内容,即>>>>>>> web-app是冲突结束的标识。

那么我们如何解决冲突呢。很简单,我们只需要自己选择要保留的修改,或者二者修改内容相结合重新修改文件,但是需要把<<<<<<< HEAD之类的冲突标识全部删除,然后把index文件放在暂存区,重新提交即可。

当然还有一种情况是当你合并的时候遇到了冲突,但是你不想马上解决它,或者你目前只想抛弃它,你可以使用git merge --abort命令,这将会从你当前分支的最后一次提交中清除你的工作目录,它同样清除你的暂存区。这里有一个merge的小技巧,如果你不想把历史汇聚起来,即你不想要合并其他分支的日志信息,但是你想要一个具体分支中的全部的commit,简单地运行git
merge --squash 你的目标分支名字,这样将会为你创建一个新的提交在你目前切换到的分支上,这代表了发生在目标分支上的所有改变。最后,当你成功的合并了目标分支之后,如果你不需要它了,请把它移除。

remote

 要参与任何一个Git项目的协作,必须了解该如何管理远程仓库。远程仓库是指托管在网络上的项目仓库,可能会有好多个,其中有些你只能读,另外有些可以写。同他人协作开发某个项目时,需要管理这些远程仓库,以便推送或者拉取数据,分享各自的工作进展。

要查看当前配置有哪些远程仓库,可以用git remote命令,它会列出每个远程库的简短的名字。在克隆完某个项目后,至少可以看到一个名为origin的远程库,Git默认使用这个名字来标识你所克隆的原始仓库。还可以使用git remote -v命令列出所有的远程仓库和它的地址。

要添加一个新的远程仓库,命令格式为:git remote add 仓库名 URL,指定的仓库名应该简单好记,以便将来引用。

从远程数据库抓取数据到本地仓库,使用git fetch命令,如果是克隆了一个远程仓库,此命令会自动将远程仓库归于origin名下,所以git fetch origin会抓取从你上次克隆以来别人上传到此远程仓库中的所有更新。有一点很重要,需要记住,fetch命令只是将远端的数据拉倒本地仓库,并不自动合并到当前工作分支,需要手工合并。如果设置了某个分支专门用于跟踪某个远端仓库的分支,可以使用git
pull命令自动抓取数据下来,然后将远端分支自动合并到本地仓库中当前分支。

推送数据到远程仓库库使用命令:git push 远程仓库名 本地分支名,注意只有在所克隆的服务器上有写权限,或者同一个时刻没有其他人在推数据,这条命令才会如期完成任务。如果在你推数据前,已经有其他人推送了若干更新,那你的推送操作就会被驳回。你必须先把他们的更新抓取到本地,合并到自己的项目中,然后才可以再次推送。

我们可以通过git remote show 远程仓库名来查看某个远程仓库的详细信息。它友善地告诉你如果是在master分支,就可以用git pull命令抓取数据合并到本地。另外还列出了所有处于跟踪状态中的远端分支。

远程仓库重命名使用命令:git remote rename 原有名字 更改名字 注意对远程仓库重命名,也会使对应的分支名称发生变化。

远程仓库移除使用命令:
git remote rm 远程仓库名

tag

Git也提供了给软件打上版本标签的命令,详细请参考链接:[url=https://git-scm.com/book/zh/v1/Git-%E5%9F%BA%E7%A1%80-%E6%89%93%E6%A0%87%E7%AD%BE]《Pro Git》" target=_blank>,例如要克隆Ruby语言的Git代码仓库Grit,可以用以下命令:

git clone git://github.com/schacon/grit.git

这会在当前目录下创建一个名为“grit”的目录,其中包含一个.git的目录,用于保存下载下来的所有的版本记录,然后从中取出最新版本的文件拷贝。如果希望在克隆的时候,自己定义新建的项目目录名称,可以在上面的命令末尾指定新的名字:

git clone git://github.com/schacon/grit.git mygrit

Git支持许多数据传输协议,上面的例子使用的是git://协议。也可以使用http(s)://或者user@server:/path.git表示的SSH传输协议。

status

上面已经提到过这个命令了,在这里详细说一下。无论是使用init新建了一个仓库,或者使用clone克隆了一个仓库,起初都是没有任何跟踪着的文件。该命令还显示了当前所在分支是什么。出现在未跟踪文件列表中的文件没有在暂存区中,也就无法提交,Git不会自动将它纳入跟踪范围,需要使用add命令显示声明。

add

使用add我们开始跟踪一个新文件,并把它放在了暂存区中,使用git status可以看到login.html文件处于暂存状态,括号中提示可以使用括号中的命令把它从暂存区中删除。绿色的字new file后面表示的就是一个新文件被跟踪,并且处于暂存区。



git add后面可以指明跟踪的文件或目录路径。如果是目录,说明要递归跟踪该目录下的所有文件。接下来我们修改下已跟踪的文件login.html,然后再查看状态。



之前的信息没有改变,多出了一些信息,发现login.html出现在了红色的字modified后面,说明已跟踪文件的内容发生了改变,但是还没有放在暂存区。我们需要再次使用add命令暂存这次更新。add命令是一个多功能命令,根据目标文件的状态不同,此命令的效果也不同,可以用它开始跟踪新文件,或者把已跟踪但更新了的文件放到暂存区,还能用于合并时把有冲突的文件标记为已解决状态等。所以记住,每次修改了文件,都需要使用add命令再次把它放到暂存区,才可以提交。

commit

暂存区域里面的东西可以用commit命令进行提交了,尽量在每次提交之前,先用git status查看,是不是都已经暂存起来了。使用commit进行提交的时候一定要加上一个清晰的描述信息,以便让其他人可以理解。命令格式形如:git
commit -m  "message" ,message为你的描述信息。



提交后它会显示,当前是在哪个分支(master)提交的,本次提交的SHA-1校验和适什么(71020de),然后是描述信息,以及本次提交中有多少文件更新了,多少行添加和删改过。

如果直接使用git commit命令,Git实际上将打开一个文本编辑器,并让你输入一个描述信息,所以输入描述信息是无法避免的。

跳过暂存区域

是不是感觉每次修改后都要add进暂存区特别麻烦,Git提供了一个跳过使用暂存区域的方式,只要在提交的时候,给git commit加上-a选项,Git就会自动把所有已经跟踪过的文件暂存起来一并提交,从而跳过git add步骤。



可以看到开始状态处于红色的modified,说明没有在暂存区中,但是提交成功了。

ignore

ignore用来避免提交那些不应该在你仓库中出现的文件,我们总会有些文件不需要Git的管理,也不希望它们总是出现在未跟踪文件列表。通常都是些自动生成的文件,比如日志文件,或者编译过程中创建的临时文件等。我们可以创建一个名为.gitignore的文件,列出要忽略的文件模式。如果.gitignore文件中什么不写,它会把当前路径下的所所有文件包含进去,也就是所有文件都不会被纳入到Git的版本管理中去,这不是我们所期望的。



所以我们应该在.gitignore文件中指定哪些文件你不想被git管理,通常使用glob模式,是指shell所使用的简化了的正则表达式。

星号(
*
)匹配零个或多个任意字符;
[abc]
 匹配任何一个列在方括号中的字符(这个例子要么匹配一个
a,要么匹配一个 b,要么匹配一个 c);问号(
?
)只匹配一个任意字符;如果在方括号中使用短划线分隔两个字符,表示所有在这两个字符范围内的都可以匹配(比如
[0-9]
 表示匹配所有
0 到 9 的数字)。




diff

如果你做了一个简单的改动,然后马上提交了它,你并不需要Git来告诉你你做了什么,你可能在你的脑子里记录了它。但是有许多时候,你会需要检验内容发生了怎样的变化。这里有三种使用diff的情况。

1.现在,假设你改动了一个文件,然后被从电脑前叫出来去了一小会儿然后回来,然后你已经忘记自己改了什么地方了。也就是说你已经修改了文件,但是还没有把文件add进入暂存区或者也没有跨越暂存区直接提交,这时候你想知道你改动了哪里,只需要输入git diff。减号代表之前的文件,红色的文字。加号代表更新后的文件,绿色的文字。



2.接着上面的情况讲,你已经修改了某文件,并且你也已经把修改后的文件加入了暂存区但是还没有提交。只需要输入git diff --staged,然后你就能看到这些改动了。



3.还是接着上面的情况,我们继续修改login.html,也就是说我们继续修改暂存区中的文件。对暂存区中的同一个文件修改了多次,我们可以使用git diff HEAD命令来将你的工作树和头一次提交相比较。

上面每次都是包括了改动信息的一整行,很多时候我们只有一点小改动,并且我们想直观快速的定位到我们的改动位置。因此我们可以在diff后面添加参数--color-words和--word-diff



我们还可以使用git diff --stat 来锁定某个被修改过的特定文件。

remove

 如果你只有一个文件需要删除,使用git rm命令即可。它真正的从文件系统中删除了文件,并且它会暂存这个文件已经被删除的事实,如果你提交了,这个文件不会从之前的历史中消失,但是会从未来的提交中消失



从图中可以看到绿色的deleted表示login.html这个文件已经被删除的事实被记录到了暂存区中,提交之后,该文件就不再纳入版本管理中了。同时工作目录下也不存在这个文件了。

如果只是简单地从工作目录中手工的删除文件,运行git status时就会发现deleted是红色的,表明它在未暂存清单中,我们需要再次运行git rm login.html才能把此次移除文件的操作记录到暂存区。

如果删除之前修改过并且已经刚到了暂存区域的话,则必须要用强制删除选项-f,以防误删除文件后丢失修改的内容。还有一种情况是,我们想把文件从Git仓库中删除(即从暂存区移除),但是仍然希望保留在当前工作目录,意思是我不希望删除这个文件,只是希望它从跟踪清单中删除。比如一些大型日志文件不小心纳入仓库后,要移除跟踪但是不删除文件,这个时候我们使用--cached选项即可。

move

在git中,重命名和移动文件是同一件事情,基本语法如下图所示



如果你直接使用mv命令而忘记了告诉git,查看状态,你会发现你已经把原来的文件给删除了,但是删除的状态没存入暂存区域,同时新的文件也没有被跟踪。



所以我们接下来做的就是:



log

log可以查看我们的提交日志,最简单的是,直接输入git log



这些记录都是按照提交的时间顺序排列的,最新的在最上面。每一个提交记录都有一串40个字符的十六进制码,这是唯一标识符或者是git生成的提交引用。然后下面第一行由你或者提交者的用户名和邮件地址,紧接着是提交的时间,最后是你的提交描述。如果你的仓库中有许多次提交,在你屏幕的左下角部分,你将会看到一个冒号,你可以使用上下方向键来滚动查看这些提交记录。

但是有时候我们不需要查看所有的提交信息,可以使用一个选项,过滤得到更加具体的内容。

git log --oneline命令每次提交只列出一行信息,这行信息包括提交标识码和提交描述信息。

git log --stat命令能够更加详细的列出每次提交修改的文件信息。

git log --patch命令能够了解提交之间哪些内容改变了,它会展示不同的地方和后续的提交作对比,如果在两次提交之间内容改变以及增加了,你将会看到使用绿色列出来并且会看到一些加法符号。如果是一些东西被移除了,你将会看到红色的减号展示。

注意你可以根据你的实际需要,通过组合上面的命令,来进行日志输出。

branch

当开始一个新项目或者打开一个已经存在的项目的时候,我们一开始就要新建一个分支,这是非常重要的。很多人认为master分支是许多工作代码所在的地方的,但是我们在提交的时候要十分小心,因为它就是对产品特性的一种呈现。要开始一个新分支,直接输入git branch,接着是新分支的名字,这就可以创建一个我们后面可以切换的分支,我们想删除一个分支,只需要输入git
branch -d 分支名字即可。现在,如果它没有完全被合并,将为给你一个warning,告诉你把-d替换为-D。注意我们肯定不能够删除正在使用额分支,所以我们需要切换分支。切换分支使用git  checkout  分支名字 



从图中可以看到,任何出现在面板区的工作或者工作目录都跟着转过来了。但是要注意如果我们处于这个活动目录或者面板区的文件被覆盖的话,是无法切换到新分支上面去的。最后一点,你可能看到文件消失又重现,在进行切换分支的时候。不用担心这些文件和它们的改变,它们会待在各自的分支里,直到你合并他们为止,分支是Git和Git流程中的一个关键元素,如果你想更详细的了解branch,请参考这个链接:《Pro
Git》

checkout

让我们来看看checkout除了上面的切换分支,它还能干什么。checkout能够把你项目下的工作树、目录和文件等东西,做一个更加详细的commit,为了做到这个,我们可以使用git checkout 提交引用(40位的十六进制码)。这样我们的工作树就会在commit提交的那个时间点被覆盖了。当我们看到这个状态时,注意我们正处于detached
head状态,这不是一个我们想commit的地方,这只是一种显示我们的工作树、目录和文件看起来是什么样子的方式,一旦你已经了解了detached head状态之后,一定要回去检查你的分支,使用这种方式,你将不会丢失掉任何东西。



git checkout的另外一个用法是撤销或者丢弃编辑的内容。可能,我们有许多文件,但是只有一个是正确的,如果我们想丢掉这些改变,我们可以使用命令:

git checkout -- 文件名

这个可以为我们做到的是它会清理掉最后一次commit的内容。

checkout的最后一个小技巧是可以创建一个分支并且直接切换到这个分支上去。

git checkout -b 新分支名字

merge

分支是每个Git工作流的关键部分,把这些改变汇聚起来也是非常重要的,这个工作可以通过merge来完成。通过merge我们可以把两个或者更多分支的历史汇聚起来,然后再工作树中展示所有这些分支中全部commit的累积结果。对于一个典型的工作流,我们会切换到master分支,然后确认该分支有我们想要合并的commit,使用命令git merge
加上我们想要的commit的分支名字。

在合并过程中可能会遇到冲突的情况,比如你在master分支里修改了一个index文件提交了,然后在另外的分支中也修改了这个index文件,合并的时候就会出现冲突。



可以看到合并时候出现冲突,指出了冲突的文件,使用git status还能发现index.html出现了未合并的路径。打开index.html文件



文件里面已经加入了冲突的标识符号了。我们都知道HEAD指针指向当前分支,所以<<<<<<< HEAD 和=======之间是当前分支修改提交的内容,而=======和>>>>>>>
web-app之间是要合并分支web-app修改提交的内容,即>>>>>>> web-app是冲突结束的标识。

那么我们如何解决冲突呢。很简单,我们只需要自己选择要保留的修改,或者二者修改内容相结合重新修改文件,但是需要把<<<<<<< HEAD之类的冲突标识全部删除,然后把index文件放在暂存区,重新提交即可。

当然还有一种情况是当你合并的时候遇到了冲突,但是你不想马上解决它,或者你目前只想抛弃它,你可以使用git merge --abort命令,这将会从你当前分支的最后一次提交中清除你的工作目录,它同样清除你的暂存区。这里有一个merge的小技巧,如果你不想把历史汇聚起来,即你不想要合并其他分支的日志信息,但是你想要一个具体分支中的全部的commit,简单地运行git
merge --squash 你的目标分支名字,这样将会为你创建一个新的提交在你目前切换到的分支上,这代表了发生在目标分支上的所有改变。最后,当你成功的合并了目标分支之后,如果你不需要它了,请把它移除。

remote

 要参与任何一个Git项目的协作,必须了解该如何管理远程仓库。远程仓库是指托管在网络上的项目仓库,可能会有好多个,其中有些你只能读,另外有些可以写。同他人协作开发某个项目时,需要管理这些远程仓库,以便推送或者拉取数据,分享各自的工作进展。

要查看当前配置有哪些远程仓库,可以用git remote命令,它会列出每个远程库的简短的名字。在克隆完某个项目后,至少可以看到一个名为origin的远程库,Git默认使用这个名字来标识你所克隆的原始仓库。还可以使用git remote -v命令列出所有的远程仓库和它的地址。

要添加一个新的远程仓库,命令格式为:git remote add 仓库名 URL,指定的仓库名应该简单好记,以便将来引用。

从远程数据库抓取数据到本地仓库,使用git fetch命令,如果是克隆了一个远程仓库,此命令会自动将远程仓库归于origin名下,所以git fetch origin会抓取从你上次克隆以来别人上传到此远程仓库中的所有更新。有一点很重要,需要记住,fetch命令只是将远端的数据拉倒本地仓库,并不自动合并到当前工作分支,需要手工合并。如果设置了某个分支专门用于跟踪某个远端仓库的分支,可以使用git
pull命令自动抓取数据下来,然后将远端分支自动合并到本地仓库中当前分支。

推送数据到远程仓库库使用命令:git push 远程仓库名 本地分支名,注意只有在所克隆的服务器上有写权限,或者同一个时刻没有其他人在推数据,这条命令才会如期完成任务。如果在你推数据前,已经有其他人推送了若干更新,那你的推送操作就会被驳回。你必须先把他们的更新抓取到本地,合并到自己的项目中,然后才可以再次推送。

我们可以通过git remote show 远程仓库名来查看某个远程仓库的详细信息。它友善地告诉你如果是在master分支,就可以用git pull命令抓取数据合并到本地。另外还列出了所有处于跟踪状态中的远端分支。

远程仓库重命名使用命令:git remote rename 原有名字 更改名字 注意对远程仓库重命名,也会使对应的分支名称发生变化。

远程仓库移除使用命令:
git remote rm 远程仓库名

tag

Git也提供了给软件打上版本标签的命令,详细请参考链接:[url=https://git-scm.com/book/zh/v1/Git-%E5%9F%BA%E7%A1%80-%E6%89%93%E6%A0%87%E7%AD%BE]《Pro Git》
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签:  Git git命令 git使用