アメリカの大学で奮闘中

アメリカの大学でプログラミングを学ぶべくコンピューターサイエンス学部に留学したものの挫折し数学科に転部した著者が、自分の挫折ポイントを踏まえて数学、プログラミング、アルゴリズムついてできる限り分かりやすく解説してみるブログ。*できる限り記事の内容は技術的な間違いをしないように気をつけていますが、もし間違いがあれば教えていただけると助かります。

GitHubの使い方を超簡単に解説してみた〜チーム開発編〜

 

astrostory.hatenablog.com

こちらの記事の続きになります。

 

 

イメージして欲しいのですが、

自分がレポジトリからプログラムを落として、修正をしてGitHubにアップしている間、他のチームメンバーも同じように開発を行い修正をしてGitHubにアップしていきます。

 

これの何が問題かと言いますと、

自分が過去にレポジトリから落としたプログラムは、今GitHubにストックされているプログラムと一緒とは限らはないのです。

 

自分は落としてきたプログラムを前提に修正点や追加機能を作る訳ですから、その前提となっていたプログラムが途中で変わってしまうと何かしらの影響が出る可能性があります。

 

また、この問題は他のチームメンバーも同じです。自分の修正点が原因となって他の人のプログラムが動かなくなるかもしれません。

 

この問題の影響を少なくする方法を知ることがチーム開発では重要なのです。

 

ソフト面でできること

・できる限りチームメンバーが修正するエリアを被らないようにする

・チーム内でどんな開発をしているかを共有する

・何か影響範囲の大きい修正する場合は事前に共有して許可をもらう

 

GitHubの機能を使ってできること

開発前に常にコードは最新にしておく

$git pull origin main

このコマンドを実行すると、すでに落としたプログラムから最新のGitHubのレポジトリ内のコードの差分をダウンロードしてくれます。結果、GitHubの最新のコードとローカルファイルが同じものになります。

 

例えば

git clone時のローカルファイル

a = 34 num = a

 

GitHUbの最新のコード

a = 34 b = 5 num = a + b

 

以下のコードが追加、変更されGitHubの最新のコードとローカルファイルが同じものになります。

b = 5 num = a + b

 

 

自分の修正をmainに入れない

毎回、チームメンバーみんなが開発する前にコードをGitHubのmainブランチの最新バージョンを落とすため、できる限り問題のあるコードはmainに入らないようにするべきです。

 

そのために前回扱った、以下のコマンドの前後に工夫をして上記の問題をないようにしましょう。

git add <入れたいファイル> git commit -m "" git push origin main

 

具体的には、mainブランチではない、自分のブランチを作って、そのブランチの修正点が問題ないかを他のチームメンバーを確認してもらってからマージしてもらいます

 

ブランチとは、枝、支部、支流の意味で、mainを大元にして自分の修正バージョンを枝のように作成することができます。

 

そのコマンドが以下です。

git checkout -b <ブランチ名>

 

全体的な流れとしては、何か新しい開発を行う前に

 

コードを最新にする

git pull origin main

 

新しくブランチを作成

git chheckout -b <ブランチ名>

 

git add <入れたいファイル>

 

git commit -m ""

 

先っほど作成したブランチでGitHubにPush

git push origin <新しく作成したブランチ名>

 

ここまで終わるとGitHubのWEBページに行きます。

 

 

Pushしたレポジトリの「Pull requests」をクリックして、どのブランチからどのブランチ(おそらくmain)に追加を希望するかの情報を入れて、レビュアーに回します。