6
2

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 3 years have passed since last update.

CODEBASE okinawaAdvent Calendar 2019

Day 14

はじめての共同開発でGitHubがめっちゃ便利だったって話

Posted at

はじめに

先月、自分が通っていたCodeBaseというプログラミングスクールの卒業生が参加できる、β版ハッカソンに参加してきました。(β版ハッカソンとはビジネスアイデアはあるけれど技術がない人と技術を学び始めたけれど、まだ実践経験がない人をマッチングしてアプリケーションを開発する場所みたいなものです。)そこで、今まで個人開発でしか使用していなかったGitHubが共同開発で利用するとめちゃくちゃ便利だなと思ったのでここに記しておきます。

GitHubとは

GitHubとはソフトウェア開発においてソースコードをオンライン上で管理できるプラットフォームです。ソースコードをオンラインで管理することにより、エンジニアが協同で開発作業を行なったり、レビューをしてソースコードのブラッシュアップしたりできます。

GitHubが便利だなと思ったポイント

①ブランチを変更することで、アプリを動かせる状態にしつつ開発を行える  アプリケーション開発時には、アプリケーションが常に正常に動いているマスターブランチの他にも、複数のブランチに分岐させることで複数の開発や変更を同時に進めることができます。分岐させたブランチは後でマージすることでそれぞれで開発した機能を1つのブランチに統合することができるので、共同での開発がすごく楽になります。

②管理する場所を一元化することで、ファイルの重複を防ぐことができる
 自分的にはこれが1番便利だと思ったポイント。パワポとかで例えるとわかりやすいんですけど、パワポの共同作成っていちいちラインにあげたものをダウンロードして、自分の担当のところを編集して、またラインにあげてってしているうちに、同じような名前のパワポが5とか10とか増えていくんです。そうなってしまったらどれが最新かわからないし、どのファイルでどんな変更したかも分からないからいちいちファイルを開くか、変更した人に詳しく聞くかをしないといけなくなります。GitHubではそんなことなくて、プロジェクトが一元管理されているから、変更した部分だけが更新されて、どこを編集したかもわかりやすいのでそういった問題が起こりにくいんです。

今回の開発で使いまくったGitコマンド

 git branch -a
 git fetch
 git checkout branch名 origin branch名
 got pull

共同開発でメンバーが作ったリモートのリポジトリにアクセスするコマンド群です。これらだけで他人の作ったブランチを簡単に自分のローカルブランチに持ってくることができます。

 git add .
 git commit -m ‘コメント’
 git push origin branch名

これらは、自分が開発した部分をオンラインに上げることができるコマンドです。変更した部分をすぐにオンラインに共有できたらとても楽ですよね。ちなみに、コメントの部分には自分が開発・変更したことを書くとメンバーにも分かりやすい、効率性のある開発になると思います。

 git stash
 git stash apply stash@{番号}

これらは、自分が変更を加えている時に、メンバーの変更部分を統合しないといけなくなった時に一度自分の変更した部分を横に置いておくっていうコマンドです。2行目のapplyコマンドを使用することによりこの横に置いていた部分をまた戻して作業を再開することができます。

共同開発でGitHubを使うときに気をつけるべきポイント

GitHubを使って共同開発をする上で(ていうか共同開発する上で)気をつけようって思ったポイントもありました。

①インデントを揃える
②無駄な改行やスペースを入れない
③いらないコードやコメントアウトは消す
④自分が書いたコードがなぜこのようになったのかというプロセスをissueに書き残す

上の3つは個人開発の時によくやってしまっていました。特に③が1番多かった。binding pry や binding irb でシステムの挙動を確認して、また後でやるかもしれないからコメントアウトして置いておくつもりがそのまま忘れてしまうことが多いんですよね。

でも、やっぱり仕事でのシステムやアプリケーション開発って基本的にみんなで一緒に開発していくものだから、誰が見ても見やすい&意味が分かるようなコードの書き方を心がける必要があるなって今回のβ版ハッカソンで強く思いました。

④は何で気をつけるべきかっていうと、自分がなんでこのコードの書き方をしたのかっていうとプロセスを開発メンバーに知っててもらうことで、一緒に開発していくときに生じるズレを少なくしていけるっていうメリットがあります。エンジニアってコミュニケーションのいらない職業って思われがちだけど、システムが動かなくなったり、開発スケジュールの遅延に関わってくることもあるからメンバー同士のコミュニケーションは必須だと思います。

あと、開発の時に詰まったところとその解決策を残しておくことで、後で見返したり、他のメンバーが開発するときの参考になったりするから再現性が高くなるんですよね。

まとめ

というわけで色々書き連ねたんですが、「共同開発でGitHub使おうぜ」って感じでまとめとさてください。ちなみに、自分のつくりたいアプリケーションとかシステムがあったらGitHubで探してみてください。結構いろんな書き方があって参考になると思います。(自分は個人開発の時に色々漁ってました。)

あと、β版ハッカソンめっちゃ楽しかった。まだプログラミングを始めて半年も経たないペーペーの意見にも耳を傾けてくれたし、先輩方の考え方や開発の技術も、参考になってとても刺激になりました。是非ともまた参加したい。

沖縄でエンジニアの勉強始めてみたい方、CodeBaseおすすめなので是非チェックしてみてください。(急な宣伝)

6
2
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
6
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?