一，配置账户，注意需要和Github账户设置一样

git config --global user.name xxx

git config --global user.emailxxx@foxmail.com

二，查看配置

git config --list

user.name=xxx

user.email=xxx@foxmail.com

三，创建Git仓库

一，本地创建一个新仓库

$ git clone http://git.dayuan.cc/practice/git-exmple.git 

cd git-exmple

$ git remote add origin http://git.dayuan.cc/practice/git-exmple.git 、

$ git add .

$ git commit -m "Initial commit"

$ git push -u origin master

二，在已经存在的目录中创建仓库

cd existing_folder

$ git init

$ git remote add origin http://git.dayuan.cc/practice/git-exmple.git

$ git add .

$ git commit -m "Initial commit"

$ git push -u origin master

三，拉取远程分支并创建本地分支

// dev2为远程分支,dev1为本地分支  

$ git checkout -b dev1 origin/dev2;

从远程分支dev拉取到本地并且创建本地分支dev，且俩者之间建立映射关系,同时当前分支会切换到dev1

//dev2为远程分支,dev1为本地分支

 $ git fetch origin dev2:dev1; 

使用该方式会在本地新建分支dev1，但是不会自动切换到该本地分支dev1，需要手动checkout。采用此种方法建立的本地分支不会和远程分支建立映射关系。

四，将本地已存在的仓库推送到远程仓库

cd existing_repo

$ git remote rename origin old-origin

$ git remote add origin http://git.dayuan.cc/practice/git-exmple.git

$ git push -u origin --all

$ git push -u origin --tags

四，查看Git状态

git status

一般来说会显示需要提交的文件（uncommited）和未追踪的文件（untracked）

uncommited：已有的，刚被修改尚未提交的

untracked：原先没有的，新建的

查看分支相关命令

$ git branch -r; //查看远程分支

 $ git branch; //查看本地分支 

$ git branch -a; //查看所有分支  

建立本地分支与远程分支的映射关系（或者为跟踪关系track）

这样使用git pull或者git push时就不必每次都要指定从远程的哪个分支拉取合并和推送到远程的哪个分支了。

$ git branch -vv

输出映射关系

// dev为远程分支名 

$ git branch -u origin/dev 

将当前本地分支与远程分支建立映射关系

$ git branch --unset-upstream

撤销当前本地分支与远程分支的映射关系

切换当前本地分支

// dev为本地分支名

 $ git checkout dev; 

拉取远程分支代码

使用的前提是当前分支需要与远程分支之间建立映射关系 

推送本地分支代码到远程分支

$ git push

使用的前提是当前分支需要与远程分支之间建立映射关系

合并分支

现在有dev本地分支与远程分支，master本地分支与远程分支现在将dev的分支代码合并到master主干上  

1.切换到本地分支dev上，并且pull拉取一下远程dev分支上的改动地方  

2.将所有本地修改进行commit并且push到远程dev分支上，保证没有遗漏的，确保当前本地dev与远程dev是一致的

 3.将当前本地分支切换到本地master上  

4.将本地分支dev合并到本地master上 

5.将本地已经合并了dev分支的master进行push到远程master上 大概思路就是这样。需要注意的是在进行merge(合并)的时候需要禁用fast-forward模式 

具体的合并命令: git merge --no-ff dev (dev为本地被合并的分支名字)

辅助分支

feature分支：

从 develop 分支建一个 feature 分支，并切换到 feature 分支 

$ git checkout -b myfeature develop 

Switched to a new branch "myfeature" 

合并feature 分支到 develop ：

$ git checkout develop  

Switched to branch 'develop'

$ git merge --no-ff myfeature

Updating ea1b82a..05e9557

(Summary of changes)

$ git branch -d myfeature

Deleted branch myfeature

$ git push origin develop

上面我们 merge 分支的时候使用了参数 --no-ff，ff 是fast-forward的意思，--no-ff就是禁用fast-forward。

release分支

新建rlease分支:

$ git checkout -b release-1.2 develop 

Switched to a new branch "release-1.2" 
$ ./bump-version.sh 1.2 

File modified successfully, version bumped to 1.2. 

$ git commit -a -m "Bumped version number to 1.2" 

[release-1.2 74d9424] Bumped version number to 1.2  

1 files changed, 1 insertions(+), 1 deletions(-)     

release 分支合并到 master 分支 :

$ git checkout master 

Switched to branch 'master'

 $ git merge --no-ff release-1.2 

Merge made by recursive. (Summary of changes) 

$ git tag -a 1.2    

release 分支合并到 develop 分支

$ git checkout develop

 Switched to branch 'develop'

 $ git merge --no-ff release-1.2 

Merge made by recursive. (Summary of changes)   

删除 release 分支

$ git branch -d release-1.2 

Deleted branch release-1.2 (was ff452fe). 

hotfix分支 

新建hotfitx分支

$ git checkout -b hotfix-1.2.1 master 

Switched to a new branch "hotfix-1.2.1" 

$ ./bump-version.sh 1.2.1

 Files modified successfully, version bumped to 1.2.1. 

$ git commit -a -m "Bumped version number to 1.2.1" 

[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1     

1 files changed, 1 insertions(+), 1 deletions(-)   

Fix bug

$ git commit -m "Fixed severe production problem"

 [hotfix-1.2.1 abbe5d6] Fixed severe production problem 

5 files changed, 32 insertions(+), 17 deletions(-)  

 buffix 之后，hotfix 合并到 master

$ git checkout master

 Switched to branch 'master' 

$ git merge --no-ff hotfix-1.2.1 

Merge made by recursive. 

 (Summary of changes) 

$ git tag -a 1.2.1    

hotfix 合并到 develop 分支

$ git checkout develop 

Switched to branch 'develop' 

$ git merge --no-ff hotfix-1.2.1

 Merge made by recursive. 

(Summary of changes)    

删除 hotfix 分支 u

$ git branch -d hotfix-1.2.1

Deleted branch hotfix-1.2.1 (was abbe5d6). 

五，添加Git文件到暂存区（需要和版本库区分）

git add <name>

六，Git提交文件

git commit -m "add a function in test.java"

-m表示注释，为提交时的说明，必须要有！

七，Git删除文件（夹）

git rm test.txt//删除文件

git rm -r filebook //删除文件夹

git rm和直接删除的区别在于git rm会将此文件的操作记录删除，而直接删除仅仅是删除了物理文件，没有删除和此文件相关的记录。git rm后会在版本库产生区别（有操作日志），而直接删除没有。

git rm test.txt => git commit -m 'delete a file'rm test.txt => git commit -am 'delete a file'注意：命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。 

八，Git操作日志

git log --decorate --graph --oneline --all #显示当前及之前的版本号

git log --pretty=oneline  #将版本历史显示为一行，历史版本号全部显示

git log --pretty=oneline --abbrev-commit  #将版本历史显示为一行，历史版本号部分显示

git log --graph      #查看分支合并图

九，版本回退

执行版本退回后，本地工作区的内容会自动和回退到的版本库版本的内容保持同步

git reset --hard HEAD^  回退到上一个版本

git reset --hard HEAD^^ 回退到上上个版本，以此类推，一次提交即为一个版本

git reset --hard e9efa77  回退到 e9efa77  版本

这种方式回退代码的弊端显而易见 ，回退后的版本会失去之后提交的信息， 所以，有些公司明令禁止使用 git reset命令去回退代码 

故此，Git  Revert 就诞生了 ！

git revert的作用通过反做创建一个新的版本，这个版本的内容与我们要回退到的目标版本一样，但是HEAD指针是指向这个新生成的版本，而不是目标版本。

$ git revert -------

当然，我们还可以批量回退！

$ git revert OLDER_COMMIT^..NEWER_COMMIT

错误的提交 C 和 D 依然保留，将来进行甩锅的时候也有依可循。而这种做法，正是企业所鼓励的。 

十，Git暂存区撤销操作

工作区修改了文件，而且执行了add，但还没执行commit，暂存区还是可以撤销的

git reset HEAD readme.txt

备注：git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本。

-------------------------------------------------------------

与github/gitee协同使用（git代码托管服务器）

和GitHub相比，码云（Gitee）也提供免费的Git仓库。此外，还集成了代码质量检测、项目演示等功能。对于团队协作开发，码云还提供了项目管理、代码托管、文档管理的服务，5人以下小团队免费。

1.配置远程仓库免密登陆

（1）在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：ssh-keygen -t rsa -C "xxx@foxmail.com"

备注：一路回车，执行生成 id_rsa 私钥 和 id_rsa.pub 公钥，Windows用户在git bash中输入上述指令

（2）获得key的内容，复制下来，添加到gitHub的SSH key中

windows位置：C:\Users\用户名\.ssh\id_rsa.pub

Linux位置：cat ~/.ssh/id_rsa.pub

（3）ssh -T git@github.com#验证key，根据提示输入yes，添加为信任主机

或者ssh -T git@git.oschina.net

2.添加远程仓库

git remote add origin https://github.com/xxx/LearnGit.git（https方式）

（ssh方式）

此处可以为https地址也可以是ssh地址，orign为设置的远程仓库的别名，强烈建议使用ssh方式，因为https方式每次都要输入用户名和密码

如果需要修改传输协议：

（1）git remote rm <远程主机名>（删除远程仓库）

（2）设置传输方式和目标远程仓库

（3）git push -u <远程主机名> <本地分支名>

码云的添加远程仓库方法：

git remote add origin git@gitee.com:xxx/LearnGit.git（ssh方式）

如果git remote add失败，并报错：fatal: remote origin already exists.

说明本地库已经关联了一个名叫origin的远程库，此时，可以先用git remote -v查看远程库信息：

origin  git@github.com:xxx/LearnGit.git (fetch)

origin  git@github.com:xxx/LearnGit.git (push)

表示本地库已经关联了Github上的origin远程库，需要先删除已有的Github库：

git remote remove origin

再关联码云的远程库（注意路径中需要填写正确的用户名）：

git remote add gitee git@gitee.com:xxx/LearnGit.git

因为git本身是分布式版本控制系统，可以同步到另外一个远程库，当然也可以同步到另外两个远程库，所以一个本地库可以既关联GitHub，又关联码云！使用多个远程库时，要注意git给远程库起的默认名称是origin，如果有多个远程库，我们需要用不同的名称来标识不同的远程库。仍然以learngit本地库为例，先删除已关联的名为origin的远程库：git remote rm origin然后，先关联GitHub的远程库：git remote add github git@github.com:xxx/LearnGit.git注意，远程库的名称叫github，不叫origin了。接着，再关联码云的远程库：git remote add gitee git@gitee.com:xxx/LearnGit.git同样注意，远程库的名称叫gitee，不叫origin。现在，我们用git remote -v查看远程库信息，可以看到两个远程库：gitee git@gitee.com:xxx/LearnGit.git (fetch)gitee git@gitee.com:xxx/LearnGit.git (push)github git@github.com:xxx/LearnGit.git (fetch)github git@github.com:xxx/LearnGit.git (push)如果要推送到GitHub，使用命令：git push github master如果要推送到码云，使用命令：git push gitee master这样一来，本地库就可以同时与多个远程库互相同步：

3.查看远程仓库及传输协议

git remote

git remote -v  查看名称和详细地址

4.删除远程仓库

git remote remove <远程主机名>

5.推送本地分支到远程仓库

git push <远程主机名> <本地分支名>:<远程分支名>

如果省略远程分支名，则表示将本地分支推送与之存在“追踪关系”的远程分支（通常两者同名），如果该远程分支不存在，则会被新建。

git push origin <本地分支名>

git push origin master

如果当前分支与多个主机存在追踪关系，则可以使用-u选项指定一个默认主机，这样以后就可以不加任何参数使用git push。

git push -u <远程主机名> <本地分支名>  例如：git push -u origin master

6.将远程仓库克隆为本地仓库

git clone git@github.com:xxx/LearnGit.git

注意：

（1）不能使用别名

（2）默认情况下，从远程clone到本地的库只能看到master分支，如果要将远程的分支同步到本地：

git checkout -b <本地分支名> <远程主机名>/<远程分支名>

前提是远程<远程主机名>必须存在名为<远程分支名>的分支，而且<本地分支名>和<远程分支名>最好一致。

7.本地仓库更新

将远程存储库中的更改合并到当前分支中。在默认模式下，git pull是git fetch后跟git merge FETCH_HEAD的缩写。更准确地说，git pull使用给定的参数运行git fetch，并调用git merge将检索到的分支头合并到当前分支中。 使用--rebase，它运行git rebase而不是git merge。

以下是一些示例：

git pull <远程主机名> <远程分支名>:<本地分支名>

比如，要取回origin主机的next分支，与本地的master分支合并，需要写成下面这样 -

git pull origin next:master

如果远程分支(next)要与当前分支合并，则冒号后面的部分可以省略。上面命令可以简写为：

git pull origin next

上面命令表示，取回origin/next分支，再与当前分支合并。实质上，这等同于先做git fetch，再执行git merge。

git fetch origin  =>  git merge origin/next

在某些场合，Git会自动在本地分支与远程分支之间，建立一种追踪关系(tracking)。比如，在git clone的时候，所有本地分支默认与远程主机的同名分支，建立追踪关系，也就是说，本地的master分支自动“追踪”origin/master分支。Git也允许手动建立追踪关系：

git branch --set-upstream-to=远程主机名/<远程分支名>  <本地分支名>

比如git branch --set-upstream-to=origin/next master，指定master分支追踪origin/next分支。

git pull origin

上面命令表示，本地当前分支自动与对应的origin主机”追踪分支”(remote-tracking branch)进行合并。

如果当前分支只有一个追踪分支，连远程主机名都可以省略。

git pull

上面命令表示，当前分支自动与唯一一个追踪分支进行合并。

如果合并需要采用rebase模式，可以使用–rebase选项。

git pull --rebase <远程主机名> <远程分支名>:<本地分支名>

git fetch和git pull的区别（1）git fetch：相当于是从远程获取最新版本到本地，不会自动合并。git fetch origin mastergit log -p master..origin/mastergit merge origin/master以上命令的含义：首先从远程的origin的master主分支下载最新的版本到origin/master分支上然后比较本地的master分支和origin/master分支的差别最后进行合并上述过程其实可以用以下更清晰的方式来进行：git fetch origin master:tmpgit diff tmp git merge tmp（2）git pull：相当于是从远程获取最新版本并merge到本地git pull origin master上述命令其实相当于git fetch 和 git merge在实际使用中，git fetch更安全一些，因为在merge前，可以查看更新情况，然后再决定是否合并。

8.查看分支

git branch

9.创建分支

git branch <name>

10.创建并切换到分支

git checkout -b <name>

备注：git checkout命令加上-b参数表示创建并切换，相当于以下两条命令

git branch <name>git checkout <name>

11.切换分支

git checkout <name>

切换分支后，在git bash中显示为绿色

12.删除分支

git branch -d <name>

如果分支没有合并，删除分支就表示会丢失修改，此时git无法使用-d删除，可使用-D强行删除

git branch -D <name>

注意：打了标签的分支，Git在删除该分支时，从版本树起始到此标签间的全部历史轨迹均会保留，此时删除分支操作只是删除分支本身的名称，因此可以说该分支没有必要长期保存。而在其他版本控制工具中，删除分支通常意味着删除分支上的所有历史轨迹，所以不能因为打了标签就认为其没有必要保存。

13.合并分支

直接合并：

如果顺着一个分支走下去可以到达另一个分支的话，那么Git在合并两者时，只会简单移动指针，所以这种合并成为快进式(Fast-forward)。

压力合并：

将一条分支上的若干个提交条目压合成一个提交条目，提交到另一条分支的末梢。把dev分支上的所有提交压合成主分支上的一个提交，即压合提交：

$ git checkout master 

$ git merge --squash dev 

dev上的所有提交已经合并到当前工作区并暂存，但还没有作为一个提交，可以像其他提交一样，把这个改动提交到版本库中：

$ git commit –m “something from dev”

拣选合并 ：

拣选另一条分支上的某个提交条目的改动带到当前分支上。每一次提交都会产生一个全局唯一的提交名称，利用这个名称就可以进行拣选提交。

比如在dev上的某个提交叫：wo_zui_shuai ,把它合并到master中： 

$ git checkout master 

$ git cherry-pick wo_zui_shuai

要拣选多个提交，可以给git cherry-pick命令传递-n选项，比如：

$ git cherry-pick –n wo_zui_shuai 

这样在拣选了这个改动之后，进行暂存而不立即提交，接着可以进行下一个拣选操作，一旦拣选完需要的各个提交，就可以一并提交。 

git合并默认使用Fast forward模式，一旦删除分支，会丢掉分支信息，也就看不出来曾经做过合并

git merge <name>    #基于当前分支，合并另外一个分支，前提需要保证分支之间不冲突

如果强制禁用Fast forward模式，即普通模式，Git就会在merge时生成一个新的commit

git merge --no-ff -m "there is a comment" <name>

因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。

工作中，肯定需要不管有没有分支被删除，都要从分支历史上就查看所有的历史分支信息，所以要使用普通模式合并。

冲突处理：

<<<<<<<标记冲突开始，后面跟的是当前分支中的内容。HEAD指向当前分支末梢的提交。

=======之后，>>>>>>>之前是要merge过来的另一条分支上的代码。

>>>>>>>之后的dev是该分支的名字。

14.创建tag

（1）git tag <tagname>  #默认在HEAD版本

（2）对指定的commit版本创建tag

需要先找到历史commit的id

git log --pretty=oneline --abbrev-commit

然后对指定的commit创建tag：

git tag <tagname> <commitid>

（3）创建带有说明的tag，用-a指定标签名，-m指定说明文字

git tag -a <tagname> -m "there is a tag description" [<commitid>]

（4）通过-s用私钥签名一个标签，签名采用PGP签名

git tag -s <tagname> -m "there is a tag description" [<commitid>]

必须首先安装gpg（GnuPG），如果没有找到gpg，或者没有gpg密钥对，就会报错，参考GnuPG帮助文档配置Key。

15.查看tag

git tag    #显示的tag不是按时间顺序排列，而是按字母顺序排列

如果想查看tag和commit的对应关系，可以用

git log --pretty=oneline --abbrev-commit

如果想查看tag的的详细情况，可以用

git show <tagname>

16.删除tag

创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除：

git tag -d <tagname>

如果标签已经推送到远程，要删除远程标签就麻烦一点：

（1）先本地删除：git tag -d <tagname>

（2）再远程删除：git push origin :refs/tags/<tagname>

17.推送标签至远程

git push origin <tagname>

或者，一次性推送全部尚未推送到远程的本地标签：

git push origin --tags

18.现场的保存与恢复

git stash      #将目前的工作现场保存

git stash list  #查看所有保存的工作现场

工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：

一是用git stash apply stash@{0}恢复，但是恢复后，stash内容并不删除，你需要用git stash drop stash@{0}来删除；

另一种方式是用git stash pop，恢复的同时把stash内容也删了，这种方式省时省力

注意点：

（1）如果在分支下新建文件，而尚未执行add操作，stash无法将新文件纳入保存的现场，因为stash只对被修改的被追踪的文件和暂存的变更有效，对于新文件必须先执行add。

（2）如果修改分支下的已被追踪的文件，不管有没有对修改的文件进行add操作，如果执行stash，所有修改会被纳入保存的现场，而文件会恢复成修改前的状态。恢复现场后，文件又呈现被修改后的状态。特别的是，如果修改的文件在stash前已经被add了，恢复现场后，暂存区的内容就会清空，相当于这个文件从未被add一样。

19.设置Git UI颜色

让Git显示颜色，会让命令输出看起来更醒目

git config --global color.ui true

20.忽略特殊文件

（1）在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件。不需要从头写.gitignore文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了。所有配置文件可以直接在线浏览：https://github.com/github/gitignore

忽略文件的原则是：

忽略操作系统自动生成的文件，比如缩略图等；

忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件；

忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件。

比如一个完成的.gitignore文件，内容如下：

------------------------------

# Windows:Thumbs.dbehthumbs.dbDesktop.ini

# Python:*.py[cod]*.so*.egg*.egg-infodistbuild

-------------------------------

（2）把.gitignore也提交到Git

git add .gitignore

git commit -m "there is a description"

就完成了！当然检验.gitignore的标准是git status命令是不是显示working tree clean。

使用Windows的注意：如果在资源管理器里新建一个.gitignore文件，系统会非常弱智地提示必须输入文件名，但是在文本编辑器里“保存”或者“另存为”就可以把文件保存为.gitignore了。

（3）如果确实想要添加已经被.gitignore忽略的文件，可以用-f强制添加到Git

git add -f test.class

（4）怀疑.gitignore写的有问题，需要查找哪个规则写错了，可以用git check-ignore命令检查：

git check-ignore -v App.class.gitignore:3:*.class    App.class

表示.gitignore的第3行规则忽略了App.class这个文件，于是我们就可以知道应该修订哪个规则。

21.为命令配置别名

（1）命令可以简写，用git st表示git status，再比如用co表示checkout、ci表示commit、br表示branch：

git config --global alias.co checkoutgit config --global alias.ci commitgit config --global alias.br branch

以后提交就可以简写成：

git ci -m "there is a description"

--global参数是全局参数，也就是这些命令在这台电脑的所有Git仓库下都有用。

（2）命令git reset HEAD <filename>可以撤销暂存区的修改（unstage），重新放回工作区。既然是一个unstage操作，就可以配置一个unstage别名：

git config --global alias.unstage 'reset HEAD'

就可以简化命令：

git unstage test.py  =  git reset HEAD test.py

（3）配置一个git last，让其显示最后一次提交信息：

git config --global alias.last 'log -1'

这样，用git last就能显示最近一次的提交：

git lastcommit 015851cbe2902bf01fbba198af5d6705dc0e03ac (HEAD -> dev)

Author: xxx <xxx@foxmail.com>

Date:  Mon Apr 23 13:52:44 2018 +0800

    add git ignore list

（4）还有把lg配置成了：

git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

来看看git lg的效果：

22.修改配置文件

配置Git的时候，加上--global是针对当前用户起作用的，如果不加，那只针对当前的仓库起作用。

每个仓库的Git配置文件都放在.git/config文件中：

cat .git/config

-----------------------------------------------------------------------------

[core]

        repositoryformatversion = 0

        filemode = false

        bare = false

        logallrefupdates = true

        symlinks = false

        ignorecase = true

[branch "master"]

[branch "dev"]

[remote "github"]

        url = git@github.com:xxx/LearnGit.git

        fetch = +refs/heads/*:refs/remotes/github/*

[remote "gitee"]

        url = git@gitee.com:xxx/LearnGit.git

        fetch = +refs/heads/*:refs/remotes/gitee/*

-----------------------------------------------------------------------------

而当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig中：

-----------------------------------------------------------------------------

[user]

name = xxx

email = xxx@foxmail.com

[gpg]

program = C:\\Program Files (x86)\\gnupg\\bin\\gpg.exe

[color]

ui = true

[alias]

co = checkout

ci = commit

br = branch

last = log -1

lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

-----------------------------------------------------------------------------

别名就在[alias]后面，要删除别名，直接把对应的行删掉即可。配置别名也可以直接修改这个文件，如果改错了，可以删掉文件重新通过命令配置。

多人协作的工作模式通常如下：

（1）首先将远程仓库克隆为本地仓库

git clone git@github.com:xxx/LearnGit.git

（2）在本地创建和远程分支对应的分支

git checkout -b <本地分支名> origin/<远程分支名>

本地和远程分支的名称最好一致；

（3）在本地分支完成任务后，可以试图用git push <远程主机名> <本地分支名>推送自己的修改；

（2）如果推送失败，则表明远程分支比本地更新，需要先用git pull试图合并；

（3）如果pull失败并提示“no tracking information”，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to=<远程主机名>/<远程分支名>  <本地分支名>创建链接；

（4）如果合并有冲突，则解决冲突，并在本地提交（add => commit）；

（5）没有冲突或者解决掉冲突后，再用git push <远程主机名> <本地分支名>推送就能成功。

命名规范：

版本号主要有3部分构成（由两个.分割成三部分）主版本、次版本、修订号：

并行开发 ：

1，依据迭代的发版计划和任务分解，创建feature（不同迭代需通过版本号隔离，同一个迭代内要上线的功能需要通过feature隔离） ，迭代内，只允许主迭代的feature代码提交到develop分支 

问题修改：

2，release(fit)环境的问题修复：应从release分支拉出分支进行问题修复，修复后及时合并到develop主分支 

3，master环境的问题修复：应从生产环境对应的tag（一般为最新的版本号）拉出分支进行问题修复，问题修复后及时合并代码至develop主分支和master主分支