Git

SWC @ 千葉大学

https://swcarpentry-ja.github.io/2024-05-30-chiba-slides/git

Git

ファイルを無視する

ファイルを無視する

  • Gitに追跡して欲しくないファイルもあります（データ、解析結果）

  • .gitignore で無視するファイルを指定できます

詳細はこちら：https://swcarpentry-ja.github.io/git-novice/06-ignore.html

チャレンジ：埋もれたファイルを無視する

以下のようなディレクトリ構造があるとします：

results/data
results/plots

results/data ではなく、results/plots のみを無視するにはどうすればいいのでしょう？

チャレンジ：ログファイル

仮に log_01、log_02、log_03、というように、中間的にログファイルを作成するスクリプトを書いたとします。 これらのログファイルは取っておきたいのですが、git で追跡したくありません。

  1. log_01、log_02、などのファイルを無視するためのルールを一つだけ .gitignoreに入力してください。
  2. 入力したパターン正常に動作しているか確認するために log_01 などのファイルを作成してください。
  3. 最終的に log_01 ファイルがものすごく重要であることが分かりました。.gitignoreを編集せずに、このファイルを追跡しているファイルに加えてください。
  4. 隣の人と、追跡したくないファイルは他にどのようなものがあるのか、そして.gitignoreに何を入力すればこれらのファイルを無視できるのかを話し合ってください。

GitHub における
リモート

認証の設定

  • リモートリポジトリに接続する前に、自分のコンピュータが GitHub に認証される方法を設定する必要があります。

  • これにより、GitHub はあなたのコンピュータからのアクセスを信頼できるようになります。

SSH プロトコルとは？

  • コマンドラインでのアクセスを認証するために一般的に使用される方法を設定します。

  • この方法は「Secure Shell Protocol（SSH）」と呼ばれます。

  • SSH は、暗号化されたネットワークプロトコルで、通常は安全でないネットワークを使用してコンピュータ間の安全な通信を可能にします。

SSH 鍵ペアの仕組み

  • SSH は「鍵ペア」を使用します。
  • 鍵ペアはアクセスを検証するために連携して動作する2つの鍵です。
  • 一つは公開鍵（public key）、もう一つは秘密鍵（private key）と呼ばれます。

公開鍵と秘密鍵の例え

  • 公開鍵を南京錠と考えてください。
  • 秘密鍵はその南京錠を開ける鍵です。
  • 公開鍵を GitHub アカウントに設定し、「この南京錠で通信をロックしてください」とします。
  • これにより、秘密鍵を持つコンピュータだけが通信を解読し、Git コマンドを GitHub アカウントとして送信できます。

SSH 鍵の存在を確認する

ls -al ~/.ssh

SSH 鍵の作成

ssh-keygen -t ed25519 -C "vlad@tran.sylvan.ia"

vlad@tran.sylvan.iaには、自分のメールアドレスを入力してください（公開されているGitHubリポジトリを使用する場合、このメールアドレスも公開されることになります）

SSH 鍵の作成

Generating public/private ed25519 key pair.
Enter file in which to save the key (/c/Users/Vlad Dracula/.ssh/id_ed25519):

デフォルト設定で良いので、リターンキーを押します。

SSH 鍵の作成

Created directory '/c/Users/Vlad Dracula/.ssh'.
Enter passphrase (empty for no passphrase):

パスワードを設定します（空欄にすると、パスワードなしになります）。パスワードを設定すると、GitHubを使用するたびに入力が必要になります。

公開鍵をGitHubに置く

cat ~/.ssh/id_ed25519.pub

  • 右上隅にあるプロファイルの画像をクリックし、次に[設定]をクリックします。

  • サイドバーの [アクセス] セクションで、 [ SSH キーと GPG キー] をクリックします

  • New SSH key または Add SSH key をクリックします

  • 公開鍵をペストし、覚えやすい名前を設定します

SSHでログイン

ssh -T git@github.com

リモートリポジトリを作成する

リモートリポジトリを追加する

git remote add originでリポジトリを追加する

git remote add origin git@github.com:vlad/planets.git

git remote -vで確認する

git remote -v

リモートリポジトリに変更をプッシュする

git push origin main

チャレンジ：GitHub の GUI

GitHubのあなたのplanetsリポジトリに移動して下さい。

「Code」ボタンの下にある「XX commits」というテキストを見つけてクリックします（「XX」は数字です）。各コミットの右側にある3つのボタンにカーソルを合わせてクリックします。

  • これらのボタンからどのような情報を収集/探索できますか？

  • シェルで同じ情報を得るにはどうしますか？

共同作業

GitHubを介して共同作業してみよう

  • 今回の課題は、ペアを組んでやります

  • 一人は「オーナー」、もう一人は「コラボレーター」

  • コラボレーターの目標は、オーナーのリポジトリに変更を加えることです。

  • 最後に役割を交代するので、両方の人がオーナーとコラボレーターの役割を果たします。

コラボレーターにアクセス権限を与える

  • GitHubのリポジトリページで「Settings」ボタンをクリックします。
  • 「Collaborators」を選択します。
  • 「Add people」をクリックし、パートナーのユーザー名を入力します。

コラボレーターがオーナーのリポジトリへのアクセスを受け入れる

  • https://github.com/notifications にアクセスするか、メール通知を確認します。
  • オーナーのリポジトリへのアクセスを受け入れます。

オーナーのリポジトリをクローンする

  • コラボレーターはオーナーのリポジトリのコピーを自分のマシンにダウンロードします。（クローンする）

  • 自分の planets.git バージョンを上書きしないように、オーナーのリポジトリを別の場所にクローンします。

オーナーのリポジトリをクローンする

デスクトップフォルダにクローンする場合:

$ git clone git@github.com:vlad/planets.git ~/Desktop/vlad-planets

vlad をオーナーのユーザー名に置き換えます。

クローンパス（~/Desktop/vlad-planets）を指定しない場合は、自分の planets フォルダ内にクローンされるので、最初にデスクトップフォルダに移動してください。

クローンしたリポジトリーに変更を加える

  • コラボレーターは、オーナーのリポジトリのクローンで変更を加えることができます。例えば:
cd ~/Desktop/vlad-planets
nano pluto.txt
git add pluto.txt
git commit -m "Add notes about Pluto"

変更を加えたファイルをリモートに送る（プッシュ）

git push origin main

オーナーのリポジトリを確認

  • オーナーのリポジトリを再確認し、コラボレーターが行った新しいコミットを確認します。

  • ブラウザをリフレッシュする必要があるかもしれません

オーナーのローカルなリポジトリの更新

  • オーナーが行います：
git pull origin main
  • これで、三つのリポジトリ（オーナー、オーナーのリモート、コラボレーター）が同期されました

もう一回しましょう

  • 今度は役割を交代して、もう一度やってみましょう

チャレンジ：変更のレビュー

オーナーはコラボレーターに情報を提供せずにリポジトリにコミットをプッシュしました。

コマンドラインでは、コラボレーターは何が変更されたかをどのように確認できますか？

また、GitHubではどうやって確認できますか？

１日目のおさらい

JSBiについて

集合写真

  • 「公開しても大丈夫」という方は、是非ご協力をお願いします。

  • 後ろから撮った写真を公開することがありますが、もし公開を希望されない場合は、お知らせください。

https://swcarpentry-ja.github.io/2024-05-30-chiba/

１日目のおさらい

  • シェルは研究に必須なスキル
    • オープンソースソフトウエア
    • サーバー
    • git, Docker
  • git は細かいレベルでコードの変更を追跡して、共有を可能にする

よくできたこと

  • 「スタッフの方々の手いフォローでなんとかついていけた」

  • 「コードの意味や一連の流れが分かりやすく説明されていた」

改善できること

  • 最後に何が出来るのか、目的設定があると分かりやすくなる

  • チャレンジをやる時、隣の方と相談できたらいい

  • 図があるのに、あまり活用できていない

  • 声が小さい

今日の目的

  • gitでコードの衝突が起きた時の解決策を身につける

  • dockerの基本的な操作が出来るようになる

  • dockerをどのように自分の研究に使えるのか、具体的にイメージができるようになる

共同作業（続き）

共同作業（続き）

衝突の管理

衝突とは

  • 共同作業をしていると、いつか、それぞれで同じ箇所に異なった変更を加えることがあるでしょう。これは git でいう「衝突」（conflict）

  • git にはどちらが正しいのか、分からないので、手で直さないといけない