タグ

gitに関するko-ya-maのブックマーク (100)

  • layer8.sh

    This domain may be for sale!

  • @ITイベントカレンダー

    平素よりイベントカレンダー+ログをご利用いただき、誠にありがとうございます。 イベントカレンダー+ログは「IT・製造業・ビジネス関係のイベント(セミナー・展示会・勉強会・コンテスト・Webイベントなど)を開催する企業・コミュニティが登録したイベント情報のポータルサイト」として約7年間運営をしてきました。これまでサービスを続けることができたのは、イベントカレンダー+ログのコンセプトに共感をいただき、適切なイベント情報をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、イベント情報の入手方法の多様化やイベント紹介サービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年6月30日(火)15:00をもちましてイベントカレンダー+ログのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知ら

    @ITイベントカレンダー
    ko-ya-ma
    ko-ya-ma 2013/03/13
    各社のつまづき
  • プロとしての行為 Act as Proffesional

    Gitのブランチをどのタイミングで切って、マージしていくかなども非常に大切ですが、ブランチやマージをするよりも頻繁におこなうコミットについて、あらためて基に立ち返ってみましょう。 一つ一つのコミットを綺麗に積み重ねていくことは、ブランチを切るタイミングやマージ、歴史の改編などを容易にすることができます。コミットが綺麗に積み重ねられていないとマージや歴史改変で苦労するでしょう。 Gitのベストプラクティス(原文)に乗っかるためにもgit commitする前に以下のようなことをチェックしましょう。 Gitの操作に慣れている人はPushやMergeをする前に今回紹介するようなことを元にしてコミットの歴史を綺麗に整えましょう。 1コミットに1つの対応1コミットにはあれこれ詰め込めすぎるべきではありません。例えば以下のような2つのことがあったとします。 Aの機能を追加Bの機能のバグを修正2つの対応

    プロとしての行為 Act as Proffesional
  • git flow でのチーム開発ワークショップ資料 - Yamashiro0217の日記

    この記事は会社内の別チームの方に、 僕の今のチームで git をどう運用してるかを ワークショップ形式で説明するための資料である。 事前準備 gitgit-flow を入れておくこと 参考資料(Macでgitgit-flowインストール) - xcode cli toolインストール -- https://daw.apple.com/cgi-bin/WebObjects/DSAuthWeb.woa/wa/login?appIdKey=d4f7d769c2abecc664d0dadfed6a67f943442b5e9c87524d4587a95773750cea&path=%2F%2Fdownloads%2Findex.action - homebrew のインストール -- https://github.com/mxcl/homebrew/wiki/installation - b

    git flow でのチーム開発ワークショップ資料 - Yamashiro0217の日記
  • FlashDevelop.org - Welcome

    FlashDevelop is a free and open source code editor for every developer FlashDevelop offers first class support for ActionScript (2 & 3) and Haxe development. Great completion & code generation, projects compilation & debugging, plenty of project templates, SWF/SWC exploration etc. FlashDevelop is also a great web development IDE with source-control support (svn, git, mercurial), tasks, snippets, X

    ko-ya-ma
    ko-ya-ma 2012/07/23
    Action Script と Haxe 向けのIDE。
  • サル先生のGit入門〜バージョン管理を使いこなそう〜【プロジェクト管理ツールBacklog】

    ようこそ、サル先生のGit入門へ。 Gitをつかってバージョン管理ができるようになるために一緒に勉強していきましょう! コースは4つ。Git初心者の方は「入門編」からどうぞ。Gitを使った事がある方は「発展編」がおすすめです。さらに「プルリクエスト編」では、コードレビューする文化をチームに根付かせましょう。 「あれ?何だっけ…?」という時は「逆引きGit」で調べて見てくださいね。

    サル先生のGit入門〜バージョン管理を使いこなそう〜【プロジェクト管理ツールBacklog】
    ko-ya-ma
    ko-ya-ma 2012/07/18
    これはわかりやすい。独習用教材に。
  • まるで魔法。GitリポジトリをHerokuに直接デプロイ·Heroku Installer MOONGIFT

    Heroku InstallerはGitリポジトリを指定してHerokuへの新規インスタンス立ち上げからデプロイまで自動化してくれるソフトウェアです。 ローカルで動作するソフトウェアはバイナリの配布ができるのでダウンロードしてすぐに試せます。Webアプリケーションの場合、サーバのセットアップからアップロードなど様々な手順を踏まなければなりません。しかしHeroku Installerを使えば魔法のように簡単にサーバのセットアップが完了してしまいます。 メイン画面です。アプリケーション名とHerokuAPIキーを設定します。 自動的にダウンロードやデプロイが行われます。 完了しました!バックグラウンドでタブが開いています。 おおー。見事に立ち上がりました。 Heroku InstallerはHerokuAPIを使い、指定したGitリポジトリからソースコードを取り込み、Heroku上に新し

    まるで魔法。GitリポジトリをHerokuに直接デプロイ·Heroku Installer MOONGIFT
  • Mac Explorer| Homebrew - Mac OS X 用スマートなパッケージ管理システム

    Mac OS X で利用可能なパッケージ管理システム。にわかに流行って(?)きているので私も導入してみました。 パッケージ管理に多くのユーザーに使われているものにMacPortsがありますが、それよりもよりスマートに動く、というもの。 MacPortsはとても扱いやすく管理パッケージも豊富でかなり便利なのですが、初めからMacに装備されているものも考慮せずに新しくアプリケーションをインストールするという性質があります。例えばMacPortsでインストールしようとしたパッケージがPerlに依存するものの場合、標準で Perl 5.10 が入っている上で依存パッケージとして新規にPerlをインストールする、という形。 その点このHomebrewはMacに標準でインストールされているものはそのまま利用するという賢い仕組みを持っています。 Homebrew ― MacPorts driving y

    ko-ya-ma
    ko-ya-ma 2012/06/11
    「Macに標準でインストールされているものはそのまま利用するという賢い仕組みを持っています」
  • Git 対 Mercurial:なぜ Git を選ぶのか? - Atlassian Japan

    今回は Atlassian の開発者である Charles O’Farrell によるゲストブログです。チームが DVCS として Git を選択する理由について説明します。Charles はコーディングをほとんど DVCS 上で行い、また ClearCase から Git へユーザーを移行させる作業を行ってきました。 前回の記事では、分散バージョン管理システムとしてチームがなぜ Mercurial を選択するのかについて考えてみました。今回は、分散バージョン管理システム (DVCS) として なぜ Git が有力な選択肢であるのかについて考えてみましょう。 1970 年の黎明期から、ギークたちはどちらが善でどちらが悪かという血なまぐさい論争を長い間行ってきました。それが VimEmacs との間の戦いです。最近では、それとは別のツールセットについて、ギークたちは来の仕事そっちのけ

    Git 対 Mercurial:なぜ Git を選ぶのか? - Atlassian Japan
    ko-ya-ma
    ko-ya-ma 2012/06/11
    「Git の方が履歴が安全」などなどの話。
  • Gyazo を自分のサーバで運用する方法 - まきもと@ねっとわーく

    Gyazo というスクリーンショット共有サービスがあります。クライアントソフトウェアを起動して自分の画面の一部分を指定してあげると、サーバに指定されたエリアのスクリーンショットがアップロードされ、共有できるというサービスです。さて、このサービスは非常に強力なのですが、通常は gyazo.com のサーバにアップロードされ、インターネット上にパブリックになってしまい、会社や大学などの内部情報を気軽に扱うことができません。ですが、実は Gyazo はサーバスクリプトを公開している *1 ので、httpd が動いている環境ではどこにでも Gyazo サーバを置くことができるのです。これで、リリース前の秘密のシステムの動作画面やミーティング議事録のツッコミ所などをみんなにシェアすることができますよ。やりましたね。Gyazo のしくみたぶんこんな感じ。簡単ですね。 -----------------

  • Google Code Archive - Long-term storage for Google Code Project Hosting.

    Code Archive Skip to content Google About Google Privacy Terms

    ko-ya-ma
    ko-ya-ma 2012/05/07
    Tortoise SVN/GIT/Hg に、Redmine のチケット管理機能を統合
  • web application 開発における git のブランチ運用ルール - tokuhirom's blog

    俺は普段こういう運用でやっているが、君はどうか。 社内の trac にドキュメントをかいたので、コピペしておく。git についてはカジュアルにつかってるだけなので、もっとこうしたほうがいいんじゃねえのというのがあればおしえてください。 ブランチ命名規則master 番の deploy 用。誰かに deploy されてこまるものはいれない。stg ステージングの deploy 用iss(\d+) チケット$1 用の topic branch。master から分岐させるその他、キャンペーン関係など、おいやすくしたい者は別途名前つけてもよし。 stg の運用基的に、開発はチケットにひもづく topic branch でおこなうので、以下のような作業フローとなる git co master git co -b issXXX # トピックブランチをきる ... # development gi

    ko-ya-ma
    ko-ya-ma 2012/05/07
    シンプルに。
  • 多人数開発で Git を使う場合の環境構築 | GREE Engineering

    こんにちは、インフラやってる sotarok です。最近、社内でも「sotarok は そーたろっくと読む」という誤解が広がっていましたので改めて自己紹介しますと、sotarok と書いて「そーたろー」または「そーたろー・けー」と読みます。ロックしてないのでよろしくお願いします。 今日は、Git の話です。 GREE ではずっと Subversion を使っているという話を、以前開発環境の話をしたときに少し触れたことがあります。Subversion での運用方法も、GREE では割と面白い運用をしているのでその話もどこかでしたいのですが、まあ、それは今回は置いておきましょう。どこかで聞いてください。 GREE もその昔 CVS から Subversion に移ったのですが、時代は流れるもので、いよいよ Git 化という流れがきています。Subversion と Git の違いを今更あえて挙

    多人数開発で Git を使う場合の環境構築 | GREE Engineering
  • Redmine, git, Jenkinsの状態を横断的かつリアルタイムに表示する『Dashbozu』をリリースしました。 - みずぴー日記

    Redmine, git, Jenkins などプロジェクト管理ツールの状態を横断的かつリアルタイムに表示するWebアプリ『Dashbozu』を作りました。 これを使えば、一つの画面でプロジェクトの”今”の状態を把握できます。 WebSocketを用いているので、ただ開いているだけで、次々と情報を得ることができます。 iPadで開きっぱなしにして、机の上に置いておくような使い方を想定しています。 なぜこれを作ったか 一般的なソフトウェア開発現場では Redmineでチケットを作成する gitでコミットを繰り返し、中央レポジトリにpushする JenkinsによるCIが実行される 結果を確認し、Redmineのチケットを閉じる という流れで作業が進んでいきます。 これらの作業の中で、開発者は「適切な」タイミングでチェックとフィードバックをすることを求められます。 例えば、チェックのタイミング

    Redmine, git, Jenkinsの状態を横断的かつリアルタイムに表示する『Dashbozu』をリリースしました。 - みずぴー日記
    ko-ya-ma
    ko-ya-ma 2012/05/07
    「Redmine, git, Jenkins などプロジェクト管理ツールの状態を横断的かつリアルタイムに表示するWebアプリ」「iPadで開きっぱなしにして、机の上に置いておくような使い方を想定」
  • 操作体系から見る、GitとMercurialの8つの違い

    つい先日、SVNからMercurialに移行するべき8つの理由をまとめたが、Twitterはてなブックマークのコメントを見ていると、同じ分散バージョン管理システムとしてGitとMercurialとの比較に関心が高く、Windowsでの動作でMercurialを評価する人が多いように感じられた。 それも一つの側面で間違いでは無いのだが、日々の開発作業で使っていくと、むしろ操作体系の方が気になるものだ。GitとMercurialの両方を使う機会があったので、操作体系の面で気づいた違いを列挙した上で、Gitに対するMercurialの優位点を考察してみる。 1. 管理対象ファイルの指定方法 .gitignoreや.hgignoreで管理外のファイル名を指定でき、正規表現も使える点は良く似ている。 しかしGitはcommit前にコミット対象を毎回git-addで指定するが、Mercurialは一

    操作体系から見る、GitとMercurialの8つの違い
    ko-ya-ma
    ko-ya-ma 2012/05/02
    「バージョン管理システムに人的リソースを割きたく無いプロジェクトには、GitよりMercurialの方が適していると言えるであろう」
  • LT概要「GitとMercurialのリポジトリ構造の違いと歴史改変について」SCMBootCamp in Tokyo - monjudoh’s diary

    SCMBootCamp in Tokyo 開催しました。KPT公開。 - うさぎ組にて手ぶらLTをしたので資料はないが、内容を軽くまとめておく。 GitとMercurialの比較 Git Mercurial リポジトリ commit objectのグラフと、branchのHEAD,tagなどの参照で出来ている。 commit objectのグラフだけで出来ている。 歴史改変サポート デフォルトであり。 デフォルトではなし。extensionが必要。 歴史改変 新しいcommit objectグラフを作成し、参照を古いHEADから新しいHEADに移す。表面上要らない歴史の削除として使われるresetはHEADの移動のみを行う。 新しいcommit objectグラフを作成し、古いcommit objectグラフをリポジトリから除去する。要らない歴史の削除として使われるstrip(MQExte

    LT概要「GitとMercurialのリポジトリ構造の違いと歴史改変について」SCMBootCamp in Tokyo - monjudoh’s diary
    ko-ya-ma
    ko-ya-ma 2012/05/02
    似てても別物です…な話。わかりやすい表がある。
  • Git使いがMercurial使いに転職するとき設定しておくべきMercurial拡張 | Webシステム開発/教育ソリューションのタイムインターメディア

    Mercurialは、Merucurial拡張という拡張モジュールを使って、Merucrialの挙動をいろいろ拡張できるようになっています。 デフォルトのままだと使いにくいので、Mercurialを使う上で便利にしてくれる拡張を設定しておきましょう。 デフォルトでバンドルされているMercurial拡張は、Using Mercurial Extensionsにまとめられています。 今回はGit使いがMercurial使いに転職するときに、Gitで実現できたことをMercurialで実現するための、組み込み拡張、および、サードパーティ製の拡張について紹介します。 色づけしよう ブランチの確認、diff、パッチ等々、色づけされていないとつらいです。 というわけでGit同様に色づけしましょう。 Color Extensionはすでにバンドルされているので、.hgrcに次の記述を加えましょう。 こ

    Git使いがMercurial使いに転職するとき設定しておくべきMercurial拡張 | Webシステム開発/教育ソリューションのタイムインターメディア
    ko-ya-ma
    ko-ya-ma 2012/05/02
    fetch, rebase, hq あたりかな。
  • MercurialとGitのブランチの違い - wyukawa's diary

    MercurialのブランチというのがどういうものでしかもそれがGitと同じなのかどうかもいままでよくわからなかった。 その辺のモヤモヤがこれを読んで理解できた(気がする)。 experimentalworks » Blog Archive » Mercurial bookmarks A Guide to Branching in Mercurial / Steve Losh まずMercurialでは以下の4種類のブランチがある。 リポジトリをcloneしてつくるブランチ hg bookmarkで作るブランチ hg branchで作る名前付きブランチ 名無しブランチ リポジトリをcloneしてつくるブランチは hg clone test-project test-project-feature-branch というように単純にcloneして新機能を開発してあとでマージなりリベースなりする

    ko-ya-ma
    ko-ya-ma 2012/05/02
    「おそらくリリースブランチのように寿命が長いブランチに対しては名前付きブランチを使い、寿命の短いトピックブランチはbookmarksを使うといいんじゃないかと思います。」
  • Rackhub - リーンでスマートに生きるエンジニアのための開発プラットフォーム

    Buyer Protection Program When you buy a domain name at Dan.com, you’re automatically covered by our unique Buyer Protection Program. Read more about how we keep you safe on our Trust and Security page. Next to our secure domain ownership transfer process, we strictly monitor all transactions. If anything looks weird, we take immediate action. And if the seller doesn't deliver on their part of the

    Rackhub - リーンでスマートに生きるエンジニアのための開発プラットフォーム
    ko-ya-ma
    ko-ya-ma 2012/03/19
    SSHログインとルート権限つきのクラウド系ホスティングサービス。安い。ポチポチポチで開発サーバをセットアップできる。fluxflexを潰して、こっちに注力するらしい。
  • Webベースバグトラッキングシステム

    tracpath(トラックパス)は、ソフトウェア開発で必要な プログラムとソースコードを一元化、 Git / Subversionのホスティングサービスです。

    ko-ya-ma
    ko-ya-ma 2012/01/27
    バージョン管理+開発プロジェクト管理サービス。日本語。かなり実務寄りな印象。