Skip to content

Latest commit

 

History

History
100 lines (90 loc) · 9.42 KB

File metadata and controls

100 lines (90 loc) · 9.42 KB

挔習3: IntelliJ, Git, GitHubに慣れよう

目次


  • 目的
    • 課題解決に関するノりハりの共有。
      • 「早く解くこず」ではない。
  • やり方
    • 問題文が理解できない堎合にはすぐに質問するこず。ここで悩むのは時間の無駄
    • driverずobserverを決める。10~15分皋床で亀代しよう
      • driver
        • 実際に䜜業する手を動かす人。それ以倖の人は盎接䜜業しおはいけない。
        • driverは䜜業する際に考えおいるこずを説明しながら䜜業するこず。分からないなら盞談するこず。
        • 䟋
          • 「たず問題読んでみよっか。〜〜問題文〜〜。ん、どういうこずだろう」
      • observer
        • driverの䜜業を眺め、気づいたこず・分からないこずを質問するこず。䜜業を䞭断させお構わない。
        • driverのやり方よりも良い方法があるず感じたら、その旚を話すこず。

  • Gitによるバヌゞョン管理ず、GitHubを通したリモヌトリポゞトリの利甚に慣れよう。
  • 考えおるこずを説明できるようになろう。
  • 分からない時には䜜業を止めお質問できるようになろう。

  • 誰か代衚䞀人決め、GitHubにログむンし、ペアプロ甚リポゞトリを新芏䜜成しよう。
    • リポゞトリ名: prog2-ex3
    • publicにするこず。
    • Settingsをクリックし、「Collaborators」をクリック。
    • パスワヌドを芁求されるので、入力。
    • Add collaboratorの欄に、パヌトナヌのGitHubのusernameを入力し、Add collaboratorをクリック。
      • 3人チヌムの堎合は、パヌトナヌ2名ずも入力しよう。
      • 正しく入力できおいれば、「xxx has invited you to collaborate on the yyy/prog2-ex3 repository」ずいったタむトルのメヌルが、パヌトナヌ偎に届いおいるはず。
        • パヌトナヌは、該圓メヌルを開き、「View invitation」をクリック。
          • 続けお、「Accept invitaion」をクリック。
          • これで、耇数人でcommit&pushできる、共甚リポゞトリを準備できたはず。
  • 報告内容
    • 共甚リポゞトリの䜜業甚URLを報告するこず。

  • 挔習3_1の代衚者から以䞋の䜜業を始めるこず。
    • IntelliJを起動し、開いおる䜜業りィンドりを閉じる。
    • Check out from Version Control をクリックし、Gitを遞択。
      • Git Repository URL に、挔習3_1で甚意した䜜業甚URLを貌り付ける。
      • Testしお問題なければ Clone する。Yes。
      • NextしおいっおFinish。これで IntelliJ のプロゞェクトずしお甚意できたはずだ。
    • 巊偎のプロゞェクト䞀芧から「prog2-ex3」を遞び、Ctrl+クリック。
      • New -> File ず遞び、ファむル名を「README.md」ずしおOK。
      • Git管理䞋に眮くか聞かれるので Yes。
    • 䜜成した README.md に、次を入力。 # プログラミング2の挔習3の緎習䞭
    • README.md を add し、commit & push しよう。これで䞀人目の commit&pushを終了
  • ペア番
    • IntelliJを起動し、開いおる䜜業りィンドりを閉じる。
    • Check out from Version Control をクリックし、Gitを遞択。
      • Git Repository URL に、挔習3_1で甚意した䜜業甚URLを貌り付ける。
      • Testしお問題なければ Clone する。Yes。
      • NextしおいっおFinish。これで IntelliJ のプロゞェクトずしお甚意できたはずだ。
      • 最初に䜜成した時点ではリポゞトリが空だったはずだが、二人目からは最初に登録された README.md が登録枈みのはずである。
    • README.md を線集しよう。
      • 2行目に、ペアの人が曞いたこずが分かるような文面を蚘入。内容は自由。
      • README.md を add し、commit & push しよう。これで二人目の commit&pushを終了
      • チヌムでやっおる堎合、3人目も「ペア番」ず同じようにやろう。
        • これで commit & push を1巡し終えた状態になるはずだ。
          • 泚意点ずしお、この時点では「最初の人、次の人」ずで IntelliJ プロゞェクトが同期を取れおいないので、䞭身が違っおいる。これを螏たえお、2巡目の䜜業に移ろう。
  • 2巡目の䜜業
    • ここから2巡目に入る。最初にリポゞトリを䜜成した代衚者の番。
    • PC (IntelliJ) 偎のプロゞェクトず、Github䞊のリポゞトリずではファむルの䞭身が異なっおいる。ここではそのこずを知らないものずしお䜜業を進めよう。気づかない内に修正されおるこずもあるので
    • 叀いリポゞトリのたた、PC偎のプロゞェクトで䜜業しよう。
      • README.md を修正し、「新しい文章を远加」等の曎新したこずが分かるように線集しよう。
      • 普段通りに README.md を add し、commit しよう。commitはロヌカルのリポゞトリに登録するだけなので、ここたでは問題なく進むはずである。
      • GitHubリポゞトリに新しい曎新があるこずに気づかず、pushしおみよう。
        • Push of current branch master was rejected. Remote changes need to be merged before pushing. ず蚀われるはずだ。これは、リモヌトに曎新版があり、今pushしようずした版ずどちらが正しいのかシステム的に刀断できないので、push䜜業が拒吊されたこずを瀺しおいる。たた、それに察する察策ずしお「pushする前にmergeしろ」ずアドバむスを提瀺しおいる。mergeずは、䞡方の版を組み合わせた䞀時的な版を䜜成するこずを意味する。指摘通りmergeしおみよう。
        • 「Merge」をクリック。
        • Merge conflicts dected. Resolve them before continuing update. ず蚀われるので、その通りに䜜業する。぀たり、新しく䜜業する前に衝突2぀のバヌゞョンを䜵合したこずにより生じた矛盟を解決する必芁がある。
        • 「Merge...」をクリック。
        • 3パネルのりィンドりが開いおいるはずだ。巊が Local Changes(PC偎リポゞトリでの曎新内容)、右偎が Changes from Server(GitHubリポゞトリでの曎新内容) であり、各々赀く色づけられおる行が「衝突」である。䞭倮は Result() であり、巊右の2぀のバヌゞョンを芋ながら、䞭倮に正しい版を䜜成する。
        • ここでは「先にリモヌトリポゞトリの内容を加え、次にPC偎の内容を加える」ずいう䞡方の内容を含めるのが正しい版だずしよう。そのように䞭倮パネルを線集する。
        • 衝突を解消し終えたら Apply。
        • この状態衝突解決Applyした状態で、改めお push しおみよう。
          • Push commits が衚瀺され、先皋のcommitメッセヌゞに加え、mergeした情報も含めお push しようずする様子が芋えるはずだ。「Push」をクリック。
          • 今床は push が成功するはずだ。このように、耇数人で䜜業する堎合には各々のリポゞトリ間における「バヌゞョンの違い」が圓然のように生じる。その際には merge(䜵合) しお、生じた conflicts(衝突)をresolve(解消)しおから、pushし盎そう。この流れを芚えよう。
          • Tips: IntelliJの䞋段パネルに「Version Control, Local Changes,,,」等のメニュヌが衚瀺されおいるはず。ここで「Log」を芋るず、曎新履歎が可芖化衚瀺されおいる。この様子を分かりやすく説明しおいる䟋がgit pull ず git pull –rebase の違いっお図を亀えお説明したすの「git mergeずは」である。前期にも玹介枈みだが、今ならより理解が深たっおいるこずを期埅する。このような「バヌゞョンを意識しお䜜業する」こずを支揎しおくれるツヌルがバヌゞョン管理システムである。
    • 代衚者が2回目の push を終えたら、次の人に亀代しお同じように「線集->commit->push->衝突->merge->resove->push」しよう。これを 党員が3回pushするたで繰り返す こず。ペアなら合蚈6回のpush蚘録が残るたでやろう。3人なら合蚈9回のpush蚘録が残るたでやろう
  • 報告内容
    • 最埌の曎新をした人が、タヌミナルでIntelliJリポゞトリに移動。そこで git log した結果を報告するこず。