Git的使用--如何将本地项目上传到Github&Git创建新分支
如何将本地项目上传到Github(两种简单、方便的方法)
创建分支与切换分支
第一种(已尝试)
Github上新建一个仓库
复制仓库地址先(两个都行)
桌面右键Git进入文件夹目录
接下来输入如下代码(关键步骤),把github上面的仓库克隆到本地
1 |
|
这个步骤以后你的本地项目文件夹下面就会多出个文件夹,该文件夹名即为你github上面的项目名,如图我多出了个html-css-js文件夹,我们把本地项目文件夹下的所有文件(除了新多出的那个文件夹不用),其余都复制到那个新多出的文件夹下。
接着继续输入命令 cd html-css-js,进入html-css-js文件夹
接下来依次输入以下代码即可完成其他剩余操作
1 |
|
第二种
参考链接:
https://blog.csdn.net/u014135752/article/details/79951802
Git创建新分支并提交到github
因为需求的变更,需要把原来的代码做一下备份,再进行下一步的开发,所以 这是就将原来的代码创建一个新的分支来保存原来的代码,以防后面需要回滚,这里记录一下操作的步骤
- 可以先查看一下当前所在分支
1 |
|
- 创建本地分支并切换到新创建的分支
1 |
|
1 |
|
- 已经创建成功了,可以看一下
1 |
|
- 将新创建的分支信息推送到github
1 |
|
可以到github看一下
git checkout branchname //切换分支 branchname为你的分支名字
分支操作
1 |
|
开发项目码云与Git分支的使用
- 在码云上你的项目中新建分支
- 本地项目文件右键Git Bash Here
命令:
1 |
|
- 查看所有分支
1 |
|
Git的基本操作指令
1 |
|
删除分支操作
1 |
|
git强制提交
1 |
|
分支命名
分支名称如果开发新功能时你就命名成feature/xxxx(xxxx表示具体描述) 修复bug时就fix/xxxx fix/整个模块的名字
如何修改当前项目git的用户名和邮箱
查看本地设置:
1 |
|
查看设置本地属性(本地用户和email)
1 |
|
解决方法:
修改当前的project
修改当前project的用户名的命令:
1 |
|
修改当前project提交邮箱的命令:
1 |
|
git stash暂存开发分支,拉去合并线上分支(开发后要合并线上分支(提pr)解决冲突)
git pull 和 git fetch 的区别
git fetch 只是将远程仓库的变化下载下来,并没有和本地分支合并。(fetch 只是下拉远程分支,怎么合并,可以自己再做选择)
git pull 会将远程仓库的变化下载下来,并和当前分支合并。pull=fetch+merge
1 |
|
还有一种是你刚刚有一条提交记录,惊觉还有没有提交的,需要在提交上去,又不想产生一条新的记录
1 |
|
然后在git push 上去
git review
1 |
|
Git默认拉取的是master分支,拉取指定分支代码命令
拉取指定分支代码解决方案:
以拉取1.0分支的代码为例, 要拉取其余分支代码类似操作
- 使用git命令拉取
命令:git clone -b 1.o XXX
其中1.0就是分支的名称
git tag标签的使用
tag是git版本库的一个标记,指向某个commit的指针。
tag主要用于发布版本的管理,一个版本发布之后,我们可以为git打上 v.1.0.1 v.1.0.2 …这样的标签。
tag感觉跟branch有点相似,但是本质上和分工上是不同的:
tag 对应某次commit, 是一个点,是不可移动的。
branch 对应一系列commit,是很多点连成的一根线,有一个HEAD 指针,是可以依靠 HEAD 指针移动的。
所以,两者的区别决定了使用方式,改动代码用 branch ,不改动只查看用 tag。
tag 和 branch 的相互配合使用,有时候起到非常方便的效果,例如:已经发布了 v1.0 v2.0 v3.0 三个版本,这个时候,我突然想不改现有代码的前提下,在 v2.0 的基础上加个新功能,作为 v4.0 发布。就可以检出 v2.0 的代码作为一个 branch ,然后作为开发分支。
tag的简单使用(一般在git commit后打tag)
创建 tag 是基于本地分支的 commit,而且与分支的推送是两回事,就是说分支已经推送到远程了,但是你的 tag 并没有,如果把 tag 推送到远程分支上,需要另外执行 tag 的推送命令。
1 |
|
git rebase
git rebase相对来说是比较复杂的一个命令了,但只要掌握了使用方式,你会深深地喜欢上他,如果有时间我也许会细细地讲一下,现将git rebase的正确使用步骤总结如下:
Git 操作
假设Git目前只有一个分支master。开发人员的工作流程是
- git clone master branch
- 在自己本地checkout -b local创建一个本地开发分支
- 在本地的开发分支上开发和测试
- 阶段性开发完成后(包含功能代码和单元测试),可以准备提交代码
- 首先切换到master分支,git pull拉取最新的分支状态
- 然后切回local分支
- 通过git rebase -i 将本地的多次提交合并为一个,以简化提交历史。本地有多个提交时,如果不进行这一步,在git rebase master时会多次解决冲突(最坏情况下,每一个提交都会相应解决一个冲突)
- git rebase master 将master最新的分支同步到本地,这个过程可能需要手动解决冲突(如果进行了上一步的话,只用解决一次冲突)
- 然后切换到master分支,git merge将本地的local分支内容合并到master分支
- git push将master分支的提交上传
- 本地开发分支可以灵活管理
1 |
|
git diff命令的使用
git diff是一个git提供的一个非常有用的命令,使用git diff可清晰的显示出文件被修改的内容。
工作区、版本库
要理解git diff命令,就必须先理解工作区、暂存区与版本库的概念。
工作区就是所在目录,比如我的TestGit文件夹:
在上图的.git文件中,存放的就是版本库,版本库中存储了很多东西,最重要的就是stage(或者叫index)暂存区、git自动创建的一个分支master,以及指向master的一个指针HEAD。
添加修改到版本库的过程如图所示:
工作区 –> 暂存区
使用git add命令将工作区文件添加到缓存区。暂存区 –> 仓库
使用git commit命令将暂存区中的文件提交到仓库。git diff命令
根据所要对比区域不同,git diff有如下几种用法。
1 |
|
分支管理规范
分批次研发规范流程
基本流程
- 需求、UE评审,确定需求优先级
- 基本确定需求间的依赖关系,确定不同提测批次的需求模块
- 不同批次研发排期确定和提测时间确定
- 第一批次需求开发开始
- 第一批次需求自测 + 提测
- 第二批次需求开发开始
- 第二批次需求自测 + 提测
- 以此类推……
注意点
有些隐晦的依赖关系可能在开发时才被发现,影响到了需求分批次的正确性,此时需要及时和项目后台负责人说明情况,调整受影响批次的需求内容
后续批次的研发,并不一定要等到第一批次提测结束后才开始,当然,提测时会被QA打断,影响编码效率,所以上一批次提测期间,后续批次的研发排期,需要自行判断延长,比如 1天 当 0.5天算
前端分支管理规范demo
需求评审 + UE评审 + 分批次提测模块划分
开始开发前,从develop拉取分支
- release/vx.x.x — 用于最终提测
- test/vx.x.x — 用于自测
- feature/xxx — 用于开发单个功能需求
第一批次feature开发联调完毕,合并到 test 分支,部署到开发环境进行自测,自测bug在 feature 分支修复后合并到 test 分支
自测结束,各feature分支合并到release分支,发起提测,提测bug从 release 拉取 fix 分支修复
第二批次feature开发联调完毕,合并到test分支,部署到开发环境进行自测,自测bug在 feature 分支修复后合并到 test 分支
自测结束,各feature分支合并到release分支,发起提测,提测bug从 release 拉取 fix 分支修复
以此类推……
全部提测通过,release分支合并到develop分支,打tag,删除各feature分支、test分支
commit提交规范
- 1,每日下班前记得提交代码,避免遗失;
- 2,提交代码时必须标注必要的描述信息;
- 3,描述信息的规范:类型:具体信息,如:fix:修复子菜单未选中问题
- 描述类型如下:
- feat: 新特性
- fix: 修改问题
- refactor: 代码重构
- docs: 文档修改
- chore: 其他修改
- test: 测试用例修改
- style: 代码格式修改等等
分支命名规范
- 1,功能分支命名:feature/版本日期_功能_作者,如:feature/20200924_createNode_ybl
- 2,版本发布分支命名:release/发布日期,如:release/20200924
gitflow流程
- 功能开发
- 所有的新功能开发应该通过创建feature分支的方式去开发,需要从最新代码的develop分支里进行创建,例如feature/add-user,开发完成之后需要发起Merge Request合并回develop分支;
- 强调下:独立的功能尽量使用独立的feature分支来开发,切忌把多个功能合并使用一个feature分支来开发;
- 不同的feature分支完成开发和联调后,需要严格执行自测,并且根据项目的需要来决定是否单独提测该feature分支。
- 功能提测
- 确认需要发布的功能集合以及对应的版本号后,将相应的feature分支统一合并回develop分支,并且从develop分支上新建相应的release分支,例如:release/v1.2.0;
- release分支在测试过程中出现的bug,可以通过新建hotfix分支的方式去并行修复问题,完成后需要通过Merge Request合并回当前release分支;
- release分支在测试过程中出现新的需求,可以通过feature分支的方式去开发,完成后需要通过Merge Request合并回当前release分支;
- 发布上线
- 待release分支测试验收通过后,在当前release分支上打出相应的tag(例如v1.2.0),然后将代码分别合并到master和develop分支中,并且需要将当前release分支相关历史的feature分支或hotfix分支进行删除。
- 线上问题修复
- 若线上发现有严重的bug,需要从具体tag(如v1.1.0)的提交版本中创建相应的hotfix分支(例如hotfix/v1.1.0);
- 当问题修复完成并且通过测试验证,需要在当前分支打tag(例如v1.1.0-P1),并且需要将当前hotfix分支分别通过Merge Request合并回master、develop分支上。
注意事项:
- 1,定期清理已合并且无用的feature分支,留版本发布的release/xxx分支;
- 清理远程分支git remote prune origin
- 清理本地分支git branch -D 分支名
- 2,记得发布后打tag;
本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!