赞
踩
Git是目前世界上最先进的分布式版本控制系统。
Workspace:工作区,就是我们通$ git init 创建的代码库的所有文件但是不包括 .git文件(版本库)
Index / Stage:暂存区,我们通过$git add ./*/Xxx/Xxxx 添加的修改,都是进入到暂存区了,肉眼不可见,通过 $git status 可以看到修改的状态
Repository:仓库区(或本地仓库)
Remote:远程仓库
SVN是集中式版本控制系统,版本库是集中放在中央服务器的,而干活的时候,用的都是自己的电脑,所以首先要从中央服务器哪里得到最新的版本,然后干活,干完后,需要把自己做完的活推送到中央服务器。集中式版本控制系统是必须联网才能工作,如果在局域网还可以,带宽够大,速度够快,如果在互联网下,如果网速慢的话,就纳闷了。
Git是分布式版本控制系统,那么它就没有中央服务器的,每个人的电脑就是一个完整的版本库,这样,工作的时候就不需要联网了,因为版本都是在自己的电脑上。既然每个人的电脑都有一个完整的版本库,那多个人如何协作呢?比如说自己在电脑上改了文件A,其他人也在电脑上改了文件A,这时,你们两之间只需把各自的修改推送给对方,就可以互相看到对方的修改了。
$ git config --global user.name "Junk Chen" //你自己设置的名字
$ git config --global user.email junkchen@vip.qq.com //你的邮箱地址。
两种获取Git项目仓库的方法: 一是在现有项目或目录下导入所有文件到Git中; 二是从一个服务器克隆一个现有的Git仓库。
在现有目录中初始化仓库
进入该项目目录并输入:$ git init
该命令将创建一个名为 .git 的子目录,这个子目录含有你初始化的 Git 仓库中所有的必须文件,这些文件是 Git 仓库的骨干。
克隆现有的仓库
如果你想获得一份已经存在了的Git仓库的拷贝,可以使用git clone [url地址]。
$ git clone https://github.com/libgit2/libgit2 mylibgit
该命令执行后会在当前目录下创建一个名为 “libgit2” 的目录,并在这个目录下初始化一个.git文件夹,从远程仓库拉取所有的数据放在该文件夹,然后从中读取最新版本的文件的拷贝。 如果你进入到这个新建的 libgit2 文件夹,你会发现所有的项目文件已经在里面了,准备就绪等待后续的开发和使用。
$ git init // 初始化一个Git仓库
$ git status // 查看仓库的状态
$ git add . // 将所有修改添加到暂存区
$ git add * // Ant风格添加修改
$ git add *Controller // 将以Controller结尾的文件的所有修改添加到暂存区
$ git add Hello* // 将所有以Hello开头的文件的修改添加到暂存区 例如:HelloWorld.txt,Hello.java,HelloGit.txt …
$ git add Hello? // 将以Hello开头后面只有一位的文件的修改提交到暂存区 例如:Hello1.txt,HellzsoA.java 如果是HelloGit.txt或者Hello.java是不会被添加的,可以多次添加然后在提交
$ git commit -m “comment” // 将暂存区的修改提交到仓库 后面添加上有意义的注释信息
$ git diff file // 在file被修改了还未提交的时候查看修改的部分(和版本库中最新版本的不同 diff == difference 不同)
$ git log // 查看git的commit信息,每次提交的信息包括注视在内,从最新提交到最久提交
$ git log --pretty=oneline // 将commit 信息简化成一行显示,注意Git的版本号(commit id)是SHA1值
$ git reset --hard HEAD^ // 退回到相对于当前版本的上一个版本 HEAD 表示当前版本
$ git reset --hard HEAD^^ // 退回到相对于当前版本的上上一个版本 HEAD 代表当前版本
$ git reset --hard HEAD~100 //退回到相对于当前版本的上 100 个版本去 HEAD 表示当前版本
$ git reset --hard 3628164 // 退回到指定的版本 这里不需要全部写commit id Git 回去自动适配,Git的版本回退速度非常快,因为Git在内部有个指向当前版本的HEAD指针,当你回退版本的时候,Git仅仅是把HEAD从指向append GPL
$ git reflog // 在退回到旧版本之后可以查看旧版本之前的提交日志
当我们想从一个旧版本退回到新版本但是我们关闭了shell窗口,不能查看之前的commit id了,就可以通过$ git reflog 查看到之前的版本的commit id
$ git checkout --file // 表示丢弃工作区的修改退回原始状态(不包括已经添加到暂存区的修改),修改只能在被add 到暂存区以后才能被提交,在file 已经修改还未add的时候可使用
$ git reset HEAD file // 丢弃file已经添加到暂存区的修改 HEAD 表示最新版本,file已经修改和添加到了暂存区,还未commit时可使用
$ git reset --hard HEAD^ //退回到上一个版本,如果file修改已经提交到本地仓库时可使用
$ rm file // 从文件系统中删除文件(Git 中还是有记录),$ git status 的时候Git 会告诉你有一个file 被删除了
$ git rm file // 从Git版本库中删除文件(同时从文件系统中删除文件) $ git status 正常
$ git rm file // 从git版本库中删除文件
$ git commit -m “delete file” // 提交删除
$ git checkout file // 想要从git恢复 会出现:error: pathspec ‘README.txt’ did not match any file(s) known to git.
$ git reset --hard HEAD^ // 恢复到上一个版本 可以恢复文件
$ git checkout file // 由于是通过文件系统删除的所以可以通过checkout恢复
在安装了git以后发现idea类名出现了不同的颜色,如下:
它们分别表示的含义:
绿色:已经加入控制暂未提交
红色:未加入版本控制
蓝色:加入,已提交,有改动
白色:加入,已提交,无改动
灰色:版本控制已忽略文件。
顾名思义,分支就是从主线上分离出来进行另外的操作,而又不影响主线,主线又可以继续干它的事,是不是有点像线程,最后分支做完事后合并到主线上而分支的任务完成可以删掉了。这样是不是很方便,主线继续做它的事,分支用来解决临时需求,二者互不相干。git的分支功能特别的强大,它不需要将所有数据进行复制,只要重新创建一个分支的指针指向你需要从哪里开始创建分支的提交对象(commit),然后进行修改再提交,那么新分支的指针就会指向你最新提交的这个commit对象,而原来分支的指针则指向你原来开发的位置,当你在哪个分支开发,HEAD就指向那个分支的最新提交对象commt。
每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支
在Git里,默认有一个主分支,即master分支。
HEAD严格来说不是指向提交,而是指向master,master才是指向提交的,所以,HEAD指向的就是当前分支。
master分支是一条线,Git用master指向最新的提交,再用HEAD指向master。
每次提交,master分支都会向前移动一步,这样,随着你不断提交,master分支的线也越来越长。
Git新建了一个指针叫dev,指向master相同的提交,再把HEAD指向dev,就表示当前分支在dev上
$ git push -u origin master // 将本地的master分支推送到远程的master分支中
$ git push -u origin dev // 本地切换到dev分支然后将本地的dev分支推送到远程
$ git branch // 查看git的所有分支
$ git branch dev // 创建dev分支
$ git checkout dev // 切换到一个已经存在的分支
$ git checkout -b dev // 创建dev分支,并切换到dev分支
$ git branch -d dev // 删除dev分支
$ git checkout master // 切换到主分支
$ git merge dev // 将dev分支合并到master分支
$ git checkout -b feature1 //处理冲突
首次查看(工作区没有任何文件)
新增文件(hello.txt)
再次查看,工作区的文件还未提交到暂存区(检测到未追踪的文件)
将工作区的文件添加到暂存区
查看状态,工作区的文件已提交到暂存区,但未提交到本地库(检测到暂存区有新文件,未提交到本地库)
将暂存区的文件提交到本地库
查看状态(没有文件需要提交)
修改文件(hello.txt)
查看状态(检测到工作区有文件被修改)
将修改的文件再次添加暂存区
查看状态(工作区的修改添加到了暂存区,但未提交到本地库)
重新将暂存区的文件提交到本地库
简易版:
详细版:
当前指针指向第三次提交
版本穿梭回第二次提交
当前指针指向第二次提交
版本穿梭回第三次提交
在 maste 分支上做修改 : vim hello.txt
hot2 分支并未做任何改变,当前 master 分支已更新为最新一次提交
的版本
查看 hot2 分支上的文件内容发现与 master 分支上的内容不同
在 hot2 分支上做修改
在 master 分支上合并 hot-fix 分支,产生冲突
冲突产生的表现:后面状态为 MERGING
冲突产生的原因:
合并分支时,两个分支在同一个文件的同一个位置有两套完全不同的修改。Git 无法替我们决定使用哪一个。必须人为决定新代码内容。
查看状态(检测到有文件有两处修改)
解决冲突
编辑有冲突的文件,删除特殊符号,决定要使用的内容
特殊符号:<<<<<<< HEAD 当前分支的代码 ======= 合并过来的代码 >>>>>>> hot-fix
执行提交(注意:此时使用 git commit 命令时不能带文件名)
***此时发现已将我们 master 分支上的内容推送到 GitHub 创建的远程仓库。***
小结: clone 会做如下操作。1、拉取代码。2、初始化本地仓库。3、创建别名
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。