259
Help us understand the problem. What are the problem?

More than 5 years have passed since last update.

posted at

Organization

Gitブランチについての基本まとめ

ブランチとは

作業履歴を枝分かれさせて記録していくためのもの。

使うと何がいいのか?

  • 他のブランチの影響を受けないため複数の作業を同時に進められる
  • 作業単位で履歴を残すことで後で見た時にわかりやすい

つまり、複数人で開発するときにはそれぞれが他の作業者の影響を受けずに進められるし、ひとりで開発する場合でも作業履歴を綺麗に管理しておけるので使用した方がいい。

ブランチの運用

統合ブランチ

リリース版がいつでも作成可能なようにしておくためのブランチ。
なので、常に安定した状態を保っておくことが重要。
通常、masterブランチを統合ブランチとする。

トピックブランチ

機能追加やバグ修正といったある課題に関する作業を行うためのブランチ。
安定した統合ブランチから分岐する形で作成し、作業が完了したら統合ブランチに取り込むという使い方をする。

ブランチの切り替え

ブランチを切り替えるにはチェックアウトという操作を行う。
チェックアウトすると移動先の最終コミット内容にバージョンが変わる。

まだコミットしていない内容があるのにチェックアウトした場合

変更内容がチェックアウトしたブランチに移動する。
競合する場合はチェックアウトに失敗する。
そのような場合はスタッシュをして変更内容を退避させてからチェックアウトする。

ブランチの統合

ブランチの統合にはマージとリベースの2つがある。

マージ

マージは統合ブランチにチェックアウトしている状態で、トピックブランチをマージするという手順で行う。
トピックブランチが統合ブランチから分岐した状態から統合ブランチが編集されていなければ普通にマージされるだけで完了する。これを早送りマージという。
もし、統合ブランチが編集されていればそれぞれを統合した新たなコミットが統合ブランチで行われる。

リベース

リベース元の履歴がリベース先のブランチの後ろに追加される形で一本化される。

マージとリベースは例えば下記のように使い分ける

  • トピックブランチに統合ブランチの最新のコードを取り込む場合はrebaseを使う
  • 統合ブランチにトピックブランチを取り込む場合は、まずrebaseしてからmerge

ブランチの名前づけ

master

  • リリース可能な状態だけを管理する
  • 特定のブランチからマージすることによってしか更新されない
  • 直接コミットしてはならないという制約をもつ
  • バージョンごとのtagはここから生まれる

develop/[バージョン番号など]

  • 先のリリースに向けた普段の開発で使用する
  • 後述のfeatureやreleaseブランチはここから派生

feature/[派生元バージョン番号など]/[機能名など]

  • 機能追加・改修などを行う作業ブランチ
  • developブランチから、featureブランチを切る
  • 完了後はdevelopブランチにマージされて、featureブランチは削除される

その他

  • release/[バージョン番号]
  • fix/[バージョン番号]/[バグ識別名]
  • support/[バージョン番号]
  • hotfix/[バージョン番号]/[バグ識別名] or hotfix/[バグ識別名]

参考URL

サルでもわかるGit入門
ぼくが実際に運用していたGitブランチモデルについて

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Sign upLogin
259
Help us understand the problem. What are the problem?