質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Git

Gitはオープンソースの分散バージョン管理システム(DVCS)です。

Q&A

解決済

7回答

22169閲覧

一人Gitでブランチは必要か?

msx2

総合スコア174

Git

Gitはオープンソースの分散バージョン管理システム(DVCS)です。

9グッド

16クリップ

投稿2016/12/28 01:17

完成まで1年くらいかかりそうなシステムを一人でぼちぼちと開発しています。

作成したプログラムの管理にGitを使っています。
管理といってもプログラムの外部保存先(バックアップ)くらいでしかありません。

開発する人間は私一人、端末はデスクトップとノートPCの2台です。ホスティングサービスはBitBucketを利用しアカウントは1つです。

現状はひたすら一直線のコミットが続いています。

基本はデスクトップで作業していて1日の終わりに必ずコミットしています。
たまにノートPCからもプルして最新のソースを取得してから作業してコミットしています。

この様な運用方法でブランチを作成する必要はあるでしょうか?
たまにおかしくなって勝手に枝分かれすることがありますが問題は起こっていません。

ブランチを作成する積極的な理由などあればご教示ください。
よろしくお願いします。

zico_teratail, Chironian, fuzzball, musix55, kitajima_rccm, kusanagi, hiroH, yakitori99👍を押しています

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答7

0

ベストアンサー

必要と感じるまでは必要ありません。
しかし、何時でも何処でも枝分かれして分岐出来るのは便利な機能です。
例として下記のようなケースをあげます。

  • ◯◯機能の超かっこいいリファクタリングをひらめいた!…でも成功するかしないか不安だし、思ったほどよくないかもしれない
  • 本番環境にリリースした◯◯機能不具合あるから修正して?…えー、僕別の機能開発中なのに!

好きな時にブランチ生やしてマージして壊してのサイクルが簡単に行えるのがGitなので、
私は基本的に目的別にブランチを作成して、気に入ったらMasterなりDevelopmentブランチへマージという風な開発手順で作業しています。

投稿2016/12/28 02:05

miyabi-sun

総合スコア21158

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

msx2

2016/12/28 04:16

Gitをよく理解していないこともあり、コミットしたりブランチを作るのを少しためらっていましたが、気軽に思いつくままやっちゃえばいい話だったんですね~。 なんだか凄く肩が軽くなった気がします。 こういうお話は本当にありがたいです!!(感謝)
miyabi-sun

2016/12/28 04:45

Gitは非常に多機能ですが、初心者なりに分かる範囲で最低限の機能だけでも、非常に多くのメリットを享受できます。 複数人開発だと履歴の改ざんとかすると他の皆が困っちゃうとかありますけど、 1人なので好き勝手に弄り倒してみてください。 そのうち「僕の考える最強のGit管理って一般的なんだろうか?」と思うタイミングが来ると思うので、他の人の本や記事を読んでみて擦り合わせてみると面白いと思います。
guest

0

少し気になったのが、

1日の終わりに必ずコミットしています。

という点です。
そもそもコミットはひとつの作業単位でしていくのがいいと思います。

つまり、「機能を追加した」、「バグをひとつ解消した」、などです。
別の角度からでは「あの作業やっぱり取り消したい」と思うかどうか。
なのでコミットは一日のうちに何回、何十回とするものだと思います。
(気になったのはここで、1日のコミット回数が少ないのでは、ということです)

自分がひとりでもブランチを分ける場合は例えばこんな感じです↓

機能実装中に迷いがあり、一度試してみてから、みたいなときでもコミットを怠ると前の状態に戻せなくなるのでコミットは頻繁にしたい。
しかし仮にその機能が「やっぱりいらないか」となった場合、今までのコミットは捨てたい。

そこで、ブランチを切って実装してみて、途中で要らないとなったらそのブランチを捨てて元のメインブランチに戻るわけです。
まさに枝切りな感じですね。

要は、

  1. コミットを細かくする。
  2. 機能単位の開発ごとにブランチを分ける。

ということを、ひとりで開発しているときでも実践しています。

投稿2016/12/28 02:25

edo_m18

総合スコア2283

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

msx2

2016/12/28 04:25

もう1日の終わりにコミットしていますと書いたのがお恥ずかしい限りで、、(*o*) 皆様のご回答を見て思ったのが、例えば今までならファイルを編集してある程度の区切りで保存しながら作業を進めていたのですが、この保存=コミットみたいな感じなのかな、と。 開発に使っているPhpStormというエディタ(環境?)がファイルを勝手に保存してしまうので、「ちょっと今のなし!」っていうのができないのが不満でしたが、変更を破棄して前に戻るのはコミットを戻すってことだと考えると納得がいきます。
Koke1024

2017/01/06 10:47

本題とはズレますが…phpstormは、gitなどのバージョン管理ツールとは別に、ローカルヒストリー機能がありますので、結構前まで遡って段階的にリバート出来ます。 VCS→Local History→Show Historyを御覧ください。
msx2

2017/01/08 13:31

ローカルヒストリー機能!?まったく知りませんでした! 調べてみますね(^^) 教えていただいてありがとうございます
guest

0

他の回答者の方の内容は、すべて賛同できますね。

開発の初期段階であるなどすると、「まだ動作確認ができてない、部品がいっぱい」の状態で、「作業」でコミットの感覚が難しいことはあると思います。そういうときは、「この保存=コミットみたいな感じなのかな」ともおっしゃるように、Ctrl+S (じゃないかもしれませんが) で保存する感覚で、どんどんコミットしてしまいましょう。その後、後から見直して git rebase -i 'HEAD~n' を使ってコミットをまとめたり、メッセージを付けたりしてみてはいかがでしょうか。

「1日の終わりに必ずコミット」のように、ある習慣を持たれていることはとても良いと思います。1日の終わりに、「今日の作業内容を整理」するつもりで、積み重ねたコミットを順番を変えて整理し、まとめるなどすると、役立つのではないかと思います。

機能や目的でブランチを作り、(細かいけれど)まとまった変更でコミット…というのは理想ですが、全体的な作業の見通しが立っていないと難しいものです。「コミットをあとからくっつける」のは「あとで分ける」よりずっと簡単なので、「このまとまりは分けなくても良かったな」と思えばくっ付けていってみて下さい、それが「1連のまとまった変更」のコミットになるはずです。git ではコミットを別のブランチに持っていくことも難しくありません。ブランチ切り替え後 git cherry-pick で適用し、不要なブランチからは rebase などで消せますので。

1人開発なら、他の人の迷惑になることを気にせず rebase できますので、どんどん使ってみてください。後から変えられることもメリットの一つと思うとよいかもしれません。

投稿2017/01/05 06:41

takotakot

総合スコア1111

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

msx2

2017/01/11 01:02

返信が遅くなりまして申し訳ありません。 今まではひたすら一人で1日作業に没頭していて、思いつくままに機能を追加したり修正したりするのでコミットをする習慣がまったくありませんでした。ご回答にあるとおり「作業コミット」の感覚がなくお恥ずかしいことに1日1回コミットでコミットコメントも”日付”という残念な一直線のブランチ…(汗) でもこの質問のおかげで多くのアドバイスをいただき、作業に対するコミットを少しずつするようになりました。ちゃんとコメントのつけられるコミットをすることで作業内容もわかりやすくなりました。 バックアップのつもりで数日に一度気が向いたらコミット ↓ 毎日の記録としてコミット ↓ 作業に対するコミット ←いまこの辺り とようやくGitを使う意味がでてきたように思います。 一人開発なのでコミットは好きなようにさわっていいと思うと気楽ですね。 ブランチやrebaseを活用する日も近い気がします。 ありがとうございました!
guest

0

Ruby on Rails チュートリアルでは、git の必要性について、こんな説明があります。

1.4.4 ブランチ、編集、コミット、マージ
...
ブランチの真価は他の開発者と共同で作業する時に発揮されますが、本チュートリアルのように一人で作業する時にも非常に有用です。
masterブランチはトピックブランチで行った変更に影響されないので、たとえブランチ上のコードがめちゃくちゃになってしまっても、masterブランチをチェックアウトしてトピックブランチを削除すれば、いつでも変更を破棄する事ができます。
...

このチュートリアルでは、章の頭で branch をつくり、章のおわりで、 master に merge したり remote repository に push するような手順でチュートリアルが進められています。

このチュートリアルのブランチの例は以下で参照できます。
https://bitbucket.org/railstutorial/sample_app_4th_ed/branches/

投稿2017/01/10 16:03

編集2017/01/10 16:10
katoy

総合スコア22324

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

msx2

2017/01/11 01:16

ご回答ありがとうござます。 Railsは未経験ですがこのチュートリアルは参考になりますね! ブランチの例もこんな風に枝分かれしたりくっついたりするんだと参考になりました。今まで他人の作ったブランチを眺めたことがなかったので…
guest

0

とある機能に複数の実装方法を思いついて、
その実装方法ごとにブランチ作って、
いろいろ比較して、
一番いいのを残す。

みたいな感じでやってます。

投稿2016/12/28 02:02

ozwk

総合スコア13512

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

msx2

2016/12/28 04:10

ご回答ありがとうございます。 確かに実装方法の候補がいくつかあったこともあります、そこがブランチの作りどころだったのですね!とても参考になりました、ありがとうございます。
guest

0

私の場合はコミット=作成の区切りとしているので、同じ日でも全く別の内容を作業する前などこまめにコミットを行うようにしています。
その方がコメントへの記載内容がまとまりやすく、後からわかりやすいという意味で「バージョン『管理』」をしやすくなるので。

ブランチに関しても、1人で作成する場合実際には分けなくても問題は発生しないかもしれません。
大事なのは「どのように分けるか」ではなく「どのような理由で分けるか」です。作業に関わる人が全員理解していれば問題ありません。

投稿2016/12/28 02:00

T_sa

総合スコア353

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

msx2

2016/12/28 04:08

やはり作業単位でコミットするのが正解ですね。 コミットすることに何となく抵抗がありましたが皆様の意見を聞かせていただいてガンガンコミットしようと思います。 ご回答ありがとうございました。
guest

0

私の場合、機能追加等をする場合はブランチを分けるようにしています。
備忘のためというのが一つ、もう一つはその機能追加等が上手くいかないなどの理由でまるっとなしにしたい場合に備えてです。
※バグ修正はブランチは分けません。

なお以下のくだりですが

1日の終わりに必ずコミットしています。

複数のソースファイルが更新されたときに、記載したコメントがどのソースに紐づくのか後から分かりにくくなりませんか?
私はこまめにコミットするようにしています。
1作業1コミットで、後からコミット時のコメントを見ればどのソースをどのような理由で修正したのか一目でわかるようにしています。

※私も必要に迫られてGitを使い出して経験が浅いので、参考にならなかったらごめんなさい。

投稿2016/12/28 01:38

編集2016/12/28 05:19
ynakano

総合スコア1894

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

msx2

2016/12/28 04:06

1作業1コミットする方がいいのですね。 現状は1日の終わりにコミットしているだけなので何がどう変更されたのかまったくわからないです。 1日1コミットではなく作業のまとまりでコミットするようにしようと思います。 ありがとうございました!
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問