Gitでリモートのマージ済みのブランチを一括削除する - Qiita
git branch -a --merged | grep -v master | grep remotes/origin| sed -e 's% *remotes/origin/%%' | xargs -I% git push origin :% Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
github上でgithubにフォークしたリモートリポジトリを本家リモートリポジトリに追随する - ...ing logging 4.0
今，フォークしたリポジトリのリモートブランチだけがある． $ git remote origin本家のリモートリポジトリの短縮名を登録する． $ git remote add github git://github.com/D-Programming-Language/dmd.git本家の更新をローカルで反映させる． $ git pull --rebase github masterフォークしたリモートリポジトリをpullしてからpushして本家に追随させる． $ git pull origin master $ git push origin master 自分のコミットを常に一番最後のコミットにしておきたいなら まず，ここで説明することは，他の人と共有しているリポジトリではやるべきではない． それを踏まえた上で，自分のコミットを常に一番最後のコミットにしておきたいならば --force
tig なんて目じゃない！ Git のログ系 Vim プラグイン gitv ＆ gitv をGit 統合インターフェース化する最強の設定 - 反省はしても後悔はしない
この記事は Vim Advent Calendar 2012 の 168 日目の記事です。 昨日は id:yonchu さんの accelerated-smooth-scroll という Vimプラグイン を作った (Vim Advent Calendar 2012, 167日目) - よんちゅBlog でした。 はじめに 最近、Git のログを見る系のエントリが多い気がします。今回の Vim Advent Calendar でも はじめての unite source(unite-tig) - Design x Verification vac143 - YouTube Vimでgitのログをきれいに表示する - derisの日記 という記事がありましたし、また最近 git? tig! | Atlassian Japan CUI で Git 使うなら入れておきたいツールまとめ | バシャロ
gitのhookでtags作成 - Qiita
git pull とかcheckoutで勝手にtags作成してほしかったので調べた時のをメモ。 プロジェクトのルートディレクトリ直下の.git/hooksディレクトリにhookさせるファイルを置けば良いんだけど毎回置くのも面倒なので勝手に作ってくれる設定 cd mkdir -p .git_tmp/hooks cd .git_tmp/hooks touch post-commit # git commit hook touch post-merge # git merge, git pull hook touch post-checkout # git checkout hook touch ctags chmod +x *
MacのGitで日本語ファイル名を扱う方法 (Creatiblog:310326)
Mac OS Xは（独特ながら）UTF-8のファイルシステムだったような気がするのですが、Gitで日本語ファイル名をCommitやPushしようとしたところ、日本語ファイル名がクォートされて文字化けしてました。 もちろん、日本語ファイル名が使えないわけではないので、Terminal.app（自分はiTerm使ってますが）から次の設定をしてあげることで、日本語ファイル名が使えるようになります。 $ git config --global core.quotepath false これをすると、~/.gitconfigのcoreセクションに「quotepath = false」が設定され、日本語ファイルのクォート処理が行われなくなります。
GitHub のプルリクエストを fetch しとくと便利 - HWPS別館
GitHub や GHE を使って多人数で開発していると，プルリクエストを横断して試す必要が頻繁に発生すると思います． プルリクエストを次々に試したり，#30 と #31 をマージした結果を試したい！なんてケースもあるのではないでしょうか． GitHub では git ls-remote すれば分かるように，プルリクエストの番号と対応したブランチがリモートに存在しているので，これを取得してみます． .git/config に追記（あるいは git remote add とかで適当に） [remote "pr"] url = git@github.com:yourusername/yourrepos.git fetch = +refs/pull/*:refs/remotes/pr/* あるいはこんな感じ（丸投げ）: https://gist.github.com/3342247 git fe
Gistub を MOONGIFT さんに取り上げていただきました - seratch's weblog in Japanese
この度、MOONGIFT さんに Gistub を取り上げていただき、多くの方に試していただく機会を得ることができました。 http://www.moongift.jp/2013/02/20130205/ https://github.com/seratch/gistub Gistub は私の勤務先の社内で使うためだけにつくったものだったので、リリース管理もあまりちゃんとされていませんでした。これを機に master を stable に保つようにしました。 また、鉄は熱いうちに打てということで、前々から気になっていた点（検索機能が欲しい、コメント数が一覧でわかるようにしたい、UI の細部を改善したいなど）に対応しました。 とりあえず一段落ですが、実際に私の職場でも使われ続けていますし、これからもメンテナンスは続けていきます。 実は Gistub を公開した後、本家が大幅リニューアルして今
VCS Vim plugins
VCS を扱う Vim plugin が乱立していて、訳がわからなくなってきたのでまとめてみた。 git.vim https://github.com/motemen/git-vim Author: motemen 対応 VCS は Git のみ status, log, diff, push, pull といった基本操作を Vim 上で行うことができる :GitStatus が便利 歴史が古く、今でも使用者がいる fugitive https://github.com/tpope/vim-fugitive Author: Tim Pope 対応 VCS は Git のみ Git に特化しているが、その高機能さに定評がある git.vim からの乗り換えが多い git add -p のグラフィカル表示、git blame のグラフィカル表示が便利 ステータスラインにブランチ名を表示する機能
GitHubでの仕事を快適にするコマンドを紹介します - $shibayu36->blog;
趣味のプログラミングや仕事をgithubを使って行なっていると、「ちょっとこんなかんじの変更してみたんだけど、このcommit見てよ」とか、「このブランチのこのファイルちょっと見てくれない？」みたいなことがよく起こります。そういう時いちいちgithub上のページをポチポチ押して、URLを教えるみたいなことをやっているのが大変だったので、ターミナルからgithub上のページを開くコマンドを作ってみました。すでにこういうのあるかもしれません。 今回のコマンドで出来ること commitを指定してgithub上の該当commitページを開く HEAD^みたいな指定も出来る ファイル名を指定して現在のブランチのそのファイルのページを開く 行を指定してハイライトさせることも出来る それらのコマンドをエディタなどから使うことでさらに便利に使う openコマンドとperlに依存しているので、これらが使えな
.gitignoreを作ってくれるgiboが便利すぎる - hnwの日記
gitignore-boilerplates（長いので以後giboと呼びます）という便利なツールを紹介します。これは.gitignoreのひな形を作ってくれるものです。 https://github.com/simonwhitaker/gitignore-boilerplates もう少し詳しく説明すると、giboは様々なOS・エディタ・言語・フレームワークなどに特化したファイルの情報を利用して、複数環境を考慮した.gitignoreを作ってくれます。 .gitignoreに入れたいファイルは環境ごとに変わってくるわけですが、各人がcommitしたくないファイルの存在に気づくたびにチマチマ.gitignoreに追記していくのって本当に無駄だと思うんですよね。giboはそれを自動化してくれるというわけです。 例えば、WindowsとMacOSXの2環境、Emacsとvimの2エディタを使う人
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
こわくない Git
8. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) 例: 受け取ったパッチを取り込んだ人 ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー（説明は省略） 1つ前のコミットのリビジョン 例: 4717e3cf182610e9e82940ac45abb0d422a76d77 9. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Co
git rebaseについてのtips | けーこ in サンフランシスコ
エンジニアの友達にgithubなどgitを使用した共同開発時の豆知識を教えてもらったので、忘れないようにメモしておきます。Thanks, Shawn! マスターとのマージ時には事前にgit rebaseを使う gitを使って共同開発をすると、たまにこんなコミットメッセージを見る機会があるかもしれません。 Merge branch ‘master’ of git://github.com/hogehoge これは、最新のマスターを私のブランチにマージしたわよ、という意味合いのコミットメッセージなのですが、正直いりません。開発者それぞれがブランチとマスターをマージするたびにこのようなメッセージをログに残してしまうと、それだけでコミット履歴を占有し、重要な情報をたどるのが困難になります。 このマージ時のコミットメッセージが発生してしまう原因は、左側の図のようにpull requestを出す前に最
git rebaseとgit mergeはともだち こわくないよ - Pixel Pedals of Tomakomai
例えば、以下のようなコミット履歴があるとします。 A---B---C---D masterここで git rebase -i HEAD~3 をして、 コミットB を E に書き換えたくなったとします。このとき、rebase -i によって履歴を書き換えてしまうと、以下のようにリポジトリからB〜Dのコミットは消滅してしまうと思っている人も居るのではないでしょうか。 A---E---C'---D' master確かに、Gitがこのような動作をするのであれば、rebase後に元の状態へ戻すことは到底困難であるように見えます。しかし、正確に書けば、実際のレポジトリの状態は以下のようになります。 E---C'---D' master / A---B---C---D実はコミットA〜Dの一連のコミットは手つかずで残っており、「master」というラベル*1が新たな枝に付け替えられただけなのです。よって、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gitでカレントブランチをpushする - Qiita
How do I delete all Git branches which have been merged?
Developer-first Project Management for Teams on GitHub | Waffle.io
IDEA * IDEA
Colorful Git (Msysgit) on Win XP