Gitによるバージョン管理入門 for windows
についての、ご指摘、ご意見、ご質問、文句はこちらへどうぞ！でもやさしくしてね。
2024年4月 月 火 水 木 金 土 日 « 4月 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 -
最近の投稿
最近のコメント
- なんでGitの発音を「ジット」だと思うのだろう？ に boku より
- なんでGitの発音を「ジット」だと思うのだろう？ に anon より
- なんでGitの発音を「ジット」だと思うのだろう？ に コレさん より
- なんでGitの発音を「ジット」だと思うのだろう？ に A より
- 間違ってるぞ、とか、文句とか、質問とか に admin より
アーカイブ
カテゴリー
メタ情報
タグ
なんか誰も何も書いてくれないので、さびしいので自分で書きます。(;_;)
改めて読み直してみると、結構わかりづらいところが沢山ありました。
書いている最中は、全部頭に入っちゃっているので気づかなかったけど、
時間があいて忘れてから見ると、気づきますね。
書き直したいけど、時間が無いなあ。
ピンバック: 明けましておめでとうございます | Plowmanのブログ
現在バージョン管理ソフトを検討しており、subversionやgitなどをいろいろ調べています。こちらのサイトを拝見させていただき、参考にさせていただいてます。
運用上で、不明な点があるので失礼ながら質問させてください。
当方は以下のようなプログラム開発業務でのバージョン管理ソフトの利用を考えております。
①顧客からソースコード一式を受領する。
②①をベースに修正/開発をする。
③顧客へリリース(ソース一式)
④③のソース一式に顧客の変更を加えたソース一式を受領→マージ
⑤④をベースに修正/開発
⑥顧客へリリース(ソース一式)
上記が大まかな流れですが、これを繰り返します。
まさにバージョン管理ソフトの機能が発揮できるのではないかと思います。
ここで①や④でさまざまなタイムスタンプのソースを受領します。
新たに修正を行うファイルに関してはタイムスタンプが更新されてもよいのですが、
何も変更がないものに関してはタイムスタンプが変わらないのがベストだと思います。
リリース時にエクスポートなどを利用してソースを梱包した時に、エクスポートした時のタイムスタンプに更新されているようです。顧客からするとタイムスタンプが変わってるので変更の有無を気にしてしまい、混乱を招くように思います。
こういうツールはファイルの内容を管理をコミットの日時で行うことはわかりますが、エクスポートしたファイルを現在の日時に更新されると問題があるようにおもいます。みなさんはどのように運用されているのでしょうか。
何か、よい方法はないでしょうか。十分機能を理解しきれていないので使い方が間違っているのかもしれませんが、助言をいただけると幸いです。
投稿ありがとうございます。初めての投稿ですので、うれしいです。
記事にも書いてありますが、Git自体はファイルのタイムスタンプを管理していないので、エクスポートするとその時点の日時になってしまうのでしょうね。
タイムスタンプの保持は、リリース用のリポジトリを一つ作り、そこにチェックアウトしてからリリースすれば可能だと思います。そのリポジトリはずっと残しておく必要がありますが、この方法なら、変更があったファイルのみタイムスタンプが変更されます。
でも、この方法でもお客さんから貰ったソースのタイムスタンプと同じになるとは限らないですね。変更の無いものはお客様から頂いた時のタイムスタンプと同じになるようにするには、お客様から頂いたファイルを登録するときに使ったリポジトリを取っておいて、リリース時にはそこにチェックアウトして、リリース、とやれば何とか出来そうです。
でも、ややこしいので、お客さんにもGitで管理してもらい、ネット上のリポジトリで共有するか、パッチでやり取りして、タイムスタンプは変更の有無とは関係ない、と出来れば、一番分かりやすいかもしれません。お客様があることなので、自由にはならないと思いますが、Gitなら比較的ネットでの共有がやりやすいと思います。
早速の返事ありがとうございます。
一人で悩んでいたので非常に助かります！
>タイムスタンプの保持は、リリース用のリポジトリを一つ作り、
>そこにチェックアウトしてからリリースすれば可能だと思います。
>そのリポジトリはずっと残しておく必要がありますが、この方法なら、
>変更があったファイルのみタイムスタンプが変更されます。
こういうことでしょうか？
・[リリース用]フォルダでリポジトリを作成
・[リリース用]フォルダにお客様から頂いたソース一式を保存
・リモートリポジトリにファイルを追加
・各作業者は、このリモートリポジトリをクローンして利用
→各自の作業ツリーでプルするとソース一式が現在のタイムスタンプでコピーされる
→内容変更があったものをプッシュしてリモートリポジトリに反映
・リリース時は[リリース用]フォルダでチェックアウトすれば
[リリース用]フォルダに最新の内容と差分があったファイルのみ更新
される。
このフォルダ内のソース一式をお客様にリリースすればよい。
・お客様が更新したソース一式を再度頂いた場合も既存の[リリース用]フォルダ
に上書きして、同様の作業を行う。
これならうまくいきそうですね。
お客様にGitを利用してもらうのは他にも数社関係するため、少し敷居が高いかもしれないですね。
提案したら気に入ってくれるかもしれませんが。。。。
上記方法で駄目なら、更新したファイルのみをGitで管理し、リリースの際は
お客様に頂いたソース一式に更新したファイルを手動で上書きして梱包する
しかないかと思っています。(←Gitの有用性が薄まってしまっていますが。。。)
> こういうことでしょうか？
そう、そうです！
文書だとわかりにくいかと思いましたが、わかっていただけてうれしいです。
>お客様にGitを利用してもらうのは他にも数社関係するため、少し敷居が高いかもしれないですね。
Gitは最初ちょっと敷居が高いので、ある程度の管理レベルと管理意識のある会社じゃないと難しいかもしれないですね。
>提案したら気に入ってくれるかもしれませんが。。。
是非ご提案を！
では！
「ソーシャルコーディング」に興味をもってGitの情報を検索して
たどり着きました。説明が非常にわかりやすいですね。
突然のコメントすいません。
私は、現在工場の社内SEとしてラインで使用するプログラムの
開発に従事しています。
そこで、最近になりプログラムのバージョン管理を行うことに
なり『TortoiseGit』を使用することになりました。
なんとか、インストールに成功してテスト的に私一人が使用して
使い方がわかってきたら他の開発者へ展開するような感じで動いていますが
すでに3か月ほどやっていますが未だに理解できずネットの中をさ迷い歩いて
ここにたどり着きました。
いきなりの質問で不躾だとは思ったのですが、質問させてください。
この『TortoiseGit』というソフトでは、フォルダごとに個別に管理することは
出来ないんでしょうか？
というのも、当方の環境では複数のラインがありそのラインごと製造製品ごと
に使用しているプログラムが違います。それを管理しようと思って
￥開発フォルダ
￥ライン1
￥ライン１、製造製品１のプログラム
￥ライン１、製造製品２のプログラム
￥ライン２
：
：
というようなディレクトリ構造にしました。
この状態で、『￥ライン１、製造製品１のプログラム』でブランチを
作り切り替えると『￥ライン1』全体が切り替わってしまって
『￥ライン１、製造製品１のプログラム』だけで別ブランチを作ることが
出来ません。
これでは非効率なので何とか『￥ライン１、製造製品１のプログラム』だけで
ブランチを作って、切り替えをした時も『￥ライン１、製造製品１のプログラム』
のみが別ブランチに移るようにしたいのですが方法はありますか？
突然にご質問で大変不躾ではありますがご回答いただけると幸いです。
当方の環境としては、OSはWinXP、『TortoiseGit』のバージョンは
『TortoiseGit-1.8.16.0-32bit.msi』を使っています。
ラインで使用しているプログラムがWinXP下でしか動作しないのでこのような環境に
なっています。
ですが、一応NASサーバを入れてそこにプログラムのバックアップを取るように
環境を作りました。
長文、乱雑な質問になってしまいましたがご回答何卒よろしくお願いします。
小林と申します。
メールありがとうございます。
＞この『TortoiseGit』というソフトでは、フォルダごとに個別に管理することは
＞出来ないんでしょうか？
まず、TortoiseGit は、Gitの実装の一つであり、基本的な考え方や機能は、Gitとまったく同じです。
TortoiseGit だから何か特別な機能があるわけではありません。
そのほかのGitのツール、例えば Source Treeでも、同じリポジトリをそのまま操作できます。
git の考え方は、リポジトリ全体のバージョンを管理する、というものですので、一部のフォルダを
分けて管理するという考えはありません。
さて、お問い合わせの件ですが、もしライン１とライン２が全く関連を持っていないのでしたら、
別のリポジトリにしてしまうのが一つの方法です。
ただおそらくは、ライブラリなど共通部品があると想像できるので、リポジトリを分けるのは
現実的ではないかもしれません。
＃細かくいうと、SubTreeという機能があって、ライブラリ等の共通リポジトリを別のリポジトリに
＃取り込んで管理するという方法があるのですが、これは結構ややこしいので、今回のケースには
＃当てはまらないかもしれません。（私はよく使っています）
ライン１とライン２の更新が 同時期に行われないのなら、おそらく苦労されていないと思うので、
ライン１とライン２の更新が同時並行的に行われる（複数人での開発も含めて）と考えると、
センターリポジトリ
|
+–> ライン１用リポジトリ
|
+–> ライン２用リポジトリ
の様にして、ライン１の変更はライン１用リポジトリで行い、ラインに２の変更はライン２用リポジトリで行い、
完了後に、各リポジトリでmasterにマージ後、センターリポジトリにプッシュする、というのがおおざっぱですが、
一般的な使い方だと思います。
もし複数人の開発者がいるのなら、開発者数分の非センターリポジトリを作って運用することになります。
この場合、 ワーキングディレクトリには 、ライン1用もライン２用もどちらのフォルダも入っています。
修正するのは、ターゲットのフォルダ内のものだけ、という事になります。
つまり、ライン１用リポジトリといっても、ライン２用リポジトリとなんら変わるところはなく、単に
運用上、修正するターゲットが違う、というだけで、ライン２用でライン１のプログラムを修正しても
まったく問題となることはありません。（ただし、同じファイルの同じ場所を修正すると、マージの時に
競合（コンフリクト）が発生します。）
Git はこのあたりが大変柔軟に運用できるので、優れた点でもあるのですが、とっつきにくい点でもあると思います。
ご参考になりましたら、幸いです。