Pijul という VCS を体験した - Qiita
まえがき 今年は色々あって、時間も取れずアドベントカレンダーにいまいち乗り切れないまま11月となってしまった。 とはいえ、せっかくの機会なので、前年の様に手を動かすことにこだわらず、気軽に今年気になったツールの体験記や情報まとめでも記して行こうと思う。 Pijul とは 分散型バージョン管理システム (distributed version control system) 。 Git や Mercurial の仲間。 プロジェクト自体は約 3年前にスタートしていて、今年の 11月に 0.11 がリリースされた。まだまだ若い VSC。 特徴 その最大の特徴としては、カテゴリー理論 (パッチ理論) をベースとしたデータモデルを採用している事 らしい。 カテゴリー理論 (パッチ理論) カテゴリー理論 (パッチ理論) について深掘りする心の余裕が無かったので、とにかく情報だけ集めた。 https:
なぜVCS(Version Control System)を使うのかを考える - Qiita
はじめに gitこわいみなさんこんにちは！ チーム内ではgitおじさんとして日々活動しています。意外と(?)git苦手なひと多いですよね。最低限の操作はできても、何のために、どのように使うのが適切かを意識しているひとは少ないと思います。 本記事は自分のチームに向けて、なぜgitを使うのか、どんな使い方が適切かを理解してもらうために書きます。 なぜ使うのでしょうか。まずはここから考えていきます。 ちょうど最近読んだベタープログラマに効果的なバージョンコントロール(p179)という章があります。そこを見て考えてみましょう。 使いなさい、さもなければ失われる(p180) 開発者にとってバージョンコントロールは、食事したり呼吸したりするようなものです。(p179) 本書ではここまで言い切っています。 バージョンコントロールを使ってください、使わないという選択はありませんし、あればよいというツールで
commit をどう分割すべきか 〜コードレビューの観点から〜
普段の開発の中で git の commit の単位に気を遣っている人もいると思うんですが、どういう単位で commit すべきかみたいな話をあまり見かけない気がします。自分自身 GitHub の Pull Request（以降 PR）ベースのチーム開発を何年か経験してみて、「こうすると良さそう」というものが見えてきた気がするのでまとめてみました。 なお、小さい単位で PR を出す方針にしている場合は、以降の内容に出てくる commit を適宜 PR で読み替えてもらうと良いかもしれません。 そもそも commit の単位に気を遣った方が良いのか？ コードレビューを行う場合など、他者がコードを読む場合はある程度気を遣った方が良いと思っています。理由は次のとおりです。 コードレビューにおいてレビュアーのレビュー時間が短縮できる コードレビューの精度が上がる 変更の経緯を追いやすい 自分にとって
【初心者向け】「コミットの粒度がわからない問題」の模範解答を考えてみた - Qiita
はじめに 先日参加したRails Developers Meetupの中で、「コミットの粒度がわからない問題」が少し話題になっていました。 「commitの粒度がわからない」すいません、私もです…！よく迷っちゃいます…！！！ #railsdm — まえとー (@maetoo11) July 20, 2017 commitの粒度がわからない問題、ある。（ほんとわからない） #railsdm — おおた (@ota42y) July 20, 2017 普段僕は感覚的に「それっ、ここでコミット！」とコミットしているんですが、具体的にどういうルールでやってるの？と聞かれると、きれいに明文化しづらいものです。 とはいえ、できるだけ明文化できるよう、模範解答を考えてみました。 この記事ではそんな「適切なコミット粒度」について解説します。 動画で明文化・・・！？ すいません、「明文化した模範解答」という
Fossil: Documentation
Fossil: 分散 リビジョンコントロール, Wiki, バグトラッキング Fossil は 分散ソフトウェアバージョンコントロールシステムの一種であり、統合された 分散 wikiおよび 分散 バグトラッキングシステムを 含む、使いやすい 1実行ファイルに全てを含んだパッケージである。 Fossil は自分自身でホスティングでき、 2007-07-21 から 2つのサーバ上で動作している。 読者はここから最新のソースを得て 自分でコンパイルするか、あるいは コンパイル済みバイナリを ここから取得できる。 機能概要: 柔軟なワークフロー: gitや、 monotone、 mercurial、 bitkeeperなどのような 分散された非接続状態での開発が可能 もしくは CVSや subversionのような クライアント・サーバによる開発作業 また、ローカルのリポジトリに対する操作 これら
vcs_infoを使おう
11. vcs_infoの設定例 とりあえずこれを~/.zshrcにコピペ autoload -Uz add-zsh-hook autoload -Uz vcs_info zstyle ':vcs_info:*' formats '(%s)-[%b]' zstyle ':vcs_info:*' actionformats '(%s)-[%b|%a]' function _update_vcs_info_msg() { psvar=() LANG=en_US.UTF-8 vcs_info psvar[1]="$vcs_info_msg_0_" } add-zsh-hook precmd _update_vcs_info_msg RPROMPT="%v"
エクセルで「上書き保存」は事故のもと。では、どうするか？
ボストン大学卒業後、モルガン・スタンレー証券投資銀行本部に入社し、大型M&Aや資金調達プロジェクトをリード。退社後はグロービス経営大学院にてMBA取得、その後、大手上場インターネット企業に入社し、事業責任者として事業計画の立案から戦略遂行までを行う。現在は、スマートニュース株式会社にて、収益計画策定、資金調達、上場準備など財務企画業務全般をリード。「グローバル投資銀行のエクセルスキルを、分かりやすく伝えたい」というモットーの下、2013年10月から週末に個人向けエクセルセミナーを開催したところ、参加者数は1年で3000人を超え、大人気セミナーとなった。現在は、個人向けセミナーに加えて、企業研修も数多く開催しており、多くのビジネスパーソンの収益計画の作成指導を行っている。https://www.facebook.com/simulation2013/ 外資系投資銀行のエクセル仕事術 ウェブ版
コミットログを綺麗にする努力をする。 - パルカワ2
綺麗なコミットログとは 綺麗なコミットログとは、コミットログを見返す時に知りたい事を知れる。 コミットログを見返す時は、「なにをしたのか」と「なぜその変更を行ったか」を知りたい。つまり、「なにをしたのか」と「なぜその変更を行ったか」を書けば綺麗なコミットログになると言える。 ファイルを変更した場合 一行目：「何」に「どういった」変更を行ったかを簡潔に書く（要約） 二行目：改行がないとおかしいことになるので、二行目は必ず改行する 三行目以降：一行目に書いた変更を「なぜ」行ったかを書く 例 HogeViewはpiyo時にfugaするように変更 fugaしないと〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜が起きて 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜で 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜なので フィードバックの対応などした場合 一行目、二行目は、変更した場合と同じ 三行目以降：フィードバ
集中型バージョン管理システムと分散型バージョン管理システムって - 未来のいつか/hyoshiokの日記
集中型バージョン管理システム（以下CVCSとする）と分散型バージョン管理システム（以下DVCS）って何がどうよかったり嬉しかったりするのだろうか。というようなことをつらつら考えてみた。きっかけは、gitの話とか、そのあたりから。（gitって難しいのかなー http://d.hatena.ne.jp/hyoshiok/20140201/p1 ） バージョン管理システム（VCS）のキモは複数人での共同開発を支援するということにつきるかと思う。http://d.hatena.ne.jp/hyoshiok/20140204/p1 一人で開発していればコミュニケーションロスはないので、ひたすらズンズン開発するだけである。一方で複数で開発していれば、どのようにしてコードを共有し統合しテストするかという問題があって、その作業を支援するのがVCSやソフトウェア構成管理と呼ばれるものである。ソフトウェア構成
社内にGITを持ち込むために上の人を納得させるセリフ集 - Qiita
Gitアドベントカレンダー10日目です。 10日目で区切りもいいので少しネタ臭い内容を。 攻め文句 「継続的リリースを支える運用フローに、gitflowは最適」 現場でgitを押す理由としては、ほんとにコレに付きます。学習コストを差し置いてでも導入したい、という点にまずコレが挙がるんじゃないでしょうか? 機能ブランチとチケット駆動開発の流れ、それにSVNのチェリーピックを露骨に危険&手間とアピールしていけばgitの重要性は認識してもらえるはず。 「世界中で採用されているgithubで、ソーシャルライクな社内開発コミュニケーションを」 お金に余裕のあるところでは、是非ともgithub enterpriseを検討してもらいましょう。開発はコミュニケーション命、的な話でコミュニケーションの重要性を説くといいと思います。 開発者としても、Web上でソーシャル的にコードレビューなどを行えるのは非常に
Google の巨大レポジトリとブランチ無し運用 - Kato Kazuyoshi
GTAC 2013 Opening Keynote の Evolution from Quality Assurance to Test Engineering (スライド) を見た。 スライドの7ページ目 によると、Google では 15,000 あまりの開発者が、40 あまりの拠点に分散している。そして、彼らはひとつの巨大なレポジトリで、ブランチなしに開発しているらしい。 Single monolithic code tree with mixed langauge code Over 100 million lines of code. 50% of code changes monthly. Development on one branch - submissions at head 講演ではこの理由について One of the benefit is that we don’
知らないと現場で困るバージョン管理システムの基礎知識
知らないと現場で困るバージョン管理システムの基礎知識：DevOps時代の開発者のための構成管理入門（3）（1/3 ページ） 「DevOps」という言葉にもあるように、ソフトウェア構成管理は、インフラ運用に取り入れられるなど、変わりつつある時代だ。本連載では、そのトレンドにフォーカスして、現在のソフトウェア開発に有効な構成管理のノウハウをお伝えする。今回は構成管理に不可欠ともいえるバージョン管理について、ブランチ機能を中心に紹介。SubversionからGitへの移行事例も。 いまさら聞けない「バージョン管理」とは 第3回目となる今回では、構成管理において「過去のある時点の状態をどのように復元するか」を実現するために不可欠ともいえるバージョン管理とバージョン管理システムについて紹介します。 「集中管理方式」と「分散管理方式」 バージョン管理システムとは、ファイルに対して「誰が」「いつ」「何を
あるプロジェクトのMercurial導入の軌跡 - 放牧日記
このエントリはMercurial Advent Calendar 2011 - PARTAKEの25日目です。 3月からMercurialを使い始めたので12月で9ヶ月目になります。一年の振り返りという事で、Mercurial導入の軌跡について簡単にまとめたいと思います。*1 Mercurialとの出会い Mercurialと出会う前はSubversionとちょっとだけGitを触っていました。とくにSubversionは仕事でかなりがっつりブランチの運用*2を行っていました。 嫌になるほどSubversionを使うプロジェクトでは次の問題が発生していました。 Subversionでのブランチマネジメントはマージ担当者の負荷が高すぎる リポジトリが巨大になりすぎてsvn stするだけでも20秒 リポジトリが巨大になりすぎてsvn upが終わらない 部分svn upし出す人が増え、整合性に関す
バージョン管理ソフトウェアの寿命は10年？
Gitが10年後存続してるとは思えないけど、Excelが10年後に消えてる筈がないだろ！！と熱弁してる — （あんちべ 心はS式とともにあります） (@AntiBayes) December 5, 2012 言うまでもなく、gitは今をときめく流行のバージョン管理システムである。たったの10年後に存続していないのだろうか。 gitが登場したのは2005年だ。githubが登場したのは2008年だ。githubは直接関係がないが、gitの価値を押し上げたといえる。それ以前、自由なソフトウェア実装によるバージョン管理システムといえば、Subversionが有名だった。Subversionは、2000年に登場している。2010年、gitは流行していた。いま、SVNがgitの流行に押されているのを考えると、たったの10年でよく変わったものだ。 Subversion以前、自由なソフトウェア実装で有名
DVCSのリンク集 - うさぎ組
共有したい個人メモということで。会社の人とかね。 雑感。DVCSの情報は、不正確なコピペ情報が反乱していて、Git, Hgあたりは結構ひどい。有用なやつはTipsとしてまとめたけど、なかには誤読すると大変なものもある。 「急がば回れ」的に基本から勉強するのが間違える可能性がかなり低くなる。 基本から体系的に学べるものは各DVCSのガイドにした。 ガイドにあがるようなものでも、15hくらいあればハンズオンしながらでもこなせるので、仕事中に困りながら1weekうまくいかないくらいなら、基本からやって、出来る範囲だけを仕事でやるほうがいい。 正直、DVCSなくても仕事できるし、出来る前提の職場なら、職場のワークフローを先輩に聞きながら1weekくらい作業すればいい。 SCM 概念とか DVCSについてだし、書きかけ。【5分でわかるDVCS！ + 20分でわかるGit入門 by Kyon Mm o
git(VCS)の未来について - 西尾泰和のはてなダイアリー
gitが素晴らしいとか自由度が高すぎてわかりにくいとかUIが酷いとか色々議論になっているけど、ちょっと歴史を振り返ってみると 1990 CVS 2000 Subversion 2003 SVK = Subverionをラップして分散バージョン管理に対応 2005 Git 2008 GitHub = Gitをラップして「ワークフローを限定してわかりやすく」 2010 gitflow = Gitをラップして「ワークフローを限定してわかりやすく」 2012 今ここ と進んできているんだからきっと2020年頃には GitHubやgitflowのような「ワークフローを限定してわかりやすくしたバージョン管理」がメジャーになってますよ。 近いうちに、かつて「svnは小学生までだよね、これからはSVKだよ」と言われたように「Gitを生で使うなんて小学生までだよね」と言われるようになり、 次に、かつて「SV
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コミュニケーションツールとしての Git & GitHub
【いまさら聞けない】初めてバージョン管理システム（Subversion、Git など）を使う時はここに注意 | バシャログ。
英語コミットコメントに使えるオシャレフレーズ集
DVCS workflows for Bitbucket | Bitbucket Cloud | Atlassian Support