draft text for git training summary

gistfile1.txt

2021/06/15 WEEK1 2回目

①バージョン管理(GIT）の目的の説明
　1.変更履歴の管理ができる
　　バージョン番号で管理するやり方の説明(ver0.1 ver0.2 ver1.0.20210615)
　　バージョン管理の移り変わり　CVS→Subversion→Git
    有料ツールPerforceはBinaryファイルの差分分析に強い

　
　2.多人数で１つのコードを平行開発できる
　　今の現実はプログラミングできてもバージョン管理できないと技術者と
　　して認められない
　　使うにあたってコンセプトを理解していないと意味がない
　　
　3.プロジェクトの管理
　　バージョンの管理ができる。バージョン〇〇で△△の機能が増えた
　　△△のバグを対応した　などの管理ができる
　　マイルストーンを設定できる。(次のリリースまでにどういう機能を追加
　　するか、進捗管理)
　　Gitのタグの機能がある。ブランチのある時点にタグが作れる
　　
　4.バグでお客さんに迷惑かけないこと
　　リリースしているバージョンからブランチを作成して
　　作成したブランチで作業することで
　　お客さんが使っているバージョンに影響しない
　　(迷惑かけない)他の人の作業スペースに影響しない
　　コードレビューでリリースする前に修正分を共有してチェックする
　　
　　コードを作成する人とコードレビューする人は分ける。
　　作成者メガネで不具合を見逃す
　
　5.オープンソースの開発協力ができる。
　　他の開発者をフォローすることで勉強ができる。
　　オープンソース成功例　Google Webkit Chromium>Microsoft Edge, UC Browser, Opera

　　GOOGLE SUMMER OF CODEの説明
　　Google Summer of Code
　　
　6.自動ビルドテスト
　　毎日仕事終わったらクラウドで自動ビルドして
　　次の日ビルドしたものテストができる
　　
②ブランチの名前の説明
　【Git】基本のブランチモデル | Memento Mori Blog
　
　-文化
　小文字で作る(URL　大文字も小文字として反映される)
　アンダーバーを使用しない「-」などを使用する。
（アンダーバーだとたまにエラー)
　
　今使っているブランチ名
　
　-"develop"
　開発者用の安定版、共有されるソースコードはここ。　
　開発者が機能追加、バク修正するならここからブランチを作成する
　
　-"feature-readable-name"
　機能を追加する場合
　
　-"bugfix-bug#-easy-to-know-name"
　不具合を修正する場合
　
　-"test-your-name-what-you-did"
　機能を試したいときなど
　マージせず消すことがある 　

③GitHubのIssueの流れ
　GitHubで課題を管理する便利機能Issueとその作成方法
　GitHubでIssueについて解決してクローズするまでの手順
　
　Issue→みんなと議論する(バグの修正,機能追加)
　
　1.タイトルの作成
　
　2.バグの場合の内容
　　WHAT?（どんなバグか一言)
　　HOW?（再現のやり方)
　
　3.担当者の割り当て
　4.ラベルの選択(つけなくてもいい)
　5.Submit

　6.作り終わったら
　　コメントして、解決したらクローズする。