GitとGithubの管理
はじめに
今まで限定公開にしてましたがなんとなく公開することにしました。ただのメモ書き程度です。
Github
issuesについて
issuesにはアプリに機能追加やバグなどの問題が見つかった時issueを追加します。
↓の写真１~3について説明する
- githubではissuesとPull requestsに追加され際に#OOと数字がカウントされて行くカウントはissuesとPull requestsは同じカウントになるこの数字は後に記述されるGitの説明で必要になってきます。
- Assigneesはこの場合では追加されたissueを誰か担当するのか指しています。この担当者を決めなければ同じ作業を複数人でやってしまう可能性が増え無駄手間。また同じ箇所をへんしゅうすることになるのでコンフリクトの原因になる。のでみんなにわかりやすいようにしましよう。
- Labelはそのissueの状態を示します。機能追加などするときはenhanceラベルを追加するなどです。
Pull requestsについて
Pull requestsでは作業ブランチで変更、追加したものをBaseブランチなどにマージすることを他メンバーに伝えることです。（簡単に説明してるので、ん？とか思わないでほしい）
誰もが勝手に変更、追加したブランチをマージしてしまうと意味のないものや無駄が多いもの、もっといえばコンフリクトが起きてしまうとんでもないものをマージしてしまう可能性があります。それらを防ぐためにレビュワーはレビューをし問題があればレビュワーは問題を提示し、なければマージを許可します。
- pull requestsを新しく作成するとき、Reviewersにレビューしてもらいたい人を追加します。
- AssigneesやLabelについてはissuesで説明したことと同じです。
- レビューとリファレンスが完了するとマージが可能になります。現状ではリーダーが強制マージの権限を持っているのでマージしていますが、可能ならば（そうしてほしい、リーダーもミスすることはあるので現状の状態はあまり良くない）レビューしてから、プルリクを送った開発メンバーがマージしましょう。
↓よくあるテンプレ
## 関連Issue
> このPRと関連するIssueの番号を書きます
> 例: ログイン画面 #13
> 「close #13」と書くと、PRがマージされた際に自動的に#13のIssueがcloseされるので便利です
## やったこと
> やったことを書きます
> 例: ログイン画面の実装
## 実装の詳細
> どのように実装したかを書きます（なるべく詳しく書いた方が良い）
> 例: LoginActivityを作成し、起動時に表示されるようにしました。
## レビューして欲しいところ
> 実装が不安なところなど、レビューして欲しいことを書きます
## スクリーンショット(あれば)
> UIに変更を加えた祭はスクショがあるとわかりやすいです。変更前・変更後のスクショがあると良い
Gitについて
gitは少し難しいかもしれませんが怖いものではないので落ち着いて対処していきましょう。ここではこれから使うであろうgitコマンドをおもに説明していきたいと思います。
git command
必要最低限の流れ
説明
(ブランチ名)で書かれているところは現在いるブランチを示しています。コマンドの一種ではないので気をつけましょう。逆に"ブランチ名"で書かれているところは入力することを示しています。この二つに気をつけて参考にしてください。
$ git clone "リポジトリのURL"
リモートリポジトリからローカルにデータを受け取ります。
$ git pull (develop)
リモートに変更があった場合pullを行います。
$ git branch "ブランチ名" (develop)
baseブランチから作業用のブランチを作成します
$ git checkout "ブランチ名" (develop)
baseブランチから作業用ブランチに移動します
$ git add ここに必要なものを書く (ブランチ名) 他
変更があった場合addを行います。詳しくは下の方で記述します
$ git commit (ブランチ名)
addでステージに上がったファイルをcommitしますcommitについても下の方に記述します。
$ git checkout develop (ブランチ名)
作業ブランチの変更をコミットしたらブランチを移動できるようになるので、移動しましょう。
※作業ブランチでファイルを変更し保存していなかった場合commitしていなくてもブランチを移動できるので注意しましょう。
$ git pull (develop)
ここでリモートのdevelopが変更されているかもしれないのでpullして変更内容をローカルにも反映しましょう。
$ git checkout "ブランチ名" (develop)
ここでdevelopの状態を確認したら作業ブランチに戻りましょう
$ git rebase develop (ブランチ名)
このコマンドではdevelopが自分の作業ブランチを切ったところから変更されていた場合に行います。ここでdevelopが変更されているにも関わらず作業ブランチをpushしてプルリクを送ってしまうとmergeした時にコンフリクト起きてしまいます。そうなると修正が面倒になるのでローカル場でbaseブランチをRebaseしてコンフリクトが起きないか確認してブランチの派生した位置を先頭に持ってきてください。コンフリクトが起きた場合はコンフリクトを解消してください
$ git rebase --continue (ブランチ名)
rebaseを行なってコンフリクトが起きるとrebaseが中断されるのでコンフリクトが解消されたらrebase -continueしましょう
$ git push -f origin "ブランチ名" (ブランチ名)
作業が終わったら作業ブランチをリモートの作業ブランチにpushしましょう。初回でリモートに作業ブランチがなくてもpush origin "ブランチ名"で生成されます。
※このコマンドでは-fをつけています。これは気をつけなければ危険なものですが理解していれば問題ありません。ローカルとリモートで大きく変更している場合、pushするとコンフリクトが起きてしまいます。今回の場合rebaseしたためにそのような自体がおきてしまうの-fをつけて強制pushさせます。初回pushならリモートに作業ブランチが存在しないので-fをつけなくても問題ありません
$ git checkout develop (ブランチ名)
作業ブランチでの作業が終了したら何かのミスが起きないためにもdevelopのブランチに戻ることを進めます。
以上が基本的な流れになります。
その他知って置くと便利なコマンド
$ git log --graph --all --oneline
ブランチの状態を知ることができます。
$ git status
変更されたファイルの状態を知ることができます。ファイルの場所が赤く表示されている場合はaddされていない状態です。緑色の状態だとaddされステージにいる状態になります。ここを見てcommitしましょう。commitはステージにあるものしかできませんのでしっかり確認しましょう。
ほかにもいろいろありますが面倒なので書くのやめます。
ググってください。
feature/"作業ブランチ名"について
git branch feature/"作業ブランチ名"
↑このfeatureを入れると作業ブランチがbase branchにmergeされたときに作業ブランチが削除されます。
基本的にissueの作業が終わればそのブランチは必要なくなるので削除していただいて構いません。
git addについて
addにはいくつか種類があります。
$ git add "ファイルの場所"
$ git add "ファイルの場所途中"*
$ git add -u
$ git add .
add コマンドにはいくつか方法があります。
基本の基本としてaddのあとにファイルの場所を入力するとそのファイルがステージングされます。
例： $ add app/res/values/colors.xml
と記入された場合colors.xmlというファイルがステージングされます
またディレクトリ（フォルダ）ないのもの全てをステージングしたいときなどは
例: $ add app/res/values*
例: $ add app/res/valu*
などパスの後に*をいれることで入力したものと一致するファイルを全てステージにあげます。
add -u ： 元のファイルを変更した時に使います。変更したファイルを全てステージにあげたいときはこのコマンドを使います。
add . : 追加、変更したファイル全てを追加するコマンドになります。別々にコミットしたい時にこのコマンドを使うと面倒なので気をつけましょう。
add -i : は面白いので試しに使って見てください。ググってから
git commitについて
git commit
git commit -m "コメント入力"
commitにも色々方法はありますが基本的にはこの２つでいいと思います。
-mをつけるとその後にコミットメッセージを入力することでこの１行でコミットすることができます。
git commitだけの場合vimが立ち上がりそこにメッセージや説明を入れることになります。詳しくはググりましょう。