気まま赴くままに。デザインからプログラミングまでをたまにまとめてます。

その他

【GitHub】使用例は仮定で説明してみる

前回の記事「GitとGitHubの違いと使い方」では

個人でプロジェクトを作る際のGitHubで公開する方法に触れました。

今回は複数人でのプロジェクト作成方法を仮定で説明してみます。

スポンサーリンク



目次

組織の作成

今回はA君B君C君の三人で簡単なサイトを作成することになりました。

A君「今回は3人でやることになったからまずは組織を作る、と。」

組織とは

Organization。グループで作る際に用いる。
無課金だとプライベート(非公開)使用は不可だが、
公開前提でならグループでのリポジトリ管理が楽になる。

組織の作り方

Githubから作成することになる。

先ずはログイン

右上の+アイコンからNew organizationを選択。

以下のような画面になるが、今回は一番左の無料のもので進める。

ちなむと大体の違いは以下のようなものになっている。

Choose Team for Open Sourceをクリックすると組織名などを決めるページになります。

Contact email:組織の連絡先

This organization belongsはこの組織は―

My personal accountで個人

今回は組織名をteam uinoeにしてみた。

Search by username, full name or email address でユーザー名かメールアドレスを用いてメンバーを追加することが出来る。

Learn more about permissions for organizations は権限についての説明ページに飛ぶ。

今回B君やC君を追加するがとりあえず仮定なのでここはSkip this stepをクリック。

今後は以下の画面で組織を管理することになる。

最初のページに戻ったとしても、以下の作業で組織のトップページに戻ることが出来る。

左側のユーザ名→チーム名
View organizationをクリック

リポジトリの作成

A君「組織を作って、メンバーの招待も完了した!次はリポジトリを作ろう!」

各メンバーはバージョン管理情報をこのリポジトリにプッシュしていくことになります。

先程の画面から Repositories Newをクリック
今回はteam_testというリポジトリにしてみた。
組織のリポジトリ(リモートリポジトリ)へのプッシュ方法の画面になる。

基本的に各メンバーには個々に

イニット(ローカルリポジトリ)

アドコミ

をしてもらった後に

プッシュ(リモートリポジトリ)

してもらうことになる。

ディレクトリ構成

個々のメンバーに作業をしてもらう際、一応こんな構成が良いのかなぁという構成を紹介。※ローカルのディレクトリです。

前回の構成の様に、

作業ディレクトリgit > プロジェクトフォルダ

プロジェクトフォルダ以下でプログラムをカキカキしていきます。

してアドコミプッシュ。

ブランチの作成


A君「組織のリポジトリは作ったし、3つブランチ作っておけばいいかな」

ブランチとは

履歴の分岐。
これまで使っていたターミナルにちょくちょく「master」と書かれていました。
前回では個人だったので触れていませんでしたが、グループでの制作となると同じ履歴をぐちゃぐちゃするのは好ましくありません。
※勿論個人でもブランチ作成は可能です。

GitHubでは「ブランチ」を用いて履歴を括ることが出来るのです。

A君は自分とB君、C君の三人別々のブランチで作業したいのですね。

ここはα世界線。

君のはβ世界線だ!!
 
masterブランチというのは初回コミット(プッシュ)時に自動的に作られる「主となるブランチ」。
基本的にはいじらず、他のブランチ(サブブランチ)を作って個々に「統合してくれ」ってリクエストを行わせるわけです。
 
このリクエストの事を「プルリクエスト」と言います。
後々説明しますが、とりあえずブランチの作り方から説明していきます。

ブランチの作り方

現段階では初回コミット(プッシュ)が済んでいない為、masterブランチ自体作成されていません。この状態だとサブブランチの作成は出来ないみたいです。

子奴はリモートリポジトリなので、プッシュすればmasterブランチが作成されますね。

まずはプッシュからしてみましょう。
プッシュとはローカルリポジトリからリモートリポジトリアアアアアアアアアアアに突っ込む作業でした。

前回の記事で

uinonフォルダを用いたローカルリポジトリ

を作っていたのでこれをプッシュしてみます。

…or push an existing repository from the command line を実行していきます。
プッシュするまでにやったこと

これでmasterブランチが作成されました。

次はサブブランチを作っていきます。

View organizationから
組織トップページ。リポジトリ名をクリックし、
masterブランチの中身が表示されます。

Branch: masterというところをクリック。
Find or create branch… とありますので、今回はsub1を作ってみましょう。

Create a branch または Enter で作成。

sub1のブランチができました。

中身はmasterのものになっていますが、変更を加えれば別々のものになるはずです。

これに変更を加え、プルリクエストをしていくわけです。

ついでにsub2ブランチも作っておきましょう。

ブランチの動作確認

ブランチごとに違ったものが出来るのか確認してみます。

sub1のtest.txtをクリック。
鉛筆マーク、 Edit this file

本来Bashからプッシュしてあげますが今回テストですし面倒なのでGithubから変更を加えちゃいます。

内容を変えて Commit changes

内容を適当に変更し、コミットさせます。

ちなみに

Github上から変更を加えているので「コミット」になっています。

画像下のCommit changes はコミットコメント。

Commit directly to the sub1 branch. でブランチに直接コミット。
Create a new branch for this commit and start a pull request. は新たなブランチを作成してコミット。その上でプルリクエストもする。

team_testのトップに戻る(masterブランチ)と、Your recently pushed branches:sub1と、黄色くなっていると思います。

最近プッシュされたものが表示されています。
masterの内容はtest2のままで、sub1の内容が違っていれば完了です。

プルリクエスト

A君「ブランチはmasterとsub1、sub2でいいかな。sub1に変更を加えたからmasterに加えてみよう。」

A君はsub1ブランチの内容をmasterブランチに加えたい様です。

プルリクエストの出番ですね。

プルリクエストとは

組織にはOwnerやMemberといった役割があり、
プルリクエストはOwnerに対して「masterブランチに結合を依頼する」
事が出来ます。

team-uinoe は自ら作成した組織なので自分がOwnerになっています。
この役割に関しては組織のトップページから確認できます。

今回は例として昔使っていた組織を使わせてもらいます。

右下のPeople。他メンバーのアイコンをクリックしてみます。
RoleはMemberになっていますが、クリックで変更可能です。

プルリクエストの仕方

sub1からmasterにプルリクエストしてみます。

まずはsub1ブランチに移動してNew pull request
プルリクエストの画面になりました。

これもコミットコメントの様なもので、これこれこう変更したからこうしてほしいなどの要望を書き込んでおきます。

今回は何も書かずにCreate pull request

リポジトリページのプルリクエストタブ

全部自分なので分かりづらいですが、
test.txt更新したよってコメントが来ています。

Cconversationはプルリクエストについてコメントし合えるページとなっています。

This branch has no conflicts with the base branch
→「ベースブランチと競合しませんよー」とのことですが、どういった変更があったのか、Ownerはちゃんと確認してからマージしなくてはなりません。

リクエストファイルの確認

マージをする前に何処に変更があったのか確認してみます。

uinoe wants to merge 1 commit into master from sub1
→uinoeさんがmasterにsub1のコミットをマージしてほしいですって。

コードの赤い部分がmasterの部分。

緑色の部分がsub1。
左に1と書いてあるので1行目のsub1 branth edit test.のみってことですね。

マージの仕方

組織のリポジトリ>Pull requests

マージするリクエストからMerge pull request をクリック。

Confirm merge をクリックします。

この様な画面になると思う。

merged commit ~ into master
Pull request successfully merged and closed となっていれば完了。

続いてきちんとマージされているか確認してみよう。

ちなみに
Delete branch をクリックすると任意のブランチが削除される。

きちんとsub1の内容に変更されていました。

ちなみに

今回はファイル名が同じものをマージしたので上書きという形になっています。

別のファイル名のものをマージした場合は、それぞれのファイルが保持されます。複数名での利用に適していますね。

プルはコミット履歴としても残っており、
リポジトリのトップページからCommits を選択することで見れます。

リポジトリトップ。既に3コミット入っている。見てみよう。

Merge pull request #1 from team-uinoe/sub1 でプルリクエストからのコミット、つまりマージだという事がわかると思います。

それぞれのコミットの右側に表示されている値をクリックすることでその時のコード内容を確認することもできます。

ちなみに

コミット履歴はmasterブランチのもののみだという事に気付かれた人もいるはず。

つまり、sub1のブランチで行っていたコミット履歴も、masterブランチの画面で見たいという場合。(sub1ブランチの画面から見ることもできますが、ブランチが多くなるのが嫌な方は削除してしまうはず。)

その場合はマージする際のMerge pull request ボタンの横の矢印をクリックし、Squash the commits into one commit というものを選択すればOKです。

まとめ

ここまででチームで利用する際の基本的な使い方は紹介できたと思います。

オーナーがリポジトリやブランチを作り、メンバーにプルリクエストをしてもらう形ですね。

GitHubには他にも話し合える場所やチーム(組織の中に作れるグループ)、フォーク等の概念が沢山あります。

大規模な開発をする際にはとても助かりますし、サービスを最大限生かすことで会社の負担を大幅に軽減できます。

又、前回の記事ではローカルリポジトリをコマンドライン上から使用しました。

今回紹介した「ブランチ」や「マージ」はローカルリポジトリ、
つまりコマンドライン上でも行えます。

個人で開発する際にもブランチを活用してみてくださいね。

-その他
-

関連記事

【GitHub】GitとGitHubの違いと使い方

今回もデザインというよりかは少々開発者向けの記事になってしまいますが。。 バージョン管理ツールとして有名なGit。 今回はGitのシェルであるGit Bashからコマンドラインを用いてGithubで共 …

カバー・アイキャッチ画像8

二子玉川 お散歩。

転職活動に向け紙面フォリオを作成。 続けてUnityやblender、StudioOneとかいじりだして。 独自ドメインへの移行をどうしようか悩み過ぎた結果、 ブログの更新が完全に止まっていた。。 気 …


uinosuke-tema

宇井野助

基本独学。趣の人。

ブログの更新はあれこれやってるうちに
気分で書く感じです(‘ω’)

 

スポンサーリンク