git の運用指針 - Cube Lilac
ソフトウェア開発に関しては、これまでほぼ一人で完結していた*1ので git の運用方法もかなり適当だったのですが（ただのコミットマシーン状態）、今回、同一プロジェクトに対して複数人でコミットしていく形になっているので、その状態だとやはりまずいなと言う気がしてきました。ググっていると「なるほど」と思う記事もたくさんあったので、それらの記事を元に自分のプロジェクトの「git の運用指針」を情報共有のために記載しておこうと思います。 前提 まず始めに、現在のプロジェクトの状況は下記のようになっています。 開発は 1 人のメインコミッタ（私）と数人のサポートコミッタ（アルバイト等）で行われる メインコミッタはフルタイム、サポートコミッタは週に数時間〜10時間程度の勤務形態 サポートコミッタに対しては、基本的に 1 機能（1 チケット）を 1 人で完結するように作業を配分するが、時間的な兼ね合いもあ
死んで覚える本当のGitの使い方 - mizchi log
注意: バズってますが、これははてなダイアリーからはてなブログの自動マイグレーションに失敗してたものを復旧させたもので、書かれたのは2012年です。 - 最近流行っているGit初心者向け記事は、「僕らが本当に知りたかったこと」が欠けているようにしか思えません。 そこで、本当のGitの使い方を僕が皆さんに伝授しようと思いました。 なにはともかく使ってみよう 前提として、皆様のお手元にはすでにGitがインストールされているものとします。 今回はエディタとしてDungeonCrawl StoneSoupを使います。 Downloads « Dungeon Crawl Stone Soup http://crawl.develz.org/wordpress/downloads Dungeon Crwal Stone Soup は今一番ホットなオープンソースのローグライクです。風来のシレンやトルネコ
小規模チームでのGithub利用開発 - Mandy Code
気づくと1週間経っている恐怖(´ω｀) いまうちの会社ではGH:Eを導入するほどの規模でもないので、Githubのビジネスプランを使って開発を進めています。 僕自身gitへの造形がそこまで深くなく、どのように開発を進めていくかかなり迷いがありましたが、現在ある程度フローを決めてスムーズに開発が進むようになってきたので、それをまとめておきたいと思います。 ベースはgit-flow Githubを導入するにあたって、gitを利用した開発フローについて調べたのですが、やはり最初に出てくるのがgit-flowでした。 一方で、実際にgitを現場で利用されている方々に聞くと、「リリーススピードが早いとgit-flowは厳しい」という声も聞かれました。 そこで、小規模チーム（現在は3人）で開発を行う際にgit-flowをベースとして利便性の高い開発フローを考えてみました。 リリースまではmasterと
Git に関する良記事 - あどけない話
適宜追加します。 Pro Git 僕が読んだ Git の書籍の中では、一番分かりやすいと思いました。日本語版の書籍はありませんが、オンライン版が翻訳されています。 Pro Git 図解 Git Git の初心者が動作を理解するのにおススメ。 図解 Git こわくない git ブランチとマージの考え方がよく分かるスライド(@methaneさんから教えて頂きました)。 こわくない git あなたの知らないGit Tips 書籍には載ってない Tips の解説。知らないと損するかも。 あなたの知らないGit Tips ワークフロー、あるいはブランチング チームでブランチを使う際の取り決め。自分のチームで一から議論するより、すでにあるものを参考にしましょう。 git-flow github-flow Github Enterprise Github Enterprise は、企業内に設置して使うこ
WebデザイナーもGit使うといいよって話 | Cherry Pie Web
※この記事では「Webデザイナー」は、「ノンプログラマ」の意味で使っています。 psd、ai などの材料データの管理ではなく、サーバーにアップするファイルの管理の話です。 サルでもわかるといわれても、やっぱりわからない・・・ Web制作をやっている人は、少なからずバージョン管理システムの話を聞いたことがあると思います。 特にGit（ギット）っていうのは、内容まで知らなくても名前くらいは聞いたことがありますよね。 で、ネット上ではバージョン管理システムのメリットに関するブログ記事なんかもたくさんあって、変更履歴をたどれるとか、複数人で同じファイルを修正したりといった時のトラブルに対応できるとか、なんか便利そうだなーとは思っていたわけですが、ずーっと導入は見送ってきました。 その理由は・・・ 「Git入門」とか書いてある記事を読んでも導入方法が書いてあるだけで、実際に使うシチュエーションが思い
git-daily 的なブランチ方針がしっくりきました
ソースコード管理でのブランチの切り方を模索してきました。いったん落ち着いたので書き残しておきます。 前提条件は以下のとおりです。 iPhone アプリがアクセスするウェブAPIを開発する。 サーバサイドの開発者はふたり。大阪と東京。 他の案件とかけもち。 行き着いたところ Mercurial git-flow/git-daily に似たブランチ方針 機能追加、開発中機能のバグ修正: default ブランチから、XXX ブランチを切って機能追加/変更し、default へマージする。 リリース: default ブランチから、release/XXX ブランチを切って、ステージングでテスト/修正。終わったら、default と master へマージし、master の先頭を本番サーバにデプロイする。 リリース済不具合の修正: master ブランチから、hotfix/XXX ブランチを切っ
危なくないgitこと、うちのチームのgit戦略草案(ver. 2)
履歴 恥を忍んで記事を公開させていただいたおかげで、いろいろフィードバックいただきました。フィードバックを取り込んで更新を行なっています。 2012/11/16: cherry-pickしやすいように、というくだりのところは論理通ってないので削除しました。 1 pull req. 1 commitの原則をやめました。言いたいことであった「試行錯誤の過程を入れないで」を丸パクリしました！ > id:kazuho その他表記修正、クリアコードさんの記事に説明丸投げなど。 まえがき gitでトラブった！という話を何度か聞いたことがあります。なんでトラブッてるんだろう…と話を聞いたところ、同一のリモートブランチに対して複数人・複数環境から操作が行われているようです。極端な例を挙げると、masterブランチしか存在しておらず、コミットログをキレイにするためと称してgit pull –rebaseを常
GitHubへpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
git commitをやり直しする＆取り消しする(「get commit --amend」と「git reset」) - hogehoge foobar Blog Style Beta
git commitを実行あとでコミットをやり直したり、コミット自体を取り消す方法です。 直前にしたコミットをやり直す（git commit --amend） 直前にしたコミットをやり直す場合、「git commit --amend」を使用します。 例えば、直前のコミットログが以下のような状態だったとします。 実は直前のコミットに含めるべきであった「hoge.txt」が含まれていませんでした。 コミットログ(git commit --amend 実行前) $ git log commit cca638b48b4c8be7ad5432f7882497534b04e2b4 Author: mrgoofy <hogehoge@example.com> Date: Wed Sep 8 23:03:57 2010 +0900 2nd Commit.-> New Add File : bar.txtこ
ペパボでの GitHub の使い方 - Gosuke Miyashita
必殺！Github導入に向けて上司を説得する時に使える資料まとめ - DQNEO起業日記 でペパボも取り上げて頂いたので、ペパボでの GitHub の使い方について、少し詳しく書いてみます。 開発での利用 これは普通の使い方ですね。なので省略。 GitHub Enterprise は利用していない 金額的な面で GitHub Enterprise の利用は厳しいため、GitHub Enterprise ではなく、ノーマル（？）な GitHub を利用しています。（GitHub Enterprise にすると、現在のコストの 8 〜 9 倍ぐらいになってしまう。） ここはセキュリティ面とのバランスが難しいところではありますが… とはいえ、GitHub に何かあってソースコードが流出した場合に影響の大きさが懸念されるサービスについては、GitHub を利用しない、といった判断もしています。（で
仕事で使ってる巨大SVNレポジトリをGithubに移管するためにやったことまとめ · DQNEO日記
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに１個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
「githug」でgitの基本操作を算数ドリルみたいに学ぼう！ | Act as Professional
GitHubのイベントである「The GitHub poweredby Agile渋谷 〜日本のSOCIAL CODINGの今を見る〜」の懇親会を受付始めました@HIROCASTERでございませう。 イベント参加者以外でも参加可能のため、イベントは補欠だったけど、どういうふうにGitHubを使っているのか聞きたい人は、ご参加ください。（イベント参加者優先で、空気読んで登録してください） イベントではGitHubの話をするので、Gitが使えることが前提になっています。 そこで、Gitの基本操作方法を学べる「githug」を紹介します。 githug Gazler/githug 「githug」はgitの基本操作を実践的に学ぶための良いソフトウェアです。 特に他のバージョン管理システムを使ったことのある人がgitの基本操作だけを学ぶだけならちょうど良い。 インストール gemで公開されているの
プライベートな git リポジトリを手軽に用意する。 - D.
プログラマなら誰しも自分用のプライベートな git リポジトリを持っていることだろう。 いままで自分専用のリポジトリを利用するために github を利用してきた。 github は Web インターフェースを備えており Wiki や Graph などチームで開発をするために有用な機能がある。 しかし github でリポジトリを非公開にするには課金しないといけない。そのためいままで必要に迫られて課金してきたのだが、よく考えると自分専用のサーバー群を格安で持てるこの時代に最低月 7 ドルもリポジトリのためだけにマネーを支払うのはなんとも勿体無い話である。上記のリッチな付加機能も自分一人で利用するならほとんど必要無い。 そこで自分のサーバーに git のリポジトリを用意することにした。セキュアにしたいので通信プロトコルは ssh を利用することにする。そのやり方をメモしたので公開する。 新し
SVN to Git Migration - TMate SubGit
This site uses cookies to improve your customer experience. For more details please read our Privacy Policy. The ultimate solution for SVN to GIT migration Works on all platforms! Choose yours. TMate SubGit is a tool for teams that migrate from SVN to Git. It converts SVN repositories to Git and allows you to work with both systems simultaneously. GET STARTED Create an SVN || Git Mirror with SubGi
A successful Git branching model を翻訳しました
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら： http://nvie.com/posts/a-successful-git-branching-model/ （翻訳の公開と画像の利用は本人より許諾済みです） このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
自分用のGit備忘録 - kanonji’s diary
gitはコマンド体系が複雑で、なかなか覚えられないので備忘録をつけます。細かすぎて毎回エントリー作るのもなんだし、でもまとまるまで待ってると忘れちゃうので、備忘録にしたいなーと思ったときに追記する形にしようかな。なので、随時追記していきます。 自分用のLinuxコマンド・シェルコマンド備忘録 - kanonjiの日記 自分用のVim備忘録 - kanonjiの日記 他にLinux(とMacの場合もあり)のコマンドとvimの備忘録も貯めてます。 ローカルに既にあるリポジトリを、githubにpushする githubでリポジトリを作る。 ローカルでpush出来る状態にしておく。*1 $ git remote add origin git@github.com:username/foo-repos.git $ git push -u origin master 例としてusernameというユ
Git使いがMercurial使いに転職するとき設定しておくべきMercurial拡張 | Webシステム開発／教育ソリューションのタイムインターメディア
Mercurialは、Merucurial拡張という拡張モジュールを使って、Merucrialの挙動をいろいろ拡張できるようになっています。 デフォルトのままだと使いにくいので、Mercurialを使う上で便利にしてくれる拡張を設定しておきましょう。 デフォルトでバンドルされているMercurial拡張は、Using Mercurial Extensionsにまとめられています。 今回はGit使いがMercurial使いに転職するときに、Gitで実現できたことをMercurialで実現するための、組み込み拡張、および、サードパーティ製の拡張について紹介します。 色づけしよう ブランチの確認、diff、パッチ等々、色づけされていないとつらいです。 というわけでGit同様に色づけしましょう。 Color Extensionはすでにバンドルされているので、.hgrcに次の記述を加えましょう。 こ
Gitのベストプラクティクスっぽいもの - Sexually Knowing
tbaggery - A Note About Git Commit Messages A successful Git branching model » nvie.com Commit Often, Perfect Later, Publish Once—Git Best Practices だいたいこれらに書いてあることを考えている。 基本的にGit Successful Branch Modelで運用する。git-flowを入れて使っているけど、手でやってもそんなに面倒ではないし好きなようにしたらよさそう。 Subversionを個人で使っていたころはブランチはよくわからないけど恐しいものだったけど、Gitを使いはじめてだいぶ親しめるようになった。 文字通り、ブランチ、枝である。気軽に扱えるということは理解の助けにもなる。 コミットの単位 論理的に最小限度のコミットをつくる。「こう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
A Visual Git Reference