Git远程

远程仓库

        Git是分布式版本控制系统，同一个Git仓库，可以分布到不同的机器上。最早，肯定只有一台机器有一个原始版本库，此后，别的机器可以“克隆”这个原始版本库，而且每台机器的版本库其实都是一样的，并没有主次之分。

        实际情况往往是这样，找一台电脑充当服务器的角色，每天24小时开机，其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。

• 设置SSH-Key：

        git本地库 和 Git服务器(github或码云) 之间如果是ssh传输，需要设置SSH key

ssh-keygen -t rsa -C "xxxyyyzzz@163.com" 
# 然后一直回车即可
# -C后"可以随意写一个，作为key的title而已，无关紧要"
# 最后：在 C:\Users\主机名\.ssh 目录下生产秘钥文件，
# id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。
# 登录GitHub，在账户设置中，选择 "SSH Keys" ，在Title中随便填写一个，在Key中填写 id_rsa.pub 文件中的所有内容即可。

        这样和 Git服务器 通信时(clone，push，pull) git服务器就可以识别出你的身份。 识别出你是谁；你是否有权限访问某个远程库；你是否可以上传你的代码。

• 关联远程库：

        将 本地git库 和 远程github库 建立关联。可以方便本地库和远程库的 push 和 pull。

# 添加远程库      远程库别名               库地址
git remote add   origin     git@github.com:zanghongjiu99/repo.git  
# 注意：origin是默认会有的别名
git remote add   test       git@github.com:zanghongjiu99/repo2.git 
# 还可以设置自己的别名

git remote -v  # 查看关联的所有远程库
git remote show origin # 关联远程库后，本地分支和远程分支的对应关系
git remote remove origin  # 删除关联
git remote rename origin origin2 # 重命名

• 管理员第一次Push：

        将本地 master 分支的内容上传到 关联的远程库中，push 结束后在 github 中可见。

# 本地的master分支上传到与之有跟踪关系的远程分支中，(克隆时就会建立跟踪关系)，如果远程分支不存在，则会建立远程分支
git push origin master
# 本地存在分支dev，上传到远程库origin的分支dev,如果没有dev,将建立远程分支dev
git push origin dev:dev
# 本地库dev:远程库dev  本地库dev2:远程库dev2
git push origin dev:dev dev2:dev2

# push动作，其一需要你有权限push，其二需要在你clone之后没人push过。(乐观锁机制)

• 员工Clone：

        下载远程库中的内容

# 任意新建一个git仓库，并执行：
git clone git@github.com:zanghongjiu99/repo.git   #ssh 地址，将远程库clone到本地，已设置key，不用口令
git clone https://github.com/zanghongjiu99/zhj_repo.git  #https地址，需要输入github口令
# 在任意目录下执行git clone，会将整个远程仓库作为子文件夹放在当前目录下，当前目录仍为普通目录(非Git仓库)，下载下来的远程仓库子文件夹则已为Git仓库，自带.git目录
# 当执行 `git clone` 命令的时候，默认配置下远程 Git 仓库中的每一个文件的每一个版本都将被拉取下来，包括所有分支，默认只显示一个master分支，需要手动执行`git checkout xxx(远程仓库中其他分支名)`把远程仓库中分支内容显示在本地，此时本地的所有分支都与远程仓库某分支对应且内容相同
# clone 只在初次从Git服务器下载项目时执行一次，后续在需要同步应该执行 `pull 或 fetch`

• 员工Fetch-Merge：

        拉取远程的新内容，存于本地版本库。

        注意：并没有合并到本地库的分支中，需要通过 merge 手动合并

# 拉取远程 master分支中本地没有的内容(即其他开发者push的内容)，
git fetch origin master # 拉取的分支名为 ”origin/原始分支名“存储位置：【.git\refs\remotes\origin】
git merge origin/master #把拉取下来的master分支的内容 合并到本地库中的分支上
# 如上两个指令可以将git服务器上的最新版本状态同步到本地库中，相当于pull

# 拉取所有分支的的内容(本地没有的，其他开发者push的内容)(假定有分支：dev2,dev3) 
git fetch origin
git checkout dev2 并 git merge origin/dev2 #切换到dev2分支，并合并拉取下来的内容
git checkout dev3 并 git merge origin/dev3

git checkout dev2 并 git diff origin/dev2 #切换到dev2分支，比较拉取的内容中的dev2分支 和 本地dev2分支的不同

• 员工Pull：

        等价于 git fetch + git merge 拉取远程的新内容，并合并到当前分支

# 语法格式：git pull <远程主机名> <远程分支名>:<本地分支名>
# 完整写法
git pull origin master:master

# 省略本地分支名 = master:当前分支(缺省)
git pull origin master

# 拉取远端origin的所有分支中的改变，并将属于当前分支的改变自动merge
# 其他分支需要自己merge，比如：【git checkout dev2    git merge origin/dev2】
git pull origin

---

协同工作流程

• 项目管理员( 项目经理 )：

1> 由管理员负责创建一个远程库，初始的库中什么也没有，成为裸库(库的名称建议和项目同名)
2> 管理员会在idea中创建一个空项目,其中包含`.gitignore`文件，
    并在项目根目录下 `git init`. 建立本地库。并建立 `dev分支`。
3> 管理员将本地库同步到远程库：`git push 远程库地址 master:master dev:dev`  
4> 将其他开发人员拉入远程库的 `开发成员列表中` ，使得其他开发人员可以访问该远程库。
5> master分支设置为 `protected分支`，只有管理员有权限将代码合并到其中，
    dev分支设置为 `常规分支`所有开发人员都可以其中合并代码。

• 开发人员：

1> 初始化：在cmd或idea中`clone` 远程库，获得项目。执行 `git clone 远程库地址` 即可。会建立本地库
2> 获得项目时，本地库中只显示master分支，需要执行： `git checkout dev` 即可获得dev分支。
3> 后续的开发中，都要在dev分支上进行。
    开发完一个功能并测试通过后就可以 `git  add ..`  并 `git commit ..`提交到本地的dev分支中，
    然后 `git push 远程库地址 dev` 同步到远程dev分支中。	
4> 注意如果在 `git push` 远程库时，有人比你早一步 `git push`,git服务器将拒绝你的 `git push`.（乐观锁原理）	  
    不过很简单，你需要 `git fetch 远程库  dev` 并 `git merge origin/dev` ，然后再 `git push`即可。

后续的开发，会接到一个个的功能任务，往复操作 3> 和 4> 而已。

• 效果：

        由上而下分别是【远程master，远程dev，micheal的本地dev，bob的本地dev】 ：

        在实际开发中，我们应该按照几个基本原则进行分支管理：

        首先，master分支应该是非常稳定的， 也就是仅用来发布新版本，平时不能在上面干活；

        那在哪干活呢？干活都在dev分支上，也就是说，dev 分支是不稳定的，到某个时候，比如 1.0版本发布时，再有管理员把dev分支合并到 master上，在 master分支发布 1.0 版本；

        你和你的小伙伴们每个人都在 dev 分支上干活，每个人都有自己的分支，时不时地往 dev 分支上合并就可以了。

---

标签

        在众多的提交中，总有些提交是尤为重要的，比如重大bug的解决，比如一个新版本的发布等。这些提交身处分支的众多提交点中，可以为他们打标签，让他们更显眼，可以更快速的找到他们。

• 打标签：

# 创建的标签会自动 打在最近的提交点上
# 创建轻量标签
git tag v1.1.0
# 创建附注标签 （ 就是带说明的轻量标签 ）
git tag -a v1.1.1 -m "说明文字"
#如果要给过往的提交点 追打标签，需要 git log 去查看提交点的 “commitID”
git tag [-a] v1.1.1 "commitID"

• 查看标签

#查看所有分支上的所有标签 ( 查看标签并不区分分支 )
git tag
#查找标签名以 “v1.1”开头的标签
git tag -l "v1.1*" 
#显示标签 及其对应的提交点信息
git show v1.1.0

• 共享标签

        标签不会随提交点一起 提交到远程服务器，需要单独push

# 将标签 “v1.1.1”  同步到git服务器
git push origin v1.1.1
# 同步所有git服务器上没有的标签
git push origin --tags

• 删除标签

        标签删除需要在本地和远程分别删除。

# 在本地删除标签
git tag -d v1.1.1
# 删除远程库中的标签
git push origin :refs/tags/v1.1.1

• 标签使用

        标签主要用于发布版本。

        假定已经为各个发布版本打了标签：v1.0 v1.1 v2.0 ....，现在需要 1.0版本

# 分离一个指针到 v1.0提交点位置
git checkout v1.0 #（ 分离头指针，是一个临时指针，不归属任何分支 ）
# 然后将工作区的代码打包(jar或war)即可。
# 最后随意切一个分支，分离头指针消失。什么也没发生过。
git checkout ”任意分支“

---

别名

        一些指令比较麻烦，可以定义别名，简化书写。

git config --global alias.ck checkout         # git ck等价git checkout
git config --global alias.commit "commit -m"  # git commitm 等价 git commit -m
git config --global alias.br branch           # git br
git config --global --unset alias.commitm     # 删除alias.commitm

---

忽略文件

        在idea开发时，会有很多和项目本身无关的文件，还有一些是不能共享的项目文件，比如包含自己数据库信息的 db.properties，还有java的字节码文件。

        此类文件，不必出现在版本控制中，可以在项目根目录下创建忽略文件：.gitignore，文件中定义

# 所有class后缀的文件
*.class
# 所有jar后缀的文件
*.jar
*.iml
*.war
# .idea 文件夹
.idea
# 所有.txt 文件
*.txt
db.properties
# abc.txt除外，不忽略
!abc.txt

gitignore: A collection of useful .gitignore templates

https://github.com/github/gitignore

---

补充

• 储存工作

        功能还没写完，还不适合提交，但此时需要去解决另一个bug，需要切换分支，则当前功能工作区中的改动会被新分支的内容覆盖，所以此时可以先储存下当前功能的内容，然后就可以放心的切换到其他分支先干别的事，过后再回来。

git stash ：储存当前修改( 为提交的内容 ，包括未暂存和已暂存的)
#                                             分支                      文件
Saved working directory and index state WIP on dev: a795274 dev commit Test.java

git stash list：查看存储列表
# 标识            分支                      储存文件
stash@{0}: WIP on dev: a795274 dev commit Test.java

git checkout 其他分支：可以放心的切到其他分支，完成其他工作
git checkout dev：切回dev分支，并：git stash apply：恢复储存的工作，继续编码


# 注意：没用的存储建议删除：
git stash drop stash@{0}：删除某一个储存点
git stash clear：清空所有储存点

• 回退详解

        回退是指：提交点回退。就是在某个分支上指针后移。回到之前的某个版本。

        三种回退模式：mixed、hard、soft，默认mixed

git reset --mixed HEAD~

git reset --hard HEAD~

git reset --soft HEAD~

# 基本使用： 当前分支 指针回退两步，就是回退到上上一个提交点。（无论是 mixed，soft，hard）
git reset HEAD~~
git reset HEAD~2
# 基本使用： 当前分支 指针指向到对应commitID的的提交点
git reset commitID

        回退时，除了指针必然移动，还有些细节：

##################### Soft ##########################
# 指针后退一步，但暂存区内容不变，工作区内容不变
git reset --soft HEAD~
假如有3个提交点，依次为 A --> B --> C
A中：添加一个文件abc.txt
B中：修改abc.txt,及其他一些修改
C中：添加一个文件def.txt 并提交。
C中：继续修改，并最终完成功能，做最终提交。可以还有一种选择：
【先从C回退到A，然后再提交，提交点就变为：A --> D.提交后内容总量不变，但起到提交点被压缩的作用】

##################### Mixed ##########################
# 指针后退一步，但暂存被清空：即版本库回到了上次提交的状态。 但工作区不变。
git reset --mixed HEAD~
# 然后执行：
git checkout -- abc.txt #从版本库中拉取abc.txt文件，可以将工作区的某个文件回退到上个版本
##############################################
# 或者执行，达到将暂存内容清空
git reset --mixed HEAD #指向当前提交点，其实没回退指针，但会清空暂存。
# 然后执行：
git checkout --abc.txt #从版本库中拉取abc.txt文件，恢复当前版本的原始状态 ( 撤销了所有修改 )

###################### Hard ###########################
#指针后退一步，暂存清空，且将工作区也同步到指针所指的状态
git reset --hard HEAD~  #用于拉取某个特定提交点的文件

• 修补提交

        提交后发现有问题，比如有些注释忘记修改，比如提交描述不够详细等等。

        当然可以在修改后再提交一次，但是还有更好的办法：

git commit --amend -m"xxxxx"：会再次提交并替换上次提交