Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩
| 書籍紹介 | サイトの目的 | ダウンロード | 更新情報 | 謝辞 | お問い合わせ | 書籍紹介 Git は、 Linux カーネル開発のために Linus Torvalds さんが2005年に公開した分散型バージョン管理システムです。スタートアップのような小規模組織からGoogle、 IBM のような巨大企業で、また数多くのオープンソースプロジェクトで利用されています。現在の Git 開発は、濱野純さんを中心としたコミュニティによって非常に活発に行われています。 本書 Pro Git は、2009年に Apress から初版が、2014年に第2版が出版された、Git の解説書です。著者の Scott Chacon さんは、GitHub 社の CIO、Git のエバンジェリストであり、Git 公式サイトの管理者でもあります。 本書の内容は、出版以降も有志により頻繁に更新されており、
Easy to install Simply run the binary for your platform. Or ship Gogs with Docker or Vagrant, or get it packaged. Cross-platform Gogs runs anywhere Go can compile for: Windows, Mac, Linux, ARM, etc. Lightweight Gogs has low minimal requirements and can run on an inexpensive Raspberry Pi. Some users even run Gogs instances on their NAS devices.
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか? この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
分散バージョン管理を華麗に扱いたい堀口です。 GREE Advent calendar 2013 の 14 日目として参加させていただきます。 お二人に続き Haskell の話をしようかと思ったのですが、急遽無難な開発の話に変更しました :o Java や C++ には OOP の概念が必要であったように、分散作業の認識が薄いまま git や Mercurial を使うことは長期的に不幸をもたらします。 とあるプロジェクトにて、その一部を副産物のミドルウェアとして抽出すべく、アプリケーションと分離したい 不具合があったので原因を探りたいが、依存関係が複雑すぎるのでコードを読む量を減らしたい テストやレビュー、提案、リファクタの運用を強化したい よそのプロジェクトに迷惑を掛けないように、そこのツールを改良して使いたい。 いままで何気なく「こんなもんだろう」と思って手間をかけていませんでした
gitはコンソール(コマンドライン)で使うのが当たり前でしょ、みたいな空気がちょっと嫌だったり、実際Windows用のgit系ツールのGUIがげんなりするほど酷い完成度だったりしたこともあり、ぶっちゃけhgの方が使いやすいよね、と思わなくもないMercurial派のサイボウズ・ラボ 中島です、こんにちは。 まぁ、そうは言っても使わなくてはならなんこともあ...、じゃなくて、ぼちぼちWindows環境でもいい感じにGUIで使えるgitツール群が揃ってきたので簡単にまとめてみました。 …と言っても、GUIだけにほとんどインストールして実行するだけであります。 入れるのはこの3つ、(ただし、残念ながらどれも今の所は英語UIのみです) Github for Windows SourceTree for Windows Visual Studio Tools for Git Extension この
ぽちぽちと git を使っていたら、変更したはずのないファイルが変更扱いになっていて悩みました。 Visual Studio で変更してないのに Ctrl+S を押すと git では変更扱いになるの何でだ— しばやん (@shibayan) May 29, 2013 他のリポジトリでは発生していなくて、ある一つのリポジトリだけでこの現象が起きていたので Twitter で呟いたところ、UTF-8 の BOM が原因だと教えてもらいました。 @ishisaka @shibayan 手元のVST4GやTortoiseGitは反応し無いようなので、BOMや改行コードの問題な気が...— Kaoru Nakajima (@kaorun) May 29, 2013 Visual Studio はデフォルトで UTF-8 のファイルに BOM を付けるようになっているので、プラグインを入れて BOM
共有gitリポジトリをホストする方法をググると、WebDAVを使ったやり方が結構出てくる。このやり方には明確なデメリットしか無いにもかかわらず、WebDAVを使ってホストする方法を紹介するページでは触れられていないことが多い。まったく大した話ではないが、開発者が二度とひっかからないためにリポジトリのホストにWebDAVを使わないほうがいい理由を書いておく。以下、2つ。 WebDAVを通じてホストすると遅い WevDAVを通じてホストするとサーバサイドフックが起動しない 遅い 超遅い。ベンチマークを測ったわけではないが、sshでホストする場合と比べてcloneやpushやpullが3倍以上遅いのではないか。 WebDAVでホストすると遅くなってしまうのには理由があって、sshでホストする場合とWebDAVでホストする場合とでは、そもそもの通信プロトコルが違うから。pro gitを参照すると、
社内向けに「こわくない 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 すると、空のマージコミットが作られてしまうのです。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く