title: Git不完全指南
date: 2019-11-27 18:01:21
categories:
- 其他
- Git
tags: - git使用
- 基础知识
description: git安装,系统理解,简单使用。
git不完全指南
本文将模拟一次项目的创建,修改,提交。分项目经理和开发员工两个角色,介绍git的简单用法。假设项目包含三个分支:master,dev,work
- 分支master用于发布,默认分支,当需要发布时将dev分支合并到其中
- 分支dev开发阶段的代码合并,每个阶段的工作完成后需要进行一次,控制项目的进度
- 成员分支work用于每个项目成员的代码开发,实现不交叉
git安装与配置
项目经理——创建项目
克隆GitHub的项目
git clone 'git地址'
将含readme.md
文件的项目仓库克隆到本地。
管理项目分支
分支记录项目文件的修改情况,便于跟踪。
创建分支
git branch [分支名]
e.g.
git branch dev
切换分支
git checkout [分支名]
e.g.
git checkout dec
推送
将分支内容推送到远程仓库相对应的远程分支
git origin pull [分支名]
e.g.
git origin pull dev
本地分支关联服务器分支
使用git在本地新建一个分支后,需要做远程分支关联。如果没有关联,git会在下面的操作中提示你显示的添加关联。关联目的是在执行git pull, git push操作时就不需要指定对应的远程分支。
git branch --set-upstream-to=origin/[远程分支名] [分支名]
e.g.
git branch --set-upstream-to=origin/dev dev
创建并切换分支
git checkout -b [分支名]
e.g.
git checkout -b work
查看所有分支
git branch
:当前分支前标记为星*
删除分支
git branch -d [分支名]
本地添加文件,上传分支
将文件(夹)添加到暂存区
git add dailyfresh/
将暂存区提交到仓储区
git commit -m '提交概要'
上传分支
当前文件在本地work分支中,故先推送到work远程分支上
git push origin work
然后将本地work分支合并到本地dev分支中
git checkout dev //切换到dev分支
git merge work
再将本地dev分支推送到dev远程分支上
git push origin dev
再将本地dev分支合并到本地master分支上
git checkout master //切换到master分支
git merge dev
最后将本地master推送到master远程分支上
git push origin master
开发员工
添加ssh账户
清除旧的密钥
rm -r .ssh
生成新密钥
ssh-keygen -t rsa -C "Github账号,可以是用户名,也可以是邮箱地址"
查看并复制公钥’id_rsa.pub’内容
cat id_rsa.pub
最后,将复制的公钥发给项目经理,等项目经理在github上添加后,会将项目地址下发,然后就可以参与到项目开发中进行后续操作
克隆项目
从github上将项目克隆到本地,默认对应的是master分支
同步分支
创建分支
git checkout -b work_1
将本地分支推送到远程服务器
git push origin work_1
本地分支关联服务器分支
git branch --set-upstream-to=origin/远程分支名 分支名
例:
git branch --set-upstream-to=origin/work_1 work_1
将远程dev分支同步到本地,因为开发过程中,所有组员都向这个分支上提交阶段性代码,并从这个分支获取最新代码
git checkout -b dev origin/dev
工作区,暂存区,仓库区
- 对于添加、修改、删除文件的操作,都发生在工作区中
- 暂存区记录工作区文件的修改记录,是版本库的一部分
工作区添加到暂存区
git add 文件1 文件2
撤销
使用暂时区的内容恢复工作区的内容,放弃工作区的更改
git checkout -- 文件名
查看暂存区记录
git status
提交到仓库区
git commit -m '本次提交的说明信息'
本地与服务器
获取
将服务器特定分支向本地工作区同步。
- 建议:在每天开始编写代码前,先与服务器同步一次;或者在公用分支如dev上开发时,建议先同步后开发
- 什么时候会用到dev分支呢?答:合并阶段代码到dev分支,编辑公用文件
1 切换到dev分支
git checkout dev
2 同步代码到本地
git pull
3 切换到自己的分支继续开发
推送内容
指将特定分支在本地仓库区的记录发送到服务器上
- 建议:在每天下班前将当天开发推送到服务器,这样可以在服务器中存储一个备份,即使本机出问题,在服务器上还能存在代码备份
- 注意:只有仓库区的记录会提交到服务器的对应分支下
- 推送前要将此分支跟踪服务器上的同名分支,推荐在创建分支时就完成跟踪
git push origin work_1
合并分支
开发完毕后,要合并到dev分支
git checkout dev # 切换到本地dev分支
git pull # 同步远程dev分支到本地
git merge work_1 # 将work_1分支合并到本地dev分支
git push origin dev # 将本地dev分支推送到远程
git checkout work_1 #切换回work_1分支
git merge dev # 将dev分支合并到work_1中,保持最新状态
解决合并冲突
当两个不同分支对文件同一区域进行修改后,合并时,会出现合并冲突的问题。
其中,<<<<<<< HEAD表示当前版本的内容,=======后面,表示>>>>>>> xxxxxxxxxxxxxxxxxxxxxxxx版本的内容,和另一个分支管理者沟通后,修改文件,重新提交。
debug分支
git中stash
提供了保存现场的功能,可以把当前工作区、暂存区中的内容不需要提交而保存下来,转而去做bug修复,完成后再恢复现场,继续开发工作。
保存现场,并修改bug
git status # 查看当前状态
git stash #保存现场
git checkout master #却换到master分支
git checkout -b bug_1 #新建类似分支修复bug,修改完成后,会删除。
# 修改相关bug,并提交到仓库区
git checkout master #切换到master分支
git merge --no-ff -m '修改日志概要' bug_1
git push
git branch -d bug_1 #删除分支
恢复现场
git checkout work_1 #切换会工作分支
git stash list # 查看现场列表
git stash pop # 恢复现场
git status #查看工作状态
项目经理-发布
项目合并与发布,需要项目经理和组员一起来完成,每个人将开发的分支逐个合并到dev分支,如果有冲突则解决冲突,在dev上的代码经过测试没有问题后,则由经理合并到master分支,完成发布
- 每个人逐个合并分支到dev
- 经理合并dev到master并发布
- 每个人获取最新的dev分支、master分支
员工逐个合并
前题:已经完成了自己分支work_1代码的开发并完成添加、提交及推送
git checkout dev #却换到dev分支
git pull #同步分支
git merge work_1 #将本地work_1合并到dev
git push origin dev #推送到远程dev分支
项目经理合并到master
所有成员都完成合并后,接下来是项目经理要执行的操作
git checkout dev #却换到dev分支
git pull #同步分支
git checkout master #切换到master分支
git merge dev #将dev分支合并到master
git tag v1 #打标签,标签就是为了给一堆数字的版本号,起一个容易记住的名字,一般用于master分支
git push
同步回员工个人
现在最新的代码已经有了,接下来在这个版本代码基础上继续开发,每个人都要获取最新的代码
git checkout master
git pull
git checkout dev
git merge master
git checkout work_1
git merge dev
总结
git clone 'git地址'
git add [文件或目录]
git rm [文件或目录]
git checkout -- [文件]
git commit -m '备注说明'
git reset HEAD或版本号
git reflog
git log
git status
git branch [分支名]
git branch --set-upstream-to=origin/分支名 分支名
git checkout 分支名
git checkout -b 分支名 origin/分支名
git diff 版本1 版本2
git merge 分支名
git pull
git push origin 分支名
git tag 标签名
git stash