Git是目前世界上最早进的分布式版本控制系统!
git
主流的版本控制器有以下这些:数据库
- Git(影响力最大使用最普遍)
- SVN(Subversion)
- CVS(Concurrent Versions System)
- VSS(Microsoft Visual SourceSafe)
- TFS(Team Foundation Server)
- Visual Studio Online
版本控制分类:安全
下载网址:Gitbash
在安装以前首先确保已经卸载:服务器
安装成功后开始菜单中有如下三个程序;任意文件夹下右键也能够看到对应的程序。
网络
全部的配置文件都保存在本地ssh
查看当前关于Git的全部配置:分布式
git config -l
查看Git的系统相关配置:ui
git config --system --list
查看本地Git相关配置(用户配置):url
git config --global --list
Git相关的配置文件:
Git\etc\gitconfig
: Git安装目录下的gitconfig --system 系统级C:\Users\Administrator\.gitconfig
: 只适用于当前登陆用户的配置 --global 全局配置用户信息(用户名与邮箱,必要配置):
git config --global user.name "Sino" git config --global user.email "12345678@qq.com"
只需作一次这个设置,传递了--global选项,Git将老是会使用该信息来处理在系统中作的一切操做。若是但愿在特定项目中使用不一样的名称或email地址,能够在该项目中运行此命令而不要--global选项。
Git本地有三个工做区域:
工做目录(Working Directory)
暂存区(Stage/Index)
资源库(Repository或Git Directory)
若是再加上远程的git仓库(Remote Directory)就能够分为四个工做区域。
转换关系以下图:
Git的工做流程通常是这样的:
平常使用记住下图6个命令:
本地仓库搭建:
建立本地仓库的方法有两种:一种是建立全新的仓库,另外一种是克隆远程仓库。
建立全新的仓库,须要用GIT管理的项目的根目录执行:
在当前目录新建一个Git代码库
$ git init
执行后能够看到,仅仅在项目目录多出了一个.git目录,关于版本等的全部信息都在这个目录里面。
克隆远程仓库
另外一种方式是克隆远程目录,因为是将远程服务器上的仓库彻底镜像一份至本地!
$ git clone [url] # https://gitee.com/sino/test.git
# 查看指定文件状态 git status [filename] # 查看全部文件状态 git status # 添加全部文件到暂存区 git add . # 提交暂存区中的内容到本地仓库 -m 提交信息 git commit -m "消息内容"
有些时候咱们不想把某些文件归入版本控制中,好比数据库文件,临时文件,设计文件等。
在主目录下创建.gitignore
文件,此文件有以下规则:
#为注释 *.txt #忽略全部 .txt结尾的文件,这样的话上传就不会被选中! !lib.txt #但lib.txt除外 /temp #仅忽略项目根目录下的temp文件,不包括其它目录temp build/ #忽略build/目录下的全部文件 doc/*.txt #会忽略 doc/notes.txt 但不包括 doc/server/arch.txt
# 进入 C:\Users\Administrator\.ssh 目录 # 生成公钥 ssh-keygen
3. 将公钥信息public key添加到码云帐户中便可
4. 使用码云建立一个本身的仓库
git分支中经常使用的命令:
# 列出全部本地分支 git branch # 列出全部远程分支 git branch -r # 新建一个分支,但依然停留在当前分支 git branch [branch-name] # 新建一个分支,并切换到该分支 git checkout -b [branch] # 合并指定分支到当前分支 $ git merge [branch] # 删除分支 $ git branch -d [branch-name] # 删除远程分支 $ git push origin --delete [branch-name] $ git branch -dr [remote/branch] # 切换到指定分支,并更新工做区 $ git checkout [branch-name] # 切换到上一个分支 $ git checkout -
master主分支应该很是稳定,用来发布新版本,通常状况下不容许在上面工做,工做通常状况下在新建的dev分支上工做,工做完后,好比上要发布,或者说dev分支代码稳定后能够合并到主分支master上来。