今日から始めるGithub
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,125
On Slideshare
1,640
From Embeds
485
Number of Embeds
3

Actions

Shares
Downloads
7
Comments
0
Likes
5

Embeds 485

http://lab.designsatellites.jp 478
https://twitter.com 6
http://geechscamp.lovepop.jp 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 今日から始める GitHub  
  • 2. 名前: ライオンの人   (@amana&ou44)   職業: 味噌汁エンジニア  
  • 3. GitHubとは…   • Gitのリポジトリをホスティングするサービス    #  =>  Gitの管理プロジェクトを自前の設備を使わ ずにインターネット上で”分かりやすく”サポートし てくれるサービス   Gitとは…   • どんなドキュメントもアップデート履歴を保存し、 管理してくれるバージョン管理システム  
  • 4. Gitの概念はもうちょっと知りたい人 はこれで…   前回の千葉さんの「はじめてのgit」  
  • 5. 突然ですが  
  • 6. 結論から   実演ミスったりしたらヤダとかそういうのじゃないんだからね!  
  • 7. この登壇で言いたい事は何?   レビューをする側    他人のコードを見る癖をつけましょう    (イライラする癖も無くしましょう)   レビューを受ける側    指摘を素直に受け止める癖をつけましょう    (君  !=  君のコードではない)  
  • 8. 勿論辛い時もあります…   ゴミコード   (目に毒かと思い、 アス比も見辛くして あります)  
  • 9. 口頭で指摘を受け、リファクタ…  
  • 10. しかし受けるレビューの嵐…  
  • 11. 細かな事まで…  
  • 12. だけどもっと良いコードにしてくれる事も…  
  • 13. 小躍り中…  
  • 14. そして後4回のリファクタと指摘を受け…   完成!!  
  • 15. 結果的に…   58行   13行   やりたかった事はたった13行で表現出来たわけです   ※短くすればするほど良いってものじゃないからそこは勘違いしないください  
  • 16. 何故github?   • 前のスライドでも書いた通り「レビューをする」 →「レビューを受ける」、この流れが大事なので す。   • なので、githubじゃなくても別に良いんです。 ツールはあくまでツール。文化を根付かせましょ う、という話です。  
  • 17. 結論を言った所で…  
  • 18. 実演に移ります!!  
  • 19. その前に…   GitHubのアカウントを作っておきましょう!   公開鍵を作っておきましょう!  
  • 20. 公開鍵の作り方は…   ・ssh-­‐keygen  コマンドがあるかどうか調べましょう。   Mac/Unix/Linuxの方に関してはssh-­‐keygenコマンドがあ るのでそれでターミナル開いてssh-­‐keygenって打って 作っちゃえよ!   詳しい作り方はここ参照     Winの方はmsysgitでダウンロードするとssh-­‐keygenコマ ンド入ると思うので、試してね。   方法は上と一緒。  
  • 21. では再度…  
  • 22. 実演に移ります!!   (後でスライド見ながらでも分かるようにしておきます)  
  • 23. サインインするとこんな感じです  
  • 24. さっさと移動  
  • 25. これがホーム画面(勝手に呼んでます)  
  • 26. Repositories  タブをクリックします  
  • 27. Newボタンをクリックします  
  • 28. Repository  nameを決めます   (自アカウント内で使ってない名前なら何でもOK!)  
  • 29. 無視  
  • 30. 金取られます…  
  • 31. .giPgnoreは分からなければそのプロジェクト内で使う言語で   Licenseはちゃんと調べてから(分からなければMITで)   READMEは一応作っておけばいいと思うよ  
  • 32. .giPgnoreとは…   プロジェクト内において  “いらない”  or  “バージョン管理してはいけ ない”  ファイルがあります。   「.DS_Store」、「swp」、「node_modules」、「gem」、「.config」などな ど…   それをgitの管理下から外す為に書いておくリストファイルです。   (厳密には上は正しく無く、『特定ディレクトリは無視するがその中 に例外ファイルが含まれいた場合のみ、管理下に置く』といったよ うな書き方も可能です)     余談ですが、JavaScriptはありません。  
  • 33. Licenseとは…   知らない人はいないと思いますが、著作権の事です。     気になる方は下記参照願います。   Githubによる、オープンソースライセンスの選び方まとめ  
  • 34. 実は  Repository  nameを入れた時点でcreate出来ます!  
  • 35. Click!  
  • 36. 出来ました!  
  • 37. まずは作成までお疲れさまです!     これでリポジトリを作成する事が出来ました。   次からはローカル内のファイルを編集してリモートにコミットすると いう流れまでを説明します。     リモート   #  =>  githubのリポジトリ   ローカル   #  =>  自PC内  
  • 38. URLコピります!  
  • 39. HTTPS、SSHとあるが…   悩む前にどっちも試せばいいネ!  
  • 40. ターミナルにて…   作成されました!  
  • 41. 中に入ってみると…   一緒ですね!!  
  • 42. 一緒じゃないじゃん…   .gitというのはバージョン管理を行ってくれているファイル 群です。   ここの中にlogやcommitや自分のプロジェクトファイルな どが管理されています。  
  • 43. じゃあ編集しちゃいましょう。   MarkDownで編集出来ます  
  • 44. Gitのstatusを見てみると…   修正されたって言われているのが分かりますね。  
  • 45. じゃあ追加っと…   .(ドット)は~/test/配下の変更があるファイル全て   という意味です。   Gitの管理下に追加されたので、いわゆるステージング状態です。  
  • 46. ではコミットだ!   ブランチにコミットされたものが1件あるよと言っていますね。  
  • 47. Pushする前に…   ロ グ  
  • 48. Logしてみよう!   さっきコミットしたログ   Githubの方で作った時のコミットログ   ※変なコミットが無いかの確認とログ を見る癖を付ける為  
  • 49. ではpush!   上手くいった!!!YES!!!!!  
  • 50. じゃあブラウザでの確認だ!  
  • 51. イヤッホオオオオオ!!!  
  • 52. でも何か足りない…  
  • 53. そうだ!PR(プルリクエスト)を送ってないじゃない か!   そうだ、   PRを送ろう  
  • 54. でも他人に送るのは気が引ける…  
  • 55. 自分に送ればいいじゃん!  
  • 56. じゃあこれに追加でPR送ります  
  • 57. ファイル追加してgit  statusで確認…   ファイルの中身  
  • 58. あ、PR送るんだからブランチ変えないと…   途中からでも大丈夫   はい、ちゃんとブランチを変更する事が出来ましたね  
  • 59. 先程の状態で…   追加!   ステータス!  
  • 60. 次に…   コミット!   ステータス!   ログ!  
  • 61. あれ?さっきとやり方が違う…   Git  commitはオプション「-­‐m」を付けることによって、   その後に渡す引数がコミットメッセージとなります。   始めの内はgit  commitをする場合は「-­‐m」を付けずに意識的にコマンドを実行して   コマンドラインと会話してみるという事をしてみましょう。   注意点:    上記の場合、「~/.gitconfig」というファイルを作り、[core]にエディタを選択して下さい。  
  • 62. ではpush!  
  • 63. ブラウザ即確認!  
  • 64. 何か増えてるし!!  
  • 65. さっそくクリック  
  • 66. え?何これ?新手の恋文?  
  • 67. そうです。恋文です。   •  Master(最新開発)ブランチへ取り込みを御願いする為のものです。   •  その内容には簡潔、かつ何をしたか明確に記載します。    -­‐  決して「いかがお過ごしでしょうか」などや「今日も貴方を思うと心が 熱くなり、眠れません」などと書いてはいけません。  
  • 68. 左がPRの送り先  
  • 69. コミットの際につけたメッセージ  
  • 70. PRの際に更に補足するPRメッセージ   (大体コミットメッセージだけで事足ります)  
  • 71. ではPRをsendしちゃいましょう!  
  • 72. これがPRが送られた状態です。  
  • 73. 実際の差分を見たい場合はこれ  
  • 74. なるほど、今回の差分はこれか…  
  • 75. コードに疑問を抱いたりした場合は…   ラインに合わせると左側に「+」マークが出てくるのでクリック。  
  • 76. 出て来たformに素直に疑問をぶつける…   自分のコミットにコメントするのは意識高い系らしいです。  
  • 77. 戻ってみると…  
  • 78. 面倒いのでMergeしちゃいます  
  • 79. 何か開いた…  
  • 80. PR送られた段階でissuesにも登録されます  
  • 81. 大体そのままでOKです!GO!GO!  
  • 82. mergeされました!  
  • 83. イヤッホオオオオオ!!!  
  • 84. 後は後処理だけですね!   基本的に1コミット1ブランチなので、   mergeが終わった後はまずはremoteのブランチを削除しちゃいます  
  • 85. 消えた事の確認  
  • 86. issuesに紐づいているので良いっちゃ良いのです が、明示的にする為にclosed宣言します   Issue  IDを覚えていなくても補完が効きます!  
  • 87. これでgithubでの作業は終了です   私の語感による問題でMergedに変更しましたが、ここら辺は本人次第で良いと思います。   例えば、    issues発祥のコミットであれば、closed。    元々やる予定であった機能追加であれば、merged。   などといったように分けています(他にfixedなどもあります)   本来であればcommitにissueIDを含めたりするんですが、 今回は自分のリポジトリになりますのでそこら辺はテキトーです。  
  • 88. 次はローカルでの作業です   ログが違う事が見 て取れるかと思い ます。  
  • 89. この状態でgit  branch  –d  で削除しようとすると…   エラーが出て怒られます!  
  • 90. なのでgit  fetchして最新をダウンロードします   fetchはどこのブランチで行ってもOK   .gitフォルダに最新情報を拾って来るだけ  
  • 91. 何でpushした情報が最新なのに最新の情報が落 として来れるの?   githubのmasterに mergeされた時のコ ミットデータがありま す。  
  • 92. なので、mergeしちゃいます   merge完了  
  • 93. mergeだけじゃなくてrebaseもあるよ!   •  それに関してはここで説明するよりかは [Git]  使い分けできていますか?マージ(merge)&リベース(rebase)再 入門    git  merge  と  git  rebase    こわくないgit    上記をURLを参照してみて下さい。  
  • 94. すぐログ確認  
  • 95. 念のためgraph付きも…  
  • 96. ここまで終わったら後は…   残ったゴミブランチを削除!  
  • 97. お疲れさまでした!   皆様も良いソーシャルコーディング生活を!  
  • 98. ご清聴ありがとうございました!!