git常用操作命令

最近5个月成了独立开发的developer了，写代码就直接在master分支开发，开发完了直接操作add commit -m '' push也不用担心冲突。
但是昨天换了台公司的设备，又看了一下开发者规范代码问题，还是重视起来了，分支还是要用的。
结果居然把分支合并的操作给忘了...把新开的分支的代码合并到主分支的操作给写成了 merge to .导致不管怎么样都合并不成功的。最后查查资料就解决了，为了方便以后查找，还是自己写个日志记录一下吧。

branch 分支

按流程来说吧：

1.查看当前分支名字

git branch 

2.查看当前分支的修改状态

git status 

3.将当前分支的修改内容添加到本地缓存区

git  add .

4.将当前分支的修改内容放到本地仓库中，'describe of change' 的''里面的内容是用来描述本次代码改动

git commit -m 'describe of change'

5.将远程仓库的代码拉到本地仓库的当前分支（一般这个操作实在当前分支是master的时候进行），并且和本地仓库的代码合并

git pull

6.将当前仓库的当前分支的代码推到远程仓库（一般这个操作也是在master分支进行的）

git push

7.将名字为localdev分支的代码合并到当前仓库的分支

git merge localdev

8.创建一个名字是localdev的分支，并且把当前分支的代码拷贝一份给localdev分支

git branch localdev

9.切换当前分支到localdev

git checkout localdev

如果想要切换回主分支，直接将localdev改为master，如下：

git checkout master

10.git stash 将当前开发代码隐藏掉

新增内容

git  stash

使用场景：

现在有一个新的开发功能A模块

还有一个新的bug需要修复B模块

当我们将A的代码开发到50%时候，测试部门来人说，发现bug需要修复

我们先将当前A的50%的代码暂时隐藏掉

此时工作区的代码会和远程pull下的代码一样

现在操作将修复bug的代码在工作区完成100%

然后将当前的修改bug的代码提交到远程

再从隐藏区域把新功能A的50%的代码出栈到工作区

将新功能A的代码完成到100%

将新功能A的代码提交到远程。

删繁就简：

1.将当前工作区内容添加到隐藏区列表堆栈里面：

git add .

git status

git stash push -m "备注隐藏的代码内涵 "

拉取代码这一步我操作的时候不需要执行，上一步执行完了之后工作区的代码就直接变成远程最新代码

git pull 

注意这里要记着下标stash@{0}，“{}”里面的这个0是下标

git stash list

操作修改bug

...

git add .

 git commit -m "修改bug代码提交"

git push

注意这里的下标，要和之前的一致

git stash apply stash@{0}

操作新功能开发，代码完善

...

git add .

git commit -m "新增功能代码提交"

git push

查看列表中是否还有隐藏区代码

git stash list

因为看到有博客说代码隐藏操作是将代码压栈，本以为我将隐藏区的代码拉去到工作区之后，隐藏区的代码是出栈操作，所以就以为会自动清理掉隐藏区的代码。
因为要写博客，为了截图我又操作了一遍，最后发现需要自己手动删除隐藏区的代码

0是下标

git stash drop stash@{0}

现在看下流程，上文已经看懂的请忽略以下内容

a.改动之前的代码和命令行

项目中的测试代码：

-(void)functionForStash
{
}

命令行和ide的代码对比图

截屏2019-12-18上午10.26.45.png

b.代码新增一行打印数据，命令行查看状态

[图片上传中...(截屏2019-12-18上午10.27.36.png-5abeb5-1576637246133-0)]

c.命令行将改动git add . 然后把改动添加到隐藏区 git stash push -m "将改动添加到隐藏区"

截屏2019-12-18上午10.29.18.png

此时工作区的代码已经变成和a一样的代码了，如果不是，请git pull ,如果还不是，请刷新下代码编辑页面

截屏2019-12-18上午10.30.25.png

d.修改bug然后将代码提交到远程 git add . git commit -m "" git push 常规操作

截屏2019-12-18上午10.33.44.png

e.将隐藏区的代码拉取到工作区 git stash apply stash@{0} ,手动解决冲突

截屏2019-12-18上午10.37.50.png

f.将之前进行到50%的工作内容进行到100%，提交代码，git add . git commit -m "" git push 常规操作

截屏2019-12-18上午10.39.08.png

g.查看当前隐藏区的隐藏代码，并根据下标删除,删除成功之后查看一下

git stash list

git stash drop stash@{0}

git stash list

截屏2019-12-18上午10.40.10.png

思考：
1.stash的操作是为了保证每次提交的代码的原子性，一次提交只做一件事情，新增或修改。
2.堆栈需要适应特定的数据结构才使用，这里的为了数据安全性，简单的将隐藏区的代码拉取到工作区，从而删除掉隐藏区的代码，这是不安全的。

来源： 关于git stash的使用方法原来一直是我的困惑，无意间发现了一篇文章，自于一位耐心细致的大神，值得推荐，关于git stash的使用更详细的解释点我查看
),感谢作者。

将本地项目添加一个git仓库
初始化

git init

修改保存

git add .

添加描述

git commit -m "init"

添加远程仓库路径https://github.com/github/demo.git,这里请修改成自己的远程仓库地址

git remote add origin https://github.com/github/demo.git

从远程仓库拉取代码

git pull --rebase origin master

将本地的修改推到远程仓库

git push -u origin master

最近一家公司的git管理比较规范，项目功能和bug管理也比较模块化，在此记录一下细节东西

Git 协作流程##

master 分支###

master 永远处于稳定状态，这个分支代码可以随时用来部署。不允许在该分支直接提交代码。

develop 分支###

开发分支，包含了项目最新的功能和代码，所有开发都在 develop 上进行。一般情况下小的修改直接在这个分支上提交代码。

feature 分支###

备注：这里的需求id是配合禅道上的任务需求，如果没有任务，开发人员可以自己创建一个任务，对于每一个需求，请从 develop 分支开出一个 feature 分支，分支名约定为feature/{需求id}-{需求描述}，开发完成后合并回 develop 分支，相应的操作如下：

$ git checkout -b feature/{需求id}-{需求描述}
# 写代码，提交，写代码，提交
# git add, commit, push etc......
# 完成开发，在gitlab上提交merge request
# 做code review，同意merge

如果develop分支已经出现过修改，在merge之前，请先用 rebase获得develop的最新版本，操作如下：

# 假设当前在 feature/{需求id}-{需求描述} 分支
$ git rebase develop
# git rebase会产生一些交互操作，比如文件冲突等，按照提示执行即可

$ git checkout develop
# 可以加上 --no-ff，以保持分支的合并历史
$ git merge --no-ff feature/{需求id}-{需求描述}
# merge完毕后，可以删除branch
$ git branch -d feature/{需求id}-{需求描述}

bug 分支###

每一个在bug列表里面的bug，请从 develop 分支开出一个 bug 分支，分支名约定为bug/{bugid}-{bug描述}，开发完成后合并回 develop 分支，相应的操作如下：

$ git checkout -b bug/{bugid}-{bug描述} develop
# 写代码，提交，写代码，提交
# git add, commit, push etc......
# bug 修改完成，在gitlab上提交merge request
# 做code review，同意merge

如果develop分支已经出现过修改，在merge之前，请先用 rebase获得develop的最新版本，操作如下：

# 假设当前在 bug/{bugid}-{bug描述} 分支
$ git rebase develop
# git rebase会产生一些交互操作，比如文件冲突等，按照提示执行即可

$ git checkout develop
# 可以加上 --no-ff，以保持分支的合并历史
$ git merge --no-ff bug/{bugid}-{bug描述} 
# merge完毕后，可以删除branch
$ git branch -d bug/{bugid}-{bug描述} 

release 分支###

当 develop 上的功能和 bug 修得差不多的时候，我们就要发布新版本了，这个时候从 develop 分支上开出一个 release 分支，来做发布前的准备，分支名约定为release/20210101，主要是测试有没有什么 bug，如果有 bug 就直接在这个分支上修复，确定没有问题后就会合并到 master 分支。相应操作如下：

$ git checkout -b release/20210101 develop
# 测试人员检查没问题后合并到 master 
$ git checkout master
$ git merge --no-ff release/20210101

为了让 release 分支上 bug 修改作用到 develop 分支，我们还需要把这个 release 分支合并回 develop 分支：

$ git checkout develop
$ git merge --no-ff release/20210101
# 到此，这个 release 分支完成了它的使命，可以被删除了
$ git branch -d release/20210101

release分支完成后，在master上打个tag，作为线上版本发布。

hotfix 分支（专门解决线上bug）###

如果我们发现线上的代码（也就是 master）有 bug，但是这个时候我们的 develop 上的有些功能还没完成，还不能发布，这个时候我们可以从 master 分支上开出一个 hotfix 分支（记住：直接在 master 上提交代码是不允许的！），分支名约定为hotfix/{bugid}-{bug描述}，在这个分支上修改完 bug 后需要把这个分支同时合并到 master 和 develop 分支。相应操作如下：

$ git checkout -b hotfix/{bugid}-{bug描述} master
# 修完 bug 后
$ git checkout master
$ git merge --no-ff hotfix/{bugid}-{bug描述}
$ git checkout develop
$ git merge --no-ff hotfix/{bugid}-{bug描述}
# hotfix 分支完成使命
$ git branch -d hotfix/{bugid}-{bug描述}

例外：当 hotfix 分支完成，这个时候如果有新的release 分支存在，那么这个 hotfix 就应该合并到新的 release，而不是 develop 分支。

关于版本号的定义###

版本号 major.minor.hotfix
major：主版本号
minor：每个阶段上线的版本号，以我们目前情况来看，一般来说2-3周+1
hotfix: 临时解决问题的版本号，一般来说是线上出现问题时修改后的发布，自动+1