GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット － Publickey
果たしてGitLab.comで何が起きたのでしょうか？ これまでの経緯をまとめました。 スパムによるトラフィックのスパイクからレプリケーションの不調へ GitLab.comは今回のインシデントについての詳細な経過を「GitLab.com Database Incident - 2017/01/31」で公開しています。また、もう少し整理された情報がブログ「GitLab.com Database Incident | GitLab」にも掲載されています。 これらのドキュメントを軸に、主なできごとを時系列に見ていきましょう。 1月31日16時（世界協定時。日本時間2月1日午前8時）、YP氏（Yorick Peterse氏と思われる）はPostgreSQLのレプリケーションを設定するためにストレージの論理スナップショットを作成。これがあとで失われたデータを救う幸運につながります。 1月31日21時
GitLab.com Database Incident - 2017/01/31
This incident affected the database (including issues and merge requests) but not the git repo's (repositories and wikis). Timeline (all times UTC): 2017/01/31 16:00/17:00 - 21:00 YP is working on setting up pgpool and replication in staging, creates an LVM snapshot to get up to date production data to staging, hoping he can re-use this for bootstrapping other replicas. This was done roughly 6 hou
初心者でもわかる！リベースの使い方を解説します | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
こんにちは、エンジニアの王です。今回は、Git初心者を悩ませるリベースについて解説してみたいと思います。 リベースが初耳 リベースを聞いたことはあるけど、使っていない 不安を抱えながらも、リベースをなんとなく使っている 上記に当てはまる方は、ぜひ読んでくださいね。 リベースで何ができる？ コミットが綺麗になる！ 以上です！ この一言に尽きる！ 具体的にどのように綺麗になるかというと…… コミット履歴がわかりやすくなる コミットメッセージを後から変える コミットの順序を後から変える 2つ以上のコミットを1個に統合する 一度コミットした内容を編集する といった具合でしょうか？ 整理整頓が好きな方は、ぜひリベースを使いこなしていただきたいと思います！ マージとリベース 2つのブランチの変更点を統合するとき、Gitの最も一般的なやり方は、マージとリベースを使うことです。マージは初回で説明したので、
GitX
GitX GitX is a git GUI made for Mac OS X. It currently features a history viewer much like gitk and a commit GUI like git gui. But then in silky smooth OS X style! Features Detailed history viewer Nice commit GUI, allowing hunk- and line-wise staging Fast workflow Explore tree of any revision Nice Aqua interface Paste commits to gist.github.com QuickLook integration Requirements GitX runs on Mac O
Github で Fork してから Pull Request をするまでの流れ | けーこ in サンフランシスコ
いつも忘れてしまうので、GithubであるプロジェクトをForkしてからPull Requestをするまでの流れをメモしたいと思います。今回、実際に私がこの流れを使っているCordova (PhoneGap) ドキュメントのプロジェクト、 https://github.com/apache/incubator-cordova-docs を例にやっていきたいと思います。 1. Fork する GithubでForkしたいプロジェクトまで行って、右上にあるForkボタンを押します。今回、 https://github.com/apache/incubator-cordova-docs をForkしたので、私のGithubアカウントkeiko713上では https://github.com/keiko713/incubator-cordova-docs というリポジトリが作成されます。 2.
GitBucket 3.14と4.0をリリースしました - たけぞう瀕死ブログ
Scalaで実装されたオープンソースのGitサーバ、GitBucket 3.14および4.0をリリースしました。 https://github.com/takezoe/gitbucket/releases/tag/3.14 https://github.com/takezoe/gitbucket/releases/tag/4.0 GitBucket 3.14は外部データベースのサポート以外は4.0と全く同じ機能を提供していますが、3.14は3系の最後のリリースとなり、今後は4系のみリリースされることになる予定ですのでご利用のプラグインの4系対応版がリリースされていないといったケースを除き、バージョンアップの際は4.0に移行することをお勧めします。ただし、既存のGitBucketを4.0に移行するにはいったん3.14にバージョンアップしてから4.0に入れ替える必要がありますのでご注意ください
CentOS 7でGitBucketを動かしてJenkinsで自動デプロイ - BLACKND
CentOS 7にLAMP環境を構築。GitBucketとJenkinsを動かし、自動ビルドや自動デプロイまでやってみます。 なぜGitBucketか GitBucketはGitHubクローンで、似たものに有名なGitLabがあります。 GitLabも最近はrpmコマンド一発でインストールできるほど簡単になっていますが、今回はより簡単 (.warファイルを置くだけ) で、見た目や使い勝手もGtiHubに近いGitBucketを選びました。 概要 ソースからのビルドは行わず、yumパッケージや.warファイルを使用Apacheのmod_proxy_ajpを使い、Tomcatへはポート8080ではなく80でアクセスGitBucketでリポジトリにpushがあったらJenkinsで自動ビルドJenkinsのビルドでは、rsyscでApacheの公開ディレクトリに自動デプロイ自動デプロイ時のユーザ
GitBucketのインストール＆ファイルの自動デプロイ - Qiita
と追記しました。これで起動時に自動起動して、すべてのファイルを /gitbucket ディレクトリ内で完結できます。 もう少しちゃんと自動起動する Upstartがインストールされていれば、 /etc/init/gitbucket.conf を作成して以下を記述します。 description "Gitbucket" author "Yamada Nanigashi" start on runlevel [2345] stop on runlevel [016] env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin exec java -jar /gitbucket/gitbucket.war --gitbucket.home=/gitbucket <?php $payload = json_decode
Gitbucketのプラグインを作成する - Qiita
GitBucket2.2がリリースされたようです。 最近地道に社内に広めている身としてはありがたい事に、プラグイン機能が実装された事を@takezoeさんのblogで知りました。 とはいえ、プラグインシステムはまだまだ試行錯誤を繰り返している状態なので、APIを含め今後大幅な変更が入る可能性が高いです。現状はあくまでお試し版といったところです。 と書かれていますが、試しにちょっと遊んでみました。 注意事項 勝手にソースを弄ってごにょごにょしているので自己責任でお願いします。 GitBucketの開発向けの起動の仕方や、Scalaの開発環境構築に関してはここでは触れません。 for Developers辺りを参考に構築してください。 前準備 デフォルトでは、https://github.com/takezoe/gitbucket_plugins.git がセントラルリポジトリとして設定されて
GitBucketインストール手順 - Qiita
GitBucketのインストール方法はとっても簡単。 gitbucket.warをデプロイするだけです。 アプリケーションサーバにデプロイする場合 GitBucketでは Tomcat 7.x Jetty 8.x GlassFish 3.x をサポートしています。 今回はtomcatへのデプロイ方法です。 warファイルダウンロード https://github.com/gitbucket/gitbucket/releases から最新バージョンのwarファイルをダウンロードしてきます。 tomcatへデプロイ CATALINA_HOME=/usr/local/tomcat の場合、{CATALINA_HOME}/webapps/以下に gitbucket.warを配置します。 tomcat起動 後は、tomcatを起動するだけです。 GitBucketへアクセス tomcatを起動したサ
gitとプルリクエストに関して思うことまとめ - Qiita
※この記事は元々「Gitのこれやめて！リスト」として2015年11月に投稿したものを改訂したものです。 この記事について 私が個人的にgitとプルリクエストについて、「こうして欲しい」とか「これはやらないで！！」とか思っていることをまとめたものです。 元々は2015年に私がコードレビューをしてる時に気になったことを、あまり推敲もせず思うがままに書いた記事でした。今改めて読み返すと稚拙な文章なのと、他に思うところとがあったりしたので、改めて書き直しました。いいね貰ってるのに書き直すのに若干後ろめたさがあるのですが、よりいい内容にできればと思います。 コミットログがきれいだとレビューしやすい 一人で開発するときはgit使っててもブランチ切らないし、プルリクもださないしで、コミットログも"First Commit"の次が"Second Commit"とかでも支障はないです。しかし、チームで開発す
git-svnでSVN→Gitへの移行をやってみたログ - Qiita
※本稿は諸事情により過去の投稿を再投稿したものです。 はじめに git-svn を使うと、素直な SVN リポジトリーなら簡単に移行できますが、実運用してきた SVN リポジトリーを移行する際はつまづくことも多々あります。 また Git リポジトリー化ができてもブランチやタグは手作業で作ることになります。 今回、たまたま移行を検討する機会があったので、その予行作業のなかで得た知識をメモしておきます。 作業を行ったクライアント環境は Ubuntu 14.04 / Git 1.9.3 です。 SVN リポジトリーは HTTPS でアクセスできる状態です。 移行の第一歩 まずは SVN リポジトリーからローカル環境に Git リポジトリーを作成します。 git svn clone または git svn init + git svn fetch を使います。 ヘルプや Book にも記載されてい
Gitの驚愕の真実：1億行のファイルに1行追記するとレポジトリ容量が200MB増える[※補足あり] · DQNEO日記
１億行のファイルに１行追記するだけでレポジトリ容量が２倍になった 以前の記事「Gitレポジトリはパッチの集積ではなくてスナップショットの集積である。」を確認するために、１億行のファイルを作って実験してみました。 結果は、なんと１行追記しただけでレポジトリ容量が200MB増加し、サイズが２倍になりました。 実験手順 空のレポジトリを作る １億行のファイルを作ってgit addしてgit commit コミットする そのファイルに１行だけ追記してgit addして git commitする 空のレポジトリを作る $ git init １億行のファイルを作る １億行のファイル(１から1億までの数字が書かれたファイル)を作ります。 $ seq 1 100000000 > numbers.txt この時点で、ワーキングツリーとレポジトリ容量を調べてみます。 $ ls -lh 合計 848M -rw-
git-cherry-pickを掘り下げる - idesaku blog
Gitにgit-cherry-pickという、知らなくてもなんとかなるが知っていると便利なコマンドがある。このコマンドを少し掘り下げてみた。 git-cherry-pick git-cherry-pickは、狙ったコミットの変更内容だけを現在のブランチに取り込む操作である。 例えば、つぎのような履歴を想定する。 ---A---B---C [master] \ \ ---X---Y [temp]ここで、YはCの後にコミットするほうが適切であることに気づいた。このとき、masterブランチで次のようにすると目的は達成される*1。 $ git cherry-pick YコミットYの変更内容だけをmasterのHEADに適用する、という操作である。このときXの変更内容は適用されない点がgit-mergeとは異なる。 ---A---B---C---Y' [master] \ \ ---X---Y [
巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
先祖返りした！:git事件帳 - つぶやき、メモ、写真、にゃど。
はじまり今日リリースの確認ををしていてびっくりした。 最近リリースした、いくつかのファイルが先祖返りしていた。 このままではリリースできない。 原因を突き止めて、解消しないと！ 捜査コミット調査githubでリリース対象のブランチのコミットを眺める。 怪しそうなのはなかった。 メンバーの作業ディレクトリメンバーの作業ディレクトリに、大量の作業中ファイルが残っており、 先祖返りしたファイルとほぼ合致した。 そういえば、ブランチの最新化をこっちでやろうとしたら、 コンフリクトしたので、担当のメンバーに解消をお願いしたんだった。 つまり、起きていたのはブランチを最新化するときに、コンフリクトがあり、 解消後のコミットしたときに、自分が触った記憶のないファイルを除いていた。 一時対応間違ったマージが入ってしまったブランチにコミットが少なかったので、cherry-pickを使って、ほかのブランチに混
git を https 経由で使うときのパスワードを保存する - Qiita
git を https 経由で使う場合、pull や push のたびに毎回パスワードを聞かれてしまいます。 これを改善するには git-credential を使うと良いです。 git-credential は git 1.7.9 以降で使用可能です。 なお、古いやり方としては .netrc を使う方法もありますが、パスワードを平文でファイルに保存するので、やらないほうがいいと思います。 使用可能な管理方式 git-credential では、以下のような方法でユーザ名とパスワードを管理できます。 git-credential-store : ファイルに保存します。ただし、パスワードが平文が保存されます。 git-credential-cache : 常駐プロセスに記憶させます。 git-credential-osxkeychain : Mac OS X のパスワード管理を使います。 G
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git管理している途中から.gitignoreを追加して、その設定を反映させる方法 - Qiita
gitlab-slide
GitHub Flow (Japanese translation)
