我们都知道在工作时,代码繁多冗乱真的是很让程序猿头痛的事情。
今天上课时老师教我们使用Github记录和存放代码文件,以下分步骤总结:
第一步:注册github→https://github.com/的账号
第二步:创建一个新的项目 new repository 就是创建仓库的意思
之后就可以安装git客户端开始配置。
http://git-scm.com/download/ ←git下载地址
安装好以后在开始程序中就可以找到git的三个程序,打开Git bash 就可以弹出窗口了。
第三步:首先输入ssh-keygen -t rsa -C “邮箱账号” 注意空格!
回车之后是输入一个保存秘钥的地方,括号里是默认的位置,可以不用输入,直接回车就可以了。
然后回到默认的位置(C:\Users\Administrator\.ssh)找到id_rsa.pub 文件复制粘贴里面的内容
转到网页端github上面找到setting 也就是设置,然后点击左侧的SSH Keys。之后再点击Add SSH Key,这样会出现添加SSH Key 的界面,在Title 这一栏填一个名字,之后将复制的内容粘贴到key这一栏,点击Add Key 按钮完成操作。
第三步就是验证是否成功,点开git端:
1.输入命令:ssh -T git@github.com 。如果你是第一次就会让你输入yes/no 这时输入yes 就可以了。
2.配置用户名和邮箱 :
git config--global user.name “用户名”
git config--global user.email “邮箱”
3.如果你想更改下本地存放的地址输入cd /更改的盘名/文件夹名字 记住!cd后面有空格!
到现在为止,就算把git 和gitHub 配置完。然后才开始项目的上传与下载以及如何更新修改!
1) git init 初始化
2) git remote add origin git@github.com:账户名/仓库名.git (本地与云端的连接)
3) 从gitHub 端同步到本地代码git pull git@github.com:naraqin/naraqin.git(前面是用户名后面是仓库名)
4) 把本地代码同步到github 端
A. git add . 是提交所有本地文件,git add是单独的文件输入命令比如 git add demo.txt 提交的文件是自己创建的文件
B.git commit -m “写下你本次提交代码的提示信息”(这个是规则必须要写 注意-m之前 有空格)
C.提交提示信息之后,我们将它推送到远程仓库上去,命令如下:git push git@github.com:账户名/仓库名.git [注意push]
基本上到这步就可以使用了,总结一下。如果有新的文件或者修改文件我们必须要先add 然后commit 最后push
必须先add 然后commit 最后 push期间我们可以穿插 git status
这是git端的基本使用记录。
以下是我对廖雪峰分支管理的自学理解:
分支在实际中有什么用呢?假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险。有了分支,就不用怕了。你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作。
这段话最够让我知道分支的大概含义,就是分身。通俗来说也许就是创建了一个可以有管理自己代码的东西,不影响自己其余的工作,也不会丢失管理的数据。
每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支。截止到目前,只有一条时间线,在Git里,这个分支叫主分支,即master
分支。HEAD
严格来说不是指向提交,而是指向master
,master
才是指向提交的,所以,HEAD
指向的就是当前分支
在git内是只有一条时间线的,并且就是主分支就是master分支。也就是我们每次提交的新的文件或者修改都是只有一条线。
master
分支是一条线,Git用master
指向最新的提交,再用HEAD
指向master
,就能确定当前分支,以及当前分支的提交点
每次提交,master
分支都会向前移动一步,这样,随着你不断提交,master
分支的线也越来越长
而分支合并就是把master分支指向当前分支的提交点,就可以合并分支了。
解决冲突:
当master分支和创建的新分支各自都分别有新的提交,
这种情况下,Git无法执行“快速合并”,只能试图把各自的修改合并起来,但这种合并就可能会有冲突
Git告诉我们,readme.txt
文件存在冲突,必须手动解决冲突后再提交。git status
也可以告诉我们冲突的文件
Git用<<<<<<<
,=======
,>>>>>>>
标记出不同分支的内容,我们必须进行人为的修改才可以解决冲突
当我们把master与新分支连接,就可以解决冲突了。
当Git无法自动合并分支时,就必须首先解决冲突。解决冲突后,再提交,合并完成。
解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容,再提交。
用git log --graph
命令可以看到分支合并图。
分支管理策略:
通常,合并分支时,如果可能,Git会用Fast forward
模式,但这种模式下,删除分支后,会丢掉分支信息。
为了防止丢失,我们就要管理分支。
在实际开发中,我们应该按照几个基本原则进行分支管理:
首先,master
分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
那在哪干活呢?干活都在dev
分支上,也就是说,dev
分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev
分支合并到master
上,在master
分支发布1.0版本;
你和你的小伙伴们每个人都在dev
分支上干活,每个人都有自己的分支,时不时地往dev
分支上合并就可以了。
所以,团队合作的分支看起来就像这样:
Git分支十分强大,在团队开发中应该充分应用。
合并分支时,加上--no-ff
参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而fast forward
合并就看不出来曾经做过合并。
BUG分支
每个bug都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除。
Git提供了一个stash
功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作
首先确定要在哪个分支上修复bug,假定需要在master
分支上修复,就从master
创建临时分支。
修复bug时,我们会通过创建新的bug分支进行修复,然后合并,最后删除;
当手头工作没有完成时,先把工作现场git stash
一下,然后去修复bug,修复后,再git stash pop
,回到工作现场。
feature分支
添加一个新功能时,肯定不希望因为一些实验性质的代码,把主分支搞乱了,所以,每添加一个新功能,最好新建一个feature分支,在上面开发,完成后,合并,最后,删除该feature分支。
如果要丢弃一个没有被合并过的分支,可以通过git branch -D <name>
强行删除
多人协作
当你从远程仓库克隆时,实际上Git自动把本地的master
分支和远程的master
分支对应起来了,并且,远程仓库的默认名称是origin
。
要查看远程库的信息,用git remote
或者,用git remote -v
显示更详细的信息
推送分支就是把该分支上的所有本地提交推送到远程库。推送时,要指定本地分支,这样,Git就会把该分支推送到远程库对应的远程分支上
查看远程库信息,使用git remote -v
;
本地新建的分支如果不推送到远程,对其他人就是不可见的;
从本地推送分支,使用git push origin branch-name
,如果推送失败,先用git pull
抓取远程的新提交;
在本地创建和远程分支对应的分支,使用git checkout -b branch-name origin/branch-name
,本地和远程分支的名称最好一致;
建立本地分支和远程分支的关联,使用git branch --set-upstream branch-name origin/branch-name
;
从远程抓取分支,使用git pull
,如果有冲突,要先处理冲突。