官方话:
是一个免费的开源分布式版本控制系统,旨在快速高效地处理从小型到大型项目的所有事务。
引用廖雪峰老师的话,它能自动帮我记录每次文件的改动,还可以让同事协作编辑,这样就不用自己管理一堆类似的文件了,也不需要把文件传来传去。如果想查看某次改动,只需要在软件里瞄一眼就可以。
直接在官网上去下载。下载完成后,随便在某个文件下右键如果有git bash here就安装成功。安装后,还要在命令行输入
$git config --global ur.name "你的名字"$git config --global ur.email "你的邮箱"
global表示全局,这台机器所有的git仓库都会使用这个配置。允许单个仓库使用其他的名字和邮箱。
mac也可以像windows一样,按上面的步骤安装。
也可以直接从appstore安装xcode,xcode集成了git,不过默认没有安装,你需要运行xcode,选择菜单“xcode”->“preferences”,在弹出窗口中找到“downloads”,选择“command line tools”,点“install”就可以完成安装了。
图片
本地仓库是对于远程仓库而言的。本地仓库 = 工作区 + 版本区。
工作区即磁盘上的文件集合。版本区(版本库)即.git文件。版本库 = 暂存区(stage) + 分支(master) + 指针head。以我使用最频繁的git命令为例,即提交到github为例。
git init 原本本地仓库只包含着南极大冒险的狗工作区,这是最常见的工作状态。此时,git init一下,表示在本地区域创建了一个.git文件,版本区建立。git add . 表示把工作区的所有文件全部提交到版本区里面的暂存区当然你也可以通过 git add ./xxx/ 一条一条分批添加到暂存区。git commit -m “xxx” 把暂存区的所有文件提交到仓库区,暂存区空空荡荡。git remote add origin https://github.com/name/name_cangku.git 把本地仓库与远程仓库连接起来。git push -u origin master 把仓库区的文件提交到远程仓库里。一旦提交后,如果你又没有对工作区做任何修改,那么工作区就是“干净”的。会有这样的信息nothing to commit, working tree clean以前不熟悉git命令的时候,我提交项目到github上都是直接在网页上直接拉取文件提交上去的。有点羞耻。
图片
git init .初始化,表示把这个文件变成git可以管理的仓库。初始化后打开隐藏的文件可以看到有一个.git文件。git add . 后面的一个点表示把这个文件全部提交到暂存区。git add ./readme.md/ 表示把这个文件下面的readme.md文件提交到暂存区。git commit -m “你要评论一点什么东西” git commit的意思是把暂存区的全部文件提交到本地仓库。-m后接评论。git remote add origin https://github.com/name/name_cangku.git表示把你本地的仓库与github上的远程仓库连接起来。只需要连接一次,以后提交的时候就可以不用谢这条命令了。name是你的github名字,name_cangku是你的仓库名。注意不要把后面的.git给漏掉了。因为我前面就是这么走过来的,绕了很多弯路。至于如何在github上新建仓库,网上有很多教程,这里不再赘述了。git push -u origin master 把本地仓库提交到远程仓库。(最后一步)在你的远程仓库上刷新一下就可以看到你提交的文件了。最后提到的是,在git commit -m “”之前,可以重复git add到暂存区。但是git commit会把你之前存放在暂存区的全部文件一次性全部提交到本地仓库。提交一个文件,有时候我们会提交很多次,在提交历史中,这样就产生了不同的版本。每次提交,git会把他们串成一江苏高考难度条时间线。如何回溯到我们提交的上一个版本,用git ret –hard + 版本号即可。版本号可以用git log来查看,每一次的版本都会产生不一样的版本号。
回溯之后,git log查看一下发现离我们最近的那个版本已经不见了。但是我还想要前进到最近的版本应该如何?只要git ret –hard + 版本号就行。退一步来讲,虽然我们可以通过git ret –hard + 版本号,靠记住版本号来可以在不同的版本之间来回穿梭。
但是,有时候把版本号弄丢了怎么办?git reflog帮你记录了每一次的命令,这样就可以找到版本号了,这样你又可以通过git ret来版本穿梭了。
场景1: 在工作区时,你修改了一个东西,你想撤销修改,git checkout — file。廖雪峰老师指出撤销修改就回到和版本库一模一样的状态,即用版本库里的版本替换工作区的版本。
场景2: 你修改了一个内容,并且已经git add到暂存区了。想撤销怎国际象棋游戏规则么办?回溯版本,git ret –hard + 版本号,再git checkout — file,替换工作区的版本。
场景3: 你修改了一个内容,并且已经git commit到了master。跟场景2一样,版本回溯,再进行撤销。
如果你git add一个文件到暂存区,然后在工作区又把文件删除了,git会知道你删除了文件。如果你要把版本库里的文件删除,git rm 并且git commit -m “xxx”.
如果你误删了工作区的文件,怎么办?使用撤销命令,git checkout –就可以。这再次证明了撤销命令其实就是用版本库里的版本替换工作区的版本,无论工作区是修改还是删除,都可以“一键还原”。
分支,就像平行宇宙,廖雪峰老师如是说。你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作。
图片
在没有其他分支插进来时,只有一个master主分支。每次你git push -u origin master 提交就是增加一条时间轴,master也会跟着移动。
图片
创建一个other的分支,通过other提交,虽然时间轴向前走了,但是主分支master还在原来的位置。
图片
理论分析完,看一下命令怎么写。
创建分支other,切换到other分支。
git branch othergit checkout other
查看当前所有分支
git branch
* other master
当前的分支会有一个*
用other提交
git add ./xxx/git commit -m "xxx"
other分支完成,切换回master
git checkout master
此时,master分支上并没有other的文件,因为分支还没有合并。
合并分支
git merge other
合并完成之后,就可以在master分支上查看到文件了。
删除other分支
git branch -d other
我由此想到,在以后工作中,应该是一个开放小组共同开发一个项目,组长会创建很多分支,每一个分支可以交给一个人去开发某一个功能,一个小组共同开发而且不会相互干扰。谁的功能完成了,可以由组长合并一下完成了的分支。哦,完美!
图片
假如有这样一种情况,分支other已经commit了,但是此时指针指回master时,并且master没有合并,而是git add / commit 提交了。这样,就产生了冲突,主分支master文件内容与other分支的内容不一样。合并不起来!所以,
修改文件的内容,让其保持一致。git add git commit 提交。分支合并了。图片git log –graph 查看分支合并图git branch -d other 删除分支,任务结束。git merge –no-ff other 禁用fast forward模式,因为使用fast forward模式,删除分支后,分支历史信息会丢失。
廖雪峰老师提到,工作中每个bug都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除。但如果你手上有分支在工作中,你的上级要你改另外的分支的bug。
你要把现在正在工作的分支保存下来,git stash,把当前工作现场“存储”起来,等以后恢复后继续工作。当你解决bug后,git checkout other回到自己的分支。用git stash list查看你刚刚“存放”起来的工作去哪里了。
此时你要恢复工作:
git stash apply恢复却不删除stash内容,git stash drop删除stash内容。git stash pop恢复的同时把stash内容也删了.此时,用git stash list查看,看不到任何stash 内容。总结:修复bug时,我们会通过创建新的bug分支进行修复,然后合并,最后删除;当手头工作没有完成时,先把工作现场git stash一下,然后去修复bug,修复后,再git stash pop,回到工作现场
图片
产生上图的冲突时,
git pull 把最新的提交从远程仓库中抓取下来,在本地合并,解决冲突。在进行git pull如果git pull 也失败了,还要指定分支之间的链接,这一步git会提醒你怎么做。然后再git pull。廖雪峰老师的总结:多人协作的工作模式通常是这样:
首先,可以试图用git push origin推送自己的修改;如果推送失败,则因为远程分支比你的本地更新,需要先用git pull试图合并;如果合并有冲突,则解决冲突,并在本地提交;没有冲突或者解决掉冲突后,再用git push origin推送南昌高中就能成功!如果git pull提示no tracking information,则说明本地分支和远程分支的链接关系没有创建,用命令git branch –t-upstream-to origin/。git reba 把分叉的提交历史“整理”成一条直线,看上去更直观.缺点是本地的分叉提交已经被修改过了。
最后在进行git push -u origin master
reba的目的是使得我们在查看历史提交的变化时更容易,因为分叉的提交需要三方对比。
比如一个app要上线,通常在版本库中打一个标签(tag),这样,就确定了打标签的版本。将来无论什么时候,取某个标签的版本,就是把那个打标签的时刻的历史版本取出来。所以,标签也是版本库的一个快照。
git的标签虽然是版本库的快照,但其实它就是指向某个commit的指针。
tag其实就是一个让人容易记住的有意义的名字,它跟某个commit绑在一起。比如tag v2.1就是把历史上的一个版本的东西叫做v2.1
步骤:
git branch查看当前分支,git checkout master切换到master分支。git tag打标签,默认为head。比如git tag v1.0默认标签是打在最新提交的commit上的。如果想要打标签在以前的commit上,要git log找到历史提交的commit id.如果一个commt id是du2n2d9,执行git tag v1.0 du2n2d9就把这个版本打上了v1.0的标签了。git tag 查看所有标签,可以知道历史版本的tag标签不是按时间顺序列出,而是按字母排序的。git show查看标签信息。git tag -a <标签名> -m “<说明>”,创建带说明的标签。-a指定标签名,-m指定说明文字。用show可以查看说明。强制提交已忽略的的文件。git add -fgit check-ignore -v检查为什么git会忽略该文件。给git命令配别名,这个有点骚,就是你以后想输入git reba时,你给它一个“外号”,就叫它git nb。以后你可以通过git nb来代替git reba。忽略文件原则:忽略操作系统自动生成的文件,比如缩略图等;忽略编译生成的中间文件、可执行文件等,也就是如果一个文件是通过另一个文件自动生成的,那自动生成的文件就没必要放进版本库,比如java编译产生的.class文件;忽略你自己的带有敏感信息的配置文件,比如存放口令的配置文件。
本文发布于:2023-04-05 11:25:47,感谢您对本站的认可!
本文链接:https://www.wtabcd.cn/fanwen/zuowen/2d265299e844e2536d761ab7612bb483.html
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。
本文word下载地址:git用法教程图文详解(git fetch和git pull的区别).doc
本文 PDF 下载地址:git用法教程图文详解(git fetch和git pull的区别).pdf
留言与评论(共有 0 条评论) |