Git

开源的分布式版本控制系统

Git 配置

用户信息

$ git config -- global user.name "lijiandong"
$ git config -- global user.email ljdong1221@163.com

查看配置信息

//检查已有配置信息
$ git config --list
//查询单个信息
$ git config user.name

Git 工作区、暂存区、版本库

工作区

自己电脑能看到的目录

暂存区

英文叫stage或index，一般存放.git目录下的index文件中，所以暂存区也叫索引（index）

版本库

工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库

解释：index：暂存区，master:master分支所代表的目录树，HEAD：指向master分支的一个游标，Object：标识的区域是Git的对象库，位于“.git/objects”目录下，里面包含创建的各种对象。

当工作区的文件执行git add命令时，暂存区的目录树被更新，同时工作区修改的文件内容被写入到对象库中的一个新的对象中，而该对象的ID被记录在暂存区的文件索引中。
当执行提交操作git command 命令时，暂存区的目录树写到版本库中，master指向的目录树就是提交时暂存区的目录树。
当执行git reset HEAD命令时，暂存区的目录树会被重写，被master分支指向的目录树所替换，但是工作区不受影响。
当执行git checkout HEAD. 或者 git checkout HEAD -- <file> 命令时，会用HEAD指向的master分支中的全部或者部分文件替换暂存区和以及工作区中的文件。这个动作极具危险性，因为不但会清除工作区中未提交的改动，也会清除暂存区中未提交的改动。

Git 创建仓库

git init

//使用当前目录作为Git仓库，只需要初始化
git init
//使用指定目录作为Git仓库
git init newrepo
//将文件纳入版本控制，目录下以.c结尾及README文件提交到仓库中
git add *.c
git add README
git commit -m '初始化项目版本'

git clone

//克隆仓库
git clone <repo>
git clone git@github.com:ljdong/test.git             ---SSH协议
git clone git://github.com/ljdong/test.git           ---GIT协议
git clone https://github.com/ljdong/test.git         ---HTTPS协议

Git 基本操作

常用命令：git clone git push git add git commit git pull git checkout

workspace：工作区

staging area：暂存区

local repository：本地仓库

remote repository：远程仓库

创建仓库命令

//初始化仓库
git init
//拷贝远程仓库
git clone

提交与修改

//添加文件到仓库
git add
//查看仓库当前的状态，显示有变更的文件
git status
//比较文件的不同，即暂存区和工作区的差异
git diff
//提交暂存区到本地仓库
git commit
//回退版本
git reset
//删除工作区文件
git rm
//移动或重命名工作区文件
git mv

远程操作

//远程仓库操作
git remote
//从远程获取代码库
git fetch
//下载远程代码并合并
git pull
//上传远程代码并合并
git push

Git 分支管理

//创建分支
git branch (branchname)
//切换分支
git checkout (branchname)
//合并分支
git merge

列出分支

//列出分支
git branch

删除分支

//删除分支
git branch -d (branchname)

分支合并

//合并分支
git merge (branchname) //当前所在分支合并branchname分支

合并冲突

可以用git add 告诉git 文件冲突已经解决

Git 分支模型

主要分支

master
develop

origin/master：这个分支源码的HEAD一直指向可用于生产环境的状态

origin/develop：这个分支源码的HEAD总是反映下一版本的最新开发状况

当develop分支上的源码达到一个稳定点并准备发布时，所有的更改都应该以某种方式合并回master分支

辅助分支

和主分支不同，辅助分支只有有限的生命周期，通常在完成使命后被删除

功能分支

可能源自于develop分支，但是必须合并回develop分支，命名习惯：功能名称，通常存在于开发人员仓库中，不会出现在origin仓库

-no-ff标记会在分支合并时，创建一个新的提交对象，避免丢失功能分支的历史信息并且可以把所有的功能在叠加一起提交。
发布分支

可能源自于develop分支，必须合并到develop和master分支，命名习惯：release-* ，发布分支支持新产品发布的准备，它们允许在最后一刻追求细节，允许小错误修复以及为发布准备元数据。准备好要发布分支后，发行版必须合并进master分支中（一定确保每次提交到master分支的都是最新的版本）。最后，发布新分支所做的更改需要重新合并为develop分支，以确保以后的版本也修复了这些错误。
修复Bug分支

可能来源于master分支，必须合并到develop和master ，命名习惯：hotfix-* ，当生产版本中的一个严重bug必须马上被修复，热修复分支可能从master分支上用于标记生产版本的对应标签上创建分支。当完成一个bug分支之后，bug分支需要合并到master和develop分支上，以保证下一版本中也包含该bug修复。与发布分支非常相似。