一个很小的HTML项目,使用。Git来记录和跟踪这个项目。包括以下内容:

  创建版本库。

  添加与修改文件。

  创建新分支。

  打标签并整理版本库。

  克隆版本库。

创建版本库 Creating a Repository

  在Git中,版本库(.git目录)是与工作目录树并排放在同一个目录中的。

  本例中,要创建一个HTML页面,给这个项目取名为mysite。

  首先创建一个同名目录“mysite”,并进入到这个目录,然后输入命令git init。

  prompt> mkdir mysite

  prompt> cd mysite

  prompt> git init

  创建完成。

代码修改

  往空版本库里面添加文件:

  创建一个名为index.html的文件,并添加文本:

<html>
<body>
<h1>Hello World</h1>
<p>My first paragraph.</p>
</body>
</html>

  创建了一个简单的HTML文件后(把它放在mysite路径下),就可以开始跟踪版本了。

  要想让Git跟踪这个文件,须先让它知道这个文件,要分两步走:

  首先使用git add命令把该文件添加到版本库的索引(index);然后使用git commit命令提交。

  prompt> git add index.html

  prompt>git commit –m "add in hello world HTML"

  文件或文件列表可以作为git add命令的参数。

  git commit命令创建一个提交记录

  提交记录是存储在版本中的历史记录,每提交一次创建一个记录,并标记出代码的演进。

  Git把提交者的姓名和邮件地址,以及提交留言,都添加到提交记录中。

  参数-m,告诉Git本次提交的留言为"add in hello world HTML"。

  运行命令git log可以看到这个提交相关的信息:

  prompt> git log

  输出的第一行显示提交名称,是Git自动产生的SHA-1码。Git通过它来跟踪提交,使用该哈希码可以保证每个提交的名称都是独一无二的。

在项目中工作

  修改HTML文件如下:

<html>
<head>
<title>Hello World in Git</title>
</head>
<body>
<h1>Hello World</h1>
<p>My first paragraph.</p>
</body>
</html>

  修改完毕,Git可以检测到文件被修改。

  命令git status会显示工作目录树的状态,即当前的视图状态。

  prompt> git status

  上面的结果表明Git监测到了修改,但还不知道如何处理它们。

  如果要提交,需要暂存(stage)修改,以准备把修改提交到版本库。

  Git有三个地方可以存放代码。

  第一个地方是工作目录树,编辑文件时可以直接在这里操作;

  第二个是索引(index),也就是暂存区(staging area)。暂存区是工作目录树和版本库之间的缓冲区。

  第三个,也就是最终的一个,是版本库。

  命令git add,可以暂存对文件刚做的修改。它跟前面添加一个新文件时使用的是同一个命令,只不过,这次它告诉Git要跟踪的是一个新的修改而非新的文件。

  prompt> git add index.html

prompt> git add 。将当前文件夹的所有文件包括文件夹都加入index

prompt> git reset 撤销上一次的add

  prompt> git status

  暂存修改过的index.html之后,执行命令git status可以看到,信息变为了Changes to be commited,index.html这行由红色变为了绿色。

  使用命令git commit时,不要忘记使用带-m的参数,并在参数后面加上提交留言,以解释修改的原因,如下:

  prompt> git commit –m "add <head> and <title> to index"

prompt> git reset 2ee446d99c02ce66f4bc4ef463241950a9f2ddcd  提交恢复到某一次版本

  git log可以快速浏览提交留言:

  prompt> git log

  prompt> git log -1

  命令中加入参数:-1可以限制命令输出的提交条目的个数。

理解并使用分支

  比如mysite项目的代码现在几乎可以发布了,但是还需要进行测试等工作,直到确认它达到了预期的功能和质量,而与此同时,借助分支,可以开始下一个版本的新功能的开发了。

查看分支:
        $ git branch    该命令会类出当先项目中的所有分支信息,其中以*开头的表示当前所在的分支。参数-r列出远程仓库中的分支,而-a则远程与本地仓库的全部分支。
创建新分支:
        $ git branch testing    创建一个名为testing的分支

切换分支:
        $ git checkout teting   切换到testing分支上。通过向该命令传递一个-b参数,可以实现创建并切换分支的功能。

合并分支:
        $ git merge hotfix      将hotfix分支合并到当前分支当中去

删除分支:
        $ git branch -d hotfix  删除分支hotfix,-d选项只能删除已经被当前分支所合并过的分支,而要强制删除没有被合并过的分支,可以使用-D。

重命名分支:
        $ git branch -m oldbranch newbranch     -M用来强制重命名,如newbranch已经存在的时候。

查看分支之间的不同:
       
$ git diff branchName   查看当前分支与branchName分支之间的差异,也可以使用:$ git diff
branch1 branch2
来比较这1和2分支之间的差异,当使用第一种方式比较时,如果当前工作目录中存在与branchName同名的文件,系统则会提示错误,要是指明要比较的
是文件还是分支,如果比较分支,可以进入.git中进行比较或切换分支,如果是>比较文件,则使用$ git diff --
fileName命令。
        $ git diff <branchA>:<fileA> <branchB>:<fileB>
        $ git ls-tree -r branch 列出所有的树对象

把两次提交的不同重定向到patch
        $git diff dc20827e8880a0403dde7a94dfa540ebdd3c6df1  547348d336697c6e166f6b9183ed7ff61ef28b04 >haixin.patch
合并冲突:
    如果在不同的分支中都修改了同一个文件的同一部分,Git 就无法干净地把两者合到一起(译注:逻辑上说,这种问题只能由人来裁决。)
    任何包含未解决冲突的文件都会以未合并(unmerged)的状态列出。Git 会在有冲突的文件里加入标准的冲突解决标记,可以通过它们来手工定位并解决这些冲突。
    在解决了所有文件里的所有冲突后,运行 git add 将把它们标记为已解决状态(译注:实际上就是来一次快照保存到暂存区域。)。因为一旦暂存,就表示冲突已经解决。如果你想用一个有图形界面的工具来解决这些问题,不妨运行 git mergetool,它会调用一个可视化的合并工具并引导你解决所有冲突。
   
要从该清单中筛选出你已经(或尚未)与当前分支合并的分支,可以用 --merge 和 --no-merged 选项(Git 1.5.6
以上版本)。比如用 git branch --merge 查看哪些分支>已被并入当前分支(译注:也就是说哪些分支是当前分支的直接上游。)

远程分支:

远程分支是对远程仓库分支的索引。它们是一些无法移动的本地分支,只有在Git进行网络交互时才会更新。我们用(远程仓库名)/(分支名)来表示远程分
支。比如想查看上次>同origin仓库通讯时master的样子,就应该查看origin/master分支。

推送本地分支:
   
$ git push (远程仓库名字) (分支名)  如:$ git push orgin serverfix
该命令会将本地serverfix分支推送到origin远程仓库的serverfix分支中去,也可以使用命令 $ git push origin
serverfix:serferfix实现同样的效果,可以将第二个serverfix更改为其它名字来指定要将该本地分支推送到远程仓库中的的指定分
支中去,如果不存在,则会在
远程仓库中新建分支。

获取远程分支:
    在使用git clone命令从远程服务器克隆Git仓库时,只是将远程仓库当前分支的内容克隆到本地,要是克隆其他分支的内容,需要使用下面命令:可通过git branch -r命令来查看想要获取的远程仓库中的分支。
    $ git fetch origin  值得注意的是,在 fetch 操作下载好新的远程分支之后,你仍然无法在本地编辑该远程仓库中的分支。
    如果要把该内容合并到当前分支,可以运行 git merge origin/serverfix。如果想要一份自己的 serverfix 来开发,可以在远程分支的基础上分化出一个新的分支来:
        $ git checkout -b serverfix origin/serverfix
    这会切换到新建的 serverfix 本地分支,其内容同远程分支 origin/serverfix 一致,这样你就可以在里面继续开发了。

Git pull:
    从服务器的仓库中获取代码,和本地代码合并。(与服务器交互,从服务器上下载最新代码,等同于: Git fetch + Git merge)。
    从其它的版本库(既可以是远程的也可以是本地的)将代码更新到本地,例如:“git pull origin master ”就是将origin这个版本库的代码更新到本地的master主分支。
       git pull可以从任意一个git库获取某个分支的内容。用法如下:
       git pull username@ipaddr: 远端repository名 远端分支名:本地分支名。这条命令将从远端git库的远端分支名获取到本地git库的一个本地分支中。其中,如果不写本地分支名,则默认pull到本地当前分支。
       需要注意的是,git pull也可以用来合并分支。 和git merge的作用相同。 因此,如果你的本地分支已经有内容,则git pull会合并这些文件,如果有冲突会报警。

Git push
    将本地commit的代码更新到远程版本库中,例如 “git push origin”就会将本地的代码更新到名为orgin的远程版本库中。
       git push和git pull正好想反,是将本地某个分支的内容提交到远端某个分支上。用法: git pushusername@ipaddr: 远端repository名 本地分支名:远端分支名。这条命令将本地git库的一个本地分支push到远端git库的远端分支名中。
       需要格外注意的是,git push好像不会自动合并文件。因此,如果git push时,发生了冲突,就会被后push的文件内容强行覆盖,而且没有什么提示。 这在合作开发时是>很危险的事情。

git-clone命令只要碰到类似下面格式的远程仓库地址,都会被认为地址是符合SSH协议的:        账户@IP:工作目录

git checkout -b [分支名] [远程名]/[分支名]
如果你有 1.6.2 以上版本的 Git,还可以用 --track 选项简化
        $ git checkout --track origin/serverfix

删除远程分支:
        git push [远程名] :[分支名]

git pull 远程仓库名 远程分支:本地分支
git push 远程仓库名 远程分支:本地分支
git checkout -b 分支名 远程仓库名/分支名

  创建分支的命令是git branch,该命令需要两个参数:新分支名称和父分支名称。新创建的分支基于已经存在的父分支。

  prompt> git branch RB_1.0 master

  该命令从主分支(master branch)上创建一个叫RB_1.0的分支。

  主分支master是Git的默认分支。分支名称中的RB代表发布分支(release branch)。该前缀可以让人快速分辨出哪些分支是发布分支。

  现在来做一些新的改动。这些改动不影响准备发布的代码。

  在</body>之前增加如下代码:

<ul>
<li><a href="bio.html">Biography</a></li>
</ul>

  用如下命令提交这些修改:

  prompt> git commit –a

  参数-a告诉Git提交全部修改过的文件。

  (这时弹出了一个文本文件,输入的信息是提交留言)。

  现在主分支上有最新的修改,而发布分支上还是原来的代码。

  

  请切换到发布分支,做发布前的最后修改。切换分支的命令是git checkout。

  prompt> git checkout RB_1.0

  转换分支后,所使用的打开文件的编辑器会提醒文件已经被修改,重新载入文件,会发现刚才在主分支上做过的修改消失了。

  可以用git status命令来查看自己在哪一个分支上:

  prompt> git status

  

  做发布前的最后修改:在<head>标记块中添加一些描述性的元标签:

<head>
<title>Hello World in Git</title>
<meta name="description" content="hello world in Git"/>
</head>

  保存并修改该提交:

  prompt> git commit –a

处理发布

添加标签

  现在是发布的时候了,要给版本打个标签。

  给Git中的代码打标签,意味着在版本库的历史中标记出特定的点,这样将来就容易找到相应版本的代码。

  prompt> git tag 1.0 RB_1.0

  以上命令中的两个参数分别指明了标签的名称(1.0)和希望打标签的点(RB_1.0分支的末梢(所对应的版本或者说所对应的提交))。

  用不带参数的命令git tag可以查看版本库中的标签列表:

  prompt> git tag

变基

  想把RB_1.0分支上所做的修改合并到主分支上来,变基命令git rebase可以完成这项工作。

  变基是把一条分支上的修改在另一条分支的末梢重现。

  先回到主分支:

  prompt> git checkout master

  接着运行命令git rebase,后面跟一个参数:希望变基到哪条分支的末梢,就使用哪条分支名称做参数。

  prompt> git rebase RB_1.0

  变基前和变基后的版本库如下面两个图:

 

删除分支

  作为整理工作的一部分,删除发布分支RB_1.0。

  只要标签还在,从标签到版本树起点的一连串提交记录就都在。

  这时候删除分支只是删除了分支的名字,并不会删除分支上的任何实际内容。

  prompt> git branch –d RB_1.0

打补丁

  如果没有了发布分支,如何给1.0.x分支打补丁呢?很简单,只需要在打标签的地方再创建一条分支即可。

  前面创建分支的时候,命令的最后一个参数是新分支的父分支名称,现在只须把父分支名称改成发布标签名即可。命令如下:

  prompt> git branch RB_1.0.1 1.0

  prompt> git checkout RB_1.0.1

  运行命令git log快速查看历史记录:

  prompt> git log --pretty=oneline

为代码发布创建归档文件

  没有必要总是把历史记录(也就是Git版本库)一起发布,通常情况下,将标签对应的版本内容打包成一个tar包或者zip包就足够了。

  Git提供了git archive命令来做归档处理。

  prompt> git archive --format=tar --prefix=mysite-1.0/ 1.0 |gzip > mysite-1.0.tar.gz

  该命令中有三个参数:

  --format指明要产生tar格式的输出。

  --prefix指明包中所有东西都放到mysite-1.0/目录下。

  1.0指明要归档的标签的名称。

  最后一段命令把git archive产生的tar文件用管道输出的方法传递给命令gzip进行压缩,而压缩结果则重定向到mysite-1.0.tar.gz压缩包里。

  创建zip文件:

  prompt> git archive --format=zip –prefix=mysite-1.0/ 1.0 >mysite-1.0.zip

  生成zip格式和tar格式的命令参数几乎一样,只是改变了传递给--format的参数,而且无需通过命令gzip管道输出,直接把归档内容保存到归档文件中。

克隆远程版本库

  git clone带有两个参数:远程版本库的位置和存放该版本库的本地目录。

  第二个参数是可选的。

git项目版本管理的更多相关文章

  1. 项目版本管理Git使用详细教程

    前言 记得刚开始做项目开发的时候都是一个人完成一个项目,单打独斗的开发,也不知道什么是团队开发,没有这个概念,随着工作后来知道公司里项目都是团队开发,这个时候这么多人怎么开发一个项目呢,难道用u盘拷贝 ...

  2. git项目开发版本控制实践

    linux和bsd: 第一, bsd, berkeley software distribution, 伯克利软件套装, 是最开始的unix是开放的, 然后berkeley对unix进行了修改, 形成 ...

  3. 极速地将git项目部署到SAE的svn服务器上

    本文最初发布于我的个人博客:http://jerryzou.com/posts/gitForSAE/ 我花了一些时间自己写了一个能够极速地将一个git项目部署到SAE的svn服务器上的脚本.代码不是复 ...

  4. 使用SSH快速下载Git项目

    文章首发于[博客园-陈树义],点击跳转到原文使用SSH快速下载Git项目. Git下载项目的几种方式 Git是常用的代码版本技术,而GitLab则是开源的Git版本管理软件,GitLab是最受欢迎的版 ...

  5. 高效开发技巧:为什么你下载Git项目这么慢?

    文章首发于[博客园-陈树义],点击跳转到原文<高效开发技巧:为什么你下载Git项目这么慢?>. 笔者所在公司采用的是 GitLab 进行版本管理,但许多同事下载 Git 项目的路径是这样的 ...

  6. Atitit 项目版本管理gitflow 与 Forking的对比与使用

    Atitit 项目版本管理gitflow 与 Forking的对比与使用 1.1. 版本管理的历史 csv>>svn >git 1 1.2. gitflow的核心是分版本管理,for ...

  7. 微信小程序如何使用 Git 实现版本管理和协作开发

    前言 在微信小程序开发的过程中,代码版本管理往往需要使用第三方工具进行管理.虽然微信Web开发工具提供了对Git文件版本状态的提示,但实际的使用体验依然不尽人意. 随着微信Web开发工具的更新,最新的 ...

  8. 实验一 GIT 代码版本管理

    实验一  GIT 代码版本管理 实验目的: 1)了解分布式分布式版本控制系统的核心机理: 2)   熟练掌握git的基本指令和分支管理指令: 实验内容: 1)安装git 2)初始配置git ,git ...

  9. 实验一  GIT 代码版本管理

    实验一  GIT 代码版本管理 实验目的: 1)了解分布式分布式版本控制系统的核心机理: 2)熟练掌握git的基本指令和分支管理指令: 实验内容: 1)安装git 2)初始配置git ,git ini ...

随机推荐

  1. 贪心 Codeforces Round #300 A Cutting Banner

    题目传送门 /* 贪心水题:首先,最少的个数为n最大的一位数字mx,因为需要用1累加得到mx, 接下来mx次循环,若是0,输出0:若是1,输出1,s[j]--: 注意:之前的0的要忽略 */ #inc ...

  2. 【原】storm源码之storm代码结构【译】

    说明:本文翻译自Storm在GitHub上的官方Wiki中提供的Storm代码结构描述一节Structure of the codebase,希望对正在基于Storm进行源码级学习和研究的朋友有所帮助 ...

  3. No FileSystem for scheme: 远程访问HDFS找不到shceme

    问题描述: hadoop版本:hadoop-2.0.0-cdh4.3.0 在本地环境下能够找到scheme,但是通过maven打包fatjar 后放到其他机器上就出现找不到scheme. 看了代码,发 ...

  4. silverlight 富文本

  5. 解决 PermGen space Tomcat内存设置

    转自:http://qwzhl100.blog.163.com/blog/static/2133124200932813148637/ 在 使用Java程序从数据库中查询大量的数据或是应用服务器(如t ...

  6. 微课程--Android--Android开发学习体系

    四大组件 csdn上面一个关于安卓学习资料的网址 http://blog.csdn.net/vanpersie_9987/article/details/53043590 因为太懒所以花钱买罪受,花了 ...

  7. PHP5 session 详解【经典】 -- 转帖

    PHP5 session 详解[经典] http协议是WEB服务器与客户端(浏览器)相互通信的协议,它是一种无状态协议.所谓无状态,指的是不会维护http请求数据,http请求是独立的,非持久的.而越 ...

  8. Linux /etc/passwd 和 /etc/group 文件格式

    passwd: /etc/passwd 文件结构 2011-04-29 16:32:54| 分类: ubuntu技巧 | 标签:passwd linux ubuntu fadero centos./e ...

  9. io资料

    jitsi red5 apache meeting2 openmeeting2 openfire http://www.onlycoder.net/ 在视频会议领域,有许多可以值得参考的开源项目,这些 ...

  10. angular+selecte2(angular ng-repeat渲染)

    一.页面代码 <select id="sponsorId" select2 ng-model="sponsorSelectedObj" ng-change ...