git版本控制管理实践-4
vcs: version control system 版本控制系统
local vcs, 集中式版本控制系统: centralized vcs; 分布式vcs: distributed vcs
Local vcs, 主要是用在linux系统上用来管理配置文件的, 代表性的有 RCS
集中式: CVCS, 典型的 有: CVS(concurrent version system, 并行版本系统, 协作开发版本系统, 跟VCS前两个字母相反) subversion(svn)
分布式vcs: DVcs, 包括git等. git既有本地版本数据库, 也可以部署远程中心版本库, 所以克服了Lvcs和Cvcs的缺点..
git config配置完成后, 通过git config --list 来查看配置信息;
git帮助, 有两种方式, 传统的: git command --help/ 另一种帮助是: git help; git help a_command.
untracted files: 表示未跟踪的文件, 未被git所管理, 所记录的文件, 当用git add后, 就成为new files: 表示被git管理跟踪的新文件了...
回溯(su四声, 不是多音字): backtrace: 逆着水流而走: 溯水而上， 追忆, 追溯.
图形界面: source trace.
git-shell: 其实是没有这个命令的, 只是不想让用户git从本地登录而已...
passwd命令: 格式如下, (其实, 几乎所有 的 linux命令的格式 都是这样的 : command [options] <[args]>
在所有的passwd选项中, 都没类似-p 之类的可以直接设置秘密的选项, 也就是说, passwd命令必须要从随后的 交互式界面 输入 密码...
userdel命令, 只会删除passwd/etc/group下的用户, 但是/home目录下的用户目录不会删除,所以, 要删除用户及其对应的目录, (傲慢和嘲笑), 用-r, --remove.
一切仓库的管理(git服务器上), 约定的是用git用户, 就说说, 专门用git这个账户来管理" remote public git repository" , 那么关于远程仓库 的创建, 权限的管理等等, 都是 用 git账户的...
chown chmod
chown是改变文件 的所有者和所属组, 如果只是指定foo, 没有指定foo:foo, 则只是 指定的所有者, 不会改变 所属组;
chown的选项, --dereference, 是默认的选项, 表示 改变 符号链接所值的目的对象, 不会改变符合链接本身
-h, 等于 --no-dereference, 表示, 不解引用, 即: 只修改符号链接本身, 而不修改链接所指的 目标文件: 通常的命令是: chown -hR foo:foo test
以后写文章, 表示 "而不是"的意思, 不再只是用 but not, 要多用instead of 和 rather than, 凡是有取代/替代的 "而不是" , 用instead of , 否则就用rather than..
instead, 可以单独使用, 表示"相反地.."; 也可以接 that从句
instead of, 后面接名词, 或doing...
rather than 后面接名词, 或 "动词原型do"
instead of只是陈述事实( 表示 "是...不是...")没有感情色彩; rather than 带感情色彩的, 表示 " 而不是", "宁愿".
de'reference [di'ref2rens], 解引用, 解除引用, 间接引用, 用引:
the de'reference opertor is also known as the indirection operator. be known as : 被称为...
int *p, i; p=&i; p; //这里的p, 就叫做 解引用...
instead of 有代替，取代的意思
but not 有然而，但不是，并非的意思
rather than 宁可...也不愿(与其...倒不如,而不是)，不是…而是…；与其说…不如说…
其实仔细研究，区别还是很大的，近义短语的准确应用，**就得看你平时的阅读量了，读多了，自然有语感，都分辨得出。**
真的仓库, 默认名称是 .git, 但是你可以指定一个有意义的git: 如: cd /opt/git, git init test-remote.git, 但是 即使你指定了test-remote.git目录, 创建的仓库还是这个目录下的.git目录: test-remote.git/.git. 要想直接在test-remote.git下生成仓库, 即没有.git目录, 需要使用--bare: git init --bare test-remote.git", 表示这个是一个 专门用来共享-- 存储远程代码的仓库. 即不需要工作目录, 所以,仓库就直接在指定目录下生成了
下面是一个成功的ssh 连接和git clone的例子:
从上图可只:
-
默认 的sshd服务是关闭的, 所以一定要开启sshd服务, 才不会被连接拒绝
-
支持ssh连接的, 要求输入git@127.0.0.1的密码, 是指git用户的密码.
-
支持~git目录扩展, 支持scp-like syntax, 但是前面不能家ssh://, 这个在man手册上说的: there is no colon before the first colon. 否则会报错说找不到那样的主机或协议:
-
sshd连接和git clone看起来跟selinux没有关系, 下面开启了setenforce=1, 还是能够clone远程仓库; 而且, 当git clone的时候, 一定要是一个空的 empty directory...
su命令, man su 1/2/3..., 表达 什么 ... 目的 时候, 动词形式用 to... , 名词形式, 用 for... , 比如 : for backward compatiblity, su **defaults to **not change the current directory. want means "a login shell": 是指的 当切换用户的时候, 当前目录 也切换到 target user's home dir, 并且重新设置环境变量...
使用 su [- == -l == --login] another_user : 将进行一次 a login shell "switch user: " su= switch user.
如果是clone来的仓库, 可以直接push, 因为这时, git已经知道origin了.但是如果不是clone的远程仓库, 则要在push之前, 先add, 好让git知道/跟踪/管理远程git仓库...
从下图可以看出: push成功后, 在远程仓库也可以看到commit的记录, 而且远程服务器和本地的仓库 的commit的 提交名称也是一样的...
算法的类型:
dsa: digit sign algorithm, 数字签名算法
ecdsa: 将ecc(erro checking and correcting,主要用在服务器 和工作站, 使系统更稳定)和dsa相结合.
**数字签名值, 就是 消息摘要值. "消息摘要值,message digest value ['daid3est] 发音参考: suggest; 这里的摘要, 并不是真的像读者文摘的摘要, 而是说, 对一段消息(其实是文本, 明文的文本), 应用 hash算法, 得到唯一的一段 128bits的 字符串 **
为什么消息摘要值, 即 hash值, 散列值, 可以作为数字签名, 表明信息的真实性?
因为, hash值具有 抗冲突性, 一段明文, 哪怕只有一个字母的改变, 都会改变计算出来的hash值; hash函数的 单向性, 表示 要找到两个hash值相同而内容不同的消息- 文本, 在计算上是不可能的.
只有消息的发送者才能产生 消息的摘要.
消息摘要保证了消息的完整性。 消息摘要采用单向Hash 函数将需加密的明文"摘要"成一串128bit的密文，这一串密文亦称为数字指纹(Finger Print)
消息摘要值的验证过程: 验证需要两个值进行比对: 一个是 接受方根据接受到的消息, 独立计算出来的一个hash值; 另一个是: 发送方对要发送的消息, 先进行hash计算出散列值, 然后用发送者保持的 私钥进行加密, 接受方会随同接收到的消息一起接受一个 公钥, 然后用这个公钥对接受到的 加密散列值进行解密, 得到一个散列值; 最后将这两个散列值进行比较, 如果相同, 就证明这个消息是完整的. 由于这个私钥和公钥 是配对的, 是一对, 而且只有消息发送者产能产生密钥对, 所以通过公钥 对消息摘要 的 解密和验证, 是能够验证 对方的身份的...验证对方的指纹的: finger print. 消息-接受信息的完整性, 和 登录用户的身份验证, 其实是一起的, 只不过关注的重点不一样而已, 身份验证的消息可能是随机产生的一段文本消息....
bit coin protocol: 比特币协议,
ssh-key -b -t -f:
-b : 表示算法的比特位数是多少位?
-t: 表示算法的类型
-f:
不管是本地的ssh用户, 还是远程服务器的git的用户, 都建议将ssh的密钥 放在 .ssh目录中,
如果是git远程的服务器, 则要存放要被验证的 用户的 ssh的公钥, 放入git用户的: ~/.ssh/authorized_keys 文件中
因为要对ssh登录进行认证, 很明显, 远程git服务器上的 .ssh目录 以及 authorized_keys都只能由 git用户自己一个人读写, 不能由其他用户读写, 这是为了保证安全! 否则就不会 认证成功.
即要用root账户对 ~git/.ssh 和它里面的 authorized_keys: 进行设置: chmod -R 700 ~git/.ssh/ (设置成600 好像是不可以的!
不要密码, 只需要 ssh identification 的截图如下:
上传 ssh 公钥, 最后在clone 拉取的时候, 输入私钥, (其实是私钥的 密码), 也叫输入(证书).
第一次要输入证书, 以后就不会需要了.........
如果不能提供证书, 还是得要 输入 git 账户的密码..
systemctl是unix的控制面板, 管理系统的服务, 核心组件什么的. 如: systemctl list-...., 是列出 loaded(已经载入的...), lsit-files, list-units, list-sockets, list-timers.
systemctl 不能只针对 某一个用户来设置, 只能针对全部用户, 所以, 开机启动项目, 是放在 /etc/systemd/system/multi-user.target.wants/ foo.service中的, 这些是开机启动的, 不开机启动 需要手动启动的服务在 : /usr/lib/-----/systemd/system/ 中: 当设置开机启动foo服务时,会: created symlink from ..(链接). to ....(链接的真实母的 referent) ....
当git remote add some_remote_repo git@somehost:/path/to/repo, 只是添加了 一个"通告", 而实际上, 远程的仓库是个 "什么样子, 本地并没有见面, 根本不知道对方的长相, "所以 你也没有办法直接去push, 只有 "谈对象"的双方 第一次 经 "媒人" 介绍接触过了后( git pull 后) , 然后对方都知道 彼此的 master 仓库结构后, 才能相互间 进行 push..
问题: ERROR: src refspec master doesn't match any(master 的指定引用 源, 没有匹配), 就是因为你没有事先 pull
解决方案:
表示密码的单词由: password, passcode, passphrase. (passcode是只是 由数字组成的密码?), passphrase是密码短语, 词组.是满足某些规则的密码.. (randomart: 是公钥的finger print 指纹):
表示从句的介词短语后面可以接不定式, 不一定是句子: 比如: Enter file in which to save the ssh keys...
以前对giit的理解总结:
origin, 是由git clone下来的仓库的 简洁的称呼, 如果不是clone下来的, 则要用git remote add some_name repo_address来定义 远程仓库
远程仓库的管理, 是用 git remote: 后面的命令包括: add, remove, rename等等, 这个可以用tab来显示 提示, 这个就不难理解 cisco的路由器或交换机的命令行的操作了, 掌握了linux的 shell-terminal 的操作, 对router/switch的操作就更加深刻理解了, 因为 后者就是通过 前者来的.两者是一样的东西..
git remote: -v只是综述的显示remote的仓库; 而要更详细地显示仓库的信息, 则要用 git remote show repo1 repo2 repo3... 可以一次性的输入多个仓库名称.
git diff比较差别, 注意, git只是 管理 已经被 tracked的files, 对于没有被tracked的文件(for untracked files), 即使你新增了好多个其他文件, 对于git来说, 凡是未被tracked的文件, 都是 "不可见的", 都是 "视而不见" 的! 所以, 虽然新增了readme文件, 但是由于没有被 tracked, 所以它认为 working tree & index & repo 三者之间都是没有差别的..., 一旦add后, 差别就能 "侦测"到了
对于多人开发的--bare仓库, 如果别人先push了代码, 你再push时, 要先把别人提交的 新增的代码 pull到本地后, 你才能再push你的代码, 只是跟push的先后顺序有关, 跟不同的用户, push的次数多少次无关
** Hints: updates were rejected because the remote contains work you do not have locally. This is usually caused by another repo pushing to the same ref. (动名词/动词 的 短语, 跟主谓句子的区别是, 前者没有系动词而已) **
注意: pull之后 所有 的文件 就都属于当前用户了, 即使他们之前是由其他账户, 如root创建的, pull之后, 在push就成功了:
前面所说的 git config --global user.username John.... 是针对 "某一个具体的账户" 而言的, git 的一切动作都是针对 "具体的 确切的 用户"而言的. 一个用户(账户)可以由多个git 项目仓库, 可以对所有的仓库共用一个账户设置, 也可以单独对某个仓库设置账户, 但是一般来说, 一个用户/账户下的仓库, 通常, 都是共用一个账户设置,而且就是 这个 账户.用户的名字. 所以 对于另外一个账户, 你在使用git的时候, 同样也要进行git账户信息的设置, 原来设置的其他账户如root账户的git设置对 bar用户就 无效了. 如果对bar用户不设置 git账户, git不会让你commit的!
.gitconfig文件, 不只是root用户才有的, 其他账户, 只要配置了 git user的都会在 ~账户/.gitconfig 下生成这样的文件
为什么对于 非root用户, 如bar用户, 设置 git config --global user.username 会出错, 而设置成user.name就好了?
这是一个细节: git config 非常多的设置中, (git config --get user.email 会获得config的 设置....) , user组中, 有: user.email, 还有 user.name (这里应该是name, 不该是username, 因为前面的group name已经是user 了, 你在写username不就 重复多余了吗, email也没有写成 useremail吧??), 写成user.username 有时会出错, 尽管 你也能创建 ~/.gitconfig文件, 也能cat .gitconfig, 但是 配置成user.username还是 错的, 改成 user.name 就能正常提交了. 不会报错: cann't commit for ident(== i'dentification) user name. (说明git没有认 user.username!)
附加内容:
-
为什么git的效率相对于其他vcs更高?
因为git保存文件之间的差别 是通过文件的快照, 而不是保存文件之间的区别:
-
远程仓库的协议, 有git(专门做了优化的), local主要是在本地多加一个备份...
-
对于远程仓库(包括本地仓库也是这样), 不管是remove, 还是rename等操作, 都要commit到远程仓库才能保存, 否则做的工作都是无效的... commit的情况, 不只是add的情况, 而是具有更广泛, 更普适的含义, 对于remove和rename, commit时,不加文件, 而是直接指明 -m '提交备注'....
-
git的算法是sha-1, 用sha-1对文件内容和目录结构进行哈希运算, 得到消息摘要值作为文件的指纹: finger print...
-
git的仓库是指.git这个隐藏文件夹, 在--bare仓库上,就是 someCode.git目录:
-
git -a -m 的提交只是针对已经tracked的文件改变时, 的提交, 注意git还是会去做git add这个
