代码管理的git--非常常用命令
这里不说很多git是什么之类的,只说工作中会使用到的场景。
创建新项目
服务器端创建项目
服务端使用 git init –bare sample.git
客户端就可以通过git clone git@127.0.0.1:sample.git 克隆仓库
客户端创建项目
项目的创建也可以是在客户端创建(前提是当前用户有创建权限)
假设需要将本地sample文件夹创建为项目仓库,进入sample文件夹,执行
## 初始化
git init
## 添加远程地址
git remote add origin git@127.0.0.1:sample.git
## 添加文件
git add README.md
## 添加第一个commit
git commit -m 'init'
## push到远程
#第一次push,使用push -u origin master
git push -u origin master
项目拉取
普通拉取
一般项目拉取使用git clone git@127.0.0.1:sample.git
shallow 拉取
如果项目比较大拉取过程可能出现Out of memory, malloc failed
这个时候就需要一点一点的拉取项目了。
git clone depth=1 git@127.0.0.1:sample.git
使用depth=1限制记录数目。可以大一点,但是不能太大,否则还是会出现上述错误。
使用depth的方式拉取下来的项目只有有限个记录,而且不包含其他分支信息。
对于初始项目如下图
使用depth=1克隆项目之后
可以发现,这样clone之后的历史记录只有一条,而且没有其他分支。那么当depth加大的时候呢?除了clone,fetch,pull都可以使用depth参数。
这里把depth设置成5,获取到分支dev创建之前的记录,看dev是否会出来。
即使depth等于5,也依然没有其他分支(branch -a 都不会显示)。
也可以通过git clone --depth 1 --no-single-branch git@127.0.0.1/sample.git
直接获取多个分支
shallow 拉取如何获取其他分支呢?
1) 指定远程分支拉取
git remote set-branches 'dev'
git fetch --depth=1 origin dev
上面这样其实是设置了远程分支名称。但是这这样会破坏master 和origin/master的关联。
使用branch -vv
可以看到本地分支和远程分支的关联关系。
如果本地分支没有和远程分支关联,可以使git branch --set-upstream-to=origin/dev
关联远程分支。如果提示
fatal: Cannot setup tracking information; starting point 'origin/dev' is not a branch.
则说明使用的是git remote set-branches 'dev'
覆盖了远程分支信息。
可以使用git remote set-branches --add origin dev
重新添加远程分支信息
所以获取远程分支应该使用的方式是
git remote set-branches --add origin dev
git fetch --depth=1 origin dev
2) 使用git fetch –unshallow ,获取所有没有检下来的内容。只有在剩余内容比较少的时候才能使用,否则还会出现Out of memory, malloc failed
错误
两种方案可以配合使用。先使用depth一点一点的把项目历史记录拉取下来。待剩余历史记录不多的时候再使用git fetch --unshallow
拉取
提交代码
## 添加变更文件,
## --all,所有的;
## 使用-p参数手动添加变更内容;
## 或指定文件添加单个文件
git add --all
## 添加commit说明
git commit -m 'commit message'
## 更新远程代码
git pull
## 将更新内容推送到服务器
## 这样其他协作者就能看到了
git push
git add -p
会以区块显示文件变更,开发者自己决定是否把变更内容添加到本次提交中。
如果觉得生成的区块粒度太大了,想要更细一些的,可以在git add -p之后的选项中输入s
会将该区块更细的划分,从而达到添加行变更的目的。
更新代码
1) git pull,git pull 执行的内容包括拉取远程的更新内容,同时将远程更新内容与本地文件进行合并。合并之后,本地工作区的内容也会立即发生变化。
2)git fetch,执行内容是拉取远程更新内容。此时本地工作区间文件还未改变。然后再自己执行git merge 手动合并更新
合并冲突
merge 或者pull之后,如果协作人员直接没有冲突地方,会直接合并。如果有冲突,需要合并才能push。
冲突文件,git会以以下的形式标记冲突双方的修改。其中<<<HEAD...===
内容是自己的修改,==..>>>
内容是他人的修改。
<<<<<<< HEAD
qww
=======
555
>>>>>>> bb2f6e59
当文件的这些标记符被删除之后,命令行认为该文件的冲突以及被处理了。
合并除了手动合并文件之外,还可以在合并之前指定保存哪一放的修改
以他人修改为准
git merge --strategy-option theirs
以本地修改为准
git merge --strategy-option ours
pull 的时候指定保留他人
git pull -X theirs
基本上日常开发常用的是这些,为避免篇幅太长,各种需求变更的场景放在下一篇。
评论