94
109

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

とりあえず周りと仕事ができるGitHub入門

Last updated at Posted at 2023-01-14

前置き

東大エンジニアリング研究会(ぜひ入ってね!)というサークルで、共同開発をやりたいという話になりました。しかしそこで、チームに開発初心者がたくさんいる中、とにかくプロジェクトの共有だけはできるようになってほしいけど、難易度が高い資料しか見つからない!自分で書くしかねえ!と思い至った記事です。

というわけで、このような読者を想定しています。
・チームで「GitHubで共有します」と言われたけど操作むずくてわからない!厳密性はどうでもいいからとりあえず仕事はできるようになりたい!
・学生の共同開発でGitHubを使わせたいが、初心者に何見させばいいか分からない!厳密性はどうでもいいから共有だけはしたい!

そう、厳密性をガン無視し、ただただ素早く仕事に参戦するための記事ですので、玄人エンジニアの皆さまからするとかなりメチャクチャですが、お許しください^^

なぜ初心者にもGitHubを使わせようとするのか

プロジェクトの共有ができる

GitHubはオンラインストレージサービスですからね
GitHub使う動機の5割がこれだと思います。
しかし、これだけではGoogleDriveとかSharePointでもいいのでは?
Gitは天才なので、ユーザーAの編集内容とユーザーBの編集内容を機械的に統合してくれます!つまり「俺が今から編集するからあんたはそこなんもやらんといて!」とか言わなくていいんですね。

バックアップがとれる

動機の3割がこれです。
コーディングしていると(特に初心者はと言いたいところですが、玄人もそうでしょう)、バグを必ず引き起こすことでしょう。
そこで、GitHubは更新されるごとの状態を保存しているので、すぐにバグが発生した直前まで戻れます。
後述するブランチも使えたら、この特徴がより発揮されるでしょう。

犯人探しができる

動機の2割がこれです。(玄人様にとってはこれが最重要かもしれませんが)
Gitを使用していると、コードのどこを編集したのか、差分を確認することができます。
image.png
なので、バグを起こしたとしても、どこの編集でバグを起こしたのかを確認でき、バグ潰しがラクになります。
もちろん、コード上の犯人捜しはもちろん、誰がバグらせたかも知ることができますね

とりあえず使おう!

御託は置いておいてとりあえず使いましょう。

最初にやること

GitHubのアカウント作成

作成してください:https://GitHub.com

Gitのインストール

GitHubではなくGitのインストールです

GitHubのアカウント作成

こちらの指示に従って、GitHubのユーザー名とメアドの登録まで済ましてください:https://www.sejuku.net/blog/73444

GitをGitHubにログインさせる。

2023/11/13
ここの情報が古くなっている可能性があります。
OSや環境によってかなり異なります

まずは、GitがGitHubにアクセスするためのトークン(暗証番号みたいなもの)を発行する必要があります。
このサイトの指示に従ってください:https://capybara-notebook.com/GitHub_accesstoken/
一つ注意としては、トークンの種類が増えましたけど、「Classic」を選べば大丈夫です。得られたトークンは絶対メモりましょう。
58B8B695-0498-4624-8133-2A7A0CD55582.jpeg
このトークンには有効期限が存在しますが、もし再発行がめんどくさかったら「No expiration」があります。(セキュリティ面からはあまりオススメされていませんが)
Gitを操作していて、パスワードを求められたら、このトークンを入力してください。(おそらくpushの段階で求められます)

ケース別対策

プロジェクト共有のための手順をケース別に見ていきましょう。
以下に出てくるコマンドは、windowsならコマンドプロンプト、macならターミナルに入力してください。
出し方はググってください。

それと、「フォルダーのパス」と言われてもわからない人はそれもググってください。

他人のGitHubを自分のパソコンに引っ張って来たい

正確にはGitHubのことをリモート、自分のパソコンのことをローカルというのですが、新しい用語は初心者を混乱させるだけなので平易な呼び方をしています。

他人のGitHubにあるプロジェクトをダウンロードしてくるには、Cloneをします。

まずは、ダウンロードしたいフォルダーまで移動

cd [ダウンロードしたいフォルダー]

そしてダウンロード

git clone [GitHubのURL]

GitHubのURLは、プロジェクトのトップページのURLをコピーすれば大丈夫です。

image.png

自分でGitHubでプロジェクトを作成する。

GitHub上のプロジェクトのことをレポジトリといいます。
GitHubで自分のプロフィールページを見て、「Repositories」のタブを引くと「New」が出てきますのでクリック。
image.png

新規レポジトリの設定画面ですが、
レポジトリ名公開設定だけ設定すればいいです。
レポジトリ名は短くわかりやすいものを、公開設定は世界中に見てほしいかどうかです。Web開発系だと乗っ取りを防ぐためにPrivateにすることが多いです。(Privateでも開発仲間がアクセスできるよう設定することができます)
image.png

Unity開発者は、Add .Gitignore.Gitignore templateのところで「Unity」と検索して登録してください。

このままではインターネット上にプロジェクトを作っただけで自分のパソコンには何も起きていないので、このプロジェクトをダウンロードしてくる必要があります。

これは上記「他人のGitHubを自分のパソコンに引っ張って来たい」と同じようにcloneしてください。

編集したファイルをアップロード(共有)したい(コミット・プッシュ)

(初心者向けに説明していますので、ここを読む玄人様は怒らないでください)

とりあえず編集したものをアップロードするには、こうします。
最初に

cd [プロジェクトのフォルダーのパス]

で、更新する度にこの3呪文を連続入力します。

git add *
git commit -m "[コミット名]"
git push origin [ブランチ名]

ブランチは現在作業しているブランチです。ブランチについては後述しますが、何もいじってないときはmainと入力。もしこれでエラーが出たらmasterと入力。

コミット名は、「更新内容」でして、他のユーザーが「どんな更新したんだろうなあ」と思ったときに見るものです。
よって、例えば戦車のクラスを追加したのなら「戦車のクラスを追加」とでも入れてください。

もし、error: failed to push some refs to…というエラーが出てきたのなら、先に誰かが更新している可能性が高いです。後述の「他人の更新をダウンロード」のpullをしてください。

更新する頻度に関しては、基本的に要素が一つできたらがいいと思います。
例えば戦車クラスを作っていて、移動機能ができたら1コミット、砲塔の旋回機能ができたら1コミット、射撃機能ができたら1コミット、といった具合ですね。

他人の更新をダウンロード

cd [プロジェクトのフォルダーのパス]
git pull origin [ブランチ名]

ブランチ名は作業中のブランチですが、ブランチについて何もいじってない場合はmainを入力。(エラー出たならmaster

もし自分が更新したファイルと他人が編集したファイルが重複していても、Gitが自動的に一つにまとめてくれます!(もしファイル内の編集箇所が重複していたらコンフリクトです。(整合作業が必要ですが、ベテランに頼むか、後述の「コンフリクトを直す」を見てください。)

ブランチを切る(本体を編集しないようにする)

エンジニア語に「ブランチを切る」という動詞があります。
ブランチとは何かについては、このサイトが分かりやすいです:https://backlog.com/ja/Git-tutorial/stepup/01/

要するに、機能を追加するときに、他人と競合が起きないように「自分だけの世界」を作っておいて、その世界内で実装してみるですね。

用途はたくさんあって

  • 新機能を追加するときにバグらせちゃっても本流(main / master)には影響のないようにしておく
  • ごっそり構造を変えてしまうときにバグらせないように本体を避難させておきたい
    というような場合があります。

本流のことをmain / masterブランチと呼びます(2020年にmasterからmainに変更されまして、呼称が混在しております)

main/masterブランチは「みんなが見るもの」ですから、試行錯誤は自分のブランチの中でして、バグのない清書をmain / masterに提出しましょう

ここではブランチを作り、作業ブランチを切り替える方法を見ます。

cd [プロジェクトのフォルダーのパス]
git checkout -b [新しいブランチ名]

自分のブランチAをブランチBに提出する

ブランチAでの作業が完了したときに、ブランチBに提出したい(統合したい)ときは、mergeすることです。

cd [プロジェクトのフォルダーのパス]
git checkout [ブランチB]
git merge --no-ff [ブランチA]

ここで編集箇所が重複していたらコンフリクトです。後述参照。

コンフリクトを直す

基本的にはベテランに頼んだ方がいいです。
このサイトを見てください:https://yoneHub.y10e.com/2021/02/05/Gitconflict/

コンフリクトが発生しているファイルが下記のように書き換えられ、

<<<<<<< Updated upstream
相手の更新
=======
自分の更新
>>>>>>> Stashed changes

これを丸ごと消して採用したい方のコードにします。

最後に

いいね頂けると泣きながら喜びます><

この記事を読んでいる方は次の記事も読んでいるかもしれません

94
109
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
94
109

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?