【Tech Women Advent Calendar 2014】この夏わたしはGitに出会い、恋をした
【移転してます】
こんにちは、そしてはじめまして
@kanufyです。かぬーと呼ばれてます、カヌーはやったことないです。
情報系女子大学院生M1です。画処理とかとか。
Tech Women Advent Calendar 2014の7日目として
インターン先の会社で出会った女子エンジニアの先輩
@sinamon129さんに誘われ、わたしなんかでいいのかと思いつつ、
恐れながら参加させていただくことになりました!
最初は研究のこととかも考えたのですが、なんもいい案浮かばなかったのと、 インターンで学んだまとめみたいなのも違う気がして、 今日はこの夏のインターンを通して出会ったGitという素晴らしい何か(笑) との壮大なラブストーリー(思い込み) 的なものをだらだら綴ってGitの素晴らしさを伝えられればと思います。 Gitに初めて触れたときのことを思い返してくだされば幸いです。
この夏わたしはGitに出会い、恋をした
1. 出会い
出会いは某IT会社のインターンでした。5日間でiOSアプリ作るでー! アイデアソンは事前にチームでやってきてねー!って感じのものでした。 開発は主にGitHubを使って、プライベートリポジトリにあげてうんぬんかんぬん。 (我がチームメンバーは全員Git初心者だった)
え、なんなんそもそもGitってなんなんバージョン管理?なにそれ←
的な状態でした。 わたしの研究室ではWebやネイティブ系のものに全く触れない環境で、
大規模開発とかもないので、個人主体で、ソースコード管理とか別にみたいな(笑)
そもそもそういうハイカラな言語にちゃんと触れたのが今年からだったw(いつもC/C++とか)
1日目は各自とりあえずローカルブランチ切って作業(pushとかとりあえずしない←)
その夜、一回統合したほうがいいと教えられる ↓ よくわからんけどリモートのマスターとってきてローカルのマスター新しくする ↓ ローカルでマージ!えいっ ↓ 2人目以降ぎゃああああああ (コンフリクトの嵐)
まあそりゃそうですよね。まず初心者すぎるわたしたちは.gitignoreを無視していた(というより知らんかった)
とりあえず色々無駄な労力なので新しくリポジトリ作りなおしてignoreファイル作ってあれやこれやして(メンターさんほんとにありがとう)
その夜はまあなんとかなりました。第一印象は本当に最悪で、なんでこんなややこしいの使うのかさっぱりわからなかったです。
2. いがみ合う日々
2日目から順調に開発。ブランチも切る(たまにマスターで作業しててぎゃーってなることもしばしば)
でもGitHubのissueとか知らない。ブランチ名と全く違うことしてたりする。細かくブランチ切れてない。コミットも適当(笑)
でも定期的に統合!よっしゃ!うわ、コンフリクトや...。
いろいろ他にもあったんですが、メインはこいつ。
xcodeの.pbxprojがそりゃあもうコンフリクトしまくる。
Xcodeのプロジェクトファイル(pbxproj)がコンフリクトしまくるのをなんとかしたい! - TOKOROM BLOG
ignore書いててもコンフリクトしまくる。ヤダもうなんで!
(ストーリーボードちょっとでもいじりあうとダメみたい)
3. 好きになりかける
あんまりにもコンフリクトしまくるので、vimでコンフリクト直すのに慣れてしまった。
はいはいとりあえず/HEAD
で検索検索ぅ。
なんかわたしの時だけどんどん素直になっていくGit(勘違い)
相変わらずコンフリクトを起こすメンバーのコンフリクトも直しつつ、
あれ、わたしもしかしてコイツ好きかも?
4. 喧嘩する
二人の距離がだいぶ近づいた気がする中、次のインターン先へ。
今回は3週間でWebサービスを作るぞ!フロントからサーバ、DBまでがんばるぞ的なものでした。
ここでもWebサービス作ったことない初心者だったので、講義で学びが多い多い。
そしてここでも登場するGit。
ふふーん、わたしだいぶ仲良くなったもんね!とか思ってたけど、
事前課題でGit学ぼうのコーナーがあり、やってみるものの何cherry-pickって何。
reset?なんか怖い。
Gitってとっても奥が深いんだなあ、
わたしが見てたのはアイツのほんの一面だったのね、と。
でもまあなんだかんだここでも、 コンフリクトは起こるので、唸ったりしながら直しつつ、 チームメンバーのコンフリクト直したり Git手順表書いたりして円滑にチーム開発できました。 wikiやissueを効率よく使うことも覚えたり。
でもなんていうかまあ、この時のわたしはGitの素晴らしさをまだ分かってなかった。
5. 離れて気づいた愛しい存在
無事インターンも終わり、台風がやってきたころ、 初心者向け女の子Webサービスハッカソン的なものに参加することになりました。 サーバの勉強したいなと思ってたのでサーバ側をやることになり、 チーム開発が始まった。
あれ、アイツがいない。
初心者向けということで、Gitを使わない開発スタイル。 たしかに初心者にGit導入させたら、なれるのに1日じゃ厳しい感じがぷんぷんする。 (自分もまだまだ全然初心者)
とりあえず担当わけて開発。
ただし時間がぜんぜんなく、最終日朝にやっと統合!!
(いまになって思えば恐怖でしかない)
統合手段は、完全手作業マージです☆
ローカル環境下での開発なのでDBがわたしのローカルにしかない。
(仮想環境ってなんて便利なのかしら)(遠い目)
すなわちわたしのローカル下で統合する他ない。
みんなAirDropで送ってー!
うおおこのページとこのページつながってない!
リンクさせとかなきゃ!あーそっかjsの方でサーバに渡す部分ないわ!(気づくの遅い)
そもそも統一したはずのファイル構造がちょっと違ったりしてパスがおかしい。
直したらなんかおかしい、あれ、前の状態からどこ変えたんだっけ??
ってなりながら必死で作業。そしてページのCSSが、個人のPCの解像度に最適化されすぎて
崩れまくる事態でぎゃー(間に合わないのでここは諦めた。解決できなくてごめんね;_;)
今思えば自分のローカルだけGit管理させときゃよかった。
こんなに、こんなにもGitが恋しくなったのは初めてでした。 初めて愛しいと思えた瞬間でした。 同時にGitの凄さを身にしみて感じました。アイツいつも小洒落た作業をサクっと短時間でやってるんだなーと。 こまめにコミットしてこまめにプッシュして不足部分確認して直してマージ...とかやってたら 最終日の朝にここまで大変な思いすることなかったんだろうなあ(遠い目)
手作業マージ、ダメ、絶対。 (もう絶対イヤだと心に刻んだ)
そして最初の設定大事(ignoreとか)
そーいうの勝手に作ってくれる便利なサービスもありますし。
初心者の私が主に使用したGitコマンド
実際にメインで使ってたコマンドです。これ以外も使うと思うんですが、変なことしない限りわりとこれでなんとかなる気がします。変なことしちゃった場合はcherry-pickなりrevertなりでよしなに頑張る(笑)
git init
使うディレクトリをgitに管理させリポジトリをつくるgit add (ファイル名) / git add .
作業の変更をステージングエリアに追加するgit commit -m "(コミットメッセージ)"
ステージされたスナップショットをコミットメッセージ付きで1行でコミットする
いちいちエディタ開かなくていいので便利git status
ファイルの現在の状態を一覧表示するgit log
コミット履歴を確認するgit diff
ステージングエリアとワーキングツリーの差分を表示
オプションつけるとファイル間の差分なども見れるgit clone git@(アドレス)
レポジトリgit@(アドレス)を複製するgit branch
現在あるブランチをの一覧を表示する
(*がついてるブランチがチェックアウト中のブランチ)git branch -d (ブランチ名)
ブランチを削除する
要らなくなったブランチは削除したほうがスッキリしますgit checkout -b (ブランチ名)
ブランチをつくってチェックアウトする
(git branch (ブランチ名)+ git checkout (ブランチ名))git checkout -b (ブランチ名) (既存ブランチ名)
既存のブランチから引き継いで新しいブランチをつくってチェックアウトするgit pull origin master
ローカルとリモートのマスターを同期する
(git fetch + git merge)git rebase / git rebase -i master
ブランチをマージする / マスターと現在のブランチをマージする
pushする前にrebase使うとコミット履歴が綺麗になります -i(interactiveの略)つけることで、各コミットについて処理(歴史の改ざん)ができる
※リモートのコミットはrebaseしないことgit rebase --continue
修正したあとに再びrebaseし直すgit push origin (ブランチ名)
リモートにローカルブランチをプッシュする
まとめ
思ってた以上にだらだらと長くなりましたが、
何が言いたいかというと出会って半年も経ってないけど、
- Git(GitHub)っていいよね!
- バージョン管理大切
- 基本コマンドは頭に叩き込む
(GitのAdvent Calendarとかも参考に)
Git Advent Calendar 2014 - Qiita - masterで作業しない
- 初心者だからこそissueやwikiを使った方がいい
(チームで決めたことはちゃんとwikiに書いて確認しあう) - issue以外のことをするならまたissueきる
(誰が何やってるのか言葉にしなくてもわかる) - プルリク貰ったらちゃんと確認する
- 手作業の統合は愚か
- 設定ファイル系は一番最初にちゃんとしよう
複数人で開発するならGitHubなりSubversionなりなんらかのツール使ったほうがいいですいやほんとに←
関西的にいうと551の豚まんがあるとき\(^o^)/とないとき/(^o^)\くらい差があります。
明日は@aa7thさんです!おたのしみに!