リリースやデータベースの移行の練習もせずに客先でやるみたいな話し声が聞こえてきて大丈夫か?この人達と他人事ながら心配になった。
客先でのリリースとかの作業は一回以上はリハーサルしないとだよね。
あと、今時点のソースをGitにPushしておいてくださいという声も聞こえてきたけど大丈夫かね?バックアップ場所ではないんですよ。
そのあと誰かに言われたんだと思うけど、「動く時点のものをアップしてください」と言ってました。
(そもそも当たり前にそういう運用をしないとダメなんだけどね)
Gitというかバージョン管理のツールとかあまり使ったことのないチームのようでとっても心配。
他人事ながら…。
メンバーがなんらかの問題点をリーダーに説明してるけど、リーダーは何を言われているか理解できていないと説明をしているメンバーはリーダーが理解できていないことに気づかずに専門的な言葉をならべて喋り続けているのがなんか滑稽な感じ。
多分トラブル。その頃自分はいない。
新潟市で個人でコンピュータ相手にシステム開発をしています。確実、安く、素早くをモットーにやっています。
システム開発の時に調べた技術を惜しみなく公開していきます。あまりよろしくない業者についての苦言も為に吐きます。
コンピュータにベッタリというのもどうかと思いますが、やはりこれからは、コンピュータのことを知らないよりは知っていたほうが良いと思いますよ。
2016年12月9日
2016年7月18日
当たり前なんだと思うが、ちょっと感動。Gitの話。
ソース管理をGitに切り替えてから1年くらい経ちます。
メインブランチとそこから派生させたフィーチャーブランチで同時開発をしてました。
メインブランチにコミットしたら、フィーチャーブランチへのマージを真面目にやってました。
とうとうフィーチャーブランチをマージする時がやってきて、マージしてみるとコンフリクト無しでマージができました。
当たり前と、言えば当たり前ですが、感動モノです。
なぜなら、フィーチャブランチのコミット回数が534回(マージも含めてですが)もあるもんで。
メインブランチにマージした時に何かおきると思ってたのでちょっと感動してしまいました。
メインブランチとそこから派生させたフィーチャーブランチで同時開発をしてました。
メインブランチにコミットしたら、フィーチャーブランチへのマージを真面目にやってました。
とうとうフィーチャーブランチをマージする時がやってきて、マージしてみるとコンフリクト無しでマージができました。
当たり前と、言えば当たり前ですが、感動モノです。
なぜなら、フィーチャブランチのコミット回数が534回(マージも含めてですが)もあるもんで。
メインブランチにマージした時に何かおきると思ってたのでちょっと感動してしまいました。
2016年5月24日
VCSでファイルコミットの時に気をつけてね
プログラム開発している時は、今時は、Gitだったり、Subversionだったりを使ってソースのバージョン管理をするのは当たり前です。
ですが、こんな人は「コミットしないでください」と言いたくなってしまいます。
ですが、こんな人は「コミットしないでください」と言いたくなってしまいます。
- 特に内容は変更してないけど、使っているエディタの影響でインデントが全体的にちょとずれちゃったけどそのまま大量にコミット
- コンフリクトとになったけど、そのマーク付きのままコミット
- コンフリクトになったけど、適切に修正しないでコミット
- 変更の塊ごとではなく、ファイルを個別にコミット
Gitだったら、コミットを纏めることができるからまだ救いようはある。
コミットをまとめてからPushしてくれれば良いので
みなさんは、ちゃんと意識してコミットしてますか?
VCSは、バックアップようのもとと思っていませんか?
使ったことない人、理屈がわかってない人にはちゃんとなぜ使うのかをちゃんと説明して挙げてください。
2016年2月10日
Subversionと違って、Gitの何が気持ちいいかというと
なんといっても、コミットを一つにまとめることができる機能は最高です。
一つの大きなテーマ(課題)の対応をしている時に、その中でのまとまり毎に小さくコミットして行きます。
で、最後に一つのテーマのコミットに纏めることができるのでコミットが多くなりすぎてカッコ悪いことにならない。
本来は、それぞれのコミットを独立させておいたほうが判りやすいのだと思いますが、修正箇所が思いの外、広範囲に渡っていた場合など、少しずつコミットして最後にまとめたほうが見栄えが良いのです。
失敗しても少しずつコミットしてれば戻れるし。
Gitバンザイッ。
一つの大きなテーマ(課題)の対応をしている時に、その中でのまとまり毎に小さくコミットして行きます。
で、最後に一つのテーマのコミットに纏めることができるのでコミットが多くなりすぎてカッコ悪いことにならない。
本来は、それぞれのコミットを独立させておいたほうが判りやすいのだと思いますが、修正箇所が思いの外、広範囲に渡っていた場合など、少しずつコミットして最後にまとめたほうが見栄えが良いのです。
失敗しても少しずつコミットしてれば戻れるし。
Gitバンザイッ。
2015年4月18日
Gitを使う前にgit svnで練習がよいのかな?
近い将来プログラムソースのバージョン管理をGitに切り替えていこうかと思っています。
現在は、Subversionでやってます。
いきなりGitってのも良いのですが、Gitを使ってSubversionのリポジトリを使うためのgit svnというのがあるというのを知りました。
Subversionを捨てて、Gitに移行してもよいのですが慣れていないツールを使って振り回されて本来やりたいことができなくなると困るのでね。
新しいプロジェクトが始まったら、Gitを本格的に使っていくことにしました。
で、git svnは。
やっていることは、以下の以下のとおりです。
準備
現在は、Subversionでやってます。
いきなりGitってのも良いのですが、Gitを使ってSubversionのリポジトリを使うためのgit svnというのがあるというのを知りました。
Subversionを捨てて、Gitに移行してもよいのですが慣れていないツールを使って振り回されて本来やりたいことができなくなると困るのでね。
新しいプロジェクトが始まったら、Gitを本格的に使っていくことにしました。
で、git svnは。
やっていることは、以下の以下のとおりです。
準備
- Subversionのtrunkをコミット毎にローカルのgitリポジトリに取り込む。
完了すると、ローカルのgitでバージョン管理ができるようになる。
運用
- プログラムソースを修正する。
- 修正したソースをステージングへ追加する。
- gitのリポジトリにコミットする。
↑ここまでが通常のGitの操作 - git svnでsubversion用のコミットをする
git svn dcommitコマンドでSubversionのリポジトリにコミットする。
かるく動かしてみたらできたので行けそうです。
これの何がいいかというと、Subversionの場合、リポジトリが見えてないとコミットできないので直したものがどんどんたまって、ポイント毎に戻りにくくなってしまいます。
ですが、Gitであれば、ローカルのGitリポジトリに対してコミットをできるのでポイント毎に戻ることができるようになります。
Subversionのリポジトリが見える環境では、Subversionを使って、つながってない時はgit svnを使ってローカルにコミットをためる。で、Subversionが見えるタイミングになったら、dcommitをしてSubversionにコミットです。
これで、どこでもソース管理ができるという寸法です。いかがですか?
本当はGitを直接使うのが良いので早くGitに移りたいです。
OSも関係なく、コマンドラインでもさくさくと作業ができればプロっぽいですよね(笑)
Git svnの使い方サイトとか
登録:
投稿 (Atom)