分类 git 相关 下的文章

git 本地 branch 按照使用时间排序

使用 git 做开发, 我们的 branch 策略是每个新功能, 每个要修改的bug 都在一个单独的 branch 上坐开发. 久而久之, 本地就有很多 branch 了, 有些还没有合并到 master 分支上, 有些是正在开发的本地 branch.

如何查看最近使用的 branch?

# 查看最近使用的 branch 时间先后排序
git branch -l --sort committerdate

# 查看最近使用的 branch 时间倒序排序
git branch -l --sort -committerdate

# 查看最近使用的 branch 时间倒序排序
git for-each-ref --sort=-committerdate refs/heads/

# 查看最近使用的 branch 时间倒序排序 特定格式
git for-each-ref --sort=-committerdate refs/heads/ --format='%(committerdate:iso8601) %(refname:short)'

git 学习笔记 之 服务器上的 Git

原书中文版网址: here

为什么需要远程 git repo? 共享, 合作, 集成, 备份?
本地 repo <- pull, push -> 远程 repo
远程 repo 没有人在开发 -> no work directory -> so bare repository -> just need files in .git folder
git repo 所管理的所有东西, 都是 .git 目录下的文件 -> 它根据 git 自己定义的组织结构存在

架设 "git server" -> 通信 -> 选择协议 (file, ssh, http/https, git).

file 本地共享, 方便, 不安全, 灾难备份, 有时候许挂载;
ssh 同时支持 读, 写的网络协议, ssh 最常见, 安全, 基于用户名密码访问, 不利于共享, 和匿名访问;
git 自带的守护线程(9418), 需要 git-daemon-export-ok 文件, 没有加密&授权机制, 要么全部允许推送, 要么全部不允许;
http/https 简便, 便于分享, 需要 post-update hook, 如果需要推送 -> WebDAV, 端口常见, 效率低

"git server" 的关键点在于管理用户权限, ssh for each user? or shared account? or LDAP integratoin?

gitosis 可以帮我们管理 authorized_keys 中所有的 public key;
貌似Gitolite 更强大, 管理的细节竟然到了某 branch, refs 了.

服务器上的 git, 而不是 git server

上周看到 ddwrt 的 repo 中有 git, 就突发奇想, 是不是可以在路由器上搭一个 git server.
后来发现, 其实并没有 git server, 只有 server 上的 git.

首先, git 维护的是 .git 目录下面的所有文件和文件夹, repo 之间 push/pull 的效果是: .git 目录下面文件的相互 copy.
服务器上的 git 默认是没有监听线程的, 所以如果你 push, 其实是把文件 copy 到 server 上的某个 .git 文件夹下面. 一般我们用的还是 ssh 协议, 其实类是你 ssh 登录到 server, 然后用 vi 写 .git 文件夹下的文件.

所以最简单的 "git server" 是你在一个大家都可以访问的 server 初始化一个存放 .git 文件夹下所有文件的目录. 然后开放 ssh 协议, 凡是能够 ssh 登上这台 server 的人, 可以可以 push. pull 就是完全 copy 下来.

之所以有 git server 的惯性思维, 是因为我们经常用 github, gitlab 这样的 git web 管理 server, 是这些 web server 给了我们一个浏览我们 git 保存的历史版本的工具.

除了 github, gitlab (免费)之外, 还有一些比较方便的共享 repo 的方法 8 ways to share your git repository

另外: 服务器上的 Git - 协议

git 学习笔记<Version Control With Git>

好记性不如烂笔头, 今天理解并记住, 并不保证下次想用的时候还能理解

  1. git object store 存储4类: blob, tree, commit, tag;
  2. blob 存储的是文件的内容, 并被压缩, 算出 hash 为160bit, 40位16进制数字, 前2位作为文件夹名, 后面做文件名;
  3. git 是以内容寻址的, 只要内容一样, 生成的 blob 对象是一个;
  4. tree 相当于 linux 文件系统的 node, 存储系统某个文件夹结构. 它指向该文件夹下面的 blob 文件和 文件夹 tree;
  5. git cat-file -p [commit id | hash value] 可以看commit, tree, blob 的内容;
  6. 当某文件改变之后, 如果 commit, 那么该文件将会出现一个新的 blob 对象, 那么它上面文件夹对应的 tree 也会为了反映新的变化, 而出现一个新的 tree, 对应的, 递归向上, 直到 git 管理的顶层文件夹, 对应的 tree 都会出现新的一份. 没有改变的文件/文件夹的 hash 值没变, 那么他们对应的 blob 和 tree 都没有变, 新的 tree 还是指向它文件夹下的这些原有而没变的blob, tree 对象.
  7. 每个 commit 仅仅指向最顶层的 tree 对象, 每次有新的 commit, 最顶层的 tree 都会有新的一份. 并且每个 commit 都会指向它之前的 commit, 称之为 parent commit;
  8. 因为每个 commit 都指向最顶层的 tree, 那么顺藤摸瓜, 每个 commit 都能顺着顶层的 tree 找到当时的所有文件/文件夹的 snapshot;
  9. index/stage/cached 要么指向 HEAD 指向的 blob/tree, 要么指向 add 的 blob/tree;

git 常用命令 - git config

git config 用来设置 git 的配置选项.

git 的配置文件分为三个层次:

  1. 系统层面, 适用于系统的所有用户和所有 git repo, 一般位于 /etc/gitconfig. 但是我的 git 是 xcode 自带的 git, 它的系统层面的配置文件就位于 /Applications/Xcode.app/Contents/Developer/usr/etc/gitconfig;
  2. 用户层面, 适用于当前用户的所有 git repo, 位于 ~/.gitconfig;
  3. repo 层面, 仅适用于当前 git repo. 一般位于当前 repo 的 .git/config.

git 的配置选项一般分成2类: 客户端起作用的配置和服务器端起作用的配置, 但绝大多数是客户端起作用的.

git 列出当前所有的配置:

git config --list (如果在某 repo, 则显示当前 repo 继承的, 否则显示当前用户层面的)
git config --global --list
git config --system --list

得到某一具体配置:

git config --get user.name
git config --global --get user.name
git config --system --get user.name

添加某一配置:

git config --global test.example example 
git config --system --add test.sample "sample value"

去掉某一配置:

git config --global --unset test.example.value

git 常见的配置
git config 完全参考

  1. 1
  2. 2