はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
「こわくない Git」というスライドを発表しました - kotas.tech
社内向けに「こわくない Git」というタイトルのスライドを作って発表しました。 対象者は「マージがなんとなく怖い」「エラーが怖い」「リベース使うなって言われて怖い」と、Git が怖いと思っている人です！ こわくない Git from Kota Saito 発表中に出た質問など 補足も兼ねて、上のスライドを発表した際に出た質疑応答などをここに書いておきます。 Q: 常に Non Fast-Forward (--no-ff) でいいのでは、と思えるけど git merge がデフォルトだと Fast-Foward or Non Fast-Forward (--ff) なのはなぜ？ A1: Non Fast-Forward だと、確かにメリットが多いのですが、1点だけデメリットがあります。特に差分が無い状態で git merge --no-ff すると、空のマージコミットが作られてしまうのです。
天下一gitconfig大会
天下一gitconfig大会(サイボウズ社内git勉強会@2012/11/20)の@teppeisの資料です。 ぎっとぎとにしてやんよ GistDeck gistでmarkdown書いたらbookmarkletでプレゼンになるよ。 ↓これをBookmarkに登録してこのページで実行してみよー！ javascript:(function()%7Bvar%20s%3Ddocument.createElement(%27script%27)%3Bs.setAttribute(%27src%27,%27https://raw.github.com/teppeis/gistdeck/fix/gistdeck.js%27)%3Bdocument.getElementsByTagName(%27head%27)%5B0%5D.appendChild(s)%3B%7D)()%3B 複数行のcodeとかが微
最近の git の使い方について - tomykaira makes love with codes
先日の #shibuyarb の懇親会ですこし話したら、わりと食い付いてもらえたので、 knowledge worth spreading だと感じた。git の設定を中心に共有する。 ワークフロー @kyon_mm さんの Continuous Commit の熱心な信奉者である。 Continuous commit とは continuous integration, continuous delivery とおなじように、開発中のコミットを自動化する試みである。 continuous commit という言葉はなくても、おなじようなことを自分でやっているひとは多そうだ。 continuous commit は大量のコミットログを残すので、これを整理する作業はけっこう負荷が大きくなる。 最近はこのあたりを改善している。似たようなワークフローを採っている人には役にたつと思う。 コミットを
仕事で使ってる巨大SVNレポジトリをGithubに移管するためにやったことまとめ · DQNEO日記
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに１個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
gitのbareリポジトリのバックアップをとる - tumblr
チームでgitを使うときは個人の公開リポジトリから適宜pullする、なんてことはせずにsvnのように中央集権的なbareリポジトリを作ることになると思います。 で、そのリポジトリが吹っ飛んだときとかは、分散型の特性を生かして個人のリポジトリをドラゴンボールみたいに寄せ集めて願い事を唱えながらmergeをしてbareリポジトリを蘇らせるというナメック式バックアップを取ることもできますが、やはりここは宇宙人のなかでもダントツでかしこいとされる地球人らしさを見せておきたいわけであります。 というわけでbareリポジトリのバックアップをとりたいのです。 ベタにrsyncとかscpでリポジトリまるごと日次バックアップというのもいいのですが、その場合バックアップ時刻からリポジトリが吹っ飛んだ瞬間の間にpushされていた変更は失われてしまうわけです。失われた分をわざわざpushするのは地球人らしくありま
GitHub Flow (Japanese translation) Latest version is here: https://gist.github.com/Gab-km/3705015
GitHub Flow Scott Chacon on the Interwebs 31 Aug 2011 git-flowの問題点 (Issues with git-flow) 私は人々にGitを教えるためにあちこちを飛び回っているが、最近のほぼすべてのクラスやワークショップでgit-flowについてどう思うかを尋ねられた。私はいつも、git-flowは素晴らしいと思うと答えている。何百万ものワークフローを持ったシステム（Git）を提供し、ドキュメントもあるし、よくテストされている。フレキシブルなワークフローは、実に容易なやり方で多くの開発者の役に立つ。標準的なものになりつつあり、開発者はプロジェクトや企業の間を移動しつつこの標準的なワークフローに馴染むことができる。 しかしながら、それ故の問題も抱えている。新しいフィーチャーブランチをmasterではなくdevelopから開始するとか、
git flow でのチーム開発ワークショップ資料 - Yamashiro0217の日記
この記事は会社内の別チームの方に、 僕の今のチームで git をどう運用してるかを ワークショップ形式で説明するための資料である。 事前準備 git と git-flow を入れておくこと 参考資料(Macでgitとgit-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ブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
Lightweight git hook management tool その名も git-hook を作りました - 鳩舎
どうもこんにちは。フックしてますか。ジャブからローにつなげてますか。 そんなこんなで最近は僕もそこそこ git に慣れてきて助けてもらわなくても良くなって来ました。 しかし人間の欲望はとどまるところをしらず、「なんか定形作業めんどくせーなだるいしなんかうまいことどうにかなれよ面倒くせぇ」とか考え始めるものです。たとえば「テスト通ってないコードコミットするなってリーダーがいうけどいちいち手でテスト走らせて確認すんのだるいからなんかうまいこと自動で動かんかな」とか。 git は大変よくできたツールですので、そういうのもちゃんと用意されています。hooks といって、コミットのタイミングなどで特定のシェルスクリプトなりなんなりを動かすことが出来るよう配慮されているのです。すげーな git 。 しかしこいつがマジめんどくさい。自分でシェルスクリプト書くとか絶対嫌だし、すでにそのへんに転がってるのを
The GitHub poweredby Agile渋谷 に参加してきた #Agile渋谷 - Diary of absj31
The GitHub poweredby Agile渋谷 : ATND 「The GitHub」イベント詳細発表！話題のあの人が登壇 #Agile渋谷 | Act as Professional - hiroki.jp by HIROCASTER 2012/06/23 The GitHub poweredby Agile渋谷 #Agile渋谷 - Togetter (写真：この日発売となった書籍『WEB+DB PRESS』最新vol.69。主催者である(@hirocaster)さんの渾身の執筆記事を掲載！) 最近プライベートでは勉強時の写経や個人開発プロジェクトなどでMercurial(＆Bitbucket)を利用しているのですが、Git(及びGithub)も最低限使えるようにしとかないとこの先アカンな、と思う部分があったのでイベント告知がされた際には即申込み。主催の@HIROCASTER
HubFlow: GitFlow For GitHub
HubFlow: GitFlow For GitHub Introduction At DataSift, we’ve standardised on: using Git for our source control, using GitHub to host our public and private Git repositories, and using GitFlow as our common workflow This website explains how we’ve adapted GitFlow and the GitFlow tools git extension for working with GitHub. This is how we work internally, and we’re sharing this in the hope that other
Git submodule の基礎 - Qiita
この記事は Git Advent Calendar 6日目の記事です！ Git submodule って最初わかりにくいと思うので、基本的な説明をしようと思います。 git submodule とは git submodule は、外部の git リポジトリを、自分の git リポジトリのサブディレクトリとして登録し、特定の commit を参照する仕組みです。 Subversion でいうところの、external と似ています。 さて、解説のため、手元に、リポジトリA (/path/to/a) とAの submodule として、よく使う例として Bootstrap (元Twitter Bootstrap) を登録してみます。 git submodule を理解するうえで重要なのは、 リポジトリAが指し示すsubmoduleとしてのBootstrapのcommit 現在のBootstr
Redmine, git, Jenkinsの状態を横断的かつリアルタイムに表示する『Dashbozu』をリリースしました。 - みずぴー日記
Redmine, git, Jenkins などプロジェクト管理ツールの状態を横断的かつリアルタイムに表示するWebアプリ『Dashbozu』を作りました。 これを使えば、一つの画面でプロジェクトの”今”の状態を把握できます。 WebSocketを用いているので、ただ開いているだけで、次々と情報を得ることができます。 iPadで開きっぱなしにして、机の上に置いておくような使い方を想定しています。 なぜこれを作ったか 一般的なソフトウェア開発現場では Redmineでチケットを作成する gitでコミットを繰り返し、中央レポジトリにpushする JenkinsによるCIが実行される 結果を確認し、Redmineのチケットを閉じる という流れで作業が進んでいきます。 これらの作業の中で、開発者は「適切な」タイミングでチェックとフィードバックをすることを求められます。 例えば、チェックのタイミング
Changelogのための英文テンプレート集 - ぴょぴょぴょ？ - Linuxとかプログラミングの覚え書き -
Changelog を英語で書く際に参考になるようなテンプレートをまとめてみました．git や svn のコミットログにも使えます． このエントリは今後も逐次更新を続けます（最終更新2018/11/01） リリースノートの英文についてはRelease note のための英文テンプレート集 - pyopyopyo - Linuxとかプログラミングの覚え書き -に分離しました git等のcommit メッセージにも使えます 以下，例文． バグ修正した場合 修正した場合 → fix を使うのが定番です Fixed a performance regression. （パフォーマンスが低下するバグを修正しました） Fix possible memory leak Fixed an issue where some devices would display the wrong image. (いく
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を使いはじめてだいぶ親しめるようになった。 文字通り、ブランチ、枝である。気軽に扱えるということは理解の助けにもなる。 コミットの単位 論理的に最小限度のコミットをつくる。「こう
Octopressのインストールから運用管理まで - T.I.D.
あらためて GitHub へのインストールから、GitHub Pages への記事投稿、Bitbucket での原稿管理までをまとめておく。 インストールは、公式サイトの Octopress Setup に従う。 GitHub Pages には、ユーザーページとプロジェクトページがあるが、以下ユーザーページ用を主とする。 1. Octopress 利用の前提条件 Git + GitHub アカウント ruby 1.9.2 1.9.3 以上 + RubyGems RubyGems は、ruby 1.9.2 以上であれば インストーラー のパッケージに含まれているという情報が多い（特に Windows）。 Mac であれば、rvm からアップデートする。 また、gem は gem update --system で最新版にしておく。 2. GitHub ユーザーページ用リポジトリの作成 Git
git pullの詳細な挙動を追ってみる - hokaccha memo
git push/pullは何気なく使ってるけど実はよくわかってなかった。ことのきっかけはこういう質問。 hogeというリモートブランチをローカルのhogeブランチにもってきたい hogeをローカルのmasterにはマージしたくない pullでなんかこんな感じでいけそう？ $ git pull origin hoge:hogeでもこれは間違えで、なぜか今いるブランチ（master）にhogeがmergeされるし、期待してる動作じゃない。正解はこう。 $ git branch hoge origin/hogeもしくはチェックアウトも同時にするなら $ git checkout -b hoge origin/hogeこう。自分は普段後者のやり方でやってたけど、なんで上のはダメで下のが正解なのか説明できなかったのでちゃんと調べてみた。 入門Gitと実用Git、あとhelpを参考にした。 ブランチ
fugitive.vim が便利すぎたのでメモ - 反省はしても後悔はしない
Vim から Git を操作するプラグインとしては、今まで git.vim を使っていたんですが、fugitive.vim のほうが便利だったので乗り換えました。 詳しい説明はここ VimmerなGit使いはfugitive.vimを今すぐ入れたほうがいい - SELECT * FROM life; ここでは、自分が特に便利だと思った機能を書きます。 git add -p をグラフィカルに行う git add -p を使うと、複数の変更箇所のうちどの変更をコミットに含めるかを選ぶことができますが、fugitive の :Gdiff を使うとこれをグラフィカルに行うことができます。 :Gdiff コマンドはインデックスとワークツリーの状態の差分を vim の diff で表示します。 こんな感じ たとえば、スタイルシートの設定（上のほうの差分）はコミットに含めたいけど、クラス属性の付与（下の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サル先生のGit入門〜バージョン管理を使いこなそう〜【プロジェクト管理ツールBacklog】
