java——git（工具类）

git分布式控制系统

创建目录作为你的仓库，在目录中通过git init 命令进行初始化；

仓库可视为有3个区域：工作区、暂存区、版本区

git add xxx.txt :将xxx.txt文件从工作区转到暂存区

git commiit -m “备注” 将所有存在暂存区的文件都提交到版本区

git log：查看历史记录

git reflog:可以查看每次命令时commit的id

git reset --hard HEAD:当前版本，也会将还没提交到版本区中的暂存区文件退回到工作区中；--hard HEAD^:回到前一个commit版本；HEAD^^:回到前两个版本，以此类推；HEAD~100:回到前100的版本；git reset --hard commitid：回到指定版本，这里的commitid是提交指定版本对应的id，无需全部完整写出，写出前几个数就好；

git status：查看各个区域的状态

git diff HEAD -- xxx.txt:查看xxx.txt文件

git checkout -- xxx.txt:让xxx.txt文件回到最近一次commit或者add的状态

可以撤销成功的前提是还没将改动后的文件提交推送到远程版本库中，要不然即使本地版本库内容已经改动，远程版本库改前的文件还是存在的；

练习：如果你在工作区中修改了文件test.txt且add到暂存区后，怎么回到修改test.txt之前的状态？

首先先运行命令git reset --hard HEAD，将暂存区的test.txt文件退回到工作区后再运行git checkout -- test.txt，使得回到修改test.txt之前的状态；

git rm xxx.txt:删除文件，需要注意的是此时删除的是工作区中的文件，如果之前这个文件你有提交到版本库中，想要恢复只需要git checkout撤销回来就好，如果是确实想删除文件那就还需git commit将删除信息同步到版本库中。

远程仓库：

首先要创建SSH KEY，将本地机器和远程仓库服务器进行联系；

ssh-keygen -t -rsa -C ""

随后进入github进行配置；

将本地仓库推送到远程仓库中，在本地仓库目录下运行：

git remote add origin git<span>@server<span>:username/reponame.git</span></span>

这里默认的远程仓库名就是origin，可以修改但不建议，因为git默认的远程库名就是origin；可以通过命令git remote -v进行查看；

将本地库的内容推送到远程库中：

git push -u origin master/dev

参数U是第一次推送时将本地的master和远程库的master联系起来，以后推送可不加；

至于通常哪些分支是要推送的，主要有：

master主分支，不解释

dev分支是开发分支，所有成员都在上面工作，所有也要远程同步

bug分支只用于本地修复bug，后面也会被合并 到dev或master分支后再远程，所有bug分支一般是不用远程的，除非老板想查看你修复了几个bug；

feature分支是否推到远程取决于是否和小伙伴有在上面进行开发；

而多人开发有时也会出现远程推送失败的情况：

比如你和你的小伙伴同时克隆了远程库后创建分支dev进行开发，这时你的小伙伴先git push origin dev将dev分支推送到远程仓库中，这时你再远程就会报错，因为你的小伙伴的最新提交和你试图推送的提交有冲突，这时需要git pull把最新的提交从origin/dev抓下来后在本地解决冲突再推送即可；需要注意的是本地分支dev是要和远程dev分支创建链接关系的，可通过命令：

git branch --set-upsteam-to <branch-name> origin/<branch-name>

正常的开发顺序是将远程库克隆到本地中，而不是将本地库推送到远程库；

所以应该通过命令：

git clone git<span>@github.<span>com:username/reponame.git</span></span>

克隆出本地库

分支管理：

创建xxx分支并切换到该分支：git checkout -b xxx；等同于git branch xxx加上git checkou xxx；

这里的git checkout和之前的撤销命令比较类似，所以git可以通过git switch -c xxx来替代创建和切换分支命令；

git branch：查看当前的所有分支

在分支做完开发任务后可切换到master分支，通过命令：

git merge xxx；将xxx分支的进度合并到master分支中；

在合并分支就可将分支删除：

git branch -d xxx；

如果所删除的分支还没被合并，可用-D参数进行强制删除

分支冲突：

是指两个分支都对通过文件进行修改，这时在合并时就会出现冲突；

这时合并时就会提示合并出现冲突的文件，将冲突文件进行修改已达到想要的效果后再将这个文件进行add+commit提交即可；

git log --graph可以查看分支合并图；

在合并分支时，会默认采用Fast forword模式进行快速合并，这样在分支删除后就会丢掉分支信息，可以通过--no-ff参数禁止快速合并模式；同时也可再加上m参数进行备注，因为合并相当于再进行一次commit；

在实际开发中，master分支应该是非常稳定的，也就是仅用来发布新版本，你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。所以团队合作的分支图是类似下图的：

bug分支：

在我们开发到一半时，突然要对master分支进行一个bug修复，这时既不能提交，又不能清除工作区，就需要通过命令：-

git stash将工作区的内容“储存”起来，再切换到master分支进行分支创建，将bug修改后合并到master后再通过命令：

git stash apply或git stash pop将“储存”在stash内容复原到工作区中，这两个命令的区别是pop复原时会自动删除在stash的内容，而apply需要通过命令git stash drop进行删除；

通过命令：

git stash list可以查看所有的“储存”状况，因为是可以进行多次不同工作区的“储存”的；

这个时候问题又来了，刚已修复好的master分支怎么同步到单前的工作分支中呢?通过合并可不是个好选择，git提供了命令：

git cherry-pick commintid来将提交id是commit的修改同步到当前分支中，只通过对应提交id所修改的内容；

创建标签：切换到需要打标签的分支中，使用命令：

git tag v1.0就好了，此时最新的一次commit上就打上了标签，方便以后查找修改

如果是想对以前的commit打上标签，需要找到对应的commit id，然后通过命令：

git tag v1.0 commidid

可用-a指定标签名，-m指定说明文字对标签进行备注；

git tag：可查看所有标签

git show v1.0：可查看标签对应的提交内容

git tag -d v1.0：删除v1.0标签

git push origin v1.0：推送标签到远程

git push origin --tags：推送所有标签

如果要删除远程的标签要先删除本地的标签后再通过命令：

git push origin :refs/tags/<tagname>进行删除

通过github参与开源项目：先通过“Fork”在自己的账号下克隆一个仓库，再通过clone克隆本地库，这样进行开发后才可以推送到远程仓库，至于要让项目负责人是否接收你的开发可以在github上发起一个pull request；

命令别名：

git config --global alias.st status：把status别名为st，可直接通过命令：git st直接代替git status；

最最基础与最最常用的git命令及作用：

1 分支设置

常用的分支有3个（master 分支、dev 分支、test 分支）以及若干个 feature_xx 分支。

1. master 分支：是主分支，是最终上线代码的分支，该分支被设置被保护分支（锁住），普通开发人员没有权限操作，只有团队 leader 有合并的权限；
2. dev 分支：是用于开发的分支，该分支被设置为默认 clone 的分支，也用于合并到 master 之前进行测试的分支，普通开发人员从远程 clone 到本地的默认分支，可以进行合并等操作；
3. test 分支：是用于测试的分支，测试人员可以将自己开发分支中的修改合并到 test 分支在测试环境进行测试，一般该分支不合并到任何分支；
4. feature_xx 分支：是用户开发自己模块功能的特征分支，可以叫 feature_login, feature_ui, feature_payment 等与开发的功能相关的名称，该分支上的功能开发完、测试无误后可合并到 dev 分支上。

 普通开发人员的操作

普通开发人员，一般按照如下几个步骤来进行开发、测试工作就可以了：

1. 将远程 dev 分支 clone 到本地，例如：git clone :goto456/test.git；
2. 从 dev 分支拉出（新建）自己的 feature 分支用于开发，例如：git checkout -b feature_login；
3. 在自己的 feature 分支上进行开发工作；
4. 开发完了用 add、commit 等操作提交到当前分支；
5. 如果需要在测试环境进行测试，则将远程 test 分支拉到本地，例如：git branch test origin/test;
6. 将自己的 feature 分支合并到 test 分支，并将 test 分支 push 到远程，例如：git rebase test, git checkout test, git merge feature_login, git push origin test；（注意：我们推荐用 rebase 来合并，以保证分支的整洁、美观）
7. 通过公司的发布平台将远程 test 分支发布到测试环境进行测试；
8. 如果测试没问题或者开始就不需要测试，这可以直接将当前 feature 分支合并到 dev 分支，并 push 到远程库，例如：git rebase dev, git checkout dev, git merge feature_login, git push origin dev；（注意：我们推荐用 rebase 来合并，以保证分支的整洁、美观）
9. 这时表示该功能已经开发完成了，代码的 review 以及发布，需要团队 leader 在合并到 master 操作时进行；这时可以删除了自己的 feature 分支，例如：git branch -d feature_login；
10. 如果在 push 到远程的时候提示需要先 pull 时，我们推荐使用 rebase 的方式：git pull --rebase 以保持分支的整洁、美观。

团队 leader 的操作

因为只有 leader 有操作 master 分支的权限，所以需要完成 dev 分支到 master 分支的合并，以及后续打 tag 和正式上线发布的工作：

1. 先切换到 dev 分支，并拉取最新的状态，例如：git checkout dev, git pull --rebase origin dev；
2. 进行代码 review 等过程后，合并到 master 分支，例如：git rebase master, git checkout master, git merge dev;（注意：我们推荐用 rebase 来合并，以保证分支的整洁、美观）
3. 为本次完成的版本打上标签，例如：git tag v1.0 -m "release version 1.0"；
4. 将本地合并后的 master 分支以及标签 push 到远程库，例如：git push orgin master --tags。