git config alias.backup '!f() { ([ -f "/path/to/git-backup/$1/HEAD" ] || git init --bare "/path/to/git-backup/$1") && (git remote set-url --delete origin "/path/to/git-backup/$1" 2>/dev/null; git remote set-url --add origin "/path/to/git-backup/$1"); }; f'
cd /path/to/something
git init
git remote add origin [email protected]:username/something.git
git backup something
git remote -v
# origin	[email protected]:username/something.git (fetch)
# origin	[email protected]:username/something.git (push)
# origin	/path/to/git-backup/something (push)
如此在每次 push 到 github/gitlab 的同时,还会 push 到 /path/to/git-backup 下,然后再用备份工具对 /path/to/git-backup 进行备份,这样:
未解决:
.gitignore 排除掉的秘密、配置文件,虽然以前提问过,站内有人推荐 git-crypt ,但我觉得我还需要一个别的方案各位对此思路有什么想法和建议吗?
以及实际在用的 git alias
!f() {
  set -e
  local git_backup_name="$1"
  local git_backup_root="/path/to/git-backup"
  local git_backup_branch="git-backup"
  if [ -z "$git_backup_name" ]; then
    echo "usage: git backup <name>"
    exit 1
  fi
  if [ ! -f "$git_backup_root/$git_backup_name/HEAD" ]; then
    git init --bare "$git_backup_root/$git_backup_name"
  fi
  git remote set-url --delete origin "$git_backup_root/$git_backup_name" 2>/dev/null || true
  git remote set-url --add origin "$git_backup_root/$git_backup_name"
  if ! git remote get-url "$git_backup_branch" >/dev/null 2>/dev/null; then
    git remote add "$git_backup_branch" "file:///dev/null"
    git remote set-url --push "$git_backup_branch" "$git_backup_root/$git_backup_name"
  fi
  git remote -v
};
f
|  |      1hellodigua      2024-06-17 12:58:04 +08:00 怎么感觉多此一举,github 本身就算备份了吧 如果你担心 github 仓库出现问题的话,写一个 github action ,每天定时打包一个 zip 发送到 OSS 里面 | 
|      20o0O0o0O0o OP @hellodigua  > github 本身就算备份了 我觉得不算,例如存在封号 /t/924024 ,我觉得没有用户尤其是大陆用户可以保证自己理解并永远遵守了所有 ToS ,因为有些事情不受你控制 (如 https://docs.github.com/en/site-policy/other-site-policies/github-and-trade-controls ),也没有人可以保证风控不会出 BUG > 写一个 github action ,每天定时打包一个 zip 发送到 OSS 里面 理解,优点是可以备份不是自己在本地发起的提交,但个人觉得没这个思路优雅和安全: 1. github repo 有 public 也有 private ,还可能是某个 organization 的 member ,每个仓库一个 github actions 有维护负担,只用一个 actions 则面临权限问题,尝试突破就无法遵循安全实践 2. 用到的 git hosting service 可能不止 github ,还有 gitlab 或者一些自建的服务 | 
|  |      3hellodigua      2024-06-17 13:31:21 +08:00 你要是担心公有 git 的安全性问题,那不如自建一个私有 gitlab ,每个仓库同时上传到 github 和私有 gitlab ,定期对 gitlab 整体备份就行了 | 
|      40o0O0o0O0o OP | 
|  |      5awesomes      2024-06-17 13:40:15 +08:00  1 工作不饱和嘛 | 
|  |      6maymay5      2024-06-17 15:43:47 +08:00 这是我现在用的方案: * 一台支持文件同步的 NAS * GitHub 照常 push ,NAS 自动同步我最新的代码文件至本地 * 同样的这个方案我也放在我的 Windows Service 上,但是为了防止覆盖,我 Server 上专门做了个 Windows 服务,用日期文件夹方式进行版本管理,缺点就是烧硬盘,而且做了自动备份,没做自动删除,每隔个十天半个月我就要去手动删垃圾 缺点: * NAS 不能版本管理,纯覆盖,只能说聊胜于无 | 
|  |      7maymay5      2024-06-17 15:46:32 +08:00 忘记说优点了哈哈:硬盘不坏的前提下,天王老子来了我代码或者程序也不会丢,一定可以还原 | 
|      8pigf      2024-06-17 17:10:45 +08:00 我就没有这些顾虑,我写的代码没什么价值 | 
|      90o0O0o0O0o OP @maymay5 #6  - 我不想让私钥或者可以读私有仓库的 PAT 离开我的笔记本电脑,所以没办法在别的设备上去主动同步仓库; - 如果是利用同步备份的工具来做,可以看我列出的优点中的第一条:需要维护麻烦的排除规则,因为本地仓库文件夹里有各种 .*ignore ,有时甚至还会有不在 ignore 文件中但也不打算提交的文件,又或者是 submodule 等等; - 工具你可以试试 restic ,压缩、加密、增量,有快照有策略 | 
|  |      10BeijingBaby      2024-06-17 17:19:14 +08:00 想的太复杂了,直接无脑同步推送到另一个自建 git 就行了。 | 
|      110o0O0o0O0o OP 改了改配置文件,已经用上了,一段时间后再来总结一下实际体验中的优缺点 | 
|      12dreammis      2024-06-17 21:55:58 +08:00 via iPhone 自己搭建 gitea ,直接从外部 clone ,自动会同步 |