Git-SSH 複数計算機同期・運用マニュアル

なぜベアリポジトリを使わないのか？

• 直結の利便性： ベアリポジトリだと「共有用」と「作業用」の2つが必要になり二度手間。
• 即時実行： updateInstead 設定により、Pushした瞬間に作業ディレクトリのファイルが最新に書き換わり、そのまま計算実行が可能。
• 一人運用に最適： 複数人での競合が起きないため、作業場へ直接Pushする方が圧倒的に効率的。

全てのマシンで、作業用ディレクトリを作成し、外部からのPushを許可します。

# 計算機 B, C, D, E のそれぞれで実行
mkdir -p ~/project_dir && cd ~/project_dir
git init
git config receive.denyCurrentBranch updateInstead

① 古い設定の削除（掃除）

混乱を避けるため、既存のローカルベア設定などを一度削除します。

git remote remove origin
git remote remove all # 存在する場合のみ

② 新しいリモートの登録

Bを「正本（origin）」とし、各マシン（b, c, d, e）を個別に登録。さらに一括送信用の「all」も作成します。

# Bをメイン同期先として登録
git remote add origin univ-b:~/project_dir

# 個別送信用リモート
git remote add b univ-b:~/project_dir
git remote add c univ-c:~/project_dir
git remote add d inst-d:~/project_dir
git remote add e inst-e:~/project_dir

# 一括送信用リモート (git push all 一発で全員へ)
git remote add all univ-b:~/project_dir
git remote set-url --add --push all univ-b:~/project_dir
git remote set-url --add --push all univ-c:~/project_dir
git remote set-url --add --push all inst-d:~/project_dir
git remote set-url --add --push all inst-e:~/project_dir

大学にいる時は、Bからも直接他の計算機を制御できるようにします。

# Desktop B のリポジトリにて実行
git remote add c univ-c:~/project_dir
git remote add d inst-d:~/project_dir
git remote add e inst-e:~/project_dir

※ Laptop Aへの逆方向SSHは不要なため、登録しません。

特定の宛先オプションをつけてPushするためのスクリプトです。A, B 両方に配置推奨。

#!/bin/bash
# Usage: gpush [-b] [-c] [-d] [-e] [-a] [-m message]

usage() { echo "Usage: gpush [-b] [-c] [-d] [-e] [-a (all)] [-m message]"; exit 1; }
if [ $# -eq 0 ]; then usage; fi

targets=()
commit_message=""

# getoptsに "m:" (引数ありのm) を追加
while getopts "bcdeam:" opt; do
    case "$opt" in
        b) targets+=("b") ;;
        c) targets+=("c") ;;
        d) targets+=("d") ;;
        e) targets+=("e") ;;
        a) targets=("b" "c" "d" "e") ;;
        m) commit_message="$OPTARG" ;;
        *) usage ;;
    esac
done

# メッセージが指定されていない場合はタイムスタンプをセット
if [ -z "$commit_message" ]; then
    commit_message=$(date "+%Y-%m-%d %H:%M:%S")
fi

# 1. git add
echo ">> git add ."
git add .

# 2. git commit
# 変更がある場合のみコミットを実行（エラー回避のため）
if ! git diff-index --quiet HEAD --; then
    echo ">> git commit -m \"$commit_message\""
    git commit -m "$commit_message"
else
    echo ">> Nothing to commit, working tree clean."
fi

# 3. git push
current_branch=$(git symbolic-ref --short HEAD)

for target in "${targets[@]}"; do
    # 自身がDesktop Bの場合、bへのpushはスキップ
    if [[ "$target" == "b" && "$HOSTNAME" == "DesktopB_Host" ]]; then continue; fi
    echo ">> Pushing to: $target ($current_branch)"
    git push "$target" "$current_branch"
done
	

研究者がブランチを使う3つのメリット

• 計算を止めない： スパコンDで重い計算を回したまま、手元のAで「コードを壊す恐れのある大胆な改造」を並行して行えます。
• 再現性の担保： 論文投稿時の状態を paper-v1 ブランチとして残せば、1年後の査読対応時でも「図表を作成した当時のコード」を1秒で復元できます。
• 心理的安全性： どんなにコードがグチャグチャになっても、git checkout main でいつでも「動く状態」に戻れる安心感が手に入ります。

作成した gpush スクリプトは、現在チェックアウトしているブランチを自動認識して送信します。

# 1. 新しいアイデアを試すブランチを作成
git checkout -b feat-new-algo

# 2. 手元でコードを書き換える
vim main.py

# 3. テスト機（C）にだけ実験版をデプロイして試す
gpush -c

# 4. うまくいったら main に戻して合流
git checkout main
git merge feat-new-algo
gpush -a  # 全環境の main を最新版に更新

ブランチ作成の判断フロー