【小ネタ】消し忘れのリモートブランチを一括表示・削除するワンライナー | DevelopersIO
みなさまリモートリポジトリに消し忘れのブランチはありませんか？？ 「1年以上の前のブランチ」「自分が作成していない詳細不明のブランチ」などが残っていて、消して良いかもわからない。。。。なんてことあるのではないでしょうか。 通常GitHubなどでfeatureブランチをpushしてpull requestがマージされれば、リモートのfeatureブランチは削除されます。が、 リモートにpushしたけど結局pull request作成しなかった リモートにpushしてpull request作成したけど、必要なかったのでそのままクローズした GitHubのブラウザからrevert commit作成したけど、やっぱり使わなかった などの場合、リモートにブランチが残ります。 そこで今回は、「リモートブランチの詳細を一覧表示」したり、「マージ済みのリモートブランチを一括削除」したりするコマンド（ワン
Conventional Commits
Conventional Commits A specification for adding human and machine readable meaning to commit messages Conventional Commits 1.0.0 Summary The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer
git ブランチを付け替える
ブランチを統合する操作として "merge" がある。 もう一つ別の方法として、 "rebase" がある。 基本的な操作 "new_branch" ブランチを "master" ブランチへ "merge" すると、以下のようになる。 $ git checkout master $ git merge new_branch $ git log --oneline --graph * e379414 Merge branch 'new_branch' Conflicts -> modified |\ | * 0792fc6 new_branch 追加 3 | * ef693eb new_branch 追加 2 | * 24edebf new_branch 追加1 * | 762bccf master 追加 3 * | 9fe9714 master 追加 2 * | 1c0a080 maste
続・Gitリポジトリ運用の最適解 - chulip.org
このエントリは過去に書いたエントリの続編として位置づけています。 過去の記事：Gitリポジトリ運用の最適解 - chulip.org この記事を書いた当時、いや少なくとも少し前までは本気でマージコミットがないGit運用が最高だと考えていました。 だからこそ、何故A successful Git branching modelがNon-Fast-Forwordマージを推奨しているか疑問であり、昨今のgit-mergeには--no--ffオプションを設定。むしろgit-configでデフォルトの挙動を--no-ffにできるから設定しとけお前らという話に対してよく理解ができていませんでした。 マージコミットがないGit運用が最高だというのは限られた場合の話ではないか ある特定の場合においてのみこの話は適応されるのではないかということに気づきはじめたような気がします。 これは例えばリリース前の開発
Gitリポジトリ運用の最適解 - chulip.org
続編のような物(2012/11/21追加) 掲題の件について最近調べたことをまとめることにします。 はじめに タイトルだいぶ誇張していますが、結論から言うとマージコミットを発生させないGitの使い方です。 マージコミットが悪という言葉を最近よく目にしていたのですが下記リンク先の説明でしっくり来ました。 マージコミットの分割が１本線の履歴の分割よりも困難となる理由 そのためマージコミットが発生しないような使い方を目指します。 また、A successful Git branching modelを実現するためのgit-flowというもののありますが今回は触れません。 (ちなみにA successful Git branching modelではマージコミットは必ず残すことを推奨しています) Non-Fast-Forwordマージでの利点はブランチでの作業履歴が残ることと認識しています。 Fa
よりよいGitの設定 | Yakst
.gitconfigファイルに記入するオプションをカスタマイズすれば、Gitをより上手に、便利に使うことができる。著者のGit設定の紹介と、便利な設定の解説。 私はGitが大好きで、いつでもGitを使っています。私は時々、何かについて深く調べてみたり、ドキュメントを一通り読んでみたり、設定を見直してみたりするのですが、今回はGitについてそれをやってみました。私の書いた4番目の技術スタックの改善に関する記事にようこそ！ Gitのすべて 私がコーディングを始めたのは、ただのファイルシステム上でコピーしていたあの辛い日々、そしてチェックアウトに排他的ロックが必要だったVisual SourceSafeを使っていた時でした。それでもその時、ソース管理のコンセプトは私にとって素晴らしいものに思えましたし、家でコーディングする時にはそういったものにアクセスできたらな、と思っていました。 その後カリフ
今さら聞けないgit pushコマンド - Shoichi Matsuda's diary
id:koogawaさんのgitの記事を読みました。 これを読んでそういえばみんな知ってるのかなと思った点があるので書いておきます。 取り上げるのはgitのpush周りのお話です。 （これ以降の記事中のリモートは全てoriginとします。） このコロンは何？？ リモートブランチの削除で以下のようなコマンドを実行すると思います。 git push origin :hoge コロンが付いていますがこのコロン正体、正しく説明できますか？ 実用Git 作者: Jon Loeliger,吉藤英明(監訳),本間雅洋,渡邉健太郎,浜本階生出版社/メーカー: オライリージャパン発売日: 2010/02/19メディア: 大型本購入: 7人 クリック: 287回この商品を含むブログ (44件) を見る pushコマンドの実体 普通、ローカルブランチをリモートに反映する際のコマンドはこんな感じです。 git p
gitでマージ作業を中止して元の状態に戻す | Webシステム開発／教育ソリューションのタイムインターメディア
問題 gitでは空気を吸うようにブランチを作り空気を吐くようにマージを行います。 例えば新機能Xを実装する場合、 X用のトピックブランチを作成し、実装を進めて、完成したら統合ブランチへマージする というのが普通です。 具体的にコマンド例を挙げると以下のようなものになります: $ git checkout -b topic-x master Switched to a new branch 'topic-x' $ $EDITOR $ git add foo.x bar.x baz.x $ git commit -m 'Implement X' [topic-x 0000001] Implement X 3 files changed, 8 insertions(+), 5 deletions(-) $ $EDITOR $ git add qux.x $ git commit -m 'Fix
Gitで「error: xxxxxxxxx does not point to a valid object!」って怒られるときの修正方法 - モノノフ日記
GitHub Enterpriseで特定のリポジトリでエラーページが表示が出てるのを修正対応したんですが、書いておかないと忘れる自信があったのでblogged. 状況について 手元にgit cloneしていたリポジトリをpullしようとすると下記のような感じで怒られてました。 % git pull error: unable to find 60c4f95fb89859e54f5fd2de864393a60fc81a08 error: refs/heads/master does not point to a valid object! error: refs/pull/1983/merge does not point to a valid object! Your configuration specifies to rebase against the ref 'master' fr
git-pr-releaseのすすめ - ninjinkun's diary
Github (含むEnterprise) で開発をしているなら、Github Kaigiでも紹介されていた git-pr-release が便利です。自分の会社ではアプリのリリース前にQAを実施しているのですが、QAを始める前にどの機能がリリースされるのかをリストアップし、それをGoogleスプレッドシートに入力する作業が繁雑でした。 git-pr-release を使うと、これをリリースPull Requestに集約して自動化することができます。リリースPull Requestとは以下のようなものです (スクショはこのツールのPR用に作ったダミー)。 具体的なリリースまでの作業手順は以下のようになります。 開発ブランチにリリースする機能のPull Requestをmergeしていく git-pr-release を実行 merge済みのPull Requestの情報を集めてチェックリス
フィーチャブランチ - Martin Fowler's Bliki (ja)
http://martinfowler.com/bliki/FeatureBranch.html gitやMercurialのような分散バージョン管理システム(DVCS)の台頭と共に、ブランチ戦略やマージ戦略をどうするか、そしてそれらをどのように継続的インテグレーション(CI)に適合させるかという話し合いを数多く見てきた。その中で、特にフィーチャーブランチのプラクティスと、それをCIにどのように適合させるかに関しては、少し議論の混乱があるようだ。 シンプルな(分離した)フィーチャーブランチ フィーチャーブランチの基本的な考え方は、フィーチャー(あなたがその言葉を好むのならばユーザーストーリーでも構わない)の作業を開始する際、そのためのブランチをリポジトリ内で分岐させるというものである。DVCSでは、あなた個人のリポジトリでこれを行うが、中央集中型バージョン管理システム(VCS)でも同様の作
僕のチームのGitの開発フロー - Mitsuyuki.Shiiba
を考えてみる。 Git Flow nvie.com やってみたことある。良いんだけど、僕の環境だと、もうちょっとシンプルにやれそうかなって思った。 Github Flow scottchacon.com これはシンプルだな。なんだけど、シンプルすぎてちょっと違うかな。 ということで、ちょうどいいくらいのを考えてみたい 今の僕の開発にとって、ちょうどいいくらいのを考えてみたいなーって。じゃあ、今の僕のやってる開発ってどんなん？ってところから。 チーム エンジニア5,6人くらい。 Feature, Story, Task Featureと呼ばれるものがあって、これは2,3ヶ月分の規模で。この単位でリリースする。 Featureは複数のStoryで構成されていて、Storyは4,5日くらいで完了する。から、1 Featureは10から15Storyくらいってことか。 Storyは複数のTaskを
transitive.info - git submodule 使い方
git submodule 使い方 サブモジュールについて サブモジュールは外部のリポジトリをソースツリーのサブディレクトリに埋め込むために使用する。 リモートリポジトリとは異なる（リモートリポジトリはソースツリーに埋め込めない） 二つのプロジェクトのヒストリは完全に分かれている サブモジュールに対しては編集できない 外部リポジトリのヒストリを取り込みたい場合は、サブモジュールではなくsubtree merge strategy を使う メインリポジトリはサブモジュールのリポジトリのあるコミットを参照している サブモジュールを追加する <git://example.com/repo.git> を サブモジュールとして追加するには git submodule add git://example.com/repo.git git submodule add git://example.com/
git pushでバーチャルホスト設定やデプロイを自動で行う | Basicinc Enjoy Hacking!
ブランチを手軽に切れるのが魅力なGitちゃん。 ただ、Webアプリケーションとして、気軽に切った先進的で先鋭的で危ない感じのその新ブランチを他の人に動作を確認してもらうのは、ちょっと面倒。 開発者ならpullってdiffって見ろよって感じなんだけど、営業さんだったりディレクターさんだったりだとブラウザで確認できなくちゃね。というわけで、開発サーバにバーチャルホスト切って、サブドメインとかで設定するわけなんだけど、それが手間。 ブランチは気軽に切れるのに、環境は気軽に作れない。 post-receive を使おう Gitにはpost-receiveという強力な仕組みがあるので、これを使います。 $git push origin new-branch って新ブランチをリモートリポジトリにpushしたら、http://new-branch.example.com/ ってサブドメインで閲覧できるよ
「技術的負債だらけのチームで技術マネージメントしてみた」資料が素晴らしい - プログラマの思索
「技術的負債だらけのチームで技術マネージメントしてみた」の公開資料が素晴らしいのでリンクしておく。 【参考】 akipiiさんのツイート: "すごく良い資料。RT @yassan168: #kichijojipm 発表資料upしました。誰かの役にたてば良いのだけど。connpassにもUPしています。＞技術的負債だらけのチームで技術マネージメントしてみた https://t.co/3R25aUnI4S" 前任の仕事を引き継ぎしたら、下記の問題があったらしい。 技術的負債込みで引き継いでしまった、という例は、本当によくある。 (引用開始) １年前の状態 ・すべてがメールベース ・ドキュメントはほぼ無い ・最強の属人化。個人のパワーで乗り切る ・技術に関心が無く誰も行動しない ・暫定スクリプトが今も元気に本番稼働中 ・ソースには、ほぼコメント無し ・hoge.pl.(日付) 形式のソース管理
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Git: Why does rebase result in conflicts while merge does not?
gitignore.io - Create useful .gitignore files for your project
[Error] ENOENT: no such file or directory, lstat 'C:\d' · Issue #10281 · microsoft/vscode![[Error] ENOENT: no such file or directory, lstat 'C:\d' · Issue #10281 · microsoft/vscode](https://cdn-ak-scissors.b.st-hatena.com/image/square/16eb593cb41da652d3f049faf1da4a282e9a7e03/height=288;version=1;width=512/https%3A%2F%2Fopengraph.githubassets.com%2F9899cd498c8bb25c0a4a47746c06b8e43b1fa478dd29879644c278b276af319d%2Fmicrosoft%2Fvscode%2Fissues%2F10281)