WEB+DB Press Vol.81の特集はBitbucketでプライベート・リポジトリを使って書いた。最初はメールで詰めて、書く段階になってBitbucketへ作業場を移すという形だった。Gitを使った執筆のメリットはそこかしこで色々と触れられているので、実際に体験してのネガティブな感想を少しだけ書く。
最初からBitbucketが良かった
メールだと後で読み返すのが非常に面倒くさいので、トピックごとに整理しながら最初からプライベート・リポジトリでやれれば良かった。特に書き始めから最初のレビューまでちょっと間が開いたので、記事がメールでのやりとりと矛盾しているかどうかを確認するのが大変だったため、参照しやすい形で残っていれば……と強く感じた。
また、トピック・ベースでの作業なら粒度も下げやすかったと思うので、コミットを追うのも楽だったはずだ。
レビュー
BitbucketのDIFFビューは改行のない段落をレビューしづらいので、長文のレビューをコミット単位で行うのが難しい。特に細かい修正は埋もれるのでどんどん辛くなった。行内での変更の差分表示は一応あったけれども、水平スクロールしながら目視で探して変更を確認という作業はかなり無理があった。
結局、手元に持ってきてエディタのDIFFビューを使わざるを得ず、Bitbucket上で完結できないことが面倒という以上に、コミットの特定行へのコメントで質問したりしづらくなるのが痛かった。GitHubにあるようなHTMLとしてレンダリングした状態での差分表示があったらかなり楽だっただろう。
Markdownのプラスアルファ
明確なルールが整理されている文書が欲しかった。md2inaoのガイドは多分書いたことのある人にしか理解できない。僕ももう今(だけ)は何となく分かるけれど、最初読んだ時はわけがわからなかった。章単位で書く場合はどのように書けばいいのかとか、メタデータはどれくらい書けばいいのかとか、執筆するものに応じたサンプル・ファイルが用意されていればわかりやすくなるはずだ。
また、記法と出力のスクリーンショットの対応も必要だ。Googleドライブにある出力見本は参考になったけど、元になったMarkdownファイルがold_files以下にあることになかなか気づけなかった。
結局、普通にMarkdownで書いたものを仕様に沿うように直してもらうみたいなやりとりになって、申し訳ない感じになった。この辺りはもっとルールが明文化されていれば互いに歩み寄れる部分のはずだ。
BitbucketのGitHubとの違い
ほぼGitHubしか使っていないので、Bitbucketの細かい挙動の違いが気になってしょうがなくなる。例えば、fixes #2というメッセージ付きのコミットを含んだ作業ブランチをpushするとイシューが閉じられてしまう(GitHubではメインブランチに取り込まれるまでは閉じられない)。フォームでのIMEなどといったフロントエンドでの細かい問題を除けば、Bitbucketが劣るとかおかしいというわけではないが、挙動の違いが招く作業の中断はストレスになる。
最初からBitbucketで……という感想も踏まえると、最初にGitHubにプライベート・リポジトリを作っておいてくれれば、僕は修正作業などもスムーズに行えただろう。もちろんBitbucketをメインに使っている人はそれで良いとは思うので、選択肢があると良かったということだ。
あとは担当の方と1対1でずっとやっていたので、ここにレビュワーを入れる必要があったと思う。他の特集や連載記事を書いている人と互いにレビューしあうとかでも良さそうなので、先入観のない読み手に近い立場の人がいると書き上がりが変わった可能性はある。
雑誌記事の執筆環境としてGitとリモート・リポジトリの組み合わせは可能性を感じるが、作業と作業フローが明確に提示されていないとその真の威力は発揮できないと感じた。