7
1

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 3 years have passed since last update.

Sourcetree で簡単に使うGitHub

Last updated at Posted at 2020-06-22

対象

  • プロジェクトにアサインされたので、最速でGitHubの基本的な使い方を取得したい人
  • コマンドを使わずにGitを扱いたい人

環境

- バージョン
OS macOS Catalina
Git 2.24.3 (Apple Git-128)
Sourcetree 4.0.1(234)

セットアップ

Git

  1. インストール

    Mac を使っている場合は Xcode に付属している Git を使うのが無難でしょう。
    ※ Xcodeをインストール後に一度起動して、付属ツール(Command Line Tool for Xcode)のインストールをしましょう。
    それ以外の環境の方は Git - Downloads から Git を導入してください。

  2. コマンドの使用に不安がある方は以降はスキップして、Sourcetreeから続けてください。

  3. Git ユーザー名の設定

    以下のユーザー名を使いたいユーザー名に変更する。

    $ git config --global user.name "ユーザー名"
    
  4. Git コミットメールアドレスの設定

    以下のコミットメールアドレスを使いたいメールアドレスに変更する。
    ※GitHub で設定しているメールアドレスと同一になっている必要があります。

    $ git config --global user.email "コミットメールアドレス"
    

Sourcetree

  1. インストール

    1. Sourcetreeより、Sourcetreeアプリをダウンロードしてください。
    2. 初回のセットアップをします。
      • Bitbucketのアカウント作成は無視して「続行」できます。
      • gitコマンドを使って Git のユーザー名・コミットメールアドレスを設定してない方はここで設定できます。
  2. 環境設定からユーザー名とコミットメールアドレスを確認しておきましょう。
    スクリーンショット 2020-06-20 15.11.27.png

  3. GitHubアカウントと紐付けます。

    1. アカウントタブから「追加」します。
    スクリーンショット 2020-06-20 15.14.18.png
    1. GitHubアカウントと紐付けます。
    スクリーンショット 2020-06-20 15.18.46.png
    項目 選択肢 説明
    ホスト Bitbucket, GitHub, GitLab, etc. GitHubを選択します。
    認証タイプ Basic, OAuth Basic: GitHubのユーザー名とパスワードを入力できます。
    OAuth: 「アカウントを接続」から、GitHubで認証できます。
    プロトコル HTTPS, SSH GitHubでSSH接続の設定を行っていない場合は、HTTPSを選択します。

リポジトリのクローン

  1. GitHub のリポジトリから URL をコピーします。
    ※GitHubでSSH接続の設定を行っていない場合は、右上にある "Use HTTPS" を使用してください。
スクリーンショット 2020-06-20 16.16.19.png
  1. Sourcetree でコピーした URL を使ってリポジトリをクローンします。

    1. 新規... > URLからクローンを選択します。
    スクリーンショット 2020-06-20 16.14.38.png
    1. ソース URL を埋めると他の項目も自動で埋まります。
    スクリーンショット 2020-06-20 16.26.23.png
  2. クローンが完了すると、そのリポジトリのウィンドウが表示されます。
    スクリーンショット 2020-06-20 16.33.25.png

ワークフロー

会社やチームごとにGitブランチのワークフローが決められています。
今回は、以下の2つのワークフローを紹介します。

  • git-flow
  • GitHub flow

ワークフローが必要な理由

もし、あなたが一人で開発を行っている場合には、ワークフローは必要ないかもしれません。
例えば、ずっと master ブランチで作業していても、さほど問題は生じないでしょう。
なぜなら、コードは唯一の開発者であるあなた自身が把握しているからです。

しかし、複数人のチームで開発を行っている場合には、複数の機能追加が同時並行で進みます。
あなたが充分に把握していないコードが混入することになります。
その結果、一つのブランチだけで作業していると、以下のような問題が生じる可能性があります。

  • 他メンバーが作業中の未完成コードが混入する。
  • 充分にテストされていないコードが混入する。
  • 本番環境で重大なバグを発見したが、作業中のコードがあるため修正をリリースできない。

こういった問題を回避するために、Git のブランチを使った運用ルールが必要になります。
ワークフローはこの運用ルールを実現するためにあります。

git-flow

git-flow は Vincent Driessen氏のA successful Git branching modelを基にしたフローです。
git-flow は後に紹介するGitHub flowと比べると、大規模で複雑です。
よりシンプルなワークフローが適している場合もありますが、既存のプロジェクトに参画する際にはそこで使われているワークフローを知っておく必要があるので紹介します。
ここでは、GitHubで行うべきことも追記してあります。

フロー

メインブランチ

名称 説明
master1 本番環境に対応しているブランチです。
develop 次のリリースに向けた最新の変更が反映されたブランチです。
main-branches@2x.png

サポートブランチ

名称 説明 分岐元 マージ先 命名
feature 新しい機能を開発するためのブランチです。 develop develop feature/ブランチ名
release 新しいリリースを作成するためのブランチです。 develop develop と master release/ブランチ名
hotfix 本番環境で発生した重大なバグを修正するためのブランチです。 master develop と master hotfix/ブランチ名

feature

feature ブランチは新しい機能の作業を始めるときに使います。

  1. feature ブランチは develop からブランチします。
  2. feature ブランチは で新しい機能の開発を行います。
  3. GitHub に Pull Request を作成し、新しい機能や変更について議論をしたり、レビューの依頼をします。
  4. 機能が完成したときは、feature ブランチを develop ブランチにマージします。
fb@2x.png

release

release ブランチは新しい本番リリースの準備をするときに使います。
新しい本番リリースのバージョン番号が割り当てられるのは、release ブランチが作成されるときです。

  1. release ブランチは develop からブランチします。
  2. relese ブランチには新しいバージョン番号の命名をします。例えば、release/1.1.0 などです。
  3. relese ブランチで新しいバージョンのリリース準備をします。内部のバージョン番号の修正や軽微なバグフィックスも含まれます。
  4. (必要な場合は)GitHub に Pull Request を作成し、レビューの依頼をします。
  5. リリースの準備が完了したら、release ブランチを master にマージします。
  6. 次に、master 上のコミットにバージョン番号のタグをつけます。
  7. 最後に、release ブランチを develop にマージします。
スクリーンショット 2020-06-21 16.58.27.png

hotfix

hotfix ブランチは本番環境で発生した重大なバグをすぐに解決しなければならない場合に使います。

  1. hotfix ブランチは master からブランチします。
  2. hotfix ブランチでバグの修正を行います。(バージョン番号をインクリメントするのを忘れないようにしましょう)
  3. (必要な場合は)GitHub に Pull Request を作成し、レビューの依頼をします。
  4. バグの修正が完了したら、hotfix ブランチを master にマージします。
  5. 次に、master 上のコミットに新しいバージョン番号のタグをつけます。
  6. 最後に、hotfix ブランチを develop にマージします。(今回のバグフィックスが今後のリリースにも含まれるようにするためです。)
hotfix-branches@2x.png

引用

A successful Git branching model

GitHub flow

GitHub flow はシンプルです。git-flow に比べると命名規則も緩やかです。

ルール

マスターブランチにあるものは常にデプロイできる

フロー

ブランチの作成

機能追加や変更を行う際には、 master から新しいブランチを作成します。
ブランチ名は説明的なものにします。(例えば add-authentication,refactor-authentication-controller など)

スクリーンショット 2020-06-21 18.52.14.png

変更の開始

新しく作成したブランチで変更を開始します。
あなたが何をしたのか、なぜしたのかを理解できるようなコミットメッセージを書くことを推奨しています。

スクリーンショット 2020-06-21 18.52.09.png

Pull Request の作成

新しいブランチの Pull Request を GitHub で作成します。

スクリーンショット 2020-06-21 18.53.28.png

コードについて議論し、レビューする

Pull Requset を使って、コードについての議論やレビューをします。
フィードバックを得て、コードに変更を追加することもできます。

スクリーンショット 2020-06-21 18.53.32.png

デプロイ

master にマージする前に、本番環境やテスト環境にデプロイして最終テストをします。
もし、問題を発見したら、既存の master をでブロイしてロールバックすることができます。

スクリーンショット 2020-06-21 18.53.51.png

マージ

本番環境での変更が確認できたので、master にブランチをマージします。

スクリーンショット 2020-06-21 18.54.04.png

引用

Understanding the GitHub flow

Sourcetree で git-flow

Sourcetree を使うと、簡単にgit-flowを導入することができます。

  1. masterという名称は差別的な意味を含んでいるため、変更する動きもあります。
    blacklist/whitelist master/slave に関する情報集め
    Change the default branch from "master" to something else #929

7
1
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
7
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?