GIT工作流程总结

单人开发

开发完之后,add自己修改的内容

add-commit-push

$ git add test.py	//添加
$ git add .        //命令中的点号 . 代表当前目录,将当前目录及其子目录中所有更改过的文件添加到暂存区
$ git commit -m "wrote a test file"	//提交
$ git push //提交到远程上游分支

这是最理想情况下的,适合于自己开发,但是当多人合作开发(企业开发环境)中时,就不能这样做了。

多人开发

当多人开发的时候,某个需求会被分配到你,这时(假设开发的分支是dev分支),需要做的是,将自己本地的dev分支更新到最新,与远程的dev分支同步:

git pull

此时,你的本地dev分支就和远程的dev分支同步了,为了保持dev的正确性和整洁性,是不可以在本地dev分支上进行开发的,因为本地的dev需要拉取其他人的最新提交,让得dev上的内容都是正确且完整的。。这时,就需要为当前的开发需求单独创建一个分支(基于dev分支),假设这个开发需求叫做a ,那么我们就为这个需求单独创建一个分支,具体多大的需求才需要创建分支,完全看自己,要是小需求,直接在dev分支上修改也无妨

git branch dev_a

此时我们创建好了这个需求的分支,接下来需要进行的就是开发工作,当开发的工作完成时,进行add操作;这里推荐add具体的文件,而不是一股脑的将所有修改的文件都 add,因为这有可能导致后续提交代码的时候将测试代码提交,造成测试同学打包的时候无法正常使用

git add .     //添加所有修改过的文件到暂存区
git add <修改的文件>   //添加具体的某几个文件到暂存区,推荐

然后提交到本地的仓库中,提交的描述一般公司都有内部的规定

git commit -m"describe what you did"

此时dev_a分支上的开发工作就已经就绪了。但是有个问题,那就是,你在开发,其它的同事也在开发并且有可能已经开发完了并且提交了新的代码,所以,此时正确的做法是,先切换到dev分支,并拉一下最新的代码

git checkout dev
git pull

现在,dev分支新加了一些代码,但是我们的dev_a分支是基于没有新增代码的dev分支创建的,所以,要先将dev分支上新增的代码给到dev_a分支上——即rebase操作。这里有一个小问题需要解释:为什么不直接在dev分支上合并dev_a分支呢?答案是:你在开发,同事也在开发,如果你们修改的代码块有重合的部分,那么就会产生冲突,规范的做法是要将冲突解决在自己的分支上,让dev分支保持正确、干净(之前提过);rebase操作就是再“基于”dev分支一次,将新的内容加到自己的分支上,有冲突就解决冲突,没有冲突就可以进行合并操作了。

git checkout dev_a    //切换回dev_a
git rebase dev

如果有冲突,解决冲突再继续rebase:

git rebase -continue  //解决后继续rebase

合并操作,如果是a和b要合并,a是标准分支,b是进行开发的分支,那么应该在a分支下,合并b

所以我们要在dev分支下,合并dev_a分支

git checkout dev
git merge dev_a    //由于已经rebase过了,所以不会出现冲突

此时dev分支就有我们的代码了,将dev分支进行提交即可,也标志着dev_a分支的使命完成了,删除即可,以保证本地仓库的整洁

git push            //提交代码到远程仓库
git branch -d dev_a    //不在dev_a分支下才能删除dev_a分支

工作目录切换tips

git stash

如果此时你在开发,在工作目录下,但是此时出现了一个紧急的bug需要你到其它分支进行排查,但是你还没开发完,没有办法进行add - commit的操作,但是如果直接git checkout 操作,会将当前工作目录下的内容带到其它分支的工作目录下,直接导致其他分支工作目录的混乱;那么此时怎么做呢——git stash:它的主要作用是临时保存(或“藏匿”)你当前工作目录中的未提交改动,使你可以切换分支或执行其他操作,而不必提交未完成的工作。

当你使用 git stash 时,Git 会将你的暂存区和工作目录中的修改(即那些已经用 git add 添加的和未添加的修改)保存起来,然后将它们从当前工作目录中移除,使你的工作目录看起来像是“干净”的,即与上次提交的状态一致。

git stash

当你处理完其它分支上的工作,回到这个分支想接着刚才的进度进行工作的时候,就可以使用 git stash pop 可以应用(并删除)存储列表中最近的更改。这会将之前存储的更改重新应用到当前工作目录。

git stash pop

那么问题来了,当反复出现这个情况的时候,可能需要多次git stash,最新存储的更改将有索引 stash@{0},紧接着是 stash@{1},依此类推。每次你创建一个新的 stash,它就会被放在列表的顶部,成为 stash@{0},而之前的 stash 索引将依次增加。

可以使用 git stash list 查看当前存储的更改列表。

git stash list

如果你有多个存储的更改,可以使用 git stash apply stash@{n} 应用特定的更改,其中 n 是你想要应用的更改在 git stash list 中的索引,索引从0开始

git stash apply stash@{n}

你可能感兴趣的:(代码命令,管理工具专栏,git,gitlab,github,gitee)