git push -f が更に安全になる --force-if-includes - id:onk のはてなブログ
歴史改変、してますか？ 私は歴史改変が大好きで、毎日 rebase しています。なので割と毎日 git push -f することになっています。 口で -f と言っても、実際には --force-with-lease --force-if-includes をしているので、これらのオプションのご紹介。 この記事は はてなエンジニア Advent Calendar 2022 の 18 日目です。昨日は id:rokoucha さんで 壊れたデータベースとの向きあいかた - rokoucha でした。 qiita.com -f の危険性 ...--F--G--H <-- main という状態で push した後、H をコミットし直したとしよう。 ...--F--G--H' <-- main \ H <-- origin/main このまま H' (main) を origin/main に p
gitのdiff-highlightを使い始めた - りんごとバナナ
git log -p や git diff などで差分を見るとき、行単位での追加/削除は表示されるが、行の中のどこが変わったのかは表示してくれない。例えば行の中の一単語を書き換えただけで、しかもその行が長い場合、どこに差分があるのか目で探すのが結構大変だった。 しかし先日、 diff-highlight という便利なモジュールが提供されていることを知り、早速導入してみた。 diff-highlightとは github.com gitコマンドの、行単位での差分を探す動作のポストプロセスとして実行され、同じ行の中の差分をハイライトしてくれる。 例えば、行の一部分だけ変えたときの git diff は、今までこんな感じだった。 それがこうなる。差分がわかりやすい。 diff-highlightの設定 この機能は gitコマンドに同梱されているため、インストールは不要。設定作業のみで使える。 ま
Spring Boot Gradle Plugin を使ってビルド情報をアプリケーションに埋め込む
Gradle で管理されている Spring Boot アプリケーションのバージョン情報などをアプリケーションコードから動的に参照できるようにするためのメモです。 ビルド情報を Spring Boot アプリケーションに埋め込む 具体的にやるべきことは リファレンス にも書かれているとおり、以下の 2 つだけです。 Spring Boot Gradle Plugin を利用する build.gradle ファイルに以下を記述する 試しに、上記設定を記述した状態で ./gradlew bootBuildInfo を実行すると、build/resources/main/META-INF ディレクトリ配下に以下のような、バージョン番号などビルドされる (された) アーティファクトに関わる内容の build-info.properties ファイルが生成されます。 build.artifact=s
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
git checkoutを禁止してgit switch & git restoreを強制する養成ギブス git-switch-trainer - Qiita
git checkoutを禁止してgit switch & git restoreを強制する養成ギブス git-switch-trainerGit git-switch-trainerはgit checkoutの使用を禁止して、git switchとgit restoreに慣れるためのコマンドです。 switchとrestoreはcheckoutから分離した機能であり、コマンド名が作業を適切に表現するようになりました。 機能的には大きく変わらないため今まで通りcheckoutを利用しても問題ありません。 既存のユーザよりもこれから学ぶユーザへの学習ハードルを下げるための機能追加と考えると良いと思います。 既存ユーザの方でも新しいコマンドを使いたいという方はcheckoutの癖が抜けきれないと思うので、このツールを使うと矯正することができます。 準備 siwtchやrestoreはGit 2
Gitでcommitやpushを忘れることありませんか？git-remindはそういう｢忘れ｣を防ぐためのツールです - Qiita
Gitでcommitやpushを忘れることありませんか？git-remindはそういう｢忘れ｣を防ぐためのツールですGitgit-remindコミット忘れ防止ツール うっかりGitのコミットやプッシュを忘れてしまうことはないだろうか？ git-remindはそんな(僕のような)忘れっぽい人のためのツールで、Gitリポジトリの状態を監視して、git commitやgit pushがなされていないリポジトリを見つけ教えてくれる。 主な機能 git commit/git pushしてないリポジトリの一覧機能 複数のGitプロジェクトを横断して、コミットされていないファイルがあるリポジトリや、コミットはされているけどgit pushがまだされていないリポジトリを見つけ出して一覧にしてくれる。 デスクトップ通知 未コミット、未プッシュのリポジトリを一覧できる他に、それらのリポジトリがあればデスクトッ
アクセスキーのコミットを抑止できて安全便利な awslabs/git-secrets - kakakakakku blog
GitHub で awslabs のリポジトリを眺めてたら git-secrets という便利なツール（シェルで実装されてる）を発見した． どんなものかを簡単に説明すると，アクセスキーなどを誤ってコミットすることを Git の hooks を使って未然に防ぐツールで，誤って GitHub に push してしまったために，AWS を不正利用されてしまった，みたいな事故もたまに聞くし，そういうのを防ぐことができる．非常に良かったので，一部のリポジトリに git-secrets を設定した． github.com インストール make install でも良いけど，Mac なら brew が使える． $ brew install git-secrets インストールすると git secrets コマンドが使えるようになった． $ git secrets usage: git secrets
gitにおけるコミットログ/メッセージ例文集100
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
Emojiで楽しく綺麗なコミットを手に入れる | Goodpatch Blog
綺麗にコミットしてますか？？ はじめまして！Emojineerのnownabeです。グッドパッチではProttのサーバサイドエンジニアをやっています 本記事ではGitのコミットを綺麗に保つためにProttチームで導入しているEmoji Prefixを紹介します。 Emoji Prefixって何？ Emoji Prefixは「Gitのコミットメッセージの先頭にEmojiをつけよう」という一種のスタイルガイドです。 GitHubなどEmojiに対応しているGitホスティングサービスの利用を前提としています。 Emoji Prefixをつけてコミットすると、例えばGitHubならこのように表示されます。 基本はコミットメッセージの先頭にEmojiをつけるだけです。 ただし、EmojiはEmoji Prefixのルールに従って決める必要があります。 コミットの種類によってEmojiが決まる、という
git push --force でなく git push --force-with-lease を使う - valid,invalid
前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある git push --force でなく、最後に fetch したタイミング以降に他人が push していたら失敗する git push --force-with-lease を使う方が良い。 --force considered harmful; understanding git's --force-with-lease - Atlassian Developers Quipper では GitHub flow のような開発フローを採用している。 各開発者が feature branch を作成し、master / develop branch へ pull request を作る流れだ。 他人と修正箇所が重なってコンフリクトした際には rebase が必要で、 rebase 後の内容を push する際には
トピックブランチ内の変更を無視してgit bisectする方法 - kazuhoのメモ置き場
merge commitについては1st parentのみをたどりながらgit bisectしたいことってありますよね？ (参照: テストファーストなGitワークフローについて - kazuhoのメモ置き場) そういうとき、1st parent以外に属するcommitをgit bisect skipするの、どうやったらきれいに書けるのかなと思ってたのですが、以下のやりかたが一番よさげ。 $ git bisect skip $(comm -23 <(git rev-list HEAD | sort) <(git rev-list --first-parent HEAD | sort)) thanks to: ひろせ３１ on Twitter: "@kazuho comm -2 -3 <(cat A|sort) <(cat B|sort) とか？", Masakazu Takahashi on
git-flow cheatsheet
About git-flowはgitの拡張であり、Vincent Driessenの提唱するブランチモデルを実現するための高度なリポジトリ操作を提供します。 more ★ ★ ★ このチートシートは基本的な使い方とgit-flowの効果を表します。 ★ ★ ★ Basic tips Git flow は素晴らしいコマンドライン補助と出力を提供します。何が起こるか注意深く読み解いてください。 macOS Clientの Sourcetree は素晴らしいGUIとgit-flowサポートを提供します。 - Git-flow はマージすることをベースとして考えるソリューションです。リベースは行いません。 ★ ★ ★ macOS Homebrew $ brew install git-flow-avh Macports $ port install git-flow-avh Linux $ apt
巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
Emacsパッケージ特集 - Qiita
バージョン24から入ったpackage.elにより、プラグインの導入が格段に容易になったEmacs。そこで、ELPA互換のリポジトリの一つであるMELPAのダウンロードTOP50+αのパッケージについてまとめてみた。 （ランキングに関しては2014/3/26時点の情報を使用） それ単体で便利というよりも、有名なパッケージの依存関係でダウンロードされるライブラリもあるので注意。 ちなみに、個人的なオススメパッケージは、auto-complete、helm、flycheck、undo-tree、zenburn-theme、expand-region、smartparens、rainbow-delimiters、multiple-cursors。 また、TOP50には入っていないが、anzu、volatile-highlights、powerline、git-gutter-fringe、hlin
gitの新人研修でtigを使うことをおすすめする理由 - Qiita
はじめに ４月まで残すところ２ヶ月と迫り、新卒などを対象とした新人研修の準備が始まっている頃かと思います。 新人研修の中でgitを教える際に、筆者はtigの活用をおすすめしています。 講師の立場からすれば、短い時間に高効率でgitの本質を伝えることができます。 研修生の立場では、tigを利用して簡単で直感的にgitリポジトリを閲覧・操作することができます。 tigを使うとどうしてそうなるのか、いくつかの理由を以下に紹介します。 セットアップが簡単ですぐ使い始められる tigは依存関係が少なくポータブルな実装でありインストールが簡単です。 会社から提供する開発サーバーであっても、社員ひとりひとりが所有するPCやMacであっても、 yumやbrewなどのパッケージマネージャから少ない手順でインストールすることができます。 一例: CentOS6.4にgit tigインストールと使い方 - Qi
[git]リモートで削除されたブランチがローカルに残っている時、一括で削除する方法 - Qiita
GitHubを使っていて、pullrequestがマージされた時にブランチも一緒に消すことが多い。 すると、GitHub上ではブランチは削除されるのだけど、ローカルには残ってしまう。 $ git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/hoge remotes/origin/master 上の例だとremotes/origin/hogeが残る。 これを放置していると、remotes/origin/fuga、remotes/origin/piyoと徐々に増殖して行き、いつの間にか大変なことになっている。 そんな時、git fetch --pruneを使うと、リモートで削除されたブランチをガーッと削除してくれる。
![[git]リモートで削除されたブランチがローカルに残っている時、一括で削除する方法 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/f444e1349581e0a4124272a6430735fec2fa2315/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCZ2l0JTVEJUUzJTgzJUFBJUUzJTgzJUEyJUUzJTgzJUJDJUUzJTgzJTg4JUUzJTgxJUE3JUU1JTg5JThBJUU5JTk5JUE0JUUzJTgxJTk1JUUzJTgyJThDJUUzJTgxJTlGJUUzJTgzJTk2JUUzJTgzJUE5JUUzJTgzJUIzJUUzJTgzJTgxJUUzJTgxJThDJUUzJTgzJUFEJUUzJTgzJUJDJUUzJTgyJUFCJUUzJTgzJUFCJUUzJTgxJUFCJUU2JUFFJThCJUUzJTgxJUEzJUUzJTgxJUE2JUUzJTgxJTg0JUUzJTgyJThCJUU2JTk5JTgyJUUzJTgwJTgxJUU0JUI4JTgwJUU2JThCJUFDJUUzJTgxJUE3JUU1JTg5JThBJUU5JTk5JUE0JUUzJTgxJTk5JUUzJTgyJThCJUU2JTk2JUI5JUU2JUIzJTk1JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1mY2E4YTY1YjlkMDIzYjQzNTZmYmJiYTIyNzgyZDdkZg%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwa19raW51a2F3YSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9NzdhODEwMTdiNzczMTliN2NiNTY4MTYwZTgxM2ZiZWI%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Db21462f288dbcf90b6b8255330f9b063)
Git の diff を美しく表示するために必要なたった 1 つの設定 #git - 詩と創作・思索のひろば
Git に同梱されている contrib/diff-highlight を使います。 あとは README に書いてあることの引き写しですが、PATH の通ったディレクトリに置いて、~/.gitconfig に以下のように設定を書く。 [pager] log = diff-highlight | less show = diff-highlight | less diff = diff-highlight | less すると、対応するコマンドの出力がこんな風になります。 行レベルの diff に加えて、単語レベルでの diff もハイライトされ、GitHub での diff のように描画されました。 組み込みのオプションで --color-words というのがありますが、こちらを使うと行レベルの diff 情報が失われるので、少し不便だったわけですね。とすべて README に書いてあ
git reset --hard HEAD を安全にした - 永遠に未完成
昨日、git reset --hard HEAD してしまって大変なことになった話を書いた。私は普段これを cancel と言う名前に alias して使っている。 [alias] # 中略 cancel = reset --hard HEAD しかし前回のようなことがまたあってはたまらない。人間はミスするものだ。 alias があって実行しやすいのが問題なのだろうか? いや、割とよくする操作*1だし、alias しなくても使うだろう。 てことで、cancel が安全になるようにしてみた。 [alias] # 中略 cancel = !git commit -a -m 'Temporary commit for cancel' && git reset --hard HEAD~ 一旦コミットしてからそのコミットを消す。こうしておけば最悪 git reflog から元に戻せる。特にコミットす
git flow でのチーム開発ワークショップ資料 - Yamashiro0217の日記
この記事は会社内の別チームの方に、 僕の今のチームで git をどう運用してるかを ワークショップ形式で説明するための資料である。 事前準備 git と git-flow を入れておくこと 参考資料(Macでgitとgit-flowインストール) - xcode cli toolインストール -- https://daw.apple.com/cgi-bin/WebObjects/DSAuthWeb.woa/wa/login?appIdKey=d4f7d769c2abecc664d0dadfed6a67f943442b5e9c87524d4587a95773750cea&path=%2F%2Fdownloads%2Findex.action - homebrew のインストール -- https://github.com/mxcl/homebrew/wiki/installation - b
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Jenkins git plugin 爆死事例集
