git 是一个分布式版本控制软件，最初由林纳斯·托瓦兹（Linus Torvalds）（Linux 之父）创作，于 2005 年发布。最初目的是为更好地管理 Linux 内核开发。Git 在本地磁盘上就保存着所有有关当前项目的历史更新，处理速度快；Git 中的绝大多数操作都只需要访问本地文件和资源，不用实时联网。
GitHub 是一个共享虚拟主机服务，用于存放使用 Git 版本控制的软件代码和内容项目；允许用户其他用户、组织、软件库的动态，对软件代码的改动和 bug 提出评论。
GitLab 是一个利用 Ruby on Rails 开发的开源应用程序，实现一个自托管的Git 项目仓库，可通过 Web 界面进行访问公开的或者私人项目，拥有与 Github类似的功能，能够浏览源代码，管理缺陷和注释。
Git 会使用 master 作为分支的默认名字。在若干次提交后，你其实已经有了一个指向最后一次提交对象的 master 分支，它在每次提交的时候都会自动向前移动。
git 的工作流程见下图，这是最标准的git使用流程，我们可以看到 git 是通过对各分支的来规范工作的。
首先有一条master分支，这是发布稳定版，一般不会对 master 进行修改，当有新需求的时候，从 master 上分出一条 develop 分支，具体开发人员在从 develop 上分出自己具体 feature 分支，开发完毕后合并回 develop 分支，测试人员从 develop 分支分出 release 分支进行测试，没有问题了合并到 master 分支发布。如果线上有 bug 需要处理，则从 master 上分出 hotfix 分支，用来解决 bug。
版本库又名仓库，英文名 repository，你可以简单理解成一个目录，这个目录里面的所有文件都可以被
在 Git 中，用 HEAD 表示当前版本，也就是最新的提交 commit id，上一个版本就是 HEAD^，上上一个版本就是 HEAD^^，当然往上 100 个版本写 100 个 ^ 比较容易数不过来，所以写成 HEAD~100。
因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支， 所以默认git commit就是往master分支上提交更改。
注：由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送到远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。
从远程分支 checkout 出来的本地分支，称为分支(tracking branch)。分支是一种和远程分支有直接联系的本地分支。在分支里输入git push，Git 会自行推断应该向哪个服务器的哪个分支推送数据。反过来，在这些分支里运行git pull 会获取所有远程索引，并把它们的数据都合并到本地分支中来。
在克隆仓库时，Git 通常会自动创建一个名为 master 的分支来 origin/master。这正是 git push 和 git pull 一开始就能正常工作的原因。当然，你可以地设定为其它分支，比如 origin 上除了 master 之外的其它分支。
如果在不同的分支中都修改了同一个文件的同一部分，Git 就无法干净地把两者合到一起 Git 作了合并，但没有提交，它会停下来等你解决冲突。可以用 git status 查阅哪些文件在合并时出现冲突。
冲突标记之间的内容是别人的修改。 最简单的编辑冲突的办法，就是直接编辑冲突了的文件，把冲突标记删掉，把冲突解决正确。
方法：Git 还提供了一个 stash 功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：比如你正在 dev 分支开发，突然接到 master 上有一个特别急的 bug 需要解决，这时就可以把当前 dev 的工作现场“储藏”起来。
我们在开发过程中，有一些文件是不需要提交的，但是 git 总显示这部分文件会让人很不舒服，这时我们就可以通过编辑 .gitignore 文件来使不需要提交的文件不在提示，编写要忽略的文件，下列内容是 Java 开发者经常用到的：
git 命令可不可以根据自己的特点配置别名呢，当然是可以的，这样做能提高工作效率，下列是一些简单的例子。
网友评论 ()条 查看