GitHub で Pull Request を Merge したらコードが消えた話
会社で使ってる GitHub のプライベートリポジトリで master ブランチに対して出てる Pull Request を Merge したらコードが消えるという珍事があった。ファイルを削除する commit とかないにもかかわらず、全消しされてしまった。ちなみに同じ Merge を手もとでやるとコードが消えたりはせずちゃんと Merge された。極めて謎な現象だった。 master ブランチが空になるとデプロイができなくなって不都合があるので（ Webistrano 上でデプロイするとき master ブランチからしかデプロイできないようなレシピになってる）、コードが消滅したブランチを bukkowaremaster にリネームして手もとで Merge したブランチを force push してしのいだ。 GitHub に問い合わせてみたところ、ぬるい感じの一次返信が来たので原因教えて
小規模開発には git-flow よりも GitHub Flow で捗る - TMD45INC!!!
これまで CVS や Subversion ではなかなか敷居の高かった「ブランチを切って作業する」というワークフローが、分散型バージョン管理、とくに Git の登場でとても手軽に取り入れやすくなりました。 Git のブランチを活用するためのワークフローとして有名なものに git-flow と呼ばれているモデルがあります。正しい名称は「A successful Git branching model」で、git-flow はこのモデルの導入を補助してくれる Git 拡張の名称だそうです。 A successful Git branching model（@oshow さんによる日本語訳） git-flow の解説～導入までは以下の記事に詳しく書かれています。 git-flow によるブランチの管理 - O'Reilly Japan Community Blog これはあくまで ”モデル” な
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
githubとgitkとWindowsと文字コード - foobardamのプログ
普段、Windows上で開発しているときは、Gitはmsysgitを使っている。 文字コードはsjisにしている。 コミット文章は、utf-8にしている。 自分は、gitkを多用しているが、この状態で何も困らなかった。 ところが、本日、githubにソースコードをアップして文字化けすることに気づいた。 どーしよー。 世の中utf-8に向かっているし、Windwosでさえ内部的にはユニコードで処理しているので、いつまでsjisなのよというのもあるのでutf-8にすることにした。ところが、gitkのソースコードの文字が化ける。gitkは、自分の生命線にあたるので文字化けは非常に困る。ググッて以下のように解決することにした。 git config gui.encoding utf-8 gitkは、OSの文字コードに合わせて表示するらしい。コミットはutf-8みたいなんだけどな。 とりあえず、リポ
Git にパッチを送って取り込まれた話
Git の挙動に変なところを見つけたので、パッチを作って Git のメーリングリストに投げてみたところ、何度かのレビューを経て、無事に取り込まれた。 Git に貢献したい人とか、オープンソース開発の流れに興味がある人もいるだろうから、作業の流れを書いておくことにする。 1. バグを発見する 何はともあれ、修正したいところを見つけるところから。 先日、git difftool --dir-diff が便利すぎて泣きそうです という記事を書いたが、difftool --dir-diff の挙動を調べているうちに、一時ファイル書き戻し条件が変なことに気づいた。 手元のバージョンが古いのかとも思ったが、master ブランチでも再現したので、ちょっくら深入りしてみた。git difftool は Perl スクリプトだったので、ソースコードに print を追加しつつ挙動を探っていった。しばらく調
面白い！Webサイトが出来上がっていく様子を再生·Time Machine MOONGIFT
Time MachineはGitを使ってHTMLコーディングが仕上がっていく様子を画像、動画にするソフトウェアです。 Webデザイナーの方がHTMLをコーディングしていく中で、後でその過程を見せたいと思ったことはないでしょうか。そこで使ってみたいのがTime Machineです。 Time Machineを使うとphantomJSを使ってnode.jsでスクリーンショットを撮ります。 デモ動画です。 Time Machineの仕組みはシンプルで、まずHTMLファイルをGitで管理しつつコーディングしていきます。そして途中途中でGitにコミットしておきます。後はTime Machineを実行するとコミットログを元にファイルを戻しつつ、phantomJSでスクリーンショットを撮る動作を繰り返していていきます。まさにアイディアの勝利です。 Time MachineはRuby/node.js製のソ
git 1.8.2 リリースノートを眺めて、新機能把握と設定を追加 | Act as Professional
世の中はGoogleリーダーで盛り上がってる中、Livedoor Readerに移行した@HIROCASTERでございませう。 そんななか、ひっそりと git 1.8.2 がリリースされました。 リリースノートを眺めていたら知らない機能があったので書いておきます。 git check-ignore * “git check-ignore” command to help debugging .gitignore files has been added. 1.8.2からの新機能です。 .gitignore ファイルに記述されてい内容と実際のファイルが該当するかチェックできます。 例えば .gitignore ファイルに /tmp と書いたとします。 $ git check-ignore -v ./tmp .gitignore:1:/tmp ./tmp のように1行目の設定に該当して、exc
GitHub リポジトリのバックアップと移行 | Weboo! Returns.
GitHub の有料プランは利用しているプライベートリポジトリの数によって料金が変わってきます。使わなくなったリポジトリは、ローカルや自分のサーバにバックアップして削除してしまうのが賢く使うコツです。 以下に GitHub のリポジトリをバックアップして、自分のサーバ上にリポジトリを移行して開発を続ける方法を紹介します。 1. バックアップ バックアップするだけで再利用しないのならば、以下のコマンドだけでOKです。このディレクトリを適宜 zip などで圧縮して保存しておけば良いでしょう。 $ git clone --mirror git@github.com:weboo/project.git $ zip -r project.git.zip project.git 2. 自分のサーバで開発を続ける リポジトリを自分のサーバに移行して開発を続けるには、1.でバックアップしたファイルをサーバ
Web上でGitの使い方をレクチャー·Learn Git Branching MOONGIFT
Learn Git BranchingはWebベースでGitの使い方を学べるソフトウェアです。 企業においてもバージョン管理にGitを利用するケースが増えてきました。しかしその機能を使いこなせていないことも多いのが事実です。そこでGitリポジトリ、特にブランチに関して学べるLearn Git Branchingを使って学習してみましょう。 トップページです。 自動的にコマンドが入力されて、右側のツリーが更新されていきます。 解決するとコミットが飛んでいきます。 ここからが本番です。 基本的にチュートリアルの通りに進んでいくのみです。 まずコミットから。 入力中は答えが見えないように隠されます。にくい演出です。 Learn Git Branchingは実際のコマンドを入力しながら、それがツリーにどういう影響を与えるかをビジュアル的に確認できます。Learn Git Branchingを通して
小規模チームでのGithub利用開発 - Mandy Code
気づくと1週間経っている恐怖(´ω｀) いまうちの会社ではGH:Eを導入するほどの規模でもないので、Githubのビジネスプランを使って開発を進めています。 僕自身gitへの造形がそこまで深くなく、どのように開発を進めていくかかなり迷いがありましたが、現在ある程度フローを決めてスムーズに開発が進むようになってきたので、それをまとめておきたいと思います。 ベースはgit-flow Githubを導入するにあたって、gitを利用した開発フローについて調べたのですが、やはり最初に出てくるのがgit-flowでした。 一方で、実際にgitを現場で利用されている方々に聞くと、「リリーススピードが早いとgit-flowは厳しい」という声も聞かれました。 そこで、小規模チーム（現在は3人）で開発を行う際にgit-flowをベースとして利便性の高い開発フローを考えてみました。 リリースまではmasterと
「こわくない 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-mergeの--ff, --no-ff, --squashの違い - アジャイルSEを目指すブログ
git-merge の--ff, --no-ff, --squashの違いをまとめてみた。 git helpから引用 まずは、git helpを読みましょう git merge --helpから引用（抜粋） NAME git-merge - Join two or more development histories together SYNOPSIS git merge [-n] [--stat] [--no-commit] [--squash] [-s <strategy>] [-X <strategy-option>] [--[no-]rerere-autoupdate] [-m <msg>] <commit>... git merge <msg> HEAD <commit>... git merge --abort OPTIONS --ff, --no-ff Do not gene
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
今日覚えたgitのコマンド - $shibayu36->blog;
git branch --merged masterとかやるとmasterにmergeされたbranchが一覧できる。-rをつければremoteの奴が一覧できる。 git branch --contains (SHA1)とかやるとあるsha1を含むbranchを一覧できる。 これを応用すると git branch --merged origin/master | perl -lnpe '$_ =~ s/[ *]+//;' | grep -v '^master$' | xargs git br -dみたいな感じでmasterにmergeされたlocalブランチをすべて消すことができる。 便利ですね。 ちなみにmaster ブランチにマージ済みのリモートブランチをまとめて削除する git-prune-remote-branch というスクリプトを作った - @kyanny's blogみたいな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
github を用いた開発フローテンプレート
git-flowは死んだ
GitHub Flow (Japanese translation)
GTUG Girls原稿
hitoyam.com
githubからのcloneが遅かったら ~/.ssh/config にコレ書いたら改善する