本地版本控制系统
大多数采用某种简单的数据库来记录文件的历次更新差异。
集中化的版本控制系统
为了让不同系统上的人员协同开发工作,集中化的版本控制系统应运而生!
集中化的版本控制系统都有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人都通过客户端连接到该服务器,取出最新的文件或者提交更新。
SVN是集中式版本控制系统,版本库是集中放在中央服务器的,而工作的时候,用的都是自己的电脑,所以首先要从中央服务器得到最新的版本,然后工作,完成工作后,需要把自己做完的活推送到中央服务器。集中版本控制系统是必须联网才能工作,对网络带宽要求较高。
存在风险:
单点故障:中央服务器一旦宕机,则其他人都无法使用,如果中心数据库磁盘损坏又没有进行备份,将会失去所有数据。
必须联网才能工作:受网络状况、带宽的影响。
分布式版本控制系统
为了弥补集中化的版本控制系统缺陷问题,分布式版本控制系统诞生了,Git是一个典型的分布式版本控制系统。
分布式版本控制系统,客户端不仅会提取最新版本的文件快照,而且会将代码仓库完整地镜像下来。这样的优势在于,任何一处协同工作用的服务器发生故障,事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的克隆操作,实际上都是一次对代码仓库的完整备份。
分布式版本控制系统可以不用联网就工作,因为每个人的电脑上都是完整的版本库,当你修改了某个文件后,你只需要将自己的修改推送给别人就可以了。但是,在实际使用分布式版本控制系统的时候,很少会直接进行推送修改,而是使用一台充当"中央服务器"的东西。这个服务器的作用仅仅是用来方便"交换"大家的修改,没有它大家一样干活,只是交换修改不方便而已。
Git采用的是直接记录快照的方式,而非差异比较。
# 方式一:在现有目录中初始化仓库,即进入项目目录运行初始化命令,该命令将创建一个名为 .git 的子目录
git init
# 方式二:从一个服务器克隆一个现有的 Git仓库
git clone [url]
git clone [url] directoryname //自定义本地仓库的名字
# 检查当前文件状态
git status
# 提出更改(把它添加到暂存区域)
git add filename //针对特定文件
git add * //所有文件
git add *.txt //支持通配符,所有.txt 文件
# 忽略文件
.gitignore
# 提交更新
# 每次提交前,先用git status看下,是不是都已暂存起来了,然后再运行提交命令 commit
git commit-m "代码提交信息"
# 跳过使用暂存区域更新的方式
# git commit 加上 -a 选项,Git就会自动把所有已经跟踪过的文件暂存起来一并提交,从而跳过git add 步骤
git commit -a -m "代码提交信息"
# 移除文件
git rm filename //从暂存区域移除,然后提交
# 对文件重命名
git mv README.md README //这个命令相当于mv README.md README、git rm README.md、git add README 这三条命令的集合
提交的标题行应该尽量清晰简洁,方便Git 日志查看工具显示和其他人的阅读
# 如果还没有克隆现有仓库,并欲将你的仓库连接到某个远程服务器
git remote add origin serverUrl
git remote add origin https://ip.com/xxx/xx.git
# 将改动提交到远程仓库
git push origin master //可以把master换成你想要推送的任何分支
# 将test重命名为test1
git remote rename test test1
# 移除远程仓库 test1
git remote rm test1
# 在提交了若干更新,又或者克隆了某个项目之后,若想回顾下提交历史。
git log //会按提交时间列出所有的更新,最近的更新排在最上面
git log --author=bob //只看某个人的提交记录
# 若提交之后发现漏掉了几个文件没有添加,或者提交信息写错了。此时,可以运行带有--amend选项命令重新提交
git commit --amend
git reset filename
git checkout --filename
git fetch origin
git reset --hard origin/master
分支是用来将特性开发绝缘开来的。在你创建仓库的时候,master 是“默认”的分支。在其他分支上进行开发,完成后再将它们合并到主分支上。
我们通常在开发新功能、修复一个紧急 bug 等等时候会选择创建分支。单分支开发好还是多分支开发好,还是要看具体场景来说。
# 创建一个名字叫做 test 的分支
git branch test
# 切换当前分支到 test(当你切换分支的时候,Git 会重置你的工作目录,使其看起来像回到了你在那个分支上最后一次提交的样子。 Git 会自动添加、删除、修改文件以确保此时你的工作目录和这个分支最后一次提交时的样子一模一样)
git checkout test
# 直接这样创建分支并切换过去
git checkout -b test
# 切换到主分支
git checkout master
# 合并分支(可能会有冲突)
git merge test
# 把新建的分支删掉
git branch -d test
# 强制删除本地分支
git branch -D 分支名
# 删除远程分支
git push origin --delete 分支名
# 将分支推送到远端仓库(推送成功后其他人可见)
git push o
To https://gitee.com/Mandy_wang/mandy_wang.git
! [rejected] dev -> dev (non-fast-forward)
error: failed to push some refs to 'https://gitee.com/Mandy_wang/mandy_wang.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
问题:
错误提示如上,本地项目向远程推送时,提示远程 non-fast-forward,即时本地比远程领先,推送前必须先合并,Git 也给出提示了,要我们先 git pull
解决方案:
$ git pull origin dev
执行 pull 操作时,如果出现下面这个错误
fatal: refusing to merge unrelated histories
是由于本地仓库和远程仓库有不同的开始点,也就是两个仓库没有共同的 commit 点而出现的无法提交。这里我们需要用到 --allow-unrelated-histories,也就是我们的 pull 命令改为下面这样的:
$ git pull --allow-unrelated-histories
执行该操作,如果出现下面这个错误
There is no tracking information for the current branch.
这是因为没有指定本地分支与远程分支的关联,可以使用
$ git pull origin dev
# 如果希望一劳永逸,可以使用
$ git branch --set-upstream-to=origin/dev
若遇到pull命令报下面的错
fix conflicts and then commit the result
解决方案:
pull 操作会自动进行合并,但产生了冲突。一般会有提示是哪个文件产生冲突,找到对应的文件进行修改,再提交一次就行了
git clone 和 fork 的区别
Git与SVN最主要区别