GitHub からファイルを完全に削除 - mooz deceives you
なんだかヤバいものを GitHub にアップしてしまった人は、はやいとこ次のコマンドを打ち込みましょう。 git filter-branch --index-filter 'git update-index --remove file' HEAD git push --force --verbose --dry-run git push --force file には削除したいファイル名を。これで GitHub から file がコミットログ含めて完全に削除されます。 ただ、ここで安心するのは早計というものです。昨今のネット世界を掌握しているかの Google を忘れてはいけません。 試しにヤバいファイルの内容で検索してみると...... 見事に引っかかりました。キャッシュ怖い。 結論 見られて恥ずかしいものをアップロードする場合は、お金を払ってでもプライベートリポジトリにしましょう。
master ブランチで pull request していいのは小学生までってこともない - HsbtDiary(2011-06-16)
■ [git][github][tDiary] master ブランチで pull request していいのは小学生までってこともない GitHubへpull requestする際のベストプラクティス - hnwの日記を読んで感じたこと。 このエントリではmasterブランチで pull request していいのは小学生までと言われているけど、少なくとも tDiary ではどうでも良いからパッチ送れとしか思わないなあ。 具体的には master ブランチで作業したものを pull request しても別にコードの内容に問題がなければがんがん取り込むし、コンフリクトがひどかったり、なんじゃこりゃというのは差し戻すのでパッチを投げる側は気にする必要はない。繰り返すけど、Gitのお作法よりもコードの内容の方が重要ってことを頭に置いた方が良い。 もちろん、件の記事のようにちゃんと Git を
GitHub時代のオープンソース・プロジェクトとの付き合い方
■ GitHub時代のオープンソース・プロジェクトとの付き合い方 GitHubへpull requestする際のベストプラクティスからmaster ブランチで pull request していいのは小学生までってこともないの流れを読んでいて、先日ruby-listであったRedmineのRuby1.9,Rails3対応の話を思い出した。あのときは投稿者は納得して、「GitHub時代のコントリビューションの仕方」みたいなものを理解してくれたようなのだけど、その上で「masterでパッチ作るな」的なお作法を生真面目に受け取りすぎて敷居を高く感じてしまわれても困るよなぁと思った。 そこで、「GitHub時代にフリー/オープンソース・ソフトウェア(以下FOSS)プロジェクトと付き合うための五ヶ条」的なものをまとめてみた。まぁ、そんな大それたものでもないけど。 1. 貢献しようと意気込まない FOS
Git と GitHub を体験しながら身につける勉強会行ってきた - 予定は未定Blog版
9/18（土） 15：30～ GitとGitHubを体験しながら身につける勉強会（名古屋） : ATND 行ってきました。 なんかいろいろと話すことになったんですけど、あの場で言いそびれたこととか、もっとこう説明してればよかったなぁ、って部分の補足も兼ねたエントリです。 長文注意。 ショートカット git add の話 git add -p/git reset -p の話 リビジョン番号がない話 ブランチの話 git-completion の話、__git_ps1 の話 コミットの指定の話 reset の話 rebase と merge の話 公開したものの rebase の話 stash の話 TortoiseGit、HG、SVNのはなし 全体を通して git add の話 Git と SVN では、add に限らず、同じ名前のサブコマンドでも意味が異なるものがいくつかあります。 その中
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
