Git配置
在Windows上安装Git
在Windows上使用Git，可以从Git官网直接下载安装程序，然后按默认选项安装即可。
安装完成后，在开始菜单里找到“Git”->“Git Bash”，蹦出一个类似命令行窗口的东西，就说明Git安装成功！
安装完成后，还需要最后一步设置，在命令行输入：
1 | $ git config --global user.name "Your Name" |
注意git config命令的--global参数，用了这个参数，表示你这台机器上所有的Git仓库都会使用这个配置，当然也可以对某个仓库指定不同的用户名和Email地址。
创建版本库
首先，选择一个合适的地方，创建一个空目录：
通过git init命令把这个目录变成Git可以管理的仓库：
Git把仓库建好了，而且告诉你是一个空的仓库（empty Git repository）。
当前目录下多了一个.git的目录，这个目录是Git来跟踪管理版本库的，没事千万不要手动修改这个目录里面的文件，不然改乱了，就把Git仓库给破坏了。
如果你没有看到.git目录，那是因为这个目录默认是隐藏的，用ls -ah命令就可以看见。
文件添加到版本库
首先这里再明确一下，所有的版本控制系统，其实只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等等，Git也不例外。版本控制系统可以告诉你每次的改动，比如在第5行加了一个单词“Linux”，在第8行删了一个单词“Windows”。而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道。
不幸的是，Microsoft的Word格式是二进制格式，因此，版本控制系统是没法跟踪Word文件的改动的，如果要真正使用版本控制系统，就要以纯文本方式编写文件。
因为文本是有编码的，比如中文有常用的GBK编码，日文有Shift_JIS编码，如果没有历史遗留问题，强烈建议使用标准的UTF-8编码，所有语言使用同一种编码，既没有冲突，又被所有平台所支持。
不要使用Windows自带的记事本编辑任何文本文件，建议下载Visual Studio Code代替记事本。
现在我们编写一个readme.txt文件，内容如下：
1 | Git is a version control system. |
一定要放到git22目录下（子目录也行），因为这是一个Git仓库，放到其他地方Git再厉害也找不到这个文件。
把一个文件放到Git仓库只需要两步。
第一步，用命令git add告诉Git，把文件添加到仓库：
1 | $ git add readme.txt |
执行上面的命令，没有任何显示，这就对了，Unix的哲学是“没有消息就是好消息”，说明添加成功。
第二步，用命令git commit告诉Git，把文件提交到仓库：
1 | $ git commit -m "wrote a readme file" |
简单解释一下git commit命令，-m后面输入的是本次提交的说明，可以输入任意内容，当然最好是有意义的，这样你就能从历史记录里方便地找到改动记录。
git commit命令执行成功后会告诉你，1 file changed：1个文件被改动（我们新添加的readme.txt文件）；2 insertions：插入了两行内容（readme.txt有两行内容）。
为什么Git添加文件需要add，commit一共两步呢？因为commit可以一次提交很多文件，所以你可以多次add不同的文件，比如：
1 | $ git add file1.txt |
疑难解答
Q：输入git add readme.txt，得到错误：fatal: not a git repository (or any of the parent directories)。
A：Git命令必须在Git仓库目录内执行（git init除外），在仓库目录外执行是没有意义的。
Q：输入git add readme.txt，得到错误fatal: pathspec 'readme.txt' did not match any files。
A：添加某个文件时，该文件必须在当前目录下存在，用ls或者dir命令查看当前目录的文件，看看文件是否存在，或者是否写错了文件名。
小结
现在总结一下今天学的两点内容：
初始化一个Git仓库，使用git init命令。
添加文件到Git仓库，分两步：
- 使用命令
git add <file>，注意，可反复多次使用，添加多个文件； - 使用命令
git commit -m <message>，完成。
版本管理
版本回退
现在，你已经学会了修改文件，然后把修改提交到Git版本库，现在，再练习一次，修改readme.txt文件如下：
1 | Git is a distributed version control system. |
然后尝试提交：
1 | $ git add readme.txt |
每当你觉得文件修改到一定程度的时候，就可以“保存一个快照”，这个快照在Git中被称为commit。一旦你把文件改乱了，或者误删了文件，还可以从最近的一个commit恢复，然后继续工作，而不是把几个月的工作成果全部丢失。
现在，我们回顾一下readme.txt文件一共有几个版本被提交到Git仓库里了。
在Git中，我们用git log命令查看：
你看到的一大串是commit id（版本号），和SVN不一样，Git的commit id不是1，2，3……递增的数字，而是一个SHA1计算出来的一个非常大的数字，用十六进制表示。
如果嫌输出信息太多，看得眼花缭乱的，可以试试加上--pretty=oneline参数：
每提交一个新版本，实际上Git就会把它们自动串成一条时间线。
首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交，上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。
现在，我们要把当前版本append GPL回退到上一个版本，就可以使用git reset命令：
1 | $ git reset --hard HEAD^ |
看看readme.txt的内容是不是正确的？
1 | cat readme.txt |
果然被还原了。
我们用git log再看看现在版本库的状态：
最新的那个版本append GPL已经看不到了！好比你从21世纪坐时光穿梭机来到了19世纪，想再回去已经回不去了，肿么办？
办法其实还是有的，只要上面的命令行窗口还没有被关掉，你就可以顺着往上找啊找啊，找到那个append GPL的commit id是3b107...，于是就可以指定回到未来的某个版本：
1 | $ git reset --hard 3b107 |
版本号没必要写全，前几位就可以了，Git会自动去找。当然也不能只写前一两位，因为Git可能会找到多个版本号，就无法确定是哪一个了。
再小心翼翼地看看readme.txt的内容：
1 | $ cat readme.txt |
Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把HEAD从指向append GPL。
然后顺便把工作区的文件更新了。所以你让HEAD指向哪个版本号，你就把当前版本定位在哪。
现在，你回退到了某个版本，关掉了电脑，第二天早上就后悔了，想恢复到新版本怎么办？找不到新版本的commit id怎么办？
在Git中，总是有后悔药可以吃的。当你用$ git reset --hard HEAD^回退到add distributed版本时，再想恢复到append GPL，就必须找到append GPL的commit id。Git提供了一个命令git reflog用来记录你的每一次命令：
小结
现在总结一下：
HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。- 穿梭前，用
git log可以查看提交历史，以便确定要回退到哪个版本。 - 要重返未来，用
git reflog查看命令历史，以便确定要回到未来的哪个版本。
工作区和暂存区
工作区（Working Directory）就是你在电脑里能看到的目录，比如我的git22文件夹就是一个工作区
版本库（Repository）工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。
Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
分支和HEAD的概念我们以后再讲。
前面讲了我们把文件往Git版本库里添加的时候，是分两步执行的：
第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；
第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。
因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。
你可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。
俗话说，实践出真知。现在，我们再练习一遍，先对readme.txt做个修改，比如加上一行内容：
1 | Git is a distributed version control system. |
然后，在工作区新增一个LICENSE文本文件（内容随便写）。
先用git status查看一下状态：
1 | $ git status |
Git非常清楚地告诉我们，readme.txt被修改了，而LICENSE还从来没有被添加过，所以它的状态是Untracked。
现在，使用两次命令git add，把readme.txt和LICENSE都添加后，用git status再查看一下：
1 | $ git status |
现在，暂存区的状态就变成这样了：
所以，git add命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支。
1 | $ git commit -m "understand how stage works" |
一旦提交后，如果你又没有对工作区做任何修改，那么工作区就是“干净”的：
1 | $ git status |
现在版本库变成了这样，暂存区就没有任何内容了：
管理修改
为什么Git比其他版本控制系统设计得优秀，因为Git跟踪并管理的是修改，而非文件。
你会问，什么是修改？比如你新增了一行，这就是一个修改，删除了一行，也是一个修改，更改了某些字符，也是一个修改，删了一些又加了一些，也是一个修改，甚至创建一个新文件，也算一个修改。
为什么说Git管理的是修改，而不是文件呢？我们还是做实验。第一步，对readme.txt做一个修改，比如加一行内容：
1 | $ cat readme.txt |
然后，添加：
1 | $ git status |
然后，再修改readme.txt：
1 | Git is a distributed version control system. |
提交：
1 | $ git commit -m "git tracks changes" |
提交后，再看看状态：
1 | $ git status |
咦，怎么第二次的修改没有被提交？
别激动，我们回顾一下操作过程：
第一次修改 -> git add -> 第二次修改 -> git commit
你看，我们前面讲了，Git管理的是修改，当你用git add命令后，在工作区的第一次修改被放入暂存区，准备提交，但是，在工作区的第二次修改并没有放入暂存区，所以，git commit只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次的修改不会被提交。
1 | $ git diff HEAD -- readme.txt |
可见，第二次修改确实没有被提交。
那怎么提交第二次修改呢？你可以继续git add再git commit，也可以别着急提交第一次修改，先git add第二次修改，再git commit，就相当于把两次修改合并后一块提交了：
第一次修改 -> git add -> 第二次修改 -> git add -> git commit
好，现在，把第二次修改提交了，然后开始小结。
小结
现在，你又理解了Git是如何跟踪修改的，每次修改，如果不用git add到暂存区，那就不会加入到commit中。
撤销修改
自然，你是不会犯错的。不过现在是凌晨两点，你正在赶一份工作报告，你在readme.txt中添加了一行：
1 | $ cat readme.txt |
在你准备提交前，一杯咖啡起了作用，你猛然发现了stupid boss可能会让你丢掉这个月的奖金！
既然错误发现得很及时，就可以很容易地纠正它。你可以删掉最后一行，手动把文件恢复到上一个版本的状态。如果用git status查看一下：
1 | $ git status |
你可以发现，Git会告诉你，git restore <file>可以丢弃工作区的修改：
1 | $ git restore readme.txt |
git checkout -- file也可以丢弃工作区的修改。
命令git checkout -- readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销，这里有两种情况：
一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；
一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。
总之，就是让这个文件回到最近一次git commit或git add时的状态。
现在，看看readme.txt的文件内容：
1 | $ cat readme.txt |
文件内容果然复原了。
git checkout -- file命令中的--很重要，没有--，就变成了“切换到另一个分支”的命令，我们在后面的分支管理中会再次遇到git checkout命令。
现在假定是凌晨3点，你不但写了一些胡话，还git add到暂存区了：
1 | $ cat readme.txt |
庆幸的是，在commit之前，你发现了这个问题。用git status查看一下，修改只是添加到了暂存区，还没有提交：
1 | $ git status |
Git同样告诉我们，用命令git restore --staged <file>可以把暂存区的修改撤销掉（unstage），重新放回工作区：
用命令git reset HEAD <file>也可以把暂存区的修改撤销掉（unstage），重新放回工作区：
git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本。
再用git status查看一下，现在暂存区是干净的，工作区有修改：
1 | $ git status |
还记得如何丢弃工作区的修改吗？
1 | $ git checkout -- readme.txt |
现在，假设你不但改错了东西，还从暂存区提交到了版本库，怎么办呢？还记得版本回退一节吗？可以回退到上一个版本。不过，这是有条件的，就是你还没有把自己的本地版本库推送到远程。还记得Git是分布式版本控制系统吗？我们后面会讲到远程版本库，一旦你把stupid boss提交推送到远程版本库，你就真的惨了……
小结
又到了小结时间。
场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- file。
场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD <file>，就回到了场景1，第二步按场景1操作。
场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。
删除文件
在Git中，删除也是一个修改操作，我们实战一下，先添加一个新文件test.txt到Git并且提交：
1 | $ git add test.txt |
一般情况下，你通常直接在文件管理器中把没用的文件删了，或者用rm命令删了：
1 | $ rm test.txt |
这个时候，Git知道你删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻告诉你哪些文件被删除了：
1 | $ git status |
现在你有两个选择，一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit：
1 | $ git rm test.txt |
现在，文件就从版本库中被删除了。
另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：
1 | $ git checkout -- test.txt |
git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。
小结
命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。
远程仓库
推送仓库
现在的情景是，你已经在本地创建了一个Git仓库后，又想在GitHub创建一个Git仓库，并且让这两个仓库进行远程同步，这样，GitHub上的仓库既可以作为备份，又可以让其他人通过该仓库来协作，真是一举多得。
首先，登陆GitHub，创建一个新的仓库，与本地库名相同：
目前，在GitHub上的这个仓库还是空的，GitHub告诉我们，可以从这个仓库克隆出新的仓库，也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitHub仓库。
现在，我们根据GitHub的提示，在本地的仓库下运行命令：
1 | git remote add origin git@github.com:guolinac/springboot_Luckymoney |
请千万注意，把上面的guolinac替换成你自己的GitHub账户名，否则，你在本地关联的就是我的远程库，关联没有问题，但是你以后推送是推不上去的，因为你的SSH Key公钥不在我的账户列表中。
添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。
下一步，就可以把本地库的所有内容推送到远程库上：
1 | git push -u origin master |
把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。
由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。
注意将本地的SSH同步到Github上哦~！
从现在起，只要本地作了提交，就可以通过命令：
1 | git push origin master |
把本地master分支的最新修改推送至GitHub，现在，你就拥有了真正的分布式版本库！
删除仓库
如果添加的时候地址写错了，或者就是想删除远程库，可以用git remote rm <name>命令。使用前，建议先用git remote -v查看远程库信息：
1 | $ git remote -v |
然后，根据名字删除，比如删除origin：
1 | $ git remote rm origin |
此处的“删除”其实是解除了本地和远程的绑定关系，并不是物理上删除了远程库。远程库本身并没有任何改动。要真正删除远程库，需要登录到GitHub，在后台页面找到删除按钮再删除。
小结
要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git；
关联一个远程库时必须给远程库指定一个名字，origin是默认习惯命名；
关联后，使用命令git push -u origin master第一次推送master分支的所有内容；
此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；
分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在，也就是有没有联网都可以正常工作，而SVN在没有联网的时候是拒绝干活的！当有网络的时候，再把本地提交推送一下就完成了同步，真是太方便了！
Git分支，推送，忽略本地变化
创建和使用git仓库
git初始化
.gitignore文件配置：匹配到的文件不推送到git仓库上，也不会检查到本地的变化
添加更新文件
推送到远程git仓库
创建及切换分支
注：前提是安装git并配置git的ssh，否则在pull和push的时候会提示无权限
github创建仓库
初始化git
创建文件type nul>README.md
写入mmall_learning
.gitignore文件配置：创建文件type nul>.gitignore
匹配到的文件不推送到git仓库上，也不会检查到本地的变化
在里面增加：
1 | *.class |
简单命令
初始化：git init
查看变更：git status
文件添加到仓库：git add .
文件提交到版本库：git commit -m “first commit init project”
提交到远程仓库
绑定到远程仓库：git remote add origin git@github.com:guolinac/mmall_learning.git
查看分支：git branch
1 | D:\project_git\mmall>git branch |
把本地改动推送到远程的master上：git push -u origin master
取回远程主机某个分支的更新，再与本地的指定分支合并：git pull
强制推送，直接覆盖远程的master：git push -u -f origin master
Github
我们回到github，可以看到上方已经出现“master had recent pushes less than a minute ago”字样
切换分支：点击main的下拉框，查看master分支
已经是最新版：
查看分支
分支开发，主干发布
查看本地分支：git branch
1 | D:\project_git\mmall>git branch |
查看远程分支：git branch -r
1 | D:\project_git\mmall>git branch -r |
新建分支
在origin/master的基础上，生成v1.0的分支
1 | git checkout -b v1.0 origin/master |
git branch
1 | D:\project_git\mmall>git branch |
将这个分支推送到远程：git push origin HEAD -u
此时github上面已经有三个分支了
v1.0的代码就是从master这个分支的基础上创建的
切换分支
1 | git checkout master |
拉取分支代码
1 | git fetch origin develop #可以使用git fetch origin 拉取全部 |
develop为我的分支名字，根据自己的分支决定。
有的同学可能会用git pull，git pull = git fetch + git merge，因为pull拉取会合并本地文件，可能会导致冲突。
Github仓库master分支到main分支迁移指南
2020年10月1日后，Github会将所有新建的仓库的默认分支从master修改为main，这就导致了一些旧仓库主分支是master，新仓库主分支是main的问题，这在有时候会带来一些麻烦，因此这里提供一种方案将旧仓库的master分支迁移到main分支
具体步骤
四步：
- 克隆原仓库
- 创建并推送
main分支 - 修改默认分支
- 删除
master分支
克隆
首先克隆一份原仓库到本地进行操作：
1 | git clone xxxxxxx.git |
创建并推送main
创建并切换到main：
1 | git checkout -b main |
推送main：
1 | git push origin main |
修改默认分支
这一步需要到Github中进行操作
删除master
删除本地master：
1 | git branch -d master |
删除远程master：
1 | git push origin :master |
这样就算成功迁移到main分支了
测试
在仓库做一些修改后进行提交：
1 | git add -A |
可以看到Github上会有对应更新
修改之前的注释
修改最后一次注释
如果你只想修改最后一次注释
git commit --amend
出现有注释的界面（你的注释应该显示在第一行）， 输入i进入修改模式，修改好注释后，按Esc键 退出编辑模式，输入:wq保存并退出。ok，修改完成。
修改之前的某次注释
输入：git rebase -i HEAD~2
最后的数字2指的是显示到倒数第几次 比如这个输入的2就会显示倒数的两次注释
你想修改哪条注释 就把哪条注释前面的pick换成edit。方法就是上面说的编辑方式：i—编辑，把pick换成edit—Esc—:wq
然后：（接下来的步骤Terminal会提示）git commit --amend
修改注释，保存并退出后，输入：git rebase --continue
已经将代码push到远程仓库
首先，你把最新的版本从远程仓库先pull下来，修改的方法都如上，最后修改完成后，强制push到远程仓库：
git push --force origin master
注：很重要的一点是，你最好保证在你强制push之前没有人提交代码，如果在你push之前有人提交了新的代码到远程仓库，然后你又强制push，那么会被你的强制更新覆盖！！！
修改第一次提交的注释
1 | git rebase -i --root |
按 i 或者 a 编辑，你想修改哪条注释 就把哪条注释前面的pick换成edit，然后edit—Esc—:wq
然后：（接下来的步骤Terminal会提示）git commit --amend
修改注释，保存并退出后，输入：git rebase --continue
查看是否成功
1 | git log |
成功
推送到github，强制推送命令
1 | git push --force origin master |
修改成功
问题解决
Git崩溃，锁未释放怎么办
操作任何git命令，都提示该内容。
Another git process semms to be running in this repository, e.g. an editor opened by ‘git commit’. Please make sure all processes are terminated then try again. If it still fails, a git process remove the file manually to continue…
另一个git进程似乎正在这个存储库中运行，例如。 “git commit”打开的编辑器。请确保所有流程 终止，然后重试。如果仍然失败，git进程 可能已在此存储库中崩溃： 手动删除文件以继续。
原因在于Git在使用过程中遭遇了奔溃，部分被上锁资源没有被释放导致的。
解决方案：
进入.git文件夹，手动将 .git 文件中 index.lock 删除即可（rm -rf index.lock）
push到远程报错
1 | fatal: unable to access 'https://github.com/guolinac/python_web_crawler.git/': Failed to connect to github.com port 443 after 21185 ms: Timed out |
网上找了下遇到类似情况的大家的处理方案，有的说是由于网络不稳定造成的，个人觉得有这方面的原因，因为github提交的时候这个错误不是一定会出来的，为了稳妥起见还是把ssl验证关了方便些
1 | git config --global http.sslVerify "false" |
git log无法退出
使用git log之后无法回到主页面,最后只能暴力关闭git bash. 解决方法其实很简单,输入字母Q即可退出
git push失败， 提示! [rejected] master -＞ master (fetch first)error: failed to push some refs
第一次提交项目到一个新的仓库
我们按照如下的步骤上传了一个项目到仓库的时候，是可以成功的：
1、git init 初始化
2、git add . 将当前目录下修改的所有代码从工作区添加到暂存区
3、git commit -m [‘注释’] 将缓存区内容添加到本地仓库
4、git remote add origin 仓库地址 将本地仓库与远程仓库连接起来
5、git push origin master 将项目推送到远程仓库的master分支上
第二次将一个新的项目在提交到仓库
此时，我们继续按照上面的步骤提交项目，第五步的时候就会出现一个错误！！
git push失败， 提示! [rejected] master -＞ master (fetch first)error: failed to push some refs
出现错误的主要原因是gitee中的README.md文件不在本地代码目录中
此时我们要执行git pull –rebase origin master命令将README.md拉到本地，
然后执行git push origin master就可以成功了
远程仓库已存在
如果你clone下来一个别人的仓库，在此基础上完成你的代码，推送到自己的仓库可能遇到如下问题：
error: remote origin already exists.表示远程仓库已存在。
因此你要进行以下操作：
1、先输入git remote rm origin 删除关联的origin的远程库
2、关联自己的仓库 git remote add origin https://gitee.com/xxxxxx.git
3、最后git push origin master，这样就推送到自己的仓库了。
Git问题Everything up-to-date正确解决方法
先说说出现这个问题的原因：git提交改动到缓存，要push的时候不会将本地所有的分支都push掉，所以出现这个问题。那么我们就需要新建分支提交改动然后合并分支。
1.先创建一个新的分支提交改动
$ git branch newbranch
2.检查这条命令是否创建成功
$ git branch
这时终端会输出：
newbranch
*master
这样就创建成功了，前面的*代表的是当前你所在的工作分支，接下来就要切换工作分支。
3.git checkout newbranch
4.然后将你的改动提交到新的分支上
$ git add XXX
$ git commit -m “XXX”
此时可以$ git status 检查下提交情况。如果提交成功，我们接下来就要回主分支了，$ git checkout master
5.我们将新分支提交的改动合并到主分支上
$ git merge newbranch
合并分支可能产生冲突这是正常的，虽然我们这是新建的分支不会产生冲突，但还是在这里记录下。可以用
$ git diff 来查看产生冲突的文件，然后做对应的修改再提交一次就可以了。
6.我们的问题解决了，接下来就可以push代码了
$ git push -u origin master
7.最后，新建分支的朋友别忘了删除分支
$ git branch -D newbranch
如果想保留分支只是想删除已经合并的部分只要把大写的D改成小写的d就行了。