73
80

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

発表用のスライドをGitで学会(報告会)ごとにブランチで管理(Power Point)

Last updated at Posted at 2017-09-08

アップデート

  • 2022/05/11
    • メッセージの追加
    • 構成の変更(マージの説明をメインの最後に)

メッセージ

Gitによるバージョン管理はテキストファイルを扱うプログラマ用のツールとは言われてますが、バイナリしか扱わないような形でも十分便利です。

  • コミットによるバージョン管理
  • ブランチを切って適切にマージさせることで変更内容の見通しが良くなる
  • ダウンロードや更新がしやすい(圧縮・解凍をしなくて良い)

この記事では、学会(報告会)のスライド作成するというような完全バイナリのシナリオを例に、バイナリファイルをGitでバージョン管理する流れを説明したいと思います。
ゴールとして、非プログラマの方が以下が出来るようになることを目標としています。

  • Gitをテキスト形式のファイルでなくてもナイーブに使えることを理解
  • PowerPointの校閲機能と関連させたGitの使い方の例を知る
  • ブランチ機能の利用方法(ずっとmaster(main)ブランチで管理するのはもったいない)
  • マージをgit merge --no-ffやプルリクエストで行い、見通しの良いバージョン管理を行う

対象

  • Gitの基本的な使い方については理解している(git add, git commit)
  • ユーザー名、メールアドレス設定などは終わっている
  • 非情報・プログラミング系の人が対象

シナリオ目的

  • 共同研究者とのスライドのやり取りなどをバージョン管理して、常に最新の状態を保ちたい
  • 学会(聴衆)ごとにスライドの内容やノートを変更したい
  • 特定の学会(報告会)で変更したスライドの修正を別の学会(報告会)用のスライドに反映させたい

Gitを使わないバージョン管理法(問題点)

名前で管理

発表A_20220522.ptxなど

  • pros
    • アーカイブとして別のフォルダに保存しておくときは便利
    • メールで送信するときはこのように書いておいた方が良い
    • onedriveなどに置いておくと検索した際にどのタイミングのスライドか分かりやすい
  • cons
    • どれが最終編集しているファイルか分かりにくい
    • レビュー待ちの時に編集してしまうと管理が煩雑になる
    • 直前の変更などが学会が終わった後で行方不明になりやすい

ひとつのファイルに全学会のスライドを保持

非表示スライド機能などを使って、全発表のスライドを一つのファイルに入れておく方法

  • pros
    • 発表しないスライドや推敲段階のスライドを保持しておける
    • どれが編集中のファイルか迷わない
    • onedriveなどでの検索性が悪い
  • cons
    • 別テーマでの研究内容も保存している場合、人に渡すときは毎回取り除く必要
    • ファイルの容量が重くなる

解決策

無題.png

  • バージョンをGitで管理
  • 編集スライドは単一ファイル
    • 5MB以下を目安に(多くて20MB)
      • 超える場合は、別ファイルに分けて保存しておく(前半後半などがある場合)
    • 動画などは適切にサイズを減らした方が良い
  • 学会ごとのスライドの管理はブランチを切って行う
  • マージはパワポの差分比較機能による手動マージ
    • バイナリなので自動マージは出来ない

Gitによるバージョン管理法

  • pros
    • ブランチを切ることで変更履歴の見通しが良くなる
    • GitHubなどを利用すれば、複数のデバイスでデータのダウンロード・更新が行える
      • サービスを使えなくても、手元のsshサーバーやローカルディスクに適切にbareレポジトリを作れば、そこからssh://やfile://プロトコルでgit cloneできる
      • 勝手に圧縮して管理してくれる
  • cons
    • Gitが難しい

Gitでのバージョン管理

Gitで最初の学会のスライドのバージョン管理

最初にgit initでフォルダをgit管理できるようにします。

git init

.gitフォルダが出来たのを確認したのち、パワポのスライドを作成します。

今回は
presentation.pptx
というファイルを作ります。
これを以下のようにコミットしてバージョンの管理を行います。

git add presentation.pptx
git commit -m "initial commit"

次にブランチを切ります。これによって、特定の学会専用のブランチを作ることが出来ます。
今回はPhysというブランチを作ります。

git branch Phys

作成したブランチは以下のコマンドで確認することが出来ます。

git branch

*がついているのが現在自分がいるブランチです。
まだmasterブランチにいるはずなので、checkoutして先ほど作成したPhysブランチに移動します。

git checkout Phys

これで、Phys学会用のブランチに移動することが出来ました。

git branch

すると*がPhysについていることが分かります。

この上でスライドを編集することでPhys学会のスライドとしてバージョン管理することが可能になります。
どんどん編集していってコミットしていきましょう。

他の人に渡すときや完成したときにタグ付け

さて、ある程度仕上がると他の人からのレビューを受けることになるかと思います。
その際、tagを付けておけばいつ何を送ったのか分かりやすくなり、レビューを受けた時の管理がしやすくなります。
送る時は一旦コピーして名前を変えてから送ることになるので、タグ名はその名前にするといいでしょう。

git tag -a presentation_170908

校閲後のスライドが返ってきたら

レビューが返ってきたら、元あったファイルは削除して、送られてきたものに差し替えます(名前をpresentation.pptxに変更)
レビューしてくれた人がパワポの校閲機能で編集してくれていた場合は、適宜対応してすべて承認・非承認します。
その上でコミットします。

git add presentation.pptx
git commit -m "レビュー返ってくる"

送ってくれたファイル名(版の管理という概念を理解している人からの返信ならpresentation_170908_revA.pptxなどのファイル名になっているかと思います)でタグをつけておくといいでしょう。

git tag -a presentation_170908_revA

問題なければこのまま編集していってください。

レビュー待ちの状態で編集を進めていた時の対応

さて、面倒見のいいレビュアーだと途中段階でも校閲してくれると思います。
そのような場合、レビューが返って来る間も編集を続けることになります。
そうなると、送信時の版からみて修正のされ方が違うファイル(自分で修正したものとレビュアーが修正したもの)が存在し、いわゆるコンフリクトが起きます。

その場合、返信が来た段階で自分の修正を保存してコミットします。

git add presentation.pptx
git commit -m "レビュー待ちの間に修正"

そのうえで先ほどと同じように、送られてきたファイル(レビュアーが編集したもの)に差し替えてコミットします。

git add presentation.pptx
git commit -m "レビュー返ってくる"
git tag -a presentation_170908_revA

パワポの機能で差分比較

さて、このままだとレビュー待ちの間に自分で修正した場所が反映されません。
そこで修正した場所をレビュー後の修正に反映させるため、パワポの機能を使って校閲します。
そのために、ひとつ前のコミットを別ファイルとして取りだします。

git show HEAD^:presentation.pptx > temp.pptx

これで、一つ前のレビュー待ちの間に修正したファイルがtemp.pptxに保存されます。

これを使ってレビューしてもらったファイルに自分の修正を反映していきます。
presentation.pptxを開いて、校閲>比較を押します。
プロンプトが表示されるのでtemp.pptxを選んでください。
必要な修正を反映したら保存してコミットしてください。

注意点

パワポの比較機能ですが、アニメーションの差分は取れないようです。
そのため、アニメーションを取り込みたい場合は取り込む側の対象のスライドを削除してから比較機能を使うようにしてください。

ブランチを切って別学会(報告会)用のスライドを作ってバージョン管理

さて、無事学会も終わっても、別の学会のスライドを作成する必要が出たとします。
同じ研究なら同じスライドを使いまわすことが多いと思いますが、分野によっては新しいストーリーを組み直すことが多いと思います。
それに伴って、結果やスライドの入れ替えが生じる事もあるかと思います。
ただ、今まで作っておいたスライドのストーリーも残しておきたいので、ここでブランチを切ってBio学会のブランチを作ります。
ただし、ブランチを切り替える前にpresentation.pptxファイルは閉じておいてください。

git branch Bio
git checkout Bio

これで、Bio学会の発表用のストーリーでpresentation.pptxを編集することが出来ます。
どんどん直してコミットしていってください。

前の学会(報告会)のスライドを見たいとき

PhysブランチにチェックアウトすればPhys上の内容に戻すことが出来ます。

git checkout Phys

Phys学会のスライドで追記や修正を行いたい場合は、ここで修正を行ってコミットすればBio学会のスライドに影響を与えることなく、ファイルを変更することが可能です。

Bio学会のスライドの編集をしたい場合はもう一度ブランチを変更すれば続きを編集することが可能です。

git checkout Bio

別の学会(報告会)の発表の変更を前の学会(報告会)のスライドに反映

一方のスライドを編集していると、他の発表でも利用したいスライドや共有しているスライドで微調整を行うことがあります。
これらの変更を別のブランチでも反映する方法について説明します。

Bioブランチで行った変更の一部をPhysブランチに反映させたいと仮定します。
まず、変更を取り込みたい方のスライドがあるブランチにチェックアウトします。

git checkout Phys

次に以下のコマンドでtemp.pptxというファイルにBioブランチ上のスライドのデータを書き出します。

git show Bio:presentation.pptx > temp.pptx

パワポでpresentation.pptxを開いて校閲>比較でtemp.pptxを開きます。
これで変更箇所が出てくるので取り込みたい変更を承認することでBioでの変更点を反映することが出来ます。
変更したら、temp.pptxを削除して変更をコミットしてください。

学会(報告会)が終わったら

学会(報告会)が終わったらアーカイブフォルダを作成して、別名(prestation_phys_20220522.pptx)で保存して
コミットしておくと良いです。

その後、以下のmaster(main)ブランチにマージしておくと良いのですが、直線関係がない場合は適宜git showでファイルを持ってきて、変更を反映するなど対応をする必要があります。

git checkout main
git merge --no-ff {持ってきたいスライドがあるブランチ}

意図せずマージモードになってしまった場合は、git statusをすれば何をすべきかが分かります。

GitHubを利用している場合は、プルリクエストで同様のことができますので、そちらを利用すると良いです。

その他

容量が大きくなった時はgit gc

やはりバイナリで保存しているのでコミットが増えるとどんどん容量が大きくなります。
そのようなときはgitの圧縮機能で容量を減らしましょう。

git gc

git diffでパワポの差分比較

パワポのノートなどは頑張ればgit diffで比較可能になります。
Appach Tikaを使うのですがやり方はgit diff で Office ファイルの差分を見るを参考にしていただければと思います。
注意点としては、1.16や1.15ではなく、1.14版を使わないとワーニングが出ることです。
またそのうちこのやり方についてまとめるかもしれません。
まとめました。git diffでパワポの差分比較を出来るようにする(Windows)

73
80
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
73
80

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?