git 三大区
工作区(写代码的地方) > 暂存区(临时存储,可以撤销) > 本地库(可以存储历史版本)
git add . 添加到暂存区 git commit -m "" 提交到本地库
分布式以及集中式?
版本控制工具功能
-
协同开发 :多人并行不悖(bei - 相反-违背-错误)的修改服务器端的同一个文件
-
数据备份:不仅保存目录和文件的当前状态,还能保持每一个提交的历史扎状态
-
版本管理:在保存每一个版本的文件信息的时候,要做到不重复数据,已节约存储空间,提高开发效率,svn增量式管理,git 文件系统快照方式
-
权限控制:对参与开发人员尽行控制,对外贡献代码者尽行审核 git 会进行审核,而 svn 没有 (git独有)
-
历史记录: 查看修改人、日志信息、修改内容、修改时间
-
分支管理 : 允许团队开发在工作中多条生产同事推进任务,提高开发效率
版本控制工具有哪些
-
集中式版本管理工具 cvs svn vss
-
分布式版本及控制工具 git Mercurial Bazaar Darcs
Git是分布式的,SVN是集中式的
SVN 集中式版本管理工具就是多人开发通过一个服务器来尽行操作,如果服务器宕机了那么历史信息,代码都会丢失
这是 Git 和 SVN 最大的区别。若能掌握这个概念,两者区别基本搞懂大半。因为 Git 是分布式的,所以 Git 支持离线工作,在本地可以进行很多操作,包括接下来将要重磅推出的分支功能。而 SVN 必须联网才能正常工作。
差异对比表
差异 | svn | git |
---|---|---|
系统特点 | 1.集中式版本控制系统(文档管理很方便) 2.企业内部并行集中开发 3.windows系统上开发推荐使用 4.克隆一个拥有将近一万个提交(commit),五个分支,每个分支有大约1500个文件,用时将近一个小时 | 1.分布式系统(代码管理很方便) 2.开源项目开发 3.mac,Linux系统上开发推荐使用 4.克隆一个拥有将近一万个提交(commit),五个分支,每个分支有大约1500个文件,用时1分钟 |
灵活性 | 1.搭载svn的服务器出现故障,无法与之交互 2.所有的svn操作都需要中央仓库交互(例:拉分支,看日志等) | 1.可以单机操作,git服务器故障也可以在本地git仓库工作 2.除了push和pull(或fetch)操作,其他都可以在本地操作 3.根据自己开发任务任意在本地创建分支 4.日志都是在本地查看,效率较高 |
安全性 | 较差,定期备份,并且是整个svn都得备份 | 较高,每个开发者的本地就是一套完整版本库,记录着版本库的所有信息(gitlab集成了备份功能) |
分支方面 | 1.拉分支更像是copy一个路径 2.可针对任何子目录进行branch 3.拉分支的时间较慢,因为拉分支相当于copy 4.创建完分支后,影响全部成员,每个人都会拥有这个分支 5.多分支并行开发较重(工作较多而且繁琐) | 1.我可以在Git的任意一个提交点(commit point)开启分支!(git checkout -b newbranch HashId) 2.拉分支时间较快,因为拉分支只是创建文件的指针和HEAD 3.自己本地创建的分支不会影响其他人 4.比较适合多分支并行开发 5.git checkout hash值(切回之前的版本,无需版本回退) 6.强大的cherry-pick |
版本控制 | 1.保存前后变化的差异数据,作为版本控制 2.版本号进行控制,每次操作都会产生一个高版本号(svn的全局版本号,这是svn一个较大的特点,git是hash值) | 1.git只关心文件数据的整体发生变化,更像是把文件做快照,文件没有改变时,分支只想这个文件的指针不会改变,文件发生改变,指针指向新版本 2. 40 位长的哈希值作为版本号,没有先后之分 3.git rebase操作可以更好的保持提交记录的整洁 |
工作流程 | 1.每次更改文件之前都得update操作,有的时候修改过程中这个文件有更新,commit不会成功 2.有冲突,会打断提交动作(冲突解决是一个提交速度的竞赛:手快者,先提交,平安无事;手慢者,后提交,可能遇到麻烦的冲突解决。) | 1.开始工作前进行fetch操作,完成开发工作后push操作,有冲突解决冲突 2.git的提交过程不会被打断,有冲突会标记冲突文件 3.gitflow流程(经典) |
内容管理 | svn对中文支持好,操作简单,适用于大众 | 对程序的源代码管理方便,代码库占用的空间少,易于分支化管理 |
学习成本 | 使用起来更方便,svn对中文支持好,操作简单,适用于大众 | 更在乎效率而不是易用性,成本较高(有很多独有的命令,rebase,远程仓库交互的命令,等等) |
权限管理 | svn的权限管理相当严格,可以按组、个人针对某个子目录的权限控制(每个目录下都会有个.svn的隐藏文件) | git没有严格的权限管理控制,只有账号角色划分(在项目的home文件下有且只有一个.svn目录) |
管理平台 | SVNBucket SVNBucket - 免费 SVN 代码托管服务器,不限私有,不限成员 | gitlab(建议使用,集成的功能较多,API开发),gerrit,github等 |
svn git 优缺点
SVN对中文支持好,操作简单,使用没有难度,美工人员,产品人员,测试人员,实施人员都可轻松上手。使用界面统一,功能完善,操作方便。
git对程序源代码进行差异化的版本管理,代码库占极少的空间。易于代码的分支化管理。不支持中文,图形界面支持差,使用难度大。不易推广。
分布式代码版本管理系统并不一定适合所有团队,比如中小团队可能更关心的只是成本更低,简单易用,那么SVN等这类集中式版本管理工具还是更为适合。但是不管团队最终选用什么代码版本管理工具,只要适合自己的团队的开发流程和工作方式,并且代码管理顺畅就可以了。
git命令总结
查看全局安装的包
npm list -g --depth=0
列出当前文件
ll
列出带隐藏资源的文件
ls -lA
初始本地仓库
git init
查看当前在什么位置
pwd
返回上一级文件
cd ..
设置签名
新的git 需要设置邮箱和账户密码 ,因每次提交代码都会弹出一个,请输入账号和密码所以要配置公钥。
-
创建一个文件
vim good.txt
- 形式 name 用户名 token email 邮箱地址 作用: 用于区分不同开发人员的身份 - 项目级别/仓库级别:尽在当前本地仓库有效
git config user.name 账户
git config user.email 邮箱
-
查看设置好了吗
cat .git/config
-
系统用户级别:登录当前操作系统的用户范围
git config --global user.name sunzhihao
git config --global user.email 1036786540@qq.com
-
查看设置好了吗
cd ~
ls -lA|less [ 查看文件查看隐藏文件 ]
cat .gitconfig [ 读区改文件信息 ]
-
优先级 :如果没设置签名则是系统用户级别 ,但是设置项目级别就优系统用户级别 二者都没有是不允许的
-
新的电脑要配置公钥SSH
为什么要设置这玩意:新的git 需要设置邮箱和账户密码 ,因每次提交代码都会弹出一个,请输入账号和密码所以要配置公钥。 你的本地邮箱必须和你绑定gitee的邮箱一致否则不会算作为提交记录。怎么配置呢下面有教程。
1、安装git --> 鼠标右键 --> Git Bash Here -->进入命令窗口
命令一:查看git配置 git config --list
命令二:重新全局配置git用户名和邮箱和密码
git config --global user.name"用户名"
git config --global user.password"密码"
git config --global user.email"邮箱"命令三:生成ssh 公钥
ssh-keygen -t rsa -C"邮箱" 出现问题,直接enter就行了命令四:查看公钥,并复制
cat ~/.ssh/id_rsa.pub操作五:配置公钥
登录码云gitee --> 点击头像 --> 设置 --> 点击左导航栏“ssh公钥” --> 粘贴到右边“公钥”的大方框中 --> 填写标题 --> 确定 ---> 输入密码
那如果我想更改邮箱了怎么办呢?
单独查看用户或邮箱信息
$ git config user.name
$ git config user.emailgit config --global --unset user.email "初始化邮箱" // 这个一般初始化的用的
git config user.email "要修改的邮箱" // 如果修改这个命令可以git config --global user.name "Your Name" // 可以试试这个
git config --global user.email you@example.com
追踪文件列表
将 ‘新建 / 修改’ 添加到暂存区(添加操作就是你要操作哪个文件)
git add . 或 git add -A 或 git add [ 文件名字 ]
暂存区删除
把你这个文件村暂存区里删除,不是直接删掉文件 - 你可以后悔
git rm --cached [ 文件名字 ]
查看文件的状态
git status [ 查看工作区,和暂存区的工作状态 ]
提交到暂存区
git commit -m "这里写的是本次需求新增了什么功能" file.txt [ 提交到本地库]
查看提交的历史记录
git log
多屏显示控制 : 空格向下翻页 b 向上翻页 q 退出
历史记录一行显示 若果日志太多屏幕放不下
git log --pretty=oneline
输出历史记录但是hash直选中其中一部分 (一行显示)
git log --oneline
显示到哪个版本需要移动几步
git reflog
HEAD@{移动到当前版本去要第几步}
回退任意版本信息
git reset --hard 35851ba [ 35851ba 索引值 ]
reset 命令的三个参数 :
--soft 仅仅在本地库移动 HEAD 指针
--mixed 在本地库移动head 指针 重置暂存区
--hard 在本地库移动head 指针 重置暂存区 重置工作存区
回退上一版本
git reset --hard HEAD^ [ 回退到上一个版本 ]
git reset --hard HEAD^^ [ 回退到上二个版本 (以此类推)]
git reset --hard HEAD~2 [ 回退到上二个版本 (以此类推)]
删除文件恢复文件
rm file.txt
恢复回退版本即可
前提 删除前,文件存在的状态提交到了本地库
git reset --hard 35851ba [ 删除操作已经提交到本地库 35851ba指针位置 ]
git reset --hard HEAD [ 删除操作尚未提交到本地库 ]
比较内容的差异 (将工作区的文件内容与本地历史记录里的内容比较差异 )
不带指定文件名比较多个
git diff 练习git.txt [练习git.txt文件名字]
git强制推送push(慎用)
git push -f origin master
如何删除git暂存区的文件
git rm -r --cached 文件名
-
使用reset命令 回退到最近一次push后的状态并清空暂存区,但是工作区修改的内容也会被回退
git reset HEAD 文件名
清除缓存
npm cache clean -f
查看全局安装的包
npm list -g --depth=0
删除node-modules包
npm i -g npkill
删除
npkill
全局安装 npm i -g npkill
进入想清理的文件夹 cd 文件路径
输入npkill 会自动查找该文件中node-models
光标上下移动来选择要清理的目录,释放宝贵的空间
按空格删除
git 分支
初始化之后是有一个master 主分支 (骨干)
-u
如果当前分支与多个主机存在追踪关系,则可以使用-u选项指定一个默认主机,这样后面就可以不加任何参数使用git push。 git push -u origin master
分支的好处
- 同时并行推进多个功能开发。提高开发效率。 - 各个分支在开发过程中。如果某一个分支开发失败,不会对其他分支有任何影响。失败的分支删除,重新开始即可。
创建分支
git branch hot_fix - hot_fix [ hot_fix 分支名字]
删除分支
git branch -d [分支名字]
查看分支
git branch -v
切换分支
git checkout hot_fix [ hot_fix 分支名字]
新建一个本地分支并切换
git checkout -b dbg_lichen_star [dbg_lichen_star 分支名字]
合并分支
切换到要合并的分支上面 git merge 进行合并
git checkout hot_fix [ hot_fix 分支名字]
git merge hot_fix [ hot_fix 分支名字]
选择提交代码版本进行合并
1、应用场景:
在A分支上提交了一个commit,B分支也同样需要这个commit的代码,为了避免人工复制代码,可以用git的一些操作替代
2、操作步骤
1、在当前A分支(deploy/t),通过git log先找到A分支的commit代号(简略ID-29d9493d-前8位数),
2、执行以下命令 ,切换到B分支(deploy/pre),通过git cherry-pick + 简略ID,进行合并指定的commit提交记录
git log //查看提交的日志,复制要合并的那个分支的commit id(简略ID-前8位数)
git checkout 要合并的分支 // 切换到要合并的分支上
git cherry-pick 上面复制的那个要合并的commit id // 提交该commit到当前分支
git push // 推送到B分支远程仓库
首先要检出B分支的代码,再通过git的
cherry-pick命令合并,29d9493d为在A分支上commit的代号
分支冲突
只要你的代码和我的代码在同一行修改了,我们合并分就会冲突,他会显示自动合并失败,然我们解决分支,然后找到对应的文件夹,里面的内容会用 大于号小于号等号分割开来,找到修改代码的人,我们要商量好,就决定要用哪个代码。把多余的代码删除即可。再去执行 git add . 即可 ,再去用 git commit -m "结束合并" 不能带文件名字 结局完毕。
git add .
git commit -m "日志信息" [不能带文件名字]
其中=======的上半部分对应的是master分支内容 (当前分支的代码 上半部分 **HEAD** 是当前所在分支的代码)(HEAD指向当前分支,因为合并命令是在master分支中执行的),下
半部分对应的是hotfix分支内容,现在就可以选择任何一个版本或者合并两个版本作为最终版本来解决冲突了。例如内容变为:其中=======的下半部分对应的是master分支内容 (要合并分支的代码 下半部分是别人提交的代码)
一般保留下半部分
补充:
-
如果不是基于GitHub,远程库的最新版。所做的修改。不能推送,必须先拉取
-
拉下来后,如果进入冲突状态。则按照分支。是冲突解决操作即可。
git hash 算法
hash是一个系列的加密算法。各个不同的哈希算法虽然加密强度不同。但是有以下几个共同点。
-
不管输入数据量有多大。输入同一个哈希算法,得到加密结果长度固定。
-
哈希算法确定。输入数据确定。输出数据能够保证不变。
-
哈希算法确定输入数据有变化,输出数据一定有变化,而且通常变化很大。
-
哈希算法不可逆。
git底层的是sha-1算法。git hash 指的就是哪个数字和英文的结合相当于 一个 id
线上分支
在线上添加创建一个分支
git push origin dbg_lichen_star
分支克隆
git clone -b 分支名字 远程地址
删除线上分支
删除远程分支:git push origin --delete dbg_lichen_star (dbg_lichen_star分支名)我比较喜欢的简单方式,推送一个空分支到远程分支,其实就相当于删除远程分支: git push origin :dbg_lichen_star
推送到远程的线上分支
-
把新建的本地分支push到远程服务器,远程分支与本地分支同名(当然可以随意起名):
git push origin dbg_lichen_star:dbg_lichen_star
git push <远程主机名> <本地分支名>:<远程分支名>
查看远程分支
git branch -r
拉取远程分支并且创建一个本地分支
git checkout -b 本地分支 origin/远程分支本地分支和远程分支建立映射关系的作用
同步本地与线上仓库
git branch --set-upstream-to origin/远程分支名 本地分支名
本地分支和远程分支进行关联合并
git push --set-upstream origin 新分支名
git 保存项目路径,推送项目,克隆项目
查看项目路径
git remote -v
保存路径
git remote add origin sunzhihao: 2022孙志豪案例 [-origin 是给这个路径设置的别名,跟上路径]
推送项目
git push origin master [origin 是路径的名字(看上一条) master 分支名字(主分支)]
克隆项目
git clone 有三个效果 1、 完整把项目下载到本地 2、 创建远程别名3、初始化本地仓库
git clone sunzhihao: 2022孙志豪案例 [git clone 跟上地址]
拉取代码
pull = fetch + merge
pull fetch [远程库地址名] [远程库分支名]
git fetch [远程库地址别名/远程分支名]
git pull [远程库地址名] [远程库分支名]
git push -u origin "master"
跨团对协作访问
a 我有问题了 让 b 协作
1、b 、我想跨团对协作访问,首先找到你要访问的项目地址然后搜索然后点击右上角FORK
2、FORK 完了克隆地址 修改 推送
3、 点击 pullRequest > new pull request >create pull request
4、a 看代码 点击 Merge pull request 合并代码即可 把修改完拉取本地