搬瓦工如何搭建做网站,网站中的宣传册翻页动画怎么做,ppt模板的种类,网站实例文章目录 一、前言二、Git手册学习2.1 Git介绍前置知识2.2 Git教程2.2.1 导入新项目2.2.2 做更改2.2.3 Git追踪内容而非文件2.2.4 查看项目历史2.2.5 管理分支#x1f53a;2.2.6 用Git来协同工作2.2.7 查看历史 三、结尾 一、前言
Git相信大部分从事软件工作的人都听说过… 文章目录 一、前言二、Git手册学习2.1 Git介绍前置知识2.2 Git教程2.2.1 导入新项目2.2.2 做更改2.2.3 Git追踪内容而非文件2.2.4 查看项目历史2.2.5 管理分支2.2.6 用Git来协同工作2.2.7 查看历史 三、结尾 一、前言
Git相信大部分从事软件工作的人都听说过甚至用过。 它是一款版本控制软件用于管理项目迭代更新。 但大部分时候你可能只是用过。就我个人而言能想起来并知道其用途的就下面几个简单命令
git init
git pull
git add
git commit
git push还有git remote、git branch等命令会偶尔用一下但使用时都得上网查询。 虽然大部分情况下这已经够了。 但偶尔会出现一些特殊情况可能是操作时序有误导致的冲突可能是项目真的有损坏。
当然本文并不需要解决这些问题只是想通过文档学习对git流程、git基础有个更全面的了解。
我打算从git介绍、git简单命令、git文档教程入手对git进行进一步学习。
二、Git手册学习
git是一个傻瓜式的内容跟踪器Linux内核的首席架构师也是Git的主要开发者Linus Torvalds是这么说的。
使用简介如下
git [-v | --version] [-h | --help] [-C path] [-c namevalue][--exec-path[path]] [--html-path] [--man-path] [--info-path][-p|--paginate|-P|--no-pager] [--no-replace-objects] [--bare][--git-dirpath] [--work-treepath] [--namespacename][--config-envnameenvvar] command [args]这一长串的命令选项可以看出其功能之强大虽然这也不是给一般人用的。不过也别被吓到根据八二定理大部分情况下你只需要用到几条简单命令即可而且现在有许多带GUI的git图形化操作相对简单许多即使如此你还是需要了解Git基本流程。
2.1 Git介绍前置知识
Git是一个快速、可扩展、分布式版本控制系统具有异常丰富的命令集提供高级操作以及对内部的完全访问。
文档建议从 gittutorial 开始学习不过在这之前还有一个非常重要的前置知识那就是Git的二区一库。 二区是指 工作区Wokespace即受Git管控的项目目录/文件夹。 暂存区英文是 index 或 stage也叫索引。一般存放在 .git 目录下的 index 文件中。
一库指
版本库在工作区有一个隐藏目录 .git 这个不算工作区而是Git的版本库。
三者的简要关系如下 可以看到Git的版本库也就是Git初始化后项目目录下多出来的那个.git文件夹里有许多东西其中最重要的就是暂存区stage或者叫index还有Git为我们自动创建的第一个分支master以及指向master的指针叫HEAD。
有了以上简单认识接下来正式进入Git教程。 注意 本小节内容是后来补的故与后文可能没那么连贯。 但其内容对了解后文部分操作相当有用。 2.2 Git教程
gittutorial这是文档中的章节名顾名思义它是git的教程介绍。 本节介绍如何将新项目导入git对其修改并将更改共享给其他开发人员。
首先可以通过git log --graph等命令获取文档
$ man git-log或
$ git help log后者会使用手册浏览器我装了的是某种GUI Git在命令行中输入前者并不起作用后者则会弹出说明文档 $ 符号 $: (读法和dollar一样), 命令行中的 $ 符号是Linux系统下的用户提示符表示当前用户是普通用户。 你在windows系统下安装git时通常会装上vim命令行编辑器也会看到该符号。 在进行操作前最好向Git说明你的姓名和电子邮件地址。最简单的方法是
$ git config --global user.name Your Name Comes Here
$ git config --global user.email Youyourdomain.example.com2.2.1 导入新项目
假设你一开始有一个tarballLinux下的打包工具 project.tar.gz 包。你可以把它放在Git版本控制路径之下能用Git访问到如下操作
$ tar xzf project.tar.gz
$ cd project
$ git init在windows下前两行通常可以省略因为可以用图形化的解压工具winrar/7zip等解压完直接在解压出的文件夹里右键打开命令行工具称为bash并输入 git init 即可。
Git会回应
Initialized empty Git repository in .git/现在Git已经初始化了该文件夹此时你可以看到该目录下多了一个名为 .git 的新文件夹。
接下来告诉Git对当前目录下的所有文件进行快照take a snapshot用 git add命令 . 表示当前目录
$ git add .该快照现在存储在Git中称为 索引index 的暂存区域中。你可以用 git commit将索引的内容持久化到仓库即版本库中。 索引相当于一个缓存区所做修改先添加到索引中然后再提交最终版。就像考试一样你先在试卷和草稿纸上写写算算然后在答题卡上填上答案最后再提交而不是试卷上写一个字提交一个字。从整个Git系统来看这个比喻可能不那么恰当
$ git commit这会提示你输入提交信息即对此次提交进行简要说明。输入完后保存退出就已将项目的第一个版本存储在Git中了Vim中是这样的GUI中则是点相应确认按钮。
2.2.2 做更改
修改一些文件然后将它们的更新内容添加到索引中
$ git add file1 file2 file3现在已经准备好了提交。 你可以使用 git diff 带 --cached 选项来查看将要提交的内容。
$ git diff --cached(若没有 –cached 选项 git diff 则显示你已经做出但尚未添加到索引中的更改)。你也可以使用 git status 来得到Git状态的简况 –cached就是缓存即查看索引的变化确切讲是索引与上一次提交的不同 不加就是查看工作区的变化工作区相对于于索引的不同。 $ git status
On branch master
Changes to be commited:(use git restore --stagedfile... to unstage)modified: file1modified: file2modified: file3若你需要进一步做更改请立即进行然后将新更改的内容添加到索引中。最后用以下命令进行提交
$ git commit这将再次提示你输入描述更改的信息。然后记录项目的新版本。 或者你可以使用以下命令而无需预先运行 git add
$ git commit -a它会自动关注任何修改过的但非新的文件将它们添加到索引中然后提交所有这一切都在一步中完成。顾名思义它不会追踪到新文件只会追踪更改过的老文件若你有新建文件则会被遗漏
提交消息的注释虽然不是必须的但最好以一个简短的不超过50个字符行来总结更改然后空一行进行更全面的描述以开始提交消息。 提交消息中第一个空行之前的文本被视为提交标题并且该标题在整个Git中使用。 例如 git-format-patch 将提交转换为电子邮件并使用主题行上的标题和正文中的提交的其余部分。
2.2.3 Git追踪内容而非文件
许多版本控制系统提供了 add 命令该命令会告诉系统开始跟踪新文件的更改。
Git的 add 命令功能更单一且更强大
git add 作用于新建文件和新更改的文件这两种情况下它都会拍摄/记录给定文件的快照并将内容暂存在索引中准备好包含在下一次提交中。即新建一个文件也能被追踪到并非只记录老文件的修改
2.2.4 查看项目历史
你可以随时使用以下命令查看更改的历史记录
$ git log若你想要看每一步完整的差异使用
$ git log -p通常每次更改的概述对了解每一步很有用
$ git log --stat --summary2.2.5 管理分支
单个Git仓库可以维护多个开发分支。 使用以下命令可以创建一个名为 experimental 的新分支
$ git branch experimental若你此时运行
$ git branch你会得到一份表示现有的分支列表 experimental
* masterexperimental 分支是你刚刚创建的分支 master 分支是默认分支。 * 标记了你当前所在的分支输入
$ git switch experimental以切换至 experimental 分支。现在编辑文件提交更改然后切换回主分支。
(edit file)
$ git commit -a
$ git switch master检查你刚刚所做的更改是否不再可见因为它是在 experimental 分支上进行的且你现在回到了主分支上。 题外话 以前用过部署在远端的git仓库觉得切换分支后内容发生变化是一件稀松平常的事。 但这次在本地试验后还是觉得很震撼就在一个文件夹下我敲一条切换分支的命令这个文件夹下的文件就变了惊叹的不是这样的功能实现而是功能设计。 现在你可以在 master 分支上做一些不同的更改
(edit file)
$ git commit -a此时两个分支已经有所不同了每个分支都做了不同的更改。若要合并 experimental 中的更改请运行
git merge experimental如果更改没有冲突就合并完成。若存在冲突则在有问题的文件中留下标记以显示冲突。 git diff 会显示冲突内容。若你编辑文件解决完了冲突。 可用 git commit -a 提交合并结果。 最后用 gitk 会出现一个友好的图形界面来显示历史记录。 此时你可以使用以下命令来删除 experimental 分支
$ git branch -d experimental该命令要确保 experimental 分支的更改已经完全在当前分支中了。 若你在一条名为 crazy-idea 的分支上开发了一阵子但又不想要这条分支了你也可以随时用以下命令删除分支
$ git branch -D crazy-idea分支很容易获取到所以在分支上开发新功能是尝试新事物的好方法即fork新的分支在新分支上开发功能开发完毕后合并以扩展主分支。
2.2.6 用Git来协同工作
假设 Alice 已在 /home/alice/project 中用Git仓库开启了一个新项目且在同一台机器上的Bob也想给该项目贡献代码。
Bob可以用以下命令
bob$ git clone /home/alice/project myrepo这会创建一个新目录 myrepo 其中包含 Alice仓库的一份克隆。克隆体与原始项目是平等的拥有自己的原始项目历史记录副本即Git也会对该克隆体管理对更改做历史记录。
接着Bob会做一些更改并提交
(edit files)
bob$ git commit -a
(repeat as necessary)当他准备好后他会告诉 Alice 从 /home/bob/myrepo 拉取pull仓库的更改。Alice 需要这样做
alice$ cd /home/alice/project
alice$ git pull /home/bob/myrepo masterbasic 这之前的内容应该属于常用且基础的这之后的内容算是进阶。 advanced 这样就将Bob master 分支的更改合并到 Alice的当前分支。若Alice在此期间也做了一些自己的变更那么她可能需要手动解决冲突。简单讲就是Alice和Bob都对某些文件做了更改Alice合并Bob的分支后这部分代码就会冲突就需要人工判断确定最终改动。
因此 pull 命令执行了两个操作从远程分支获取更改fetch然后将它们合并到当前分支中merge。
一般来讲Alice会在启动 pull 前提交她的本地更改。 但若在Bob克隆分支后Bob的工作与Alice所做的内容冲突Alice将使用她的 工作树 和索引来解决冲突且已有的本地更改会干扰冲突解决过程Git仍将执行获取但会拒绝合并——Alice将不得不以某种方式摆脱本地更改的干扰并在该操作后再次 pull 。
Alice可以使用 fetch 命令先窥视Bob所作的事情而不首先合并。这允许Alice使用特殊标记 FETCH_HEAD 检查Bob所做的事情以确定Bob的分支上是否有值得拉取的东西就像这样
alice$ git fetch /home/bob/myrepo master
alice$ git log -p HEAD..FETCH_HEADHEAD 与 FETCH_HEAD 1 HEAD 如果你和我一样在这之前没有系统地学习过Git。 那看到HEAD和FETCH_HEAD应该会很头疼所以这里我对这两者做简单介绍。 HEAD是Git中非常重要的概念你可以将它理解为指针或引用就像C/C中的指针一样数据结构中的头指针它可以指向任意一个节点并且指向的节点始终为当前工作目录。换句话说当前工作目录就是HEAD指向的节点即它是对当前 Commit-ID 的引用。 为了更好地理解HEAD及相关操作再介绍一下什么情况下会影响HEAD。 使用 git commit 时HEAD会跟着移动并指向当前分支的最新 Commit-ID。使用 git checkout 时HEAD会跟着移动并指向对应分支的最新 Commit-ID。使用 git reset 时HEAD会跟着移动并指向对应分支的指定 Commit-ID。 2 FETCH_HEAD FETCH_HEAD 是一个版本链接记录在本地的一个文件中指向目前已经从远程仓库取下来的分支的末端版本。 而 git fetch 就会将远程仓库的最新版本获取到本地但不会 merge 。 即使Alice未提交本地更改该操作也是安全的。范围标记 HEAD…FETCH_HEAD 意思是显示从 FETCH_HEAD 可达的所有内容但排除可从 HEAD 到达的内容前不达后达。
Alice已经知道导致她当前状态 HEAD 的所有内容并使用该命令查看 Bob 在 Bob所在状态即 FETCH_HEAD 中她没有看到的内容。
若Alice想可视化Bob在历史分叉后做了什么可用以下命令
$ gitk HEAD..FETCH_HEAD这使用了我们之前在 git log 中看到的两点范围表示法。Alice可能想查看两人分支后都做了什么她可以使用三点的形式来代替两点
$ gitk HEAD...FETCH_HEAD这表示显示从任一者可访问的所有内容但排除从两者均可访问的任何内容。
注意该范围标记法也可以用在 gitk 和 git log 中。
在查看了 Bob 做了什么后若没有紧急情况Alice 也许会继续工作而不拉取 Bob的更改。若Bob的历史记录中确实有 Alice 立即需要的内容那么Alice可以选择先藏匿/储备stash她正在进行的工作进行一次 pull 最后再将自己的工作内容在新产生的内容之上进行修改。
当你在一个紧密联系的小团队中工作时反复与同一个仓库进行交互很正常。通过给远程仓库定义简写shorthand缩略名可以使其更简洁
alice$ git remote add bob /home/bob/myrepo这样Alice 可以使用 git fetch 命令单独执行 pull 操作的第一部分而无需将它们与自己的分支合并
alice$ git fetch bob与普通写法不同当 Alice 使用 git remote 设置的远程仓库简写从 Bob 处获取时获取的内容将存储在远程跟踪分支remote-tracking branch中在本例中为 bob/master 。所以在这之后
alice$ git log -p master ..bob/master显示 Bob 自 Alice 的 master 分支 fork 以来所作的所有更改的列表显示bob/master可达的路径排除master可达路径。
检查这些更改后 Alice 可以将这些更改合并到她的 master 分支中
alice$ git merge bob/master该合并也可通过从她自己的远程跟踪分支中拉取来完成就像这样
alice$ git pull . remotes/bob/master注意 git pull 总是合并到当前分支无论命令行给出了什么。 之后Bob 可以使用 Alice 的最新更改来更新他的仓库
bob$ git pull注意他并不需要提供 Alice 仓库的路径当 Bob 克隆 Alice 的存储库时 Git 将她的仓库位置存储在了仓库配置中并且将该位置用于 pull 操作
bob$ git config --get remote.origin.url
/home/alice/project使用 git config -l 可以看到 git clone 创建的完整配置git config -l 手册解释了每个选项的含义
Git还以 origin/master 名称保留了 Alice master 分支的原始副本
bob$ git branch -rorigin/master如果 Bob 后来决定在不同的主机上工作他仍然可以使用 ssh 协议执行 clone 和 pull
bob$ git clone alice.org:/home/alice/project myrepo或者Git 有本地协议或者可以使用 http详情参阅 git-pull(1) 。
Git也可以在类似 CVS 的模式下使用具有一个中央仓库各个用户都可以将更改推送到其中。详情参阅 git-push(1) 和 gitcvs-migration(7) 。
2.2.7 查看历史
Git 的历史记录表现为一系列相关联的提交。我们已经看到 git log 可以列出这些提交。请注意每个 git log 项的第一行还给出了提交的名称那串长长的英文字符与数字的组合字串 可以将该名称给到 git show 以显示该次提交的细节 也有一些其他的方法引用提交。你可以使用名称的任何初始部分得足够长来唯一标识提交 通常每个提交都会有一个 父 提交它指向项目的前一个状态
$ git show HEAD^ # 查看HEAD的父亲
$ git show HEAD^^ # 查看HEAD的祖父
$ git show HEAD~4 # 查看HEAD的曾曾祖父注意合并merge类型的提交可能会有多于一个的父亲
$ git show HEAD^1 # 显示HEAD的第一个父亲同HEAD^
$ git show HEAD^2 # 显示HEAD的第二个父亲你也可以自己给提交命名
$ git tag v2.5 709d387fbd12通过名称 v2.5 来引用 709d387fbd12 。若你打算与其他人共享此名称例如确认版本发布你应该创建一个“标签tag”对象并对其进行签名。
任何需要知道提交的Git命令都可以采用这些名称中的任何一个。例如
$ git diff v2.5 HEAD # 比较当前HEAD 和 v2.5
$ git branch stable v2.5 # 基于v2.5开启一条名为stable分支
$ git reset --hard HEAD^ # 将当前分支和工作目录回滚至 HEAD^ 的状态特别小心第三条命令它除了会丢失工作目录的更改外还会删除此分支中所有之后的提交类似于回档。若该分支是包含这些提交的唯一分支那么它们将会丢失。另外不要在其他开发人员从中 pull 的公开可见的分支上使用 git reset因为这会迫使其他开发人员进行不必要的合并以清除历史。若你需要撤销已经推送push的更改请用 git revert 。
git grep 命令可以在项目的任何版本中搜索字符串因此
$ git grep hello v2.5会搜索 v2.5 中所有出现的 “hello” 。 若省略提交名称 git grep 将搜索它在当前目录中管理的任何文件。因此
$ git grep hello是一种仅搜索Git跟踪的文件的快速方法。
许多Git命令还接受提交集即一次多个可以通过多种方式来指定这些提交。以下是 git log 的一些示例
$ git log v2.5..v2.6 # v2.5和v2.6之间的提交结合前面的HEAD..FETCH_HEAD来看# 就很清晰能看到v2.6的路径但排除v2.5的路径所以就是它们之间的
$ git log v2.5.. # 自v2.5开始的提交
$ git log --since2 weeks ago # 过去的两周提交
$ git log v2.5.. Makefile # 自v2.5开始的 Makefile的提交
你也可以给 git log 一个提交的范围在该范围中第一个参数不一定为第二个参数的祖先例如如果分支stable 和 “master” 的尖端从一个共同的提交中分离那么
$ git log stable..master会列出 master 分支所做的提交而没有 stable 分支做的提交。而
$ git log master..stable会列出 stable 分支所做的提交而没有 master 分支的提交。
git log 命令有一个缺点它必须以列表的形式呈现提交。当历史上有开发线分开然后合并在一起时 git log 显示这些提交的顺序就没有意义了。
大多数有多个贡献者的项目如Linux内核或Git本身都有频繁的合并而gitk在可视化它们的历史记录方面做的更好。例如
$ gitk --since2 weeks ago drivers/允许你浏览最近两周的修改了 drivers 目录下的文件提交。注意你可以通过按住control键同时按-“或”来调整gitk的字体
最后大多数接受文件名的命令允许你在任何文件名前添加一个提交以指定文件的版本
$ git diff v2.5:Makefile HEAD:Makefile.in你也可以使用 git show 来查看文件
$ git show v2.5:Makefile三、结尾
本文大部分是gittutorial中的内容整文偏应用向。 看完该教程对于你项目的基本修订控制应该是足够了。 然而为了充分理解Git的深度与功能本文还有p2p2重点对对象数据库和索引文件做介绍本文开头处也提到过它们是git中简单而重要的思想。
