Git 实战笔记
什么是 Git ?
Git 是一个分布式版本控制软件,使用 Git 能够帮助团队更加容易的管理代码
如何使用 Git 去管理
Git个人信息配置,初次运行 Git 必须配置个人邮箱和名字后,才能正常的使用 Git 去版本控制
git config --global user.email "你的邮箱地址"
git config --global user.name "你的名字"
若不配置个人信息,则无法生成本地版本库。(即无法 git commit )
每个项目都会有一个目录,我可以通过 Git 来管理这个项目(目录)
- 初始化 Git
git init
Git 初始化后,会在项目的根目录下生成一个 .git 的隐藏目录,此目录包括了所有用于版本控制的重要信息。
- 查看当前目录下文件的状态
git status
- 文件名红色 -> 文件未被提交到暂存区(未被 Git 管理)
- 文件名绿色 -> 文件已被提交到暂存区(已被 Git 管理)
- 提交到暂存区
git add <文件路径>
- git add . -> 提交当前目录下所有未被管理的文件到暂存区
- 提交本地版本
git commit -m '版本描述'
将当前暂存区的文件生成一个新的版本
- 查看提交的版本信息
git log
此时会显示你提交的版本
Git 的三大区域
1. 工作区回滚指定版本
git reset --hard 版本号
- 查看回滚的历史记录
git reflog
Git 分支与合并
- 查看分支
git branch
- 创建分支
git branch 分支名称
- 切换分支
git checkout 分支名称
- 分支合并(可能产生冲突)
git merge 要合并的分支
注意:切换回主分支再合并
- 以当前分支为基础建立 feature 分支,并切换到 feature
git checkout -b feature
- 删除分支
git branch -d 分支名称
远程仓库
- 给远程仓库起别名
git remote add origin 远程仓库地址
- 向远程推送代码
git push -u origin 分支
- 克隆远程仓库代码
git clone 远程仓库地址
- 切换分支
git checkout 分支
忘记推送代码,解决方法: 比如有一天,你在公司写了一个评论功能,因为某种原因,忘记推送代码到远程仓库了,然后回到家中开发时,发现代码并不是最新的,但是又不能耽误项目的进度,所以你打算先开发其他的功能,回到公司后,再开发评论功能。
- 在家开发新功能(在dev分支上)
git checkout dev
...
git add .
git commit -m 'dev2.0'
git push origin dev
- 回到公司
首先拉代码到本地
git pull origin dev
这时候合并出错了,远程的dev分支(就是你在家里写的其他功能的代码)和本地dev分支代码出现冲突,以当前的知识,解决方法就是手动解决冲突,然后再生成新的dev版本。
git pull 命令
git pull origin dev
相当于
git fetch origin dev
git merge origin/dev
远程仓库与本地仓库关系示意图
Git rebase 合并不必要的提交记录
git rebase 原理分析: https://blog.csdn.net/weixin_42310154/article/details/119004977
常见场景分为 3 种
- 多个记录 -> 1 条记录(注意最好不要合并已经提交到远程仓库的记录)
比如当前分支有很多提交记录
V1 <- V2 <- V3 <- V4 这时候我想把 v2 ~ v4 合并为一条提交记录
git rebase -i HEAD~[合并的个数]
或者使用hash值
git rebase -i 5efac3....
- 将2以上个分支的记录合并
git checkout dev
当前在 dev 分支下
git rebase master
切换到 master 分支
git checkout master
合并 dev 分支的代码
git merge dev
此时观察记录
git log --graph --pretty=format:”%h %s”
发现 2 个分支的记录合并到一条线上了 3.本地分支与远程分支的合并
在本地有一个 dev 分支,在远程有一个 dev 分支,这时候我想把远程的 dev 分支拉取到本地,并且不产生新的分支记录 我们知道 git pull origin dev 等同于 git fetch origin dev 和 git merge origin/dev,而 git merge 这个命令必然会产生一个新分支的记录,所以此方法不通
这时候 git rebase 就派上用场了。首先, 拉取远程分支到本地版本库
git fetch origin dev
此时使用 rebase 命令合并仓库,这样就会不产生新的分支记录
git rebase origin/dev
此时观察记录
git log --graph --pretty=format:”%h %s”
发现记录被合成一条线上了
解决 rebase 产生的冲突
很常见的场景,远程分支和本地分支代码产生冲突,首先要找到冲突的文件,然后手动解决冲突
解决完冲突后,执行
git add .
git rebase --continue
这时会让你输入版本名称,输入完后,保存即可
使用 beyond Compare 4
配置 git
git config --local merge.tool “b3”
git config --local mergetool.path ‘/local/bin/...’
git config --local mergetool.keepBackup false
其实上面的命令等同于编辑 .git/config 文件
使用 beyond Compare 帮助解决合并冲突
git mergetool
总结
添加远程连接(别名)
git remote add origin 地址
推送代码
git push origin dev
下载代码
git clone 地址
拉取代码
git pull origin dev
价等于
git fetch origin dev
git merge origin/dev
代码提交记录整洁(变基)
git rebase 分支
多人协同开发的工作模式
假如现在开发项目的不止你一个人,还有其他人,几十个,甚至上百个人开发者一同开发一个项目,只用一个master分支显然是不够的,我们需要一个规范来管理这些团队,才能合理快速的开发项目。 这个图基本阐述了一个团队开发项目的过程,master是线上生产的主分支,此分支不可轻易的提交代码,需重重把关,release,dev分支如是。 比如现在有3个人,一个团队的领导者,2个开发者。Actor1 用于开发注册和登录功能,Actor2用于开发支付功能,每个开发者都需要有一个自己的本地分支,用于开发代码,远程仓库只需要3个分支用于管理代码。 某个时间点,Actor1开发完了注册和登录功能,想要提交到远程的dev分支时,必须经过团队的领导者代码审核,审核通过方可提交代码,Actor2如是。 通过审核后,就需要进行测试,需提交到release分支进行测试,如果测试出现了bug,需要在 release分支进行修复,然后合并到dev分支,直到release没有了问题,就可以提交到master分支进行上线项目了。 这里 Actor1 和 Actor2 可以是一个团队,每个团队可以建立一个分支,每个人提交到团队的这个分支,这个团队主分支再合并到dev分支,可以无限套娃,这种方式,我们称之为 gitflow 工作流 在一些小公司,可能开发时,没有release测试分支,甚至没有dev分支,但是在中大型企业,这3个主要分支(master,release,dev)是必须有的,而且会更多。
线上版本出 bug 了怎么办?
这时候可以再master基础上建立一个bug(或hotfix,按公司规范来,名不同然意同)分支,在bug(hotfix)分支进行紧急修复代码,修复完成后再合并到 master分支就行了,团队项目建议不要使用变基(rebase)不然弄不清是谁提交的,容易打架。
通用的分支名
- master:表示线上部署项目的主分支
- release:表示待部署的分支(或叫做预上线分支),用于测试开发分支的代码
- dev:表示开发分支,提交到此分支需要 code view(代码审查),一般是团队领导审查,审查通过才能提交到此分支
- feature:
以dev分支为基础的分支,通常由开发者负责,此分支的代码提交需要通过 pull request,万不可切到dev分支进行合并此分支,小心命没了。 - Hotfix:以 master 分支为基础,紧急修复 bug 的分支
注意:在团队协作时,合并时,必须带上 --on-ff, 如 git merge --no-ff feature,确保不会快进,即指针右移。而是生成一个新的commit,即新的版本。
给开源项目贡献代码
- Fork 开源项目
- 在自己fork的项目中修改代码
- 给源项目团队提交 pull request,如果审核通过,恭喜你,你就是这个项目的贡献者了。
Git 的配置文件
- 项目配置文件 -> ./git/config
使用 git config --local 进行修改 - 全局配置文件
Windows: C:\Users\用户名.gitconfig Mac和linux: ~/.gitconfig 使用 git config --global 进行修改 - 系统配置文件(需要管理员权限或者叫root权限)
Windows: 安装盘符:\git\etc\gitconfig Mac和linux: /etc/.gitconfig 使用 git config --system 进行修改
免密登录
做免密登录的好处就是以后提交都不需要输入用户名和密码
HTTPS
原来的 url:https://gitee.com/xxx/xxx.git 修改为:https://用户名:密码@gitee.com/xxx/xxx.git
直接在 .git/config 项目配置文件修改即可
SSH(企业用的比较多)
- 生成公钥和私钥
ssh-keygen
公钥生成的路径 Windows: C:\Users\admin.ssh\id_rsa.pub Mac和Linux: ~/.ssh/id_rsa.pub 私钥的路径就是 id_rsa.pub 去掉 .pub 后缀
- 拷贝公钥给 gitee 或 github
找到公钥的路径后,复制里面所有的内容 并设置到gitee或github中 公钥的名字随便起 Key也就是你复制的内容。
- 在 git 本地设置ssh地址
git remote add origin git@gitee.com:用户名/xxx.git
设置完成后,以后git push origin 本地分支时都不需要认证了。
Git 自动管理凭证
当第一次输入用户名和密码后,git会自动把用户名和密码存起来,下次提交时,就不会输入用户名和密码。
Git 提交忽略文件
.gitignore 文件用于在管理项目时忽略某些文件,比如node_modules这个文件夹。 将不需要被管理的文件名添加到这个文件后,git 就不会管理这个文件了,git status也不会去检测文件的状态了,当然提交的时候就不会有这个文件。
常用通配符 *.js -> 表示所有js文件 !index.js -> !除了index.js之外都要忽略 忽略文件夹 node_modules/
各种语言项目的 .gitignore
任务管理
- Issues,任务管理(每一个问题就是一个任务)
- Wike,项目文档,用于帮助新加入的成员了解项目所用的技术,以及如何实现的,API有哪些等等。
|