The most-comprehensive AI-powered DevSecOps platformSoftware. Faster. GitLab is the most comprehensive AI-powered DevSecOps Platform.
Gitのインラインdiff (word-diffの進化型) - quattro_4's diary
gitの--word-diffなどは時々使うことがあると思いますが、さらにその出力を少しアレンジした方法が以下のgit diffオプション。 $ git diff --color-words --word-diff-regex='\\w+|[^[:space:]]'使いたい場面はあまり多くない気はしますが、主な用途としては、テキスト(HTML含め)の変更のdiffを見るときに使うと見やすいことが多いかと思います。 他では変数や文字の置換など、同じパターンの変更を大量にしたときなど。 以下、railsのドキュメント変更のコミットのdiffを見比べた例 $ git diff --color-words --word-diff-regex='\\w+|[^[:space:]]' 7a0dad2^..7a0dad2 $ git diff 7a0dad2^..7a0dad2 $ git diff -
【やっとわかった！】gitのHEAD^とHEAD~の違い - Qiita
20190502追記 わかりにくい表現を修正しました 「おまけ」を追加しました 追記ここまで そもそもHEADとは 現在チェックアウトしているブランチの先頭を指す。 ブランチの切り替えという動作は、「HEADの移動＋ワークスペースのファイルの更新」で成り立っています。 詳しくはこちらを参照ください。→ Git のブランチ機能 - ブランチとは ~ (チルダ) ~世代前のコミットを指定できる。 ^ (キャレット) 複数ある親コミットのなかからコミットを指定できる。 絵にしてみる チルダ チルダ指定をすることで、コミットをさかのぼって指定ができます。 HEAD~と指定することで、HEADに対して1世代前のコミットを指定でき、HEAD~~と指定することでHEADの2世代前のコミットを指定できます。 キャレット キャレット指定をすることで、複数親がいる場合に、親コミットを指定できます。 複数親がい
Git submodule の基礎 - Qiita
この記事は Git Advent Calendar 6日目の記事です！ Git submodule って最初わかりにくいと思うので、基本的な説明をしようと思います。 git submodule とは git submodule は、外部の git リポジトリを、自分の git リポジトリのサブディレクトリとして登録し、特定の commit を参照する仕組みです。 Subversion でいうところの、external と似ています。 さて、解説のため、手元に、リポジトリA (/path/to/a) とAの submodule として、よく使う例として Bootstrap (元Twitter Bootstrap) を登録してみます。 git submodule を理解するうえで重要なのは、 リポジトリAが指し示すsubmoduleとしてのBootstrapのcommit 現在のBootstr
自分が必要とする最低限の git submodule の知識 - Qiita
それは git プロジェクトに別のリポジトリの特定コミットを示すポイントを埋め込むものです。 理屈の上では、「どのディレクトリに対して、どのリポジトリが関連付けられており、コミットオブジェクトのハッシュはこれです」っていう情報が管理されているだけのシンプルなもの。 以下のような構成のプロジェクトを簡単に管理できます。 root_project/ ├── external_project │ ├── library1（独立した git リポジトリ） │ │ ├── lib │ │ └── src │ ├── library2（独立した git リポジトリ） │ │ ├── lib │ │ └── src │ ├── library3（独立した git リポジトリ） │ │ ├── lib │ │ └── src │ └── li
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
Gitのdiffコマンドにある--exit-codeオプション - Hail2u
npmコマンドでよく書くパターンにGitで固定のファイルをステージしてコミットするというようなものがある。なんらかの処理を行うメインコマンドのpostコマンドでよくやる。まれにその固定のファイルが更新されないこともあり、その時コミットしてしまうとcommitサブコマンドが正常に(終了コード0で)終了しない。これを避けるためにはステージされることで更新があったかどうかをチェックする必要があることになる。それはdiffサブコマンドの--exit-codeオプションを使うとうまく書くことができる。 例えば更新されているかもしれないfooというファイルをステージして、更新があった場合にのみコミットしたい、とすると以下のようにコマンドをつなげれば良い。 $ git add foo && git diff --cached --exit-code --quiet || git commit --mes
Git Snippet - Gist風にGitHub/BitBucket/GitLabのコードを埋め込み MOONGIFT
GitHubの提供するGistではコードを埋め込みで外部のWebサイトに表示する機能をサポートしています。しかし本体のGitHubの方では提供されていません。 そこでGitHubをはじめとして各種リポジトリサービスでGist風なコード埋め込みを可能にするのがGit Snippetです。 Git Snippetの使い方 Git Snippetで表示した例です。指定した行だけを表示できます。 ファイル全体を表示することもできます。 Git SnippetはGitHubやBitBucket、GitLabに対応しています。リポジトリのコードを説明したり、ブログ記事にする際などに使うと便利そうです。 Git Snippetはnode/JavaScript製のオープンソース・ソフトウェア（MIT License）です。 Git Snippet by Chiedo Labs chiedolabs/git
最近のgitを使った開発フローについて - その手の平は尻もつかめるさ
最近のgitを使ったWebアプリケーションのプロジェクトの開発フロー (主にブランチ運用) について記すものです． なお前提としてGitHub Enterpriseを利用しています． git-flow 大上段に構えたもののあまり特殊なことはしていなくて，基本的にgit-flowをそのまま踏襲しています． git-flowについてはしっかりした解説記事がインターネット上に数多く存在しますからそれらを参考にしていただければと思いますが，ざっくり説明すると masterブランチ，developブランチ，releaseブランチ，featureブランチ及びhotfixブランチがある masterブランチは常にリリース可能な状態になっている (すなわち現在本番で稼働しているアプリケーションのコードと等しい) developブランチは開発中の状態で，ステージング環境等に上がっている releaseブラン
CentOSでGit v2系をRPMで作成する - 本日も乙
[toc] 脆弱性スキャンツールVulsをインストールする際、Vulsのバージョンがv0.1.6まではGitのバージョンをv2以上にする必要がありました(最新版v0.1.7でv2以上でなくてもよくなったみたいです)。 CentOSでGitをYumでインストールしようとすると最新のCentOS 7.2でもv1.8.3が最新なので、v2以上をインストールするには自分でソースを持ってきてビルドする必要がありました。しかし、他のサーバも同様にGit v2以上をインストールする際、一つ一つビルドするよりもパッケージでインストールできた方が楽ですよね。 そこで今回は他サーバに配布するためにGitのv2系をRPMで作成してみました。方法等はgit 2.2.0 の rpm 作成方法 - tkuchikiの日記を参考にさせていただきました。参考記事ではCentOS 6.4でしたが、CentOS 7でも同じ方
git diffコマンドで比較する時のダブルドット(..)とトリプルドット(...)の違いとは？ | Yakst
Gitでブランチ(コミット)間の違いを表示するgit diffコマンドに存在するダブルドット(..)記法とトリプルドット(...)記法の違いについて、Stackoverflowの分かりやすい回答。 「git diffコマンドで比較する時のダブルドット(..)とトリプルドット(...)の違いとは？」という質問へのMark Longair氏の回答 git diffコマンドは通常(「通常」というのは、例えばマージコンフリクトを解消する際などには3ウェイマージを表示することがあるため)、コミットグラフにおける完全な2つのポイント間のツリーの状態の違いを表示します。git diffでの..と...の表記は、以下の意味になります。 言い換えると、git diff foo..barはgit diff foo barと完全に同じです。どちらも2つのブランチfooとbarの最新の変更同士の違いを表示します。
Stop using `git pull` for deployment! - The Grimoire
Stop using git pull for deployment!¶ The problem¶ You have a Git repository containing your project. You want to “deploy” that code when it changes. You'd rather not download the entire project from scratch for each deployment. The antipattern¶ “I know, I'll use git pull in my deployment script!” Stop doing this. Stop teaching other people to do this. It's wrong, and it will eventually lead to dep
サーバの/etcを自動的にGitとかにコミットとかプッシュしてくれるetckeeperを使う - Qiita
はじめに インフラを担当しています。 一人が管理できるホストには限りがあるなと思っていて、補助ツールがなければ10台ぐらいが精一杯かと思っています。 補助ツールを使うことで100台ぐらいまでは行けるんじゃないかと思っていて、そのためのツールを探していました。 普段のサーバ管理でやっていることを書いてみます。 チューニングなどでconfの調整 過去に他のホストで導入した設定の適用 バックアップと復元、移設 これらはetcを管理することで実現できそうですね。 過去にはSubversionを使って手作業で管理していましたが、この辺りを(半)自動化してくれるetckeeperというツールがあるということで試してみました。 インストールと初期設定 yumにもaptにもあります。 CentOSの場合にはepelを入れておきます。
Commit Hash から、該当 Pull Request を見つける方法 - Qiita
git blameなどを使用して、変更を加えたcommit sha hashだけわかった時、git show daced1d3のようにすれば、そのコミットの変更内容を見れます。ですが、本当は内容よりその変更を加えたPull Requestを知りたいことありますよね？ そんなコミットからプルリクエストを探したい時に使えるgit aliasコマンドを紹介します。 git showpr Pull Requestをマージしているコミットログを見つけます。 show pull request => showpr としてますが、名前は好きにつけてください。 .gitconfigのalias設定 [alias] showpr = !"f() { git log --merges --oneline --reverse --ancestry-path $1...master | grep 'Merge p
なぜdevelopブランチは必要なの？
「Gitのブランチ構成どうしましょうか？」 「とりあえずdevelop切ってやっていきますね。」 そのdevelopブランチ本当に必要でしょうか。 developブランチだけ使われていて、masterが全く使われていなかったりしないでしょうか。 よく聞かれるブランチ戦略としてはgit-flowやGitHub Flow、、GitLab Flow等があります。 git-flowにおいてはdevelopやhotfix、releaseといったブランチがありますが、GitHub Flowにはmasterブランチと機能開発ブランチの2つしかありません。GitLab Flowはmasterを中心に開発を行い、productionブランチを安定させていくスタイルです。 実際に新しいプロジェクトを始めるとしたら、どの構成が良いのでしょうか。 今回はカウルを開発するにあたり採用したブランチの構成とその背景につ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
tig でいま見ているコミットをブラウザで開く - @kyanny's blog
gitで無視されているファイルを表示する - Qiita
git-schemlexとddl-makerを使ったDB migrationの紹介 / git-schemalex and ddl-maker migration #golangtokyo - Speaker Deck
クラウド破産しないように git-secrets を使う - Qiita
gitでremoteをfetch専用(push禁止)にする方法 - xuwei-k's blog
