首先在本地电脑新建HelloWorld文件夹,然后打开Git Bash,经过git init
命令把这个目录变成Git能够管理的仓库:git
然后编辑HelloWorld.c文件github
a. 设置用户名和邮箱分布式
b. 将HelloWorld.c添加至暂存区,再提交到本地仓库fetch
c 查看状态、日志spa
git log显示从最近到最远的提交日志,其中commit id为版本号,可以使用git reset --hard commit id实现版本回退3d
创建远程仓库指针
生成SSH KEY日志
这里要特别注意的是其中邮箱是你github帐号注册的邮箱,要否则没法将本地仓库和本地仓库关联起来,出现相似下图的错误code
在github上添加SSH KEYblog
这时咱们查看github上的对应仓库,会发现已然同步。
因为远程库是空的,于是第一次推送master
分支时,加上了-u
参数,Git不但会把本地的master
分支内容推送的远程新的master
分支,还会把本地的master
分支和远程的master
分支关联起来,在之后的推送或者拉取时就能够简化命令。
为了便于比较fetch和pull的区别,首先将本地的工做空间中HelloWorld.c文件修改以下并提交至本地仓库
经过git log可查看具体提交状况
这里git branch -a是显示全部分支状况(可看出目前分支位于master),而git branch -r是只显示远程分支
下图中使用git diff命令查看不一样分支的状况,二者有差别,说明git fetch不会自动merge,那么我想merge该如何呢?
使用git merge命令,即合并分支,按照预想的应该是两分支有冲突,合并的时候会出现错误,而后得先解决冲突才能合并,可会出现下面的状况
what???ㄟ(▔︹▔ㄟ) (╯▔︹▔)╯
Already up-to-date 说明已经合并了啊,但是切换到对应的分支,分别查看HelloWorld.c的内容仍然是不同,这是为何呢?
这里推荐一个gitk的命令,它可将分支状况很好的可视化以及历史信息显示出来,
举一个例子来更好地说明这种状况,假设在branch1分支上提交历史以下
而后创建一个新的分支branch2,继续提交四次:
此时branch1的头指针指向D,branch2的头指针指向H。"Already up-to-date"说明你想要合并的分支已然成为你如今分支的parent,这里D即是H的parent
那么将branch1分支合并到branch2是无论用的,由于branch2并无发生改变,要想合并就须要将branch1的指针提交历史变成
即便用git reset --hard H强制变成branch1分支的指针指向H
回到问题中,remotes/origin/master显然是master的parent,所以没法将其合并到master分支中。
下图中git fetch origin master:temp 这句命令的意思是:将远程origin仓库的master分支下载到本地并新建一个分支temp
显然这种状况是能够将master分支合并到temp分支上
git pull <远程主机名> <远程分支名>:<本地分支名>
好比,取回origin主机的master分支,与本地的master分支合并,须要写成下面这样。
git pull origin master:master
若是远程分支是与当前分支合并,则冒号后面的部分能够省略。
git pull origin master
上面命令表示,取回origin/master分支,再与当前分支合并。实质上,这等同于先作git fetch,再作git merge。
新建test.txt文件
git merge
git pull
整个过程当中咱们能够看出git做为分布式系统的强大之处,而远程仓库和本地仓库既相互独立而又紧密相连,分支的存在使得工做可以分工而有条理地进行。由上咱们也能够得知,"git fetch"命令执行完毕以后,还不会当即将下载的文件合并到当前工做目录里,要是想将从远程分支下载的文件更新到工做目录里,须要执行一个合并("git merge")操做。"git pull"的问题是它把过程的细节都隐藏了起来而是自动合并,这样致使本地工做目录在未经确认的状况下就会被远程分支更新,一旦代码有问题,很难找到错误的地方,于是建议使用git fetch+git merge。