失敗する前提でデプロイする - hitode909の日記
うちのチームでは，デプロイするたびに自動的にgitのtagを切るようにしてる．たとえば，いまデプロイしたら，deploy/2014-02-01-14-48とか． たまに，リリースした直後になんかミスってたことに気付いて，慌ててロールバックすることがある． tagを切ってるので，ひとつ前に戻せばいいのだけど，えっと，どれだっけとかいって探すので慌てるし，普段はタグ指定してデプロイしてないので，どうやって戻すか忘れる． デプロイ終わったときに，今回のデプロイを戻すには，これをしましょう，とか表示するようにした． デプロイ終わったらこんなのが出る．前回のデプロイが昨日だったら昨日くらいのタグが出る． ヒント：戻すときは以下のコマンドを実行しましょう cap -S revision=deploy/2014-01-31-15-17 deploy 実装方法としては，こんな感じに，デプロイ前に最新のタグ
Git（GitHub）の運用で気をつけていること - えいのうにっき
ある日、 PR の内容を見ずにマージすることを岡島（ピッチャーの）というらしい 笑った— いのうえ (@a_know) 2015, 9月 10 ということで、脳天気に笑っていたら、 @a_know むしろイキナリmasterリポジトリに直接pushするパターンですね！— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 という話になり、そしてなぜだか、 @a_know push -fと同様、Gitの運用アンチパターンとかどこかに纏めがほしいですねー。 #ブログ待ってます— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 というはなしになったので、本当に必要として頂いているのかどうかはともかく、 Git / GitHub でぼくやぼくの職場で気をつけていそうなことをまとめてみる。 もくじ もくじ GitHub Flow に沿って開発する 基本
Gitで操作を取り消す方法色々 | Yakst
コミットなどのGitの色々な操作を取り消すための方法。その操作が必要になる場面と、方法、その仕組みと意味合いまで丁寧な説明。GitHub社のブログから。 あらゆるバージョン管理システムの最も便利な機能の1つに、間違いを「取り消す(undoする)」ことができるというのがあります。Gitにおいては、「取り消す」という言葉には少しずつ異なる様々な意味合いがあります。 新しいコミットをすると、ある時点におけるあなたのリポジトリのスナップショットをGitが保存します。それにより、後からあなたのプロジェクトを以前の状態に戻すのにGitを使うことができるわけです。 この記事では、あなたの変更を「取り消し」たくなるだろうよくあるシナリオを提示して、そのためにうまい具合にGitを使えるような方法を取り上げようと思います。 「パブリックな」変更を取り消す シナリオ : git pushを実行してGitHubに
巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
Gitのリモート操作を5倍から50倍高速化するには | Yakst
リモートからのgit pullなどの操作を、SSHのコネクション共有とリポジトリの自動ミラーを使って50倍高速化する方法。 注意 Gitサーバとの距離によって結果はまちまちだ。timeコマンドを使った全く科学的とは言えないベンチマークでは、以下の手順を実行した後はgit pullが、GitHubとシンガポールAWSのEC2で5秒以下から0.1秒以下になった。 なぜ？ $ time git pull Already up-to-date. real 0m5.075s Gitリポジトリが最新だってことを表示するだけで5秒かかるって？あり得ない。 SSHコネクションの共有と永続化 シンガポールでは、github.comへの往復時間は250msほどだ。GitのオペレーションをするたびにSSHコネクションを張るのは、たくさんのやり取りが発生してしまう。しかし、~/.ssh/configに以下の行を書
Git の mirror 関連のオプションや設定 - Qiita
git clone --mirror $URL bare リポジトリが作られる git init --bare と大体同じ --mirror オプション付きでリモートリポジトリが追加される git remote add --mirror origin $URL と大体同じ リモートリポジトリが fetch される git fetch origin と大体同じ git push --mirror $NAME ローカルリポジトリの refs/ がそのままリモートリポジトリの refs/ にプッシュされる git push $NAME "refs/*:refs/*" と大体同じ git remote add --mirror=push $NAME $URL config の remote.$NAME に下記が追記される
多人数開発で Git を使う場合の環境構築 | GREE Engineering
こんにちは、インフラやってる sotarok です。最近、社内でも「sotarok は そーたろっくと読む」という誤解が広がっていましたので改めて自己紹介しますと、sotarok と書いて「そーたろー」または「そーたろー・けー」と読みます。ロックしてないのでよろしくお願いします。 今日は、Git の話です。 GREE ではずっと Subversion を使っているという話を、以前開発環境の話をしたときに少し触れたことがあります。Subversion での運用方法も、GREE では割と面白い運用をしているのでその話もどこかでしたいのですが、まあ、それは今回は置いておきましょう。どこかで聞いてください。 GREE もその昔 CVS から Subversion に移ったのですが、時代は流れるもので、いよいよ Git 化という流れがきています。Subversion と Git の違いを今更あえて挙
GitHubクローンまとめ 無料でGitHubのような機能を実現するための候補 | Act as Professional
Bitbucket – 無料のプライベートリポジトリが魅力https://bitbucket.org/ 無料でプライベートリポジトリを無制限につくることができる。 プライベートリポジトリは5人までは無料で利用できる。GitHubクローンではないが、個人や数人で利用するだけならBitbucketのサービスだけでまかなえるのでおすすめ。オンプレミス製品は有償での提供。 Gitea – Go製セルフホスト型のGitHubクローン2016年にver1をリリースした期待の新星です。別途記事を書いてますので、詳細はそちらをどうぞ。 https://hiroki.jp/gitea Go製のためマルチプラットホームでさくっと動きます。DockerやVagrantの提供もしているため動作させるまでのハードルが低いです。 全文検索機能はありませんが、主要な機能は搭載されています。 GitPrephttp://
tigから git rebase -i したらいろいろ捗った - くりにっき
git dtコマンド - razokulover publog を見て自分もgitのコマンドをカスタマイズしてるのを思い出したので普段よく使っているのを紹介します。 対象者 作業途中はtmpコミットをたくさん作って、最後に git rebase -i でコミットを整えている人 前置き gitのタイプ数を減らす gitコマンドを使う時に毎回 git と3文字タイプするのは時間の無駄なのでエイリアスつけるのをおすすめします ~/.bash_profile とか ~/.bashrc 辺りに下記を書きます。 alias g='git' これで g だけでgitコマンドが使えます git-now iwata/git-now tmp コミットのための独自サブコマンド git-now - アジャイルSEを目指すブログ 最速でtmpコミットするためのコマンド。Macなら brew install git-
やけに丁寧なtigの設定ガイド（表示制御編） - Qiita
はじめに コマンドラインで利用できるgitブラウザとして人気のtigですが、 使っていくうちにデフォルトの挙動では物足りなく感じ、.tigrcを利用したカスタマイズをしたくなってきます。 .tigrcをいじると色々なカスタマイズができますが、一度に多くの設定を書いてしまうと、 何が変わったかわかりづらかったり、変更の利点が曖昧になる時もあると思います。 そこで本記事では、.tigrcに関して筆者がオススメする4つの表示制御設定を紹介します。 ただ設定を紹介すると設定4行とコメントだけで終わるので、 スクリーンショットでbefore/afterを比較したり、オススメ理由を書いていきます。 なお、表示されているリポジトリは、本稿執筆時点で筆者が個人的に気になっているプロダクトである favico.js のmasterブランチです。 「やけに丁寧だね！」と読者からコメントをいただけるような内容に
もう巨大なデータをgitignoreしなくていい！ ~git-mediaの使い方~ - 3度の飯と最新技術
はじめに gitはコミットごとにレポジトリ内のファイル全てをスナップショットとして保存するというリッチな 設計になっている。 それがgitの便利さの所以なのだが画像データや音声データのようなバイナリデータを持とうとすると 少しの変更でもそのたびにコピーが生じてファイルサイズ分の容量が増えることになり、あっという間にレポジトリが 肥大化してしまう。 特に学習結果をファイルに保持してテスト等に使いまわすようなプログラムを管理しようとすると アルゴリズムのパラメータを少し変えるたびに100kB近い容量が増えていき、実にイケてない。 普通なら.gitignoreに*.xmlと書いてデータ自体は手動管理したり、シンボリックリンクにして別ディレクトリに置いてそれだけrsyncで同期するようにしたりするんだが 過去の実験時の状態に戻れなかったり、毎回rsyncするのは不便だった。 なんか無いかなーと思っ
Gitレポジトリを移行する方法 - tanacasinoのメモ
既存のGitレポジトリを、GithubやBitBucketのようなホスティングサーバに移行したり、逆にローカルサーバのGitBucketやGitLabなどに移行したい場合、まあ単純にpushすればいいやんと思ったら、思うような結果にならなかったり、面倒な手順になってしまったりしてしまった。 どうも自分のワーキングのレポジトリから飛ばそうとすると、tagだったりbranchだったりが移行できていないかったりするのです。 ぐぐると、いったんローカルにリモートと同名のブランチ作って(checkoutして)から、push --all, --tags とかしてる奴とかありますがそれは面倒だなぁやだなぁみたいな。 最終的には、これが一番楽な手順かなと思う手順に行きつけたのでここに記す。 $ git clone --mirror <SOURCE_REPOSITORY_URL> $ cd <REPOSIT
zsh の vcs_info に独自の処理を追加して stash 数とか push していない件数とか何でも表示する - Qiita
zsh で Git 使ってる人はプロンプトにブランチ名とかを表示してる人も多いと思う。 zsh に標準で入ってる vcs_info っていうのを使うとだいたいいい感じにできるんだけど、できないことも当然ある。 例えば stash した数の表示には対応していないので、自分で無理矢理な感じで Git コマンドを呼び出してプロンプトに表示してる人もいると思う。 でも zsh 4.3.11 ぐらいから vcs_info に Hooks というのが追加されて、元の機能に自分で処理を追加できるようになってる。これを使うと好きなようにカスタマイズできるようになるので紹介する。 この記事でできるようになること こんなことがプロンプトに表示できるようになる。 使用しているバージョン管理システムの名前(svn, git, hg, ...) 現在のブランチ名 マージ失敗のエラー表示 さらに Git の場合は以下
「こわくない 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 すると、空のマージコミットが作られてしまうのです。
こわくない Git
8. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) 例: 受け取ったパッチを取り込んだ人 ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー（説明は省略） 1つ前のコミットのリビジョン 例: 4717e3cf182610e9e82940ac45abb0d422a76d77 9. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Co
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コンセプトから理解するGitコマンド
Setting up a git repository that is accessible via HTTP WebDAV | Björn's Blog
やりなおせる Git 入門
http://blog.inouetakuya.info/entry/20130602/1370173582
Log in with Atlassian account