Tweet
Tweet

Slide 1

Slide 1 text

© DMM.com ソース管理入門 あまてく×PeachTech Git勉強会

Slide 2

Slide 2 text

© DMM.com 講師紹介 富山 雄太(マヤミト) (Tomiyama Yuta) ● 22新卒 ● 戦略開発本部 DMMTV開発部 ○ Android版DMM TVを開発してます ● Kotlinと車とゲームが好き ○ 最近ランエボXを買って金欠です ● 学生時代はZliという学生団体をやってました ○ 代表経験あり

Slide 3

Slide 3 text

© DMM.com 本講義の目的 ● ハッカソンなどのチーム開発において、GitおよびGitHubを円滑に活用できるように なること

Slide 4

Slide 4 text

© DMM.com ソース管理の必要性について

Slide 5

Slide 5 text

© DMM.com Webサービスに求められるもの • 安定稼働 • 継続的な開発・運用 開発チーム サービス ユーザ 機能追加・ 不具合修正 したい 24時間365日 使いたい

Slide 6

Slide 6 text

© DMM.com 開発体制に対する要求 1. 複数人での同時開発 2. 変更内容・意図の追跡 3. 状態の復元 4. リリース版保守と新機能開発の同時進行 5. レビュー・承認フローの可視化 Git, GitHubを用いたソース管理によって解決

Slide 7

Slide 7 text

© DMM.com Git, GitHubを用いた ソース管理

Slide 8

Slide 8 text

© DMM.com ここからはハンズオンです 用語の説明が多いですが、手を動かしながら少しずつ理解していきましょう！

Slide 9

Slide 9 text

© DMM.com Gitの概要 • Git • 分散型バージョン管理システム（Distributed Version Control System: DVCS） の一種 • ファイルの変更履歴を記録して管理するソフトウェア • https://git-scm.com/

Slide 10

Slide 10 text

© DMM.com Gitについて 1. 管理対象 2. 変更の記録 3. 作業ツリーの復元 4. 複数の開発ラインの管理 5. 複数のマシンによる開発

Slide 11

Slide 11 text

© DMM.com 1. 管理対象 • リポジトリ • Gitの管理単位 • 構成 • 管理対象のファイル群 （作業ツリー） • 変更履歴 • 範囲 • 特定のディレクトリ以下の ファイル・ディレクトリ

Slide 12

Slide 12 text

© DMM.com git initでローカルにリポジトリを作成する ● git initとは ○ 新しいローカルリポジトリを作成 ○ 個人や新規プロジェクト作成時は必要になってきます ● ハンズオン用のディレクトリを作成し、git initしてみましょう

Slide 13

Slide 13 text

© DMM.com • Gitはファイルを4つの状態で管理 2. 変更の記録：ファイルの状態 追跡されていない Untracked 変更されていない Unmodified 変更された Modified ステージされた Staged git管理されており、かつ変更され ていないファイル 変更されたファイル 記録につける予定のファイル git管理されていないファイル 例：新規作成したファイル ファイルへ変更を加える どの変更を記録するのか 選択する（ステージング） 変更を記録する（コミットする） git管理対象に加える

Slide 14

Slide 14 text

© DMM.com 2. 変更の記録：記録の形式 • コミット • 変更の記録 • ハッシュ値によって識別 • 親子関係を作り 親コミットへのポインタを 持つ形で蓄積 commit ecdfebc746fdf197d4ec8c704a55477373de75a1 Author: hoge-taro Date: Mon Mar 10 10:16:19 〇〇画面の××バグの修正 commit 389e395adbe1df1f0a9ca9ba3f0049cacce69f5d Author: hoge-taro Date: Tue Mar 11 13:47:13 △△機能の追加 commit 7b697ea2f8298b44f97aa4ebdb47dc0b30a5f531 Author: hoge-taro Date: Wed Mar 12 19:26:16 ⬜⬜表記の修正 親 子 親 子

Slide 15

Slide 15 text

© DMM.com ファイルの状態の変化を体験する Gitの状態はgit statusコマンドで確認することができます まずはecho 'Hello, Git!' > sample.txtとgit statusを実行してみましょう 新しく作ったファイルなのでGit管理下になく、Untracked filesに表示されて いると思います

Slide 16

Slide 16 text

© DMM.com git add について ● git addとは ○ ファイルの変更内容を「Staged(次のコミットに含める状態)にする」操作のこと ● コマンド例

Slide 17

Slide 17 text

© DMM.com ファイルの状態の変化を体験する git add sample.txt を実行し、git statusを実行します sample.txtがgitに認識され、このファイルの状態がStagedになります

Slide 18

Slide 18 text

© DMM.com git commit について ● git commitとは ○ コミットは、Stagedなファイルの変更内容を保存する操作のこと。 ○ 履歴を追跡できるようになります。 ● コマンド例

Slide 19

Slide 19 text

© DMM.com ファイルの状態の変化を体験する git commit -m "add sample.txt" を実行し、 git status を実行します Stagedなファイル(sample.txt)の変更が記録され(コミット)、状態が Unmodifiedになります この状態だとUntracked, Modifiedなファイルが存在しないため、 git status の実行結果にsample.txtは表示されません。

Slide 20

Slide 20 text

© DMM.com ファイルの状態の変化を体験する echo 'Goodbye Git!' > sample.txt を実行してsample.txtに変更を加え、 git status を実行します。 Git管理されたsample.txtに変更が加えられているため、状態がModifiedに なります。

Slide 21

Slide 21 text

© DMM.com ファイルの状態の変化を体験する この状態で git add sample.txt, git commit -m "change sample.txt" する と、再びsample.txtがStagedになったのち変更が保存されUnmodifiedにな ります。

Slide 22

Slide 22 text

© DMM.com 3. 作業ツリーの復元 • コミットはスナップショット • いつでも過去のコミットの状態を 復元できる HogeApplication file1 file2 file3 HogeApplication file1 file2 file3 HogeApplication file1 file2 file3 commit 7b697ea2f8298b44f97aa4ebdb47dc0b30a5f531 commit 389e395adbe1df1f0a9ca9ba3f0049cacce69f5d commit ecdfebc746fdf197d4ec8c704a55477373de75a1

Slide 23

Slide 23 text

© DMM.com git resetについて ● git resetとは ○ 今の環境を特定のコミットの状態まで巻き戻すことができる ○ --softと--hardのオプションに気をつけてコマンドを叩く ■ オプションなしだと--softのほうになる ● コマンド例 ○ - soft - 作業ツリーの変更を残す - hard - 作業ツリーの変更を削除

Slide 24

Slide 24 text

© DMM.com 過去のコミットを復元する git log を実行すると、リポジトリのコミット履歴を確認することができます。

Slide 25

Slide 25 text

© DMM.com 過去のコミットを復元する git reset <コミットハッシュ> でGitの状態を指定したコミットまで戻すことがで きます。 git reset を実行し、Gitの状態を最初 のコミットに戻してみましょう(コミットハッシュは皆さんの手元で確認したもの をコピペしてください)。

Slide 26

Slide 26 text

© DMM.com 4. 複数の開発ラインの管理 • ブランチ • 開発ラインを表す • コミットの蓄積によって 表現される 安定版 ライン 新規機能開発ラ イン

Slide 27

Slide 27 text

© DMM.com git branch について ● git branchとは ○ 現状含めて全てのブランチを見ることができる ○ 存在しないブランチ名を入力することでブランチ作成も可能 ● コマンド例

Slide 28

Slide 28 text

© DMM.com 現在のブランチを確認する デフォルトではmainブランチでGitリポジトリが作成される(はず)。 git branch を実行すると、現在存在するブランチが表示され、今いるブラン チにはブランチ名の隣に*が表示されます。

Slide 29

Slide 29 text

© DMM.com 4. 複数の開発ラインの管理 • ブランチを切る • 新規開発ラインを作成 • 1つのコミットを親として 2つのコミットがある状態 安定版 ライン 新規機能開発ラ イン

Slide 30

Slide 30 text

© DMM.com ブランチを作成する git branch another を実行し、anotherブランチを作成してみましょう。 git branch を実行すると、anotherブランチが作成されていることを確認でき ると思います。

Slide 31

Slide 31 text

© DMM.com git switch について ● git switchとは ○ 現在のブランチから他のブランチに移動すること ○ -c オプションを使えばブランチ作成も一緒にできる ● コマンド例

Slide 32

Slide 32 text

© DMM.com ブランチを移動する git switch another を実行し、anotherブランチに移動してみましょう。 git branch を実行すると、anotherブランチに移動できていることを確認でき ると思います。

Slide 33

Slide 33 text

© DMM.com 4. 複数の開発ラインの管理 • ブランチのマージ • 開発ラインの統合 • 2つのコミットを親にもつ コミット（マージコミット）を作成 安定版 ライン 新規機能開発ラ イン

Slide 34

Slide 34 text

© DMM.com • コンフリクト • ブランチをマージする際に、同じファイルの同じ箇所に異なる変更があり、競合 してしまう状態 4. 複数の開発ラインの管理：変更の衝突と解消

Slide 35

Slide 35 text

© DMM.com コンフリクトとマージの体験 スライドの説明通りにやっていれば、今はanotherブランチにいる状態で sample.txtファイルがModifiedになっているはずです この状態で git add sample.txt git commit -m "another change sample.txt" を実行し、anotherブランチにコミットを追加します

Slide 36

Slide 36 text

© DMM.com コンフリクトとマージの体験

Slide 37

Slide 37 text

© DMM.com コンフリクトとマージの体験 git switch main でmainブランチに戻り、 echo 'main branch change' > sample.txt でsample.txtを変更し、 git add sample.txt , git commit -m "main change sample.txt" で変更を 保存します。

Slide 38

Slide 38 text

© DMM.com コンフリクトとマージの体験 マージは git merge <取り込みたいブランチ名> で行います。 今はmainブランチにいるので、 git merge another を実行するとanotherブ ランチをmainブランチに取り込む操作になります。 今いるブランチと取り込みたいブランチで変更箇所が被っていなければその ままマージが完了しますが、今回は同じファイルで変更箇所が被っているた め、コンフリクトが発生します。

Slide 39

Slide 39 text

© DMM.com コンフリクトとマージの体験 VSCodeなどの好きなエディタでsample.txtを開いてsample.txtを確認して みましょう。 <<<<<<< HEAD ~ ======= ~ >>>>>>> main のようになるはずです

Slide 40

Slide 40 text

© DMM.com コンフリクトとマージの体験 HEADのセクションが自分が手元で加えた変更、その下のセクションが取り 込みたい変更です。 <<<<<< ===== >>>>> を消してコンフリクトを解消 します。 今回は1,3,5行目を丸ごと消して 保存しましょう。

Slide 41

Slide 41 text

© DMM.com コンフリクトとマージの体験 コンフリクトを解消したら、git add sample.txt で再度sample.txtをaddし、git commit を実行します。(今回は-mオプションなし) vimが起動し、デフォルトのマージコミットのメッセージが入力された状態に なっているので、このまま :wq を入力、エンターを押すとコミットが完了しま す。これでマージが完了しました。

Slide 42

Slide 42 text

© DMM.com • 複数マシンでリポジトリを共有 5. 複数のマシンによる開発：リポジトリの共有 Gitサーバー ローカルマシン ローカルリポジトリ リモートリポジトリ （ベアレポジトリ） ローカルマシン ローカルマシン 作業ツリー 変更履歴 （.gitディレクトリ） 変更履歴 （.gitディレクトリ）

Slide 43

Slide 43 text

© DMM.com • Gitサーバー • 仲介用のマシン 5. 複数のマシンによる開発：リポジトリの共有 Gitサーバー ローカルマシン ローカルリポジトリ リモートリポジトリ （ベアレポジトリ） ローカルマシン ローカルマシン 作業ツリー 変更履歴 （.gitディレクトリ） 変更履歴 （.gitディレクトリ）

Slide 44

Slide 44 text

© DMM.com • リモートリポジトリ • Gitサーバー上のリポジトリ • 変更履歴のみを持つ 5. 複数のマシンによる開発：リポジトリの共有 Gitサーバー ローカルマシン ローカルリポジトリ リモートリポジトリ （ベアレポジトリ） ローカルマシン ローカルマシン 作業ツリー 変更履歴 （.gitディレクトリ） 変更履歴 （.gitディレクトリ）

Slide 45

Slide 45 text

© DMM.com • ローカルリポジトリ • 手元のマシン上のリポジトリ • 変更履歴と作業ディレクトリを持つ 5. 複数のマシンによる開発：リポジトリの共有 Gitサーバー ローカルマシン ローカルリポジトリ リモートリポジトリ （ベアレポジトリ） ローカルマシン ローカルマシン 作業ツリー 変更履歴 （.gitディレクトリ） 変更履歴 （.gitディレクトリ）

Slide 46

Slide 46 text

© DMM.com • プッシュ • ローカルの変更履歴をリモートリポジトリへ反映 5. 複数のマシンによる開発：リポジトリの共有 Gitサーバー ローカルマシン ローカルマシン ローカルマシン 作業ツリー 変更履歴 （.gitディレクトリ） 変更履歴 （.gitディレクトリ） プッシュ プル リモートリポジトリ （ベアレポジトリ） ローカルリポジトリ

Slide 47

Slide 47 text

© DMM.com • プル • Gitサーバー上の変更履歴をローカルリポジトリへ反映 5. 複数のマシンによる開発：リポジトリの共有 Gitサーバー ローカルマシン ローカルマシン ローカルマシン 作業ツリー 変更履歴 （.gitディレクトリ） 変更履歴 （.gitディレクトリ） プッシュ プル リモートリポジトリ （ベアレポジトリ） ローカルリポジトリ

Slide 48

Slide 48 text

© DMM.com GitHubの概要 • GitHub • “The complete developer platform to build, scale, and deliver secure software.” • チーム開発で有用な機能を提供 • リポジトリの管理 • レビュー・承認体制の可視化 • タスクの管理...etc • https://github.com/

Slide 49

Slide 49 text

© DMM.com GitHubができること 1. Gitサーバの提供 2. レビュー・承認フローの可視化 3. その他チームコラボレーションに便利な機能

Slide 50

Slide 50 text

© DMM.com 1. Gitサーバの提供 • （復習）GitはGitサーバーを介してリポジトリを共有する Gitサーバー ローカルマシン ローカルリポジトリ リモートリポジトリ （ベアレポジトリ） ローカルマシン ローカルマシン 作業ツリー 変更履歴 （.gitディレクトリ） 変更履歴 （.gitディレクトリ）

Slide 51

Slide 51 text

© DMM.com 1. Gitサーバの提供 • GitHubはGitサーバーを提供 ローカルマシン ローカルリポジトリ ローカルマシン ローカルマシン 作業ツリー 変更履歴 （.gitディレクトリ） GitHub

Slide 52

Slide 52 text

© DMM.com GitHubにリポジトリを作成する GitHubを開き、右上の+をクリックして表示されるメニューに「New repository」があるため、それをクリックします

Slide 53

Slide 53 text

© DMM.com GitHubにリポジトリを作成する 「Owner」に自分を選択し、「Repository name」にリポジトリ名(今回 「git-learn」)を入力します 「Create repository」ボタンをクリック すると、リポジトリが作成されます

Slide 54

Slide 54 text

© DMM.com GitHubにリポジトリを作成する 次のような初期画面になると思うので、下の 「…or push an existing repository from the command line」の指示通りに コマンドを実行すると、ローカルで今まで作業していた内容がGitHubにPush されると思います

Slide 55

Slide 55 text

© DMM.com GitHubにリポジトリを作成する ここでエラーになった人はgitに認証情報を登録する作業を一緒にやりましょ う エラーにならなかった人は休憩です

Slide 56

Slide 56 text

© DMM.com チーム開発時のソース管理

Slide 57

Slide 57 text

© DMM.com (おさらい)git init について ● git initとは ○ 新しいローカルリポジトリを作成 ○ 個人や新規プロジェクト作成時は必要になってきます ● コマンド例

Slide 58

Slide 58 text

© DMM.com git clone について ● git cloneとは ○ 既存のリモートリポジトリをローカルに複製すること ○ チーム開発などで新しいプロジェクトに参加するときに行う ● コマンド例

Slide 59

Slide 59 text

© DMM.com 新しいプロジェクトをgit cloneしてみる 先ほどまでのディレクトリとは違うディレクトリに移動し、以下を実行してくだ さい git clone https://github.com/yt8492/git-study.git git-studyリポジトリがローカルにcloneされるので、git-studyディレクトリに 移動してください。

Slide 60

Slide 60 text

© DMM.com 新しいプロジェクトをgit cloneしてみる README.mdというファイルが存在すると思います

Slide 61

Slide 61 text

© DMM.com 演習1 ● このリポジトリにはもともと exam-base というブランチが作成してあるの で、そのブランチに移動してください ● exam-baseブランチに移動したら、そこから自分のブランチを作成して そこに移動してみてください ○ 例えばtomiyama-yutaブランチを作成してそこにブランチを移動 ● README.mdに書いてある自己紹介を自分のものに修正し、add, commitしてGitHubにpushしましょう

Slide 62

Slide 62 text

© DMM.com ● プルリクエストとは ○ ブランチで行った変更内容を他のメンバーにレビューしてもらい、対象のブラン チ（例: mainやdevelop）にマージするための仕組み ○ 差分が視覚的に確認できる ○ コードレビューを円滑に進めるために用いる Pull Requestの説明 画像：https://www-creators.com/archives/4996

Slide 63

Slide 63 text

© DMM.com ● Draft PullRequestとは ○ 開発中の変更内容を下書きとして共有するPRの形式 ○ 進捗状況を共有したい場面で役に立つ ● 特徴 ○ ドラフトの状態ではマージができない ○ レビュー依頼の前に、コメントやフィードバックを頂くことが可能 Draft PullRequestの説明

Slide 64

Slide 64 text

© DMM.com ● commentとは ○ PullRequestの変更点のフィードバックを行うためのもの ● 使用するタイミング ○ 軽微な改善点やリファクタリングの提案をする場合。 ○ コードの意図を確認したい場合。 ○ コードの意図をレビュアーに伝えたい場合 PullRequestのcommentの説明

Slide 65

Slide 65 text

© DMM.com ● Approveとは ○ PullRequestをマージしても問題ないと判断した場合に行う操作 ● 使用するタイミング ○ コードレビューを行い、仕様や実装に問題がないと判断した場合。 ○ テストが正常に通過し、CIの要件を満たしている場合。 PullRequestのApproveの説明

Slide 66

Slide 66 text

© DMM.com ● GitHub上でPullRequestを作成 ○ タイトルと説明を伝わるように記述する ● レビュアーを追加 PullRequestの出し方

Slide 67

Slide 67 text

© DMM.com ● タイトル: 簡潔かつ具体的に変更内容を記載 ● 説明（下記一例） ○ 何をしたか（概要） ○ なぜ必要か（背景） ○ テストした内容 ○ 必要なレビュー観点（例: UIの変更、パフォーマンス） ● テンプレートを活用する PRのタイトルと説明

Slide 68

Slide 68 text

© DMM.com ● レビューではあくまでコードにコメントするが、読むのは人間 ○ 表現の柔らかさに気を遣う ○ 絵文字やLGTM画像などでフランクさを伝えるのも◎ ● コメントをした人と受け取る人で感じ方が異なる ■ 「この部分の実装でAを使っているのはなぜ？」 ■ 「あ、すみません！Bを使って実装し直します！」 ■ 「ただの質問だったんだけど……」 ○ レビューコメントにラベルを付けどのようなコメントか明確にしたり レビュー時の会話の心得

Slide 69

Slide 69 text

© DMM.com Pull Requestの作成 GitHubの「Pull requests」タブを開き、「New pull request」ボタンをクリック します

Slide 70

Slide 70 text

© DMM.com Pull Requestの作成 baseがmain、compareが自分の作成したブランチになっていることを確認し たら、Pull Requestのタイトルを説明文を入力し、「Create pull request」ボタ ンをクリックします

Slide 71

Slide 71 text

© DMM.com Pull Requestの作成 指示通りにできていれば、コンフリクトするはずです

Slide 72

Slide 72 text

© DMM.com git pullについて ● git pullとは ○ リモートリポジトリの最新変更をローカルリポジトリに取り込む操作 ○ 他のメンバーの作業内容を反映できます。 ● コマンド例

Slide 73

Slide 73 text

© DMM.com git pullで最新のmainを取り込む mainブランチに変更を今加えたので、それを皆さんの手元に反映させましょ う。 git switch main でmainブランチに移動し、 git pull origin main を実行して ください。 ファイルの中身を確認すると、最新のmainの状態に更新されたのがわかる と思います。

Slide 74

Slide 74 text

© DMM.com 演習2 ● Pull Requestのコンフリクトを解消しましょう ○ Pull Requestのコンフリクトの解消の仕方は、マージしたいブランチ(皆さんが 作ったブランチ, 例だとtomiyama-yuta)に対してマージ先のブランチ(今回は main)をローカルでmergeし、ローカルでもコンフリクトを発生させたうえでそれ を解消し、コンフリクトが解消された状態で再度pushすることでPull Requestの コンフリクトも解消されます

Slide 75

Slide 75 text

© DMM.com コミットの粒度 ● コミット = 作業ログ ● コミットの大きさ ○ コミットが大きい ■ ロールバックポイントが少ない ○ コミットが小さい ■ コミットログが多い ■ 変更点がわかりづらい

Slide 76

Slide 76 text

© DMM.com コミットの粒度 ● コミットをするタイミング ○ issue等のチケット単位 ■ 機能要件に沿ったコミット ○ セーブポイントとして ■ 作ったところまで、失いたくないポイントでコミット ○ 動作が保証されている状態 ■ ロールバックする場合を意識したコミット

Slide 77

Slide 77 text

© DMM.com コミットメッセージ ● 後から見て何をしたコミットなのかがわかるメッセージ ○ prefixでコミットの種類を判別できるようにしたり(gitmoji) ○ 「wip〇〇」のような内容がわかりにくいのは△ ● コミットメッセージの1行目は簡潔に ○ Gitクライアントにサマリとして使われる ○ 説明が必要な場合は改行を挟んで3行目以降が多い印象

Slide 78

Slide 78 text

© DMM.com その他のコマンド status - 現在のリポジトリ状態を表示する fetch - リモートリポジトリの最新の変更を取得する diff - ファイルの変更内容や差分を表示する tag - 特定のコミットにタグ（バージョンや目印）を付ける log - リポジトリのコミット履歴を表示する remote - リモートリポジトリを管理する switch - 作業ブランチを切り替える restore - ファイルの変更を元に戻す cherry-pick - 特定のコミットを現在のブランチに適用する blame - ファイルの各行が「いつ」「誰によって」変更されたかを表示する rev-parse - SHA-1ハッシュやブランチ名など、Git内部で使われる情報を取得する filter-branch - 過去の履歴から特定のファイルを完全に削除する(破壊的変更のため、注意！)

Slide 79

Slide 79 text

© DMM.com ブランチの命名 ● 英単語2〜4単語くらいで概要を書いておく ○ 変更内容がわかりやすくなる ● チームの運用によって柔軟に変える ○ 例： ■ ■ イシュートラッカーのチケット番号をプレフィックス

Slide 80

Slide 80 text

© DMM.com Git Flowの説明 ● 複数のブランチを使い分けて、複雑な開発プロセスを整理するための運用モデル ● 主なブランチ ○ main - 本番環境 ○ develop - 開発環境 ○ feature - 新規機能開発 ○ release - リリース準備 ○ hotfix - 緊急のバグ修正

Slide 81

Slide 81 text

© DMM.com Git Flowの利点と欠点 ● 利点 ○ 複雑なプロジェクト管理に強い ■ 複数のブランチが役割ごとに分かれているため、並行開発がしやすい。 ■ リリース準備や緊急対応がしやすい。 ○ 安定性 ■ 本番環境に影響を与えずに開発が進行可能。 ● 欠点 ○ 小規模プロジェクトでは冗長 ■ ブランチが多すぎると管理が煩雑になる。

Slide 82

Slide 82 text

© DMM.com GitHub Flowの説明 ● mainブランチを中心としたシンプルなブランチ運用モデル ● 小〜中規模プロジェクトに適している ● 主なブランチ ○ main - 常時デプロイ可能 ○ feature - 新規機能・修正

Slide 83

Slide 83 text

© DMM.com GitHub Flowの利点と欠点 ● 利点 ○ シンプル ■ mainとfeatureブランチのみで運用可能 ○ 履歴が見やすい ■ マージコミットが簡潔で、履歴が見やすい ● 欠点 ○ 大規模プロジェクトには不向き ■ リリースの調整が必要なプロジェクトでは管理が難しい ○ 複数環境の対応が困難 ■ 開発環境、ステージング環境、本番環境などがある場合は工夫が必要

Slide 84

Slide 84 text

© DMM.com ハッカソン参加の心構え

Slide 85

Slide 85 text

© DMM.com 一番重要なこと • 開発を楽しむ 優勝することに囚われすぎないでほしい 優勝することに囚われすぎて、技術をおろそかにして発表だけ凝るのはハッ カソンに参加する意義が薄くなる

Slide 86

Slide 86 text

© DMM.com ハッカソンを円滑に進めるコツ • 開発に取り組む前に方針をちゃんと立ててそれに従う • Gitのブランチの運用 • レビュー、マージをどうするか • タスクを細かく分解する • 細かく分解すると分担もしやすくなる • 暇な人がなるべく出ないように • タスクごとに難易度も設定するとやりやすくなる • 進捗確認を定期的にする • 今やっていることを定期的に話し合うことにより、仕様などの認識のズレなどに も気づくことができる