流程
一般顺序为在本地建立代码仓库,然后git init
初始化生成一个.git
文件作为本地仓库版本控制。
通过git clone XXXX(地址)
克隆远端仓库代码到本地,进行开发。(此处省略clone前的ssh配置步骤)
当本地写好代码需要提交到远端仓库时,首先通过git add .
将代码加入暂存区,再通过git commit -m “xx”
对代码版本进行说明备注,最后通过git push -u origin master
将暂存区提交代码提交到远端仓库。
问题
-
冲突
-
解决办法
提交出现冲突时,需要先fetch获取,手动修改冲突,之后强制pull,再add,commit,就可。
-
原因分析
如描述,A和B合作完成某项目,A先向master提交,之后B提交。但是B这边需要先fetch下来看看A在哪里改动了,是否和自己写的冲突,手动对代码进行修改,然后再pull,这里需要说明的是pull是拉取下来直接合并,所以矛盾点在这里。
-
本质
对pull这个行为的理解不到位。
-
-
版本控制
-
问题(错例)
如果要实现本地和远端协同,把远端的直接clone到本地,在本地进行更改再提交远端?
-
正解(远程库关联)
现在本地建一个文件夹,并git init,作为本地仓库,而此文件夹中通过git init生成的.git文件,就是本地仓库的版本控制器。
-
用法
用git log --graph
命令可以看到分支合并图。
创建并切换到新的dev
分支,可以使用:$ git switch -c dev
合并完成后,删除dev
分支:$ git branch -d dev
新建标签: git tag <name>
分支和master合并: git merge XX(分支名)
补充
-
远程库的名字就是
origin
,这是Git默认的叫法 -
Git用
<<<<<<<
,=======
,>>>>>>>
标记出不同分支的内容 -
关于冲突的一些碎碎念:一篇作文,你改开头,他改结尾,一合并,满分。你改开头,他也改开头,那叫冲突,因为不知道怎么合。在Git中,由于分支是如此的强大,所以,每个bug都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除。
-
关于rebase:
rebase: 使Git的提交历史成为一条干净的直线
-
rebase操作可以把本地未push的分叉提交历史整理成直线;
-
rebase的目的是使得我们在查看历史提交的变化时更容易,因为分叉的提交需要三方对比。
-
-
图形界面管理工具 sourcetree,界面的每个操作对应了git的不同命令。