gitって難しいのかなー - 未来のいつか/hyoshiokの日記
いろいろな人がgitは難しいという。そうなのかなー。ふーん。自分はあんまりそうは思わないけどつらつらと考えてみた。（無駄に長いし、有意義なことを書いてあるわけではないので、お急ぎの人はスルーしちゃってください） 前提として、分散バージョン管理システムを使うケースというのは、複数の人が共同でソフトウェアなどを作るという状況のときだ。管理の対象は通常ファイルになる。複数の人が同じところにいるという必要はないけど、別に同じ場所にいてもいい。「分散」というぐらいだから、インターネットさえ繋がっていれば、地球の裏側でもいいし、火星から共同開発をしてもかまわない。そーゆー前提でソフトウェアを開発するとする。 それのレポジトリをどこに置くかという問題は、社内のどっかのサーバーでもいいし、自分のPCでもいいし、インターネット経由でコラボレーションをするのならgithubみたいなサービスを使うというのでもい
ミーティング：仕事が死ぬ場所
寂しい気分ですか？自分で仕事をするのが嫌になりましたか？自分で決断をするのが嫌ですか？ それならミーティングを開催しましょう！ 皮肉なネタ画像と共にミーティングについての5原則がCoding Horrorに掲載されていました。 1時間以上のミーティングをしたものは死刑 ミーティングが1時間以内に収まらない場合は根本的な過ちがある。まずはそれを正すべき。 全てのミーティングは明確なミッションステートメントが必要 ミーティングの目的を簡潔な短文で定義できますか？ ミーティング前に宿題を済ませる ミーティングのアジェンダを明確にしたら参加者には事前に何を話すべきかを伝えます。ミーティングルームに入る前に宿題を済ませて準備ができている事が1時間以内にミーティングを終わらせる秘訣です。 任意参加にせよ 必須参加は甘えです。ミーティングの参加者はそこに居たいと思っているべきです。 ミーティングの最後に
GitHub Pagesホスティングサービス（ほぼ）完全活用ガイド | ゆっくりと…
GitHub がオープンソースの場として魅力的な理由は、Git という優れた分散・協調型リビジョン管理システムのリポジトリー・ザーバーとして誰でも利用できるということはもちろん、README などのドキュメント生成機能やコメンティング機能、問題のトラッキング機能など、Git を補助し、オープンな分散・協調開発を支えるサブシステムが充実している点が挙げられるでしょう。無料でもかなりのことができるのに、ビジネスとしてもちゃんと成立している理由はこんなところにあるように思います。 ただ、同種サービスの Google Code や Bitbucket と決定的に異なり、GitHub の最大の魅力となっているのは、GitHub Pages という1種のホスティング・サービスではないかと思います。成果物をただずらずらと味気ないページに並べるのではなく、趣向を凝らした紹介ページを自由に作り、プロジェクト
hg-gitでbitbucketのMercurialリポジトリをgithubにインポートした - 偏った言語信者の垂れ流し
hg-gitはMercurialでGitリポジトリを扱えるようにするプラグイン。試しに使ってみた。 Hg-Git Mercurial Plugin 書いてある通りで使えた。bookmarkを使わなくてもdefault/masterは良きに計らってくれるっぽい？ 次のように実行してインポートしました。 $ sudo easy_install hg-git $ vim ~/.hgrc # hggit= をextensionsセクションに追加 $ hg clone http://bitbucket.org/tokibito/myrepo $ cd myrepo $ hg push git+ssh://git@github.com/tokibito/myrepo.githg-gitのリポジトリ操作はpure pythonのモジュール(dulwich)を使っているのでGitのインストールは特に必要な
GitユーザだけどBitbucket使いたい！ - CROSS HOPE
「そんなむちゃくちゃな！」「なんだそれ？」と思う方へ。 結論を言ってしまうと、「無料」で「便利」だから使いたいと思ったのです。 Githubすごい！けど… ★研究目的で使うから、ちょっと非公開にしておきたい ★Wikiほしい！ となったら、お金がかかっちゃうんです。$7/moということは、$84/yrかな。 ちょっと貧乏な学生さんはとてもタダに弱いので、「タダのGithubはないのか！」と血眼になって探しまわりまして(誇張)、見つけたのがBitbucketでした。 BitbucketはMercurialという、Gitとは別の分散型バージョンシステムのためのホスティングサービスです。 このBitbucketは、 ★非公開にできるよ！ ★WikiもIssueもついてるよ！ ★さらにタダですよ！(5 Usersまでは共有可能のご様子) …使わない手はない。 でも友人たち含め、自分はGitを愛して
GitHub を Maven 公開リポジトリにする (Gradle 編) - bluepapa32’s Java Blog
最近は Gradle がとってもお気に入りなので プラグインの開発も少しずつ行っているのですが、 折角作成したプラグインやライブラリも Maven リポジトリで公開しないと利用しづらいので どこか公開できる場所がないか探していたところ Github を Maven 公開リポジトリにする という記事を見つけたので ソース管理と合わせて GitHub に Maven リポジトリを作成することにしました。 ただ無料版だと300MB しか利用できないので容量がちょっと心配だったのですが id:kimukou_26 さんのアドバイスによりあまり容量を気にする必要はないことがわかったので GitHub にしました。 それによく考えてみれば そもそも 300MB もコードが書けるほど時間に余裕はないですし... 上記の記事では Maven が使われていましたが、今回は Gradle を利用することもあり
GitHubへpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
pshared.net