52715


アジャイルで開発している現場のプロジェクトがSVNからGitに移行したものの、  
結局SVNの時と同じような使い方をしていて何か違うような気がしています。

集中型から分散型のバージョン管理になってローカルリポジトリができ、  
けれど結局はdevelopをローカルにcloneし、  
各々開発してコミットと同時にプッシュする運用をしていて、  
ローカルリポジトリの必要性というか、そこをうまく使えていない気がしています。

ローカルリポジトリがあることによるメリットであったり、  
ローカルにコミット後プッシュまで貯めておく？ケースや  
ローカルでブランチを切るケース、  
こういう使い方やこういう開発スタイルに合っている、などありましたら教えて頂きたいです。

運用上弊害がある訳ではないですが、Gitのメリットが生かせていない気がしました...。


CC BY-SA 4.0
2019-02-09T09:25:59.107
52661
2019-02-12T03:36:33.363
2019-02-09T11:21:17.290
19727
19727
question
git
Gitのローカルリポジトリの有効活用（メリット）について


分散型リポジトリのメリットは、主に

  1. ローカルにpullした時点の全てを持ってこれるので、その範囲での作業であればネットワークはいらない
  2. リモートに反映する部分を選べる
  3. ローカルの反映する部分も選べる（大きなリポジトリでは、操作速度を上げるのに役に立つ）
  4. 修正の競合を防ぐ方法が、ロックではなくマージで解決するので、誰かがロックしたまま放置して困るということがない
  5. パッチ版など本家と差異があっても維持しやすく、マージによって修正の取り込みがしやすい

ということだと思います。

よくありそうなパターンだと、

  1. pushするまではリモートに影響が出ないので、ローカルで好き勝手やっても問題ない 
    * ブランチやタグを作ったり消したり放棄したりや、コミットやコミット取り消しも気楽に行える
    * push済みのコミットでなければ、rebaseなどでコミットを綺麗にしたりも気楽に行える
  2. リモートブランチに納得がいったブランチだけをpushすることができる 
    * よくある「git push origin master」なら、originリモートリポジトリにローカルのmasterブランチのみを反映し、例えばdevelopローカルブランチがあったとしても、リモートには反映されない
    * （SVNは記憶の彼方なので、こういうことができないというのは自信なし）
  3. （話を聞いたことがあるだけで実体験なし）
  4.     1. と同じ
  5. GitHubなどを使っているなら、必要に応じてプルリクエストを発行するまで影響が出ない 
    * 自分のリポジトリが、本家のリポジトリのフォークの場合、ある意味本家に対するgit cloneしたクラウド上にあるローカルリポジトリなので、本家にマージ処理されるまでは変更は反映されないため
    * 独自パッチ版が必要な時便利

というところでしょうか？


CC BY-SA 4.0
2019-02-11T03:02:02.867
52692
2019-02-11T03:02:02.867
7900
52661
answer


記憶装置の価格がん十年前に比べて１００万分の一になっているという現在においては、各自がローカルにリポジトリを持っても記憶装置のコストは無視できて、それらがすべてバックアップと見なせるので安全とか。

組み込み系では、実機が実験室に１台しかない（普通はシミュレータとか擬似装置とかでデバッグする）ような状況もあり得て、実験室からサーバに繋げられない状況でも細かな変更をするたびに
commit できるとか。過去履歴を自由に参照できデバッグがはかどるとか。事務所に戻ってレポート書きながら push できるとか。

あたりが分散型一般の長所でしょう。あと [git](/questions/tagged/git "'git' のタグが付いた質問を表示")
についていうなら、

[git](/questions/tagged/git "'git' のタグが付いた質問を表示")
は既にソースコード管理ツールの域を超えて、一種の社会インフラみたいな使い方がされている・できるようになっています。要するに
[git](/questions/tagged/git "'git' のタグが付いた質問を表示") を自分の中のツールとして使う **別なツール**
がいっぱい作られています。例えば `production` サーバーの設定データも [git](/questions/tagged/git "'git'
のタグが付いた質問を表示") で管理し共有するようなツールもあるあるです。そういう [git](/questions/tagged/git "'git'
のタグが付いた質問を表示") を内部で使っているツールを使いこなすには [git](/questions/tagged/git "'git'
のタグが付いた質問を表示") に習熟しているほうが望ましく `subversion` の知識では足らない、なんてのもしばしばあります。

オイラが思うに [git](/questions/tagged/git "'git' のタグが付いた質問を表示")
は「何でもできる＝高度なことをするためには高度に習熟する必要がある」ので web
の記事でよくある「こんなことできて便利！」な内容をチームメンバー全員でできるようになるためのハードルは高いですよ。最初はできなくて当然。使いこなそうとする必要なんかありません。使えりゃいいんです。


CC BY-SA 4.0
2019-02-11T07:59:28.610
52696
2019-02-11T07:59:28.610
8589
52661
answer


> こういう使い方やこういう開発スタイルに合っている、などありましたら教えて頂きたいです。

ブランチモデルのことだと思いますが、いろんなモデルが存在していますので、開発スタイルに合わせて検討されると良いと思います。とても書ききれませんので、ブランチモデルで検索してもらっていろいろ調べてみてください。

真っ先に思いつくのは git-flow のブランチモデルを採用した使い方です。  
有名で一般的ですが安全にリリース管理する点が重視されていて やや大げさな印象です。

github flow というのもあります。Pull Request するタスクがあるので Github などを利用するのが前提です。git-flow
よりは簡略で頻繁にリリースすることを重視しているそうです。

もっと単純なものとしては、ブランチを切らないパターン（現状はこれなのかと）、master&developの2つで運用するパターン、feature(機能)ごとにブランチを切るパターン、などがよくあるパターンだと思います。


CC BY-SA 4.0
2019-02-12T03:36:33.363
52715
2019-02-12T03:36:33.363
5008
52661
answer