赞
踩
注意:这里再解释一下分布式的意思,假如有A和B两个人开发软件,为了让这两人顺利合作,弄了 一个类似于数据库的东西,姑且叫它D,两个人把各自的代码上传到D中,同时各自在本地保留了相应的代码,这个就叫分布式。
总之就一句话,Git就是控制版本的一个软件。那为什么要做版本的控制呢?
答:要保留之前所有版本,以便回滚和修改。
详见:
https://git-scm.com/book/zh/v2/%E8%B5%B7%E6%AD%A5-%E5%AE%89%E8%A3%85-Git
想要让git对一个目录进行版本控制需要以下步骤:
就进入到命令行窗口了,然后执行初始化命令:
git init
git status
注:新增的文件和修改后的文件都是红色。
git add 文件名
或者
git add .
注:第一个命令只是管理一个文件放入暂存区中,第二个指所有的文件都放入暂存区中。
git config --global user.email "you@example.com"
git config --global user.name "Your Name"
git commit -m "描述信息"
git log
现在已经将目录下的文件都管理起来了,但是,如果我们要回到以前的版本,又要怎么做呢?
git log
git reset --hard 版本号
注:上面的版本号是由git log
查看出来的,如下所示:
这里还有个注意的地方,就是使用
git log
时,如果版本太多,最下面就会显示:
,这个时候可以使用q
来退出。
现在回到以前的版本了,但是又想回到之后的版本,应该怎么做呢?
git reflog
git reset --hard 版本号
注:通过git reflog查找到版本号,如下所示红框框起来的就是版本号:
其实就很简单的几个命令:
git init
git add .
git commit -m "描述信息"
git log
git reflog
git reset --hard 版本号
在前面说了使用git add
放入暂存区,使用git commit
放入版本库,这个到底什么意思呢?下面来介绍:
其实git有三个状态,分别是工作区、暂存区和版本库。
(1)工作区:
就是要管理的那个文件夹,有两个形式:一个是已经被git标记管理的文件,使用git status
查看则显示白色;另一个是新文件或者虽然已经管理但是有变动的文件,使用git status
查看,显示红色。
(2)暂存区:
其实就是一个暂时存放文件的地方,因为有时候我们虽然改动了文件,但是下一时刻又感觉改错了,放入暂存区就不用再到保存的地方修改了,这样比直接保存要效果好。
还不形象,举一个例子:
你很生气,想要把你的电脑砸了,如果不经过思考,那就真的砸了,但是要是这个想法先放入你的脑子中,那后面后悔了还来得及。所以这个暂存区就是这么个作用。
下图显示了三种状态的转换。注意,箭头里是状态到达的命令:
我们前面说过,当我们的程序每次需要加新功能的时候,我们就使用git这个分布式版本控制软件更新一下版本,现在假如说,我们的程序要从版本1
更新到版本2
,应该怎么做呢?
答:两种做法:1)第一种做法为:将版本1
的所有文件复制一份,然后在此基础上改,生成版本2
;2)第二种做法为:版本2
的内容是只保留版本1
修改的文件和增加的文件,然后使用一个指针指向版本1
,当需要那些没有修改的文件的时候,只需要按指针的指向,从版本1
那里取就可以了。
git分布式版本控制软件 使用的是方法2,至于好处,我这里就不说了,其实很明显的。
因此,按方法2的做法,那么就形成了一条线(由指针串联每个版本),我们把这个叫做主分支,也叫master分支。
那有了主分支,肯定就有其他分支,现在的问题就是为啥要出现其他分支呢?难道主分支对于有些需求满足不了我们?
确实是因为只使用一个主分支,对于有些需求满足不了我们。更官方的回答是:
举个例子:
假设 张三 编写了一个网站,可以正常运行,接下来他的老板需要添加卖货功能,所以 张三 就着手于开发 卖货 功能,但这个时候运行的网站出现了bug,使用不了。那么应该怎么做呢?
答:如果按我们前面,只有一个master分支,做法是:张三从卖货这个版本回滚到之前运行网站的那个版本,然后把bug修改完了,再重新开发卖货功能。但这显然太浪费时间了,也可以说不能并行开发,而分支可以很好的解决这个问题:
如果按分支来解决,是这样的:在网站能够运行的那个版本,分出两个分支版本,分别为bug分支和dev分支,这个bug分支专门用来修复bug,而dev分支依然开发卖货功能,当bug和新功能都完工之后,再合并到master主分支中,就可以完美的解决这个问题了。下图展示了这个过程:
有了上面的基本思想,下面看看git是如何实现的。
git branch
注:如下所示的*表示当前所在的分支。
git branch 分支名称
git checkout 分支名称
git merge 要合并的分支
注意:切换分支再合并。例如要将修复bug的分支合并到master,那就要先切换到master再合并bug分支。
这里再说一下可能会产生冲突,如果要合并两个分支,而这两个分支分别在同一个文件的同一行做了修改,那么git就不知道怎么合并了,所以就把所有的内容列出来了,这个时候运行git merge就会产生下面的警告,表明产生了冲突。
这个时候我们只能去那个文件的那行手动修改,文件会被如下所示的符号所标识,三行符号中间夹的两行代码就是两个分支的内容,我们删除不需要的就可以了。
git branch -d 分支名称
一般开发程序不在master上进行,而是在新建工程的时候就建立一个dev分支,用于开发软件,而master主要是用于稳定版的发行,下图展示了工作流的过程:
至此,git在本地版本控制的操作就这么多了,接下来,看看非本地怎么使用:
在介绍GitHub之前,我先说一下为啥要使用GitHub。现在假设 张三 要开发一个项目,每天在公司和家两点一线,为了节省时间,需要在家里也能敲代码,这个时候怎么做比较好呢?
有人是这么做的:
第一种:使用一个U盘,每次在公司工作完就拷贝的U盘上,然后回家再拷贝到家里的电脑上,像我以前为了麻烦,直接在U盘上工作,所以时常怕U盘坏了,那不就gg了么。
第二种:使用百度云之类的东西,每次在公司工作完,上传到百度云,到家之后再从 百度云上下载下来,有点麻烦。
第三种:使用GitHub(托管代码的仓库),和百度云有点类似,但是可以和Git做无缝衔接。我们可以这么做,每次在公司工作完,上传到GitHub,在家里的电脑上使用Git,更新本地的代码,工作完再上传到GitHub,到公司再使用Git更新公司本地的代码,等等。这么做只需简单的几行命令就可以了,下图展示了这个过程:
接下来就看看怎么使用GitHub做到上述的工作:
假设我们现在在家里的电脑上。
第一步:注册GitHub账号(去https://github.com/),按下图:
第二步:创建远程仓库;
(1)点击New repository:
(2)按下面说明选好后,点击Create repository:
(3)查看远程仓库网址:
到这里,远程仓库就创建好了。
第三步:将代码上传到GitHub:
进入到项目文件夹,打开git,然后:
git remote add origin 远程仓库地址
git push -u origin 分支名称
现在上传成功了,接下来看看怎么在别的电脑上下载这个项目的代码呢?
git clone 远程仓库地址(内部已实现git remote add origin 远程仓库地址)
git checkout 分支名称
注意:初次克隆下来后,使用git branch查看时,没有分支显示。直接切换就可以了。
第四步:在公司下载完代码后,继续开发:
git checkout dev
git merge master
git add .
git commit -m "xx"
git push origin dev
第五步:下班回家继续写代码
git checkout dev
git pull origin dev
3、继续开发
4、提交代码
git add .
git commit -m "xx"
git push origin dev
第六步:到公司继续开发
git checkout dev
git pull origin dev
3、继续开发
4、提交代码
git add .
git commit -m "xx"
git push origin dev
总结:
你会发现,实际上对于 公司----家 的这种模式,就很简单的归结为下面的一段话:
在家写好代码,推到GitHub上,到公司后再拉下来(第一次是克隆),再编写代码,然后再推到GitHub上,一直到项目开发完毕。
第七步:开发完毕,上线
git checkout master
git merge dev
git push origin master
git checkout dev
git merge master
git push origin dev
扩展:
git pull origin dev
等价于
git fetch origin dev
git merge origin/dev
下图展示了各种状态到达的命令:
git remote add origin 地址
git push origin 分支名
git clone
git pull origin 分支名
等价于
git fetch origin 分支名
git merge origin/分支名
git log --graph --pretty=format:"%h %s"
协同开发时,需要所有成员都可以对同一个项目进行操作,需要邀请成员并赋予权限,否则无法开发。GitHub支持两种创建项目的方式(贡多人谢工开发)。
下面是创建过程:
为了能清晰的管理版本,在公司不会直接使用commit来做版本,会给予tag来实现:v1.0、v2.0、v3.0等等。
下面是命令:
git tag -a v1.0 -m "版本介绍"
git tag -d v1.0
git push origin --tags
git pull origin --tags
git checkout v1.0
git clone -b v1.0 地址
邀请小弟成为某项目的合作者
小弟在自己的电脑上下载代码并开发
git clone https://github.com/organization-of-masizhou/dbhoyt.git
cd dbhoyt
git checkout dev # 切换到dev分支
git checkout -b ddz # 在dev分支的基础上,创建dzz分支并切换
写代码...
git add .
git commit -m "开发完毕"
git push origin ddz
由专门团队或团队leader执行以下步骤:
git checkout dev
git checkout -b release
使用GitHub上的pull request
或
本地将release合并到master
git tag -a v2 -m "第二版"
git push origin --tags
多人合作其实主要是做了下面的工作:
1、每个人新建一个分支,进行开发功能;
2、开发完成后,先不合并到开发分支dev
,而是先code review 给小领导看,等审核通过了,小领导就点击通过合并了;
3、开发分支dev完成之后,就要向master
分支提交,但在这之前,一般先新建release
分支,在这个分支上测试有没有bug,要是没有bug,那就再把release
分支合并到master
分支。
~/.git/config
git config --local user.name '马司周'
git config --local user.email '1907609069@qq.com'
~/.gitconfig
git config --global user.name '马司周'
git config --global user.email '1907609069@qq.com'
/etc/.gitconfig
git config --system user.name '马司周'
git config --system user.email '1907609069@qq.com'
# 注意:需要root权限
应用场景:
git config --local user.name '马司周'
git config --local user.email '1907609069@qq.com'
git config --local merge.tool bc3
git config --local mergetool.path '/usr/local/bin/bcomp'
git config --local mergetool.keepBackup false
git remote add origin 地址 默认添加在本地配置文件中(--local)
原来的地址:https://github.com/WuPeiqi/dbhot.git
修改的地址:https://用户名:密码@github.com/masizhou/dbhot.git
git remote add origin https://用户名:密码@github.com/masizhou/dbhot.git
git push origin master
(1)生成公钥和私钥(默认放在 ~/.ssh
目录下,id_rsa.pub
公钥,id_rsa
私钥,下面是生成命令:
ssh-keygen
(2)拷贝公钥的内容,并设置到github中。
(3)在git本地中配置ssh地址
git remote add origin git@github.com:masizhou/dbhot.git
(4)以后使用就可以直接使用了:
git push origin master
目的:让git不再管理当前目录下的某些文件。
先在当前目录创建一个名叫.gitignore
的文件;然后把不想管理的文件名称加入里面即可。如下面:
*.h
!a.h
files/
*.py[c|a|d]
更多参考:https://github.com/github/gitignore
若有用,欢迎点赞,若有错,请指正,谢谢!
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。