Q&A
もう1日の終わりにコミットしていますと書いたのがお恥ずかしい限りで、、(*o*)
皆様のご回答を見て思ったのが、例えば今までならファイルを編集してある程度の区切りで保存しながら作業を進めていたのですが、この保存＝コミットみたいな感じなのかな、と。
開発に使っているPhpStormというエディタ（環境？）がファイルを勝手に保存してしまうので、「ちょっと今のなし！」っていうのができないのが不満でしたが、変更を破棄して前に戻るのはコミットを戻すってことだと考えると納得がいきます。
完成まで1年くらいかかりそうなシステムを一人でぼちぼちと開発しています。
作成したプログラムの管理にGitを使っています。
管理といってもプログラムの外部保存先（バックアップ）くらいでしかありません。
開発する人間は私一人、端末はデスクトップとノートPCの2台です。ホスティングサービスはBitBucketを利用しアカウントは1つです。
現状はひたすら一直線のコミットが続いています。
基本はデスクトップで作業していて1日の終わりに必ずコミットしています。
たまにノートPCからもプルして最新のソースを取得してから作業してコミットしています。
この様な運用方法でブランチを作成する必要はあるでしょうか？
たまにおかしくなって勝手に枝分かれすることがありますが問題は起こっていません。
ブランチを作成する積極的な理由などあればご教示ください。
よろしくお願いします。
回答7件
0
ベストアンサー
必要と感じるまでは必要ありません。
しかし、何時でも何処でも枝分かれして分岐出来るのは便利な機能です。
例として下記のようなケースをあげます。
- ◯◯機能の超かっこいいリファクタリングをひらめいた！…でも成功するかしないか不安だし、思ったほどよくないかもしれない
- 本番環境にリリースした◯◯機能不具合あるから修正して？…えー、僕別の機能開発中なのに！
好きな時にブランチ生やしてマージして壊してのサイクルが簡単に行えるのがGitなので、
私は基本的に目的別にブランチを作成して、気に入ったらMasterなりDevelopmentブランチへマージという風な開発手順で作業しています。
投稿2016/12/28 02:05
総合スコア21345
0
少し気になったのが、
1日の終わりに必ずコミットしています。
という点です。
そもそもコミットはひとつの作業単位でしていくのがいいと思います。
つまり、「機能を追加した」、「バグをひとつ解消した」、などです。
別の角度からでは「あの作業やっぱり取り消したい」と思うかどうか。
なのでコミットは一日のうちに何回、何十回とするものだと思います。
（気になったのはここで、1日のコミット回数が少ないのでは、ということです）
自分がひとりでもブランチを分ける場合は例えばこんな感じです↓
機能実装中に迷いがあり、一度試してみてから、みたいなときでもコミットを怠ると前の状態に戻せなくなるのでコミットは頻繁にしたい。
しかし仮にその機能が「やっぱりいらないか」となった場合、今までのコミットは捨てたい。
そこで、ブランチを切って実装してみて、途中で要らないとなったらそのブランチを捨てて元のメインブランチに戻るわけです。
まさに枝切りな感じですね。
要は、
- コミットを細かくする。
- 機能単位の開発ごとにブランチを分ける。
ということを、ひとりで開発しているときでも実践しています。
投稿2016/12/28 02:25
総合スコア2286
本題とはズレますが…phpstormは、gitなどのバージョン管理ツールとは別に、ローカルヒストリー機能がありますので、結構前まで遡って段階的にリバート出来ます。
VCS→Local History→Show Historyを御覧ください。
ローカルヒストリー機能！？まったく知りませんでした！
調べてみますね(^^)
教えていただいてありがとうございます
0
他の回答者の方の内容は、すべて賛同できますね。
開発の初期段階であるなどすると、「まだ動作確認ができてない、部品がいっぱい」の状態で、「作業」でコミットの感覚が難しいことはあると思います。そういうときは、「この保存＝コミットみたいな感じなのかな」ともおっしゃるように、Ctrl+S (じゃないかもしれませんが) で保存する感覚で、どんどんコミットしてしまいましょう。その後、後から見直して git rebase -i 'HEAD~n' を使ってコミットをまとめたり、メッセージを付けたりしてみてはいかがでしょうか。
「1日の終わりに必ずコミット」のように、ある習慣を持たれていることはとても良いと思います。1日の終わりに、「今日の作業内容を整理」するつもりで、積み重ねたコミットを順番を変えて整理し、まとめるなどすると、役立つのではないかと思います。
機能や目的でブランチを作り、(細かいけれど)まとまった変更でコミット…というのは理想ですが、全体的な作業の見通しが立っていないと難しいものです。「コミットをあとからくっつける」のは「あとで分ける」よりずっと簡単なので、「このまとまりは分けなくても良かったな」と思えばくっ付けていってみて下さい、それが「1連のまとまった変更」のコミットになるはずです。git ではコミットを別のブランチに持っていくことも難しくありません。ブランチ切り替え後 git cherry-pick で適用し、不要なブランチからは rebase などで消せますので。
1人開発なら、他の人の迷惑になることを気にせず rebase できますので、どんどん使ってみてください。後から変えられることもメリットの一つと思うとよいかもしれません。
投稿2017/01/05 06:41
総合スコア1111
返信が遅くなりまして申し訳ありません。
今まではひたすら一人で1日作業に没頭していて、思いつくままに機能を追加したり修正したりするのでコミットをする習慣がまったくありませんでした。ご回答にあるとおり「作業コミット」の感覚がなくお恥ずかしいことに1日1回コミットでコミットコメントも”日付”という残念な一直線のブランチ…（汗）
でもこの質問のおかげで多くのアドバイスをいただき、作業に対するコミットを少しずつするようになりました。ちゃんとコメントのつけられるコミットをすることで作業内容もわかりやすくなりました。
バックアップのつもりで数日に一度気が向いたらコミット
↓
毎日の記録としてコミット
↓
作業に対するコミット ←いまこの辺り
とようやくGitを使う意味がでてきたように思います。
一人開発なのでコミットは好きなようにさわっていいと思うと気楽ですね。
ブランチやrebaseを活用する日も近い気がします。
ありがとうございました！
0
Ruby on Rails チュートリアルでは、git の必要性について、こんな説明があります。
- Ruby on Rails チュートリアル https://railstutorial.jp/chapters/beginning?version=5.0#sec-what_good_does_git_do_you
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
総合スコア22328
ご回答ありがとうござます。
Railsは未経験ですがこのチュートリアルは参考になりますね！
ブランチの例もこんな風に枝分かれしたりくっついたりするんだと参考になりました。今まで他人の作ったブランチを眺めたことがなかったので…
0
私の場合はコミット=作成の区切りとしているので、同じ日でも全く別の内容を作業する前などこまめにコミットを行うようにしています。
その方がコメントへの記載内容がまとまりやすく、後からわかりやすいという意味で「バージョン『管理』」をしやすくなるので。
ブランチに関しても、1人で作成する場合実際には分けなくても問題は発生しないかもしれません。
大事なのは「どのように分けるか」ではなく「どのような理由で分けるか」です。作業に関わる人が全員理解していれば問題ありません。
投稿2016/12/28 02:00
総合スコア353
やはり作業単位でコミットするのが正解ですね。
コミットすることに何となく抵抗がありましたが皆様の意見を聞かせていただいてガンガンコミットしようと思います。
ご回答ありがとうございました。
0
私の場合、機能追加等をする場合はブランチを分けるようにしています。
備忘のためというのが一つ、もう一つはその機能追加等が上手くいかないなどの理由でまるっとなしにしたい場合に備えてです。
※バグ修正はブランチは分けません。
なお以下のくだりですが
1日の終わりに必ずコミットしています。
複数のソースファイルが更新されたときに、記載したコメントがどのソースに紐づくのか後から分かりにくくなりませんか？
私はこまめにコミットするようにしています。
1作業1コミットで、後からコミット時のコメントを見ればどのソースをどのような理由で修正したのか一目でわかるようにしています。
※私も必要に迫られてGitを使い出して経験が浅いので、参考にならなかったらごめんなさい。
投稿2016/12/28 01:38
編集2016/12/28 05:19
総合スコア1894
1作業1コミットする方がいいのですね。
現状は1日の終わりにコミットしているだけなので何がどう変更されたのかまったくわからないです。
1日1コミットではなく作業のまとまりでコミットするようにしようと思います。
ありがとうございました！
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2016/12/28 04:16
2016/12/28 04:45