目录
一、前言:git教程介绍
二、简单配置:安装git并设置名字、email地址
三、开始使用git:创建一个版本库(文件夹)
四、往版本库里面添加一个文件:新建test.txt(文件)
五、查看文件的状态:git status 、git diff
六、文件的版本回退
七、后悔回退了版本,想恢复新版本
八、先不再哔哔,看看git的工作原理吧
九、后悔修改了内容,想撤销修改
十、在git中删除文件
十一、Git的杀手级功能:远程仓库(介绍)
十二、在本地创建SSH钥匙
十三、在github中添加此钥匙
十四、在github上创建一个远程仓库
十五、将本地仓库与远程仓库关联
十六、关联后就可以进行基本操作,比如:把本地库的所有内容推送到远程库上
十七、想删除github上的远程库
十八、将远程仓库克隆到本地
十九、分支管理(介绍)
二十、创建与合并分支
二十一、解决不同分支的冲突
二十二、普通模式下的合并,管理分支的总体策略
二十三、推送分支
二十四、抓取分支
二十五、多人协作的工作模式(解决提交冲突)
二十六、在github中参与一个开源项目
二十七、后记
对于小白来说,一开始学习使用git确实有些困难,曾身为小白的我,走过一些弯路,断断续续地学习中,总算是真正成为了一个git用户,写下此篇博客,来记录一些知识。
(博客写完后回来吐槽一下CSDN的编辑功能,在本文编辑过程中,由于无意按下了Ctrl + z,导致博客的大部分内容被删,被删后的残余文章直接秒覆盖草稿箱,所以无法恢复,导致内容大部分编辑了三次(ctrl+z按了两次,一次快写完了,一次完成了前20节,一删只剩前7节),当时心态是快崩了,希望CSDN能改一下这个bug吧)
----------------------------------------------------------------------------
关于笔者所学的教程,一方面是廖雪峰老师的教程,一方面是B站的git教程资源,我觉得本博客的内容是记录了git使用的皮毛(其实已经够用了),若还想学得更加深入,可以参考下面的教程,分享如下:
1.廖雪峰老师的git教程(推荐):https://www.liaoxuefeng.com/wiki/896043488029600
2.百度网盘保存的黑马的git教程,读者自取,链接永久有效,内含git讲义(word文档)
链接:https://pan.baidu.com/s/1g09tBA0ytL-8vNa4J79qSA 提取码:1111
3.B站还有有很多教程,估计多数大同小异,读者挑自己感兴趣的学习即可
下面是__花花__的总结。
1.可以从Git官网直接下载git,然后按默认选项安装即可。
git官网:https://git-scm.com/
2.在开始菜单打开刚刚安装的git bash并“逐行”输入以下代码:
git config --global user.name "Your Name"
git config --global user.email "Your Email"
1.首先选择电脑里一个合适的地方,逐行输入以下代码创建出一个空目录:
mkdir 文件夹名 //创建一个空文件夹
cd 文件夹名 //该命令表示进入某个文件夹
pwd //该处会显示处你创建的文件夹的地址
//pwd命令用于显示当前目录
如:
$ mkdir learngit
$ cd learngit
$ pwd
/Users/michael/learngit
注意:请确保目录名(包括父目录)不包含中文!
2.通过git init命令把这个目录变成Git可以管理的仓库,如:
$ git init
Initialized empty Git repository in /Users/michael/learngit/.git/
一下子空的仓库(empty Git repository)就创建出来了,我们可以发现当前目录下多了一个.git的目录,这个目录是Git来跟踪管理版本库的,没事千万不要手动修改这个目录里面的文件,不然改乱了,就把Git仓库给破坏了。如果你没有看到.git目录,那是因为这个目录默认是隐藏的,用ls -ah命令就可以看见。
注:推荐使用文本编辑器Visual Studio Code、Notepad3和记事本,不建议使用Notepad++。
由上面可以发现,在git bash新建“文件夹”命令是 mkdir+文件夹名。
而新建“文件”有两种方式:
1,touch+文件名(推荐),直接新建一个文件;然后可以在本地修改内容。
2,vi+文件名,新建一个文件并进入编辑状态(如果文件已存在,则直接进入编辑状态)
vi其实是linux的一个文本编辑器,所以 vi+文件名 后,其实是进入vi程序了。
新建完文件后,如果在git中编辑文本内容,就可以通过git add与git commit来上传内容到本地文件夹中。
解释一下git commit命令,-m后面输入的是本次提交的说明,可以输入任意内容,当然最好是有意义的,这样就能从历史记录里方便地找到改动记录。
为什么Git添加文件需要add,commit一共两步呢?因为commit可以一次提交很多文件,所以你可以多次add不同的文件,比如:
$ git add file1.txt
$ git add file2.txt file3.txt
$ git commit -m "add 3 files."
还要注意一点,如果没有add过,就不会被Git管理(那么git reset也不会被Git被删除掉)
1.往test.txt(现在是空内容)里面添加内容:
Git is a distributed version control system.
Git is free software.
接着输入git status查看工作区的状态,发现有文件被修改过,可以用git diff可以查看修改内容:
显然我们在git中不断地对文件进行修改,然后不断地提交“修改”到版本库里,一旦你把文件改乱了,或者误删了文件,git还可以将旧的文件恢复,以降低我们的损失。
如果嫌输出信息太多,看得眼花缭乱的,可以加上--pretty=oneline参数:
2.现在把当前版本回退到上一个版本,就可以使用git reset命令:
注意:上一个版本就是HEAD^,上上一个版本就是HEAD^^,当然往上100个版本写100个^比较容易数不过来,所以写成HEAD~100。
3.用cat观察test.txt的内容是不是上一个版本
cat test.txt 后是空内容说明版本确实已经回退了。
注意:也可以在本地打开文件观察是否已经回退了版本。
现在,你回退到了某个版本,关掉了电脑,第二天早上就后悔了,想恢复到新版本怎么办?
在Git中,总是有后悔药可以吃的。Git提供了一个命令git reflog用来记录你的每一次命令:
记住40fcbf9这个commit id,接着用git reset的方法恢复到新版本:
workspace:工作区
index/staged:暂存区
repository:本地仓库
remote:远程仓库
workspace首先是add到index上,让后commit到repository,再push到remote。
所以,上面的git add命令实际上就是把要提交的所有修改放到暂存区(Stage),然后,执行git commit就可以一次性把暂存区的所有修改提交到分支。
一旦提交后,如果你又没有对工作区做任何修改,那么工作区就是“干净”的。
突然想起一个“坑“,举一个例子,我们某次的操作如下:
第一次修改 -> git add -> 第二次修改 -> git commit
由于Git管理的是修改,当你用git add命令后,在工作区的第一次修改被放入暂存区,准备提交,但是,在工作区的第二次修改并没有放入暂存区,所以,git commit只负责把暂存区的修改提交了,也就是第一次的修改被提交了,第二次的修改不会被提交。
那怎么提交第二次修改呢?你可以继续git add再git commit,也可以别着急提交第一次修改,先git add第二次修改,再git commit,就相当于把两次修改合并后一块提交了:
第一次修改 -> git add -> 第二次修改 -> git add -> git commit
good,现在第二次也被修改提交了。
1. 使用命令git checkout -- file可以丢弃工作区的修改。
git checkout -- test.txt
命令git checkout -- test.txt意思是,把test.txt文件在工作区的修改全部撤销,这里有两种情况:
一种是test.txt自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态。
一种是test.txt已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态。
总之,就是让这个文件回到最近一次git commit或git add时的状态。
注意:git checkout -- file命令中的--很重要,没有--,就变成了“切换到另一个分支”的命令。
2. 使用命令git reset HEAD
git reset HEAD test.txt
git reset命令既可以回退版本,也可以把暂存区的修改回退到工作区。当我们用HEAD时,表示最新的版本。
3.小总结:
场景1:当你改乱了工作区某个文件的内容,想直接丢弃工作区的修改时,用命令git checkout -- file。
场景2:当你不但改乱了工作区某个文件的内容,还添加到了暂存区时,想丢弃修改,分两步,第一步用命令git reset HEAD
场景3:已经提交了不合适的修改到版本库时,想要撤销本次提交,参考版本回退的第七节,不过前提是没有推送到远程库。
估计大部分家人们通常直接在本地中把没用的文件删了,花花也是,简单直接,不搞什么花里胡哨,也估计肯定有家人真的想在git中用git rm操作删除一个文件,这里花花推荐去阅读一下廖雪峰老师的教程~
如果只是在一个仓库里管理文件历史,Git和SVN真没啥区别。为了保证现在所学的Git物超所值,将来绝对不会后悔,同时为了打击已经不幸学了SVN的童鞋,本节开始介绍Git的杀手级功能之一:远程仓库。
分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在,也就是有没有联网都可以正常工作,而SVN在没有联网的时候是拒绝干活的!当有网络的时候,再把本地提交推送一下就完成了同步,实在方便!
你肯定会想,至少需要两台机器才能玩远程仓库不是?但是我只有一台电脑,怎么玩?
其实一台电脑上也是可以克隆多个版本库的,只要不在同一个目录下。不过,现实生活中是不会有人这么傻的在一台电脑上搞几个远程仓库玩,因为一台电脑上搞几个远程库完全没有意义,而且硬盘挂了会导致所有库都挂掉。
实际情况往往是这样,找一台电脑充当服务器的角色,每天24小时开机,其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上,并且各自把自己的提交推送到服务器仓库里,也从服务器仓库中拉取别人的提交。
其实也完全可以自己搭建一台运行Git的服务器,不过现阶段,为了学Git先搭个服务器绝对是小题大作。好在这个世界上有个叫GitHub的神奇的网站,从名字就可以看出,这个网站就是提供Git仓库托管服务的,所以,只要注册一个GitHub账号,就可以免费获得Git远程仓库。
由于本地Git仓库和GitHub仓库之间的传输是通过SSH加密的,所以,需要进行设置。
提示:在进行下面的设置前,请读者自行注册好github的账号。
1.在用户主目录下,看看有没有.ssh目录,如果有,再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件,如果已经有了,可直接跳过创建钥匙这一步。如果没有,打开(Windows下)打开Git Bash,开始创建SSH Key:
ssh-keygen -t rsa -C "Your Email"
你需要把邮件地址换成你自己的邮件地址,然后一路回车,使用默认值即可。
配置完毕后,可以在用户主目录里找到.ssh目录,里面有id_rsa和id_rsa.pub两个文件,这两个就是SSH Key的秘钥对。
注意:
(1)id_rsa是私钥,不能泄露出去,id_rsa.pub是公钥,可以告诉任何人。
(2)私钥和公钥的概念这里不再赘述,我们只需要知道有这样的东西就行。
1.打开github,先把github的背景颜色改为黑色(该步可有可无)。
2.点击git的setting开始添加钥匙,操作如图:
注意:
(1)要在key文本框里粘贴id_rsa.pub文件的内容
(2)为什么GitHub需要SSH Key呢?因为GitHub需要识别出你推送的提交确实是你推送的,而不是别人冒充的,而Git支持SSH协议,所以,GitHub只要知道了你的公钥,就可以确认只有你自己才能推送。当然,GitHub允许你添加多个Key。假定你有若干电脑,你一会儿在公司提交,一会儿在家里提交,一会儿在学校里面提交,只要把每台电脑的Key都添加到GitHub,就可以在每台电脑上往GitHub推送了。(每台电脑只有一把钥匙)。
友情提示一下,在GitHub上免费托管的Git仓库,任何人都可以看到喔(但只有你自己才能改)。所以,不要把敏感信息放进去。
现在的情景是,你已经在本地创建了一个Git仓库后,又想在GitHub创建一个Git仓库,并且让这两个仓库进行远程同步,这样,GitHub上的仓库既可以作为备份,又可以让其他人通过该仓库来协作,真是一举多得。
1. 首先在右上角找到“+”按钮,开始创建一个新的仓库
2.create完毕后,会出现以下的界面:
说明远程仓库已经创建完毕了!
1.在本地的learngit仓库下运行下面的命令:
git remote add origin [email protected]:Leo-Love-Running/learngit.git
千万注意,把上面的Leo-Love-Running替换成你自己的GitHub账户名,否则,你在本地关联的就是我的远程库,关联倒没有什么问题,但是你以后推送是推不上去的,因为你的SSH Key公钥不在我的账户列表中。
添加后,远程库的名字就是origin,这是Git默认的叫法,也可以改成别的,但是origin这个名字一看就知道是远程库。
我们要注意,git给远程库起的默认名称是origin,如果有多个远程库,我们需要用不同的名称来标识不同的远程库。
仍然以learngit本地库为例,我们先删除已关联的名为origin的远程库:
git remote rm origin
然后,先关联GitHub的远程库:
git remote add github [email protected]:Leo-Love-Running/learngit.git
注意,远程库的名称叫github,不叫origin了。
接着,再关联Gitee的远程库:
git remote add gitee [email protected]:leo_love_running/for_test.git
同样注意,远程库的名称叫gitee,不叫origin。
现在,我们用git remote -v查看远程库信息,可以看到两个远程库:
git remote -v
gitee [email protected]:liaoxuefeng/learngit.git (fetch)
gitee [email protected]:liaoxuefeng/learngit.git (push)
github [email protected]:michaelliao/learngit.git (fetch)
github [email protected]:michaelliao/learngit.git (push)
如果要推送到GitHub,使用命令:
git push github master
如果要推送到Gitee,使用命令:
git push gitee master
good!
1.用git push命令把本地库的内容推送到远程,代码如下:
git push -u origin master
实际上是把当前分支master推送到远程。
由于远程库是空的,我们第一次推送master分支时,加上了-u参数,Git不但会把本地的master分支内容推送的远程新的master分支,还会把本地的master分支和远程的master分支关联起来,所以我们在以后的推送或者拉取时就可以简化命令。
第一次推送后,只要本地打算提交,就可以通过下面的命令:
git push origin master
1.如果添加的时候地址写错了,或者就是想删除远程库,可以用git remote rm
2. 接着根据名字删除,比如删除我的origin:
使用代码:
git remote rm origin
注意:此处的“删除”其实是解除了本地和远程的绑定关系,并不是物理上删除了远程库。远程库本身并没有任何改动。要真正删除远程库,需要登录到GitHub,在后台页面找到删除按钮再删除。
前言(后面会讲到分支):当你从远程仓库克隆时,实际上Git自动把本地的master分支和远程的master分支对应起来了,并且,远程仓库的默认名称是origin。
要查看远程库的信息,用git remote:
$ git remote
origin
或者,用git remote -v显示更详细的信息:
$ git remote -v
origin [email protected]:michaelliao/learngit.git (fetch)
origin [email protected]:michaelliao/learngit.git (push)
上面显示了可以抓取和推送的origin的地址。如果没有推送权限,就看不到push的地址。(抓取和推送后面也会讲到)
现在,我们先创建远程库,然后,从远程库克隆。
1.登陆GitHub,创建一个新的仓库,名字叫learngit02:
(我们勾选Add a README file,这样GitHub会自动为我们创建一个README.md文件。创建完毕后,可以看到README.md文件:)
创建完毕:
2. 使用命令git clone克隆出一个本地仓库,代码如下:
git clone [email protected]:Leo-Love-Running/learngit02.git
注意:把Git库的地址换成你自己的。
克隆完毕后:
注意:如果有多个人协作开发,那么每个人各自从远程克隆一份就可以了。
你也许还注意到,GitHub给出的地址不止一个,还可以用https://github.com/Leo-Love-Running/learngit02.git这样的地址。实际上,Git支持多种协议,默认的git://使用ssh,但也可以使用https等其他协议。
使用https除了速度慢以外,还有个最大的麻烦是每次推送都必须输入口令,但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。
以下内容选自廖雪峰老师的教程:
教程地址:https://www.liaoxuefeng.com/wiki/896043488029600
分支在实际中有什么用呢?假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险。
现在有了分支,就不用怕了。你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作。
其他版本控制系统如SVN等都有分支管理,但是用过之后你会发现,这些版本控制系统创建和切换分支比蜗牛还慢,简直让人无法忍受,结果分支功能成了摆设,大家都不去用。
但Git的分支是与众不同的,无论创建、切换和删除分支,Git在1秒钟之内就能完成!无论你的版本库是1个文件还是1万个文件。
注意:
在版本回退里,我们已经知道,每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支。
截止到目前,只有一条时间线,在Git里,这个分支叫主分支,即master分支(现在是main分支)。HEAD严格来说不是指向提交,而是指向master,master才是指向提交的,所以,HEAD指向的就是当前分支。
一开始的时候,master分支是一条线,Git用master指向最新的提交,再用HEAD指向master,就能确定当前分支,以及当前分支的提交点:
每次提交,master分支都会向前移动一步,这样,随着你不断提交,master分支的线也越来越长。
当我们创建新的分支,例如dev时,Git新建了一个指针叫dev,指向master相同的提交,再把HEAD指向dev,就表示当前分支在dev上:
你看,Git创建一个分支很快,因为除了增加一个dev指针,改改HEAD的指向,工作区的文件都没有任何变化!
不过,从现在开始,对工作区的修改和提交就是针对dev分支了,比如新提交一次后,dev指针往前移动一步,而master指针不变:
假如我们在dev上的工作完成了,就可以把dev合并到master上。Git怎么合并呢?最简单的方法,就是直接把master指向dev的当前提交,就完成了合并:
所以Git合并分支也很快!就改改指针,工作区内容也不变!
合并完分支后,甚至可以删除dev分支。删除dev分支就是把dev指针给删掉,删掉后,我们就剩下了一条master分支:
太神奇了,你看得出来有些提交是通过分支完成的吗?
1.结合上面的介绍,使用git checkout创建并切换分支:
git checkout -b dev
git checkout命令加上-b参数表示创建并切换,相当于以下两条命令:
$ git branch dev //创建出dev分支
$ git checkout dev //切换至dev分支
2. 用git branch命令查看当前分支:
注意:git branch命令会列出所有分支,当前分支前面会标一个*号。
3.我们就可以在dev分支上正常提交,比如对test.txt做个修改,加上一行:
I am the champion 0f Games of the Tokyo Olympic.
然后提交:
$ git add test.txt
$ git commit -m "branch test"
[dev b17d20e] branch test
1 file changed, 1 insertion(+)
现在,dev分支的工作完成,我们就可以切换回master分支:
$ git checkout master
Switched to branch 'master'
切换回master分支后,再查看一个test.txt文件,刚才添加的内容不见了!
这是为什么呢?因为那个提交是在dev分支上,而master分支此刻的提交点并没有变:
4.我们把dev分支的工作成果合并到master分支上:
git merge dev
$ git merge dev
Updating d46f35e..b17d20e
Fast-forward
readme.txt | 1 +
1 file changed, 1 insertion(+)
git merge命令用于“合并指定分支到当前分支”。合并后,再查看test.txt的内容,就可以看到,和dev分支的最新提交是完全一样的。
注意到上面的Fast-forward信息,Git告诉我们,这次合并是“快进模式”,也就是直接把master指向dev的当前提交,所以合并速度非常快。
当然,也不是每次合并都能Fast-forward,还有其他方式的合并。
合并完成后,就可以放心地删除dev分支了:
git branch -d dev
删除后,查看branch,就只剩下master分支了。
补充:switch
我们注意到切换分支使用git checkout
实际上,切换分支这个动作,用switch更科学。因此,最新版本的Git提供了新的git switch命令来切换分支:
创建并切换到新的dev分支,可以使用:
$ git switch -c dev
直接切换到已有的master分支,可以使用:
$ git switch master
使用新的git switch命令,比git checkout要更容易理解。
假设master分支和feature1分支各自都分别有新的提交,变成了这样:
提交时就产生了冲突,到底要提交哪一个版本?
解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容,再提交。该过程在此不再赘述。
注意:用git log --graph命令可以看到分支合并图。
通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息。
如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。
例如:将dev合并到当前分支的代码:
git merge --no-ff -m "merge with no-ff" dev
因为本次合并要创建一个新的commit,所以加上-m参数,把commit描述写进去。
注意:合并分支时,加上--no-ff参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而fast forward合并就看不出来曾经做过合并。
补充:
分支策略
在实际开发中,我们应该按照几个基本原则进行分支管理:
首先,master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
那在哪干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev分支合并到master上,在master分支发布1.0版本;
你和你的小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往dev分支上合并就可以了。
所以,团队合作的分支看起来就像这样:
推送分支,就是把该分支上的所有本地提交推送到远程库。推送时,要指定本地分支,这样,Git就会把该分支推送到远程库对应的远程分支上,代码如下:
$ git push origin master
如果要推送其他分支,比如dev,就改成:
$ git push origin dev
但是,并不是一定要把本地分支往远程推送,那么,哪些分支需要推送,哪些不需要呢?
master分支是主分支,因此要时刻与远程同步;
dev分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步;
bug分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug;
feature分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发。
多人协作时,大家都会往master和dev分支上推送各自的修改。
现在,模拟一个你的小伙伴,可以在另一台电脑(注意要把SSH Key添加到GitHub)或者同一台电脑的另一个目录下克隆:
$ git clone [email protected]:Leo-Love-Running/learngit.git
Cloning into 'learngit'...
remote: Counting objects: 40, done.
remote: Compressing objects: 100% (21/21), done.
remote: Total 40 (delta 14), reused 40 (delta 14), pack-reused 0
Receiving objects: 100% (40/40), done.
Resolving deltas: 100% (14/14), done.
当你的小伙伴从远程库clone时,默认情况下,你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看:
$ git branch
* master
现在,你的小伙伴要在dev分支上开发,就必须创建远程origin的dev分支到本地,于是他用这个命令创建本地dev分支:
$ git checkout -b dev origin/dev
现在,他就可以在dev上继续修改,然后,时不时地把dev分支push到远程;
你的小伙伴已经向origin/dev分支推送了他的提交,而碰巧你也对同样的文件作了修改,并试图推送。
会出现推送失败,因为你的小伙伴的最新提交和你试图推送的提交有冲突,解决办法也很简单,Git已经提示我们,先用git pull把最新的提交从origin/dev抓下来,然后,在本地合并,解决冲突,再推送:
$ git pull
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.
git pull
If you wish to set tracking information for this branch you can do so with:
git branch --set-upstream-to=origin/ dev
天哪!git pull也失败了,原因是没有指定本地dev分支与远程origin/dev分支的链接,根据提示,设置dev和origin/dev的链接:
$ git branch --set-upstream-to=origin/dev dev
Branch 'dev' set up to track remote branch 'dev' from 'origin'.
再pull:
$ git pull
Auto-merging env.txt
CONFLICT (add/add): Merge conflict in env.txt
Automatic merge failed; fix conflicts and then commit the result.
成功!
这回git pull成功,但是合并有冲突,需要手动解决,解决的方法和分支管理中的解决冲突完全一样。解决后,提交,再push。
结合上面的内容,可以看出多人协作的工作模式总体上是:
1.首先,可以试图用git push origin
2.如果推送失败,则因为远程分支比你的本地更新,需要先用git pull试图合并;
3.如果合并有冲突,则解决冲突,并在本地提交;
4.没有冲突或者解决掉冲突后,再用git push origin
如果git pull提示no tracking information,则说明本地分支和远程分支的链接关系没有创建,使用命令git branch --set-upstream-to
1.首先访问指定项目的主页。
2. 点“Fork”就在自己的账号下克隆了一个该项目仓库,然后,从自己的账号下clone,
clone完毕后,立刻就可以开始改bug或修进,肝完后,往自己的仓库推送。
注意:
(1) 一定要从自己的账号下clone仓库,这样你才能推送修改。如果从其它项目作者的仓库地址克隆,因为没有权限,我们将不能推送修改。
(2) 如果你希望某项目的官方库接受你的修改,你就可以在GitHub上发起一个pull request。当然,对方是否接受你的pull request是视情况而定的。
我们一直用GitHub作为免费的远程仓库,如果是个人的开源项目,放到GitHub上是完全没有问题的。其实GitHub还是一个开源协作社区,通过GitHub,既可以让别人参与你的开源项目,也可以参与别人的开源项目。
在GitHub出现以前,开源项目开源容易,但让广大人民群众参与进来比较困难,因为要参与,就要提交代码,而给每个想提交代码的群众都开一个账号那是不现实的,因此,群众也仅限于报个bug,即使能改掉bug,也只能把diff文件用邮件发过去,很不方便。
但是在GitHub上,利用Git极其强大的克隆和分支功能,广大人民群众真正可以第一次自由参与各种开源项目了。这是git联合github带来的好处!
但Git虽然极其强大,命令繁多,但常用的就那么十来个,掌握好这十几个常用命令,每个人已经可以得心应手地使用Git了。
十分感谢您的阅读~
祝您变强了~
我是花花,希望能和您一同成长~