あなたはmerge派？rebase派？綺麗なGitログで実感したメリット - BIGLOBE Style ｜ BIGLOBEの「はたらく人」と「トガッた技術」
BIGLOBEの開発現場の様子や、developブランチにrebaseで綺麗なコミット履歴を作る方法をご紹介します。 はじめまして！ GitHubを中心に仕事がまわる開発現場 Git logが綺麗だとバグが起こりにくい？ developブランチを綺麗に保つGit操作（マージ編） 1. そのまま気にせずdevelopにマージする。 2. 最新のdevelopをfeature/Bブランチに取り込んでからdevelopにマージする 3. 最新のdevelopにrebaseしてからマージする ﾘﾍﾞｰｽ ｺﾜｸﾅｲｮ 最後に はじめまして！ 基盤本部（開発部門）の江角です。 2021年8月にSIerからBIGLOBEに転職し、半年が経過しました。 転職期間中はもちろんコロナ禍で、カジュアル面談も面接も全てオンラインでした（多分今もそうだと思います）。 入社日当日は出社しましたが、入社してから半年の
git branch の結果を時間順にソート: git branch --sort=-authordate - Islands in the byte stream
id:kazuho さんと「gitのbranchを消すべきか否か」という話をしていて、ぼくの「ローカルにせよリモートにせよbranchが増えすぎると目的のブランチを見つけられない」という意見に対して次のエントリを教えてもらったのでした。 git branch の結果を時間順にソート - kazuhoのメモ置き場 一理あるかもしれないと思ってこれをgitに組み込むためにgitのソースコードを眺めていたら、実はもうできるということを知りました。それがこれ: # 新しいのが下 git branch --sort=authordate # 新しいのが上 git branch --sort=-authordate このソートに使えるフィールドは、 git branch --help を引くと "The keys supported are the same as those in git for-e
git blameでプルリクエストの番号を表示する
GitHubでプルリクエスト前提の開発をしていると、git blameで「なぜ、このコードがこうなっているのか」調べる際に、commit idではなくプルリクエストの番号を表示してほしくなります。 というわけで書いたのが git-blame-pr.pl。 以下のような感じで表示されるので、調査がはかどります。 $ git-blame-pr.pl lib/core/request.c (中略) PR #446 PR #606 h2o_iovec_t h2o_get_redirect_method(h2o_iovec_t method, int status) PR #606 { PR #606 if (h2o_memis(method.base, method.len, H2O_STRLIT("POST")) && !(status == 307 || status == 308)) PR
git commit --fixup とは何か - 詩と創作・思索のひろば
git commit --fixup というオプションの存在を最近知って調べた。 ヘルプとリリースノートより "git commit" learned the --fixup and --squash options to help later invocation of interactive rebase. Git v1.7.4 Release Notes --fixup=<commit> Construct a commit message for use with rebase --autosquash. The commit message will be the subject line from the specified commit with a prefix of "fixup! ". See git-rebase(1) for details. 1.7.4 から入って
git と mercurial の diff を美しく表示するために必要なたった 1つの設定 (原題: diff-highlight 1.0.0 をリリースしました) - Hack like a rolling stone
Git の diff を美しく表示するために必要なたった 1 つの設定 #git にインスパイアされて作り始めた diff-highlight にあれこれ手を入れ、1.0.0 として正式リリースしました。 diff-highlight と git-contrib/diff-highlight の違い 差分の中で +/- の行数が一致していないときのハイライトの扱い git-contrib/diff-highlight での表示 +/- の行が一致していないとハイライトされません。 diff-highlight では、マッチする行を認識してハイライトします。 +/- の行数が一致しても、文字単位でのハイライトをしてくれないケースがある git-contrib/diff-highlight での表示 差分の 1行目同士を比較しているため、pager の行がハイライトされていません。 diff-
Gitのfetch/pullサブコマンドで--pruneオプションをデフォルトにする
Gitではbranch -aでリモート・リポジトリーも一覧できる。この一覧には既にリモートでは消されたリモート・リポジトリーも表示される。この一覧を更新するにはfetch --pruneを使うわけだが、いちいちそうするのは面倒くさい。どうやらfetch.pruneをtrueにするとデフォルトで--pruneを付けてfetch(及びpull)を実行してくれるようだ。 $ git config --global fetch.prune true $ git fetch From https://github.com/hail2u/example x [deleted] (none) -> origin/deleted-branch グローバルに設定して良い場合はこれで常に--prune付きでfetchとpullが実行されるようになる。この設定はプロジェクト・ローカルで特定のリモートに対してのみ
ローカル作業でのgitリポジトリ管理とコーディング環境の話 - すずけんメモ
gitを改めてちゃんと使おうという人がまわりで増えてきたのでメモとして貼っておく。 現状の設定はこんな感じ。1年くらい変わってなかった。 https://github.com/suzuken/dotfiles/blob/cbf8e7168c96029d535d69f981337d23aacfa51c/gitconfig 特にaliasまわりは普段つかっているのであげておく。 [alias] # http://oli.jp/2012/git-powerup/ # http://blog.blindgaenger.net/advanced_git_aliases.html alias = !git config --list | grep 'alias\\.' | sed 's/alias\\.\\([^=]*\\)=\\(.*\\)/\\1\\\t => \\2/' | sort b = b
より良いプルリクエストのための10のヒント | Yakst
GitHubなどの普及により、プルリクエストを使った開発フローは非常に一般的になった。一方でプルリクエストの品質も色々だ。オープンソースプロジェクトや業務でたくさんのプルリクエストをレビューするMark Seemann氏から、良いプルリクエストを作り、スムーズにマージしてもらうための10のヒント。 原文 10 tips for better Pull Requests by Mark Seemann 良いプルリクエストを作ることには、良いコードを書くこと以上を含んでいる。 プルリクエストモデルは、チームでソフトウェアを開発するための素晴らしい方法になりつつある。チームメンバーが分散している場合は特にそうで、オープンソースの開発だけでなく、企業においてもそれは同じことだ。2010年頃から私は、オープンソースプロジェクトにおいてだけでなく、クローズドソースのソフトウェア開発のために内部的にプル
git の push.default 設定を理解する - Qiita
$ git push warning: push.default is unset; its implicit value is changing in Git 2.0 from 'matching' to 'simple'. To squelch this message and maintain the current behavior after the default changes, use: git config --global push.default matching To squelch this message and adopt the new behavior now, use: git config --global push.default simple See 'git help config' and search for 'push.default' f
Vulnerability announced: update your Git clients
EngineeringVulnerability announced: update your Git clientsA critical Git security vulnerability has been announced today, affecting all versions of the official Git client and all related software that interacts with Git repositories, including GitHub for Windows… A critical Git security vulnerability has been announced today, affecting all versions of the official Git client and all related soft
Git - Book
The entire Pro Git book, written by Scott Chacon and Ben Straub and published by Apress, is available here. All content is licensed under the Creative Commons Attribution Non Commercial Share Alike 3.0 license. Print versions of the book are available on Amazon.com. The version found here has been updated with corrections and additions from hundreds of contributors. If you see an error or have a s
GitHub で submodule ではなく subtree を使うべき理由
GitHub には、タグを打つとソースパッケージを自動的にリリースするという機能があります。スクリプト言語においては、それぞれの言語について一般的なパッケージ管理システム注1があるため、この機能を使うことが少ないかと思いますが、デファクトのパッケージ管理システムが存在しないC等の言語で書かれたプログラムや、単独で動作する管理用のスクリプトを GitHub で開発・配布する際には、本機能はとても便利なものです。 しかし、この機能は git-archive コマンドのラッパーとして実装されているため、サブモジュールのファイルが含まれないという問題を抱えています。この点は GitHub の人たちも認識しているものの、今のところ GitHub で独自に対応するということは考えていないようです注2。 私がこの問題を 知ることになったのは、picojson の issue で指摘を受けたからです。pi
バージョン管理したくない作業用スクリプトは「,」ディレクトリに入れるといい - Qiita
TL;DR: グローバルな gitignore に ,/ を追加して、作業用スクリプトを , ディレクトリに入れると便利。 ,/tmp_script.sh で実行できる。 Git リポジトリの中に一時的に使う作業用スクリプトを置いておきたいことがある。自分だけが使うものなのでコミットはしたくないが、いちいち .git/info/exclude に追加して無視させるのも面倒臭い。 今まで自分は、 tmp_script.sh~ や tmp_script.sh.bak など、グローバルな gitignore で無視されるファイル名にしていたが、これは不要なファイルと間違えて消してしまう危険がある。 ignored.tmp_script.sh は分かりやすいぶん長い。 _tmp_script.sh は悪くないが、コミットすべきファイルにもアンダースコアで始まるものがあって紛らわしい。 そこで、作業
GitLab flowから学ぶワークフローの実践 | POSTD
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
pull request後にupstreamに更新が入ったのでrebaseしてconflictを解消してpush -fする話 - wyukawa's diary
azkabanというソフトを使っていて手元でバグっぽいのを見つけたのでpull requestしたんですよ。 How to Contributeに従ってまずGitHub issueを作ってその後、https://github.com/azkaban/azkaban2 から自分のところにforkして以下のように作業しました。 まあ大半の作業はSourceTreeからやっていることを告白します。 $ git clone https://github.com/wyukawa/azkaban2.git $ cd azkaban2 $ git remote add upstream https://github.com/azkaban/azkaban2.git $ git checkout -b issue-247 $ vim ... //実際はEclipseでコード修正 $ git add ...
How to contribute to a Go open source git repo
Photo Credit: t1ggr Dependencies. They’re knotty, and there really is no straight-forward, one-size-fits all solution. Dependency hell is a colloquial term for the frustration of some software users who have installed software packages which have dependencies on specific versions of other software packages. —Wikipedia I recently saw a comment on GitHub: When I run [the tests] they always pass, but
pecoでgit commit --fixup - None is None is None
peco/pecoがそこそこ流行っているみたいなので、 git commit --fixup の fixup先を選択するコマンドを作ってみました。 git-fixup-peco: select fixup target with peco これで、git log してコミット番号をマウスでコピペする必要がなくなりました！ # 実はパイプから1行選択するツールにはmooz/percolという元祖があります。 # percolはPython製、pecoはGolangで書きなおしたものです。 # pecoは単一バイナリとして提供されているのが売りですが、今のところ、機能ではpercolの方が優っている様子。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2つのブランチの分岐点をみつけるgit show-branch --merge-base - Qiita
C87：冬コミ当選しました - Uni-Q blog
Difference between git stash pop and git stash apply