Agile育成ブログ
未来を変える喜びを
GitHub

GitHub

  /

共同開発を行う際に自分の書いたコードをほかの人に共有する必要があります。
そんな時に使うのがGitです。
ターミナルはMacに備わっているCUI（キャラクターユーザーインターフェース）ツールです。

Git Hubインストール

https://www.agile-software.site/2021/04/24/vs-code%e3%81%ae%e8%a8%ad%e5%ae%9a/

共有したいファイルの選択

$ git add ファイル名

選択したファイルを記録する(コミットする)

$ git commit -m "コミットメッセージ"

共有の仕組み

ファイルのアップロード

$git push origin master

すでにリモートリポジトリがある場合

VSCodeにおけるターミナルでコマンドを入力します。

ファイルを新しいローカルリポジトリに追加します。
git add .
GitHub リポジトリの Quick Setup ページの上部で、 をクリックしてリモートリポジトリの URL をコピーします。
コマンドプロンプトで、ローカルリポジトリのプッシュ先となるリモートリポジトリの URL を追加します。
$ git remote add  [追加するリモートリポジトリ名]   [追加したいリポジトリ]
# 新しいリモートを設定する
[追加するリモートリポジトリ名] にorigin、[追加したいリポジトリ]に<リモートリポジトリのURL
(http://xxxxxx.xxx/xxxx)>を指定することでリモートリポジトリを登録できる 
$ git remote -v
# リモートリポジトリを一覧表示する
GitHub へ、ローカルリポジトリの変更をプッシュします。
git push origin main

「git clone」

git cloneとは、既存のリポジトリをローカル環境に複製するコマンドのことです。

git clone [リポジトリパス]

URLを変更する

git remote set-url origin [変更先のURL]

ファイルのダウンロード

$ git pull origin master

自分が変更したファイルの確認

どのファイルをaddしてどのファイルがaddされていないのかも確認することができます

git status

変更した部分を確認

git diff

ローカルに登録してあるリモートリポジトリを削除

git remote remove　origin

自分や他人のコミットを確認

過去のコミットの変更はgit log
変更内容まで見たいときはgit log -p

git log

ブランチとは

ブランチを使用することで、開発者は異なる機能やバグ修正を独立して行うことができ、メインのコードベースに影響を与えることなく作業を進めることができます。
ブランチとは、履歴の流れを分岐して記録していくためのものです。分岐したブランチは他のブランチの影響を受けないため、同じリポジトリ中で複数の変更を同時に進めていくことができます。

また、分岐したブランチは他のブランチと合流(マージ)することで、一つのブランチにまとめ直すことが出来ます。

  • メインブランチ（多くの場合「main」または「master」と呼ばれる）から新しいブランチを作成し、そこで機能追加やバグ修正を行います。
  • 主要なブランチの種類:
    • main（またはmaster）: 常にデプロイ可能な状態を保つブランチ。
    • develop: 次のリリースに向けた開発が行われるブランチ。
    • feature: 新しい機能を追加するためのブランチ。
    • release: リリース前の最終調整やバグ修正を行うブランチ。
    • hotfix: 本番環境で発見されたバグを修正するためのブランチ。

2. ブランチの作成と管理

  • ブランチの作成: 新しいブランチは、コマンドラインで以下のように作成します。
git branch <branch-name>
  • プルリクエスト（PR）: 開発が完了したら、変更をメインブランチに統合するためにプルリクエストを作成します。これにより、他の開発者が変更をレビューし、問題がなければマージすることができます。
  • マージ: プルリクエストが承認されると、変更がメインブランチに統合されます。マージ後は、作業が完了したブランチを削除することが推奨されます。

マージンコンフリクト

マージンコンフリクトは競合するコミットを持つブランチをマージしようとしたときに生じるもので

pull

pullを実行するとリモートリポジトリの履歴を取得することができます。

fetch

fetchを実行すると、リモートリポジトリの最新情報をローカルリポジトリに持ってくることができます。

push

ローカルリポジトリからリモートリポジトリにpushするときは、pushしたブランチがfast-forwardマージされるようにしておく必要があります。もし、競合が発生するような場合は、pushが拒否されます。

https://www.agile-software.site/2021/04/24/github%e7%94%a8%e8%aa%9e%e9%9b%86/

GitHub関連サイト

最初のコミットを保護しつつ、新しいブランチを作成して開発を進める方法を説明します。また、間違いが発生した場合に最初のコミットに戻る手順も解説します。

1. 最初のコミットを確認

現在の状態を確認して、最初のコミットのハッシュ値を取得します。

git log --oneline

2. 新しいブランチを作成

新しいブランチを作成して切り替えます。

git checkout -b 新しいブランチ名

3. 開発作業を進める

新しいブランチで自由に作業を進めてください。

ファイルを編集してコミットする例:

echo "New feature" > new-feature.txt
git add new-feature.txt
git commit -m "Add new feature"

フォーク(fork)

fork は他の開発者のリポジトリを github上でclone(クローン）します。

クローン(clone)

クローンとはリモートリポジトリを手元のマシンの指定した場所に複製します。

プッシュ(push)

ローカルリポジトリの内容をリモートリポジトリに反映させます。

リモートリポジトリ

サーバなど自分のPC以外のネットワーク上にあるリポジトリのこと。

コミット(commit)

追加・変更したファイルをリポジトリに記録します。

プル(pull)

リモートリポジトリのコミットをローカルリポジトリに送り込みます。

1. Issue（イシュー）とは？

一言でいうと、「やるべきことの掲示板」です。コードを書く前段階の相談や、見つけた不具合の報告に使います。

  • 役割: 課題の管理、タスクの整理。
  • 主な用途:
    • バグ報告: 「ここのボタンが動きません」という報告。
    • 新機能の提案: 「こんな機能があったら便利じゃない？」というアイデア。
    • タスク管理: 「〇〇のドキュメントを作成する」といったToDo。
  • 特徴:
    • 誰が担当するか（Assignees）を決められる。
    • ラベル（Label）を貼って、「重要」「バグ」などの分類ができる。
    • マイルストーンを設定して、期限を管理できる。

2. Pull Request（プルリクエスト）とは？

一言でいうと、「コードの変更を合流させてほしいというリクエスト」です。

  • 役割: コードレビューと、メインブランチへの合流（マージ）。
  • 主な用途:
    • 自分が書いたコードを他のメンバーにチェックしてもらう。
    • 修正内容を記録に残す。
  • 特徴:
    • 差分の表示: どのファイルの、どの行が、どう変わったか（Diff）が一目でわかる。
    • レビュー機能: 特定の行に対して「ここ、もっとこう書けませんか？」といったコメントをやり取りできる。
    • 自動テストとの連携: コードが正しいか、自動的にチェックを走らせることができる。

3. Issue と Pull Request の連携フロー

実際の開発では、これらをセットで使うのが一般的です。

  1. Issueを作成: 「ログイン画面のロゴを変えたい」という課題を立てる。
  2. 作業開始: そのIssueを解決するためのコードを書く（ブランチを切る）。
  3. Pull Requestを作成: 「ロゴを変えたので、確認してください」とリクエストを送る。
    • このとき、PRの説明欄に Closes #123（123はIssue番号）と書くと、PRが承認された瞬間にIssueも自動でクローズされるという便利な機能があります。
  4. レビュー & マージ: メンバーが承認（Approve）したら、コードがメインに合流（Merge）される。

1. Actions

一言でいうと、「作業を自動化するロボット」です。

  • 役割: CI/CD（継続的インテグレーション／継続的デプロイ）の実行。
  • 主な用途:
    • 自動テスト: コードをプッシュするたびに、エラーがないか自動でチェック。
    • 自動デプロイ: コードが完成（マージ）したら、自動的にAWSやAzureなどのサーバーへ公開。
    • 定期実行: 毎日決まった時間にスクレイピングやバックアップを行う。
  • 特徴: .github/workflows というフォルダにYAML形式の設定ファイルを置くだけで、自分専用の自動化パイプラインが作れます。

2. Wiki

一言でいうと、「プロジェクト専用の説明書」です。

  • 役割: 長文のドキュメントやマニュアルの管理。
  • 主な用途:
    • 環境構築手順: 新しいメンバーが開発に参加するためのセットアップ方法。
    • 設計思想: なぜこの技術を選んだのかという背景。
    • 用語集: プロジェクト内で使う独自の言葉の定義。
  • 特徴: Markdown形式で誰でも簡単に編集でき、IssueやPRとは独立した「独立したページ群」として情報を蓄積できます。

3. Security（セキュリティ）

一言でいうと、「コードの脆弱性を見張るガードマン」です。

  • 役割: リポジトリの安全性を高める機能の集約。
  • 主な機能:
    • Dependabot: 使っているライブラリに脆弱性が見つかった際、自動で「アップデートしてください」とプルリクエストを投げてくれます。
    • Secret scanning: パスワードやAPIキーを間違えてコードに書いてプッシュしてしまった場合、即座に検知して警告してくれます。
    • Code scanning: コードの中にバグやセキュリティの穴がないか静的に解析します。

4. Insights（インサイト）

一言でいうと、「プロジェクトの活動分析レポート」です。

  • 役割: 開発の「勢い」や「健康状態」をグラフで可視化。
  • 主な指標:
    • Contributors: 誰が一番コードを書いているか。
    • Commits: いつ、どのくらい作業が行われたかの頻度。
    • Network: ブランチの分かれ方や合流の履歴（グラフ表示）。
    • Dependency Graph: どのライブラリに依存しているかのツリー。
  • 特徴: 「最近開発が停滞していないか？」「特定のメンバーに作業が集中しすぎていないか？」といったマネジメント視点での確認に役立ちます。

5. Settings（セッティングス）

一言でいうと、「リポジトリの管理設定」です。

  • 役割: リポジトリの基本動作や権限の変更。
  • よく使う設定:
    • Collaborators: 誰に編集権限をあげるか。
    • Branches: メインブランチに「勝手にプッシュできないようにする（保護ルール）」の設定。
    • Pages: GitHub Pages（Webサイト公開機能）の設定。
    • Webhooks: GitHubで何かが起きた時に、Slackなどに通知を送る設定。
    • Danger Zone: リポジトリ名の変更や、リポジトリの削除。
RELATED POST