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
2020年に「コミットログは良くならない」というのを悟ったので、現実的な解決案である「git-notesでメモを残す」について記事を書いておきます。 前回の記事 sinsoku.hatenablog.com git-notes 詳細は git notes --help を読んでください。 概要は以下の通りです。 コミットログとは別にメモを残せる コミットはそのままなのでshaは変わらない shaが変わらないのでCIの再実行が起きない 他人のコミットにメモをつけられる 他人に作業を依頼する必要がない メモもリモートにプッシュできる 過去のコミットにメモを残せる 使い方 メモを書く git notes edit <sha> でメモを書くと、git log のときに一緒に表示される。 $ git notes edit d2cdf0b $ git log -1 d2cdf0b commit d2c
「Jenkins X」発表。Git/Docker/Kubernetesに特化したことでCI/CD環境の構築運用を自動化 ソフトウェアの開発プロセスにおいて、「Jenkins」はビルドやテスト、デプロイなどを自動化してくれるツールとしてよく知られています。 そのJenkinsの派生プロジェクトとして、「Jenkins X」が発表されました。Jenkins Xは、Git、Docker、Kubernetesの環境を前提とすることで、Jenkinsの設定、運用などを大幅に自動化し、より簡単な導入と運用を実現するものです。 Jenkins Xは、Git/Docker/Kubernetes環境に特化 オリジナルのJenkinsは汎用的なビルドやテストの自動化ツールとして、さまざまな環境やツールと連係できるように作られています。そのため柔軟なコンフィグレーションが可能になっていますが、一方でそれが導入や
gitで外部リポジトリを取り込んで利用するには、submodule(サブモジュール) とsubtree merging(サブツリーマージ)の2手法があります。 私の観測範囲内では、サブモジュールはよく利用されていますが、サブツリーマージは目にしません。 そこで、サブツリーマージを試してみての使い分けや思ったことをつらつらと。 大雑把な要点を最初に書いておく 外部リポジトリを外のものとして取り込むならサブモジュール 外部リポジトリを取り込みつつ、中のものとして手を加えていくならサブツリーマージ git初心者にはサブモジュール(異論ありそう) サブツリーマージ使ってみた github.com/marutanm/dotfiles 中身としては、よくある環境設定ファイル一覧です。 前提として、 tmux.conf(gistにおいていた) vim設定(githubにおいていた) zsh設定(gith
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 に書いてあ
2013/08/13 GitHubの新デザインに対応するために記事内容・画像をアップデートしました。 こんにちは、ブログ記事を書くのが約2年ぶりのruedapです。 さっそくですが、Pull Request（プルリクエスト）機能を使ったことはありますか？ GitHubの代表的な機能で、「pull req」や「PR」とも略されたりして、名前はよく聞きますよね。 この記事は、Gitはいちおう入門済みで、GitHubも使い始めたけど、Pull Request機能はまだ使ったことがない、そんな人に向けた 簡単な方のPull Request の入門記事です。 もう1つのPull Requestについて Pull Request機能の解説としてよくあるのは「他の人のリポジトリを自分のGitHubアカウントにFork（コピー）してきて、変更を加えて、それを元のリポジトリに取り込んでもらうようにリクエスト
$ 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
VimのステータスラインにGitのブランチ名を表示させる、という記事で以下の一文が。 当然、ターミナルのプロンプトには表示させてますよね？ 今こそ！git の branch を vim のステータスラインに表示！！するとき！！！ すみません、表示させてませんでしたッ…! WindowsでmsysGit使ってる時にはプロンプトにブランチ名が表示されてて、これ結構便利かもなーとは思ってたんだけど、そもそも自分はGitのブランチをまともに使えてないので、ありがたみがよくわかってなかった。でもこれからちゃんと使うためにも早めに表示しておいたほうが良さそう。上記の記事のようにVimでも表示させたいしね。というわけで、とりあえずMacのターミナルでGitのブランチ名を表示できるようにしておく。完成形はこうなる。 git-completion.bash 今回はこちらの記事を参考にさせてもらった。ちなみに
2017.8.31 追記 この記事は間違っています。正しくは下記でした。 git submoduleの更新方法を勘違いしていた 昔書いた記事を参考にしてくださった方がいて、 でも「git submodule updateで更新できないよ」と。 gitのsubmoduleだけを最新版にしたい場合のコマンドメモ - Reinvention of the Wheel 私自身もgit submodule updateで更新できると思ってました。 というか、一度も更新処理試してなかった。 結論から言うと これでOKでした。foreach便利。 $ git submodule foreach 'git pull origin master' $ git submodule update ですが、no branch になってしまってるsubmoduleがあったので、pullするのはこっちの方がいいかもし
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 Advent Calendar / Jun. 29日目の記事です．28日目は@uasiさんの「どこでも使える git diff と git apply」でした． 「間違ってマージしていないブランチを消した」「reset --hard HEAD^*で戻しすぎた」ということがたまにある． しかしgit reflogを使うと(GCされていなければ)過去のあらゆるコミット履歴を見ることができ，git logやgit branchでは辿り着けない時点まで戻すことができる． $ git reset --hard HEAD^^ # HEAD^と指定するつもりが間違えた! $ git reflog f5cb888 HEAD@{0}: head^^: updating HEAD b0b8073 HEAD@{1}: merge @{-1}: Merge made by the 'recursive'
git rebaseについてのtips - けーこ in サンフランシスコ gitを使って開発をすすめていると、このようなコミットを見かけることがあります。 Merge branch ‘master’ of git://github.com/hogehoge 最新のマスターを私のブランチにマージした、という意味のログなのだが、 はっきり言ってこれ必要ないね。 ブランチをマージして、その後にgit pullしたあとに出てしまうコミットのようで、 pull requestを出す前に最新のマスターを自分のブランチにマージしたいために このようなコミットメッセージが出てしまうようだ。 要するに、自作したブランチの修正が、git pullしたmasterブランチの最新の修正よりも 前だったら上記のようなコミットメッセージを出しつつ、ブランチのコミットを前に 持ってくるわけですね。 で、 git lo
→→→〇www.js3311.com职业教育中心校为江苏省南通市规模最大的职业学校。2004年晋升为国家级重点职业高中。2009年成为首批江苏省四星级中等职业学校暨江苏省高水平示范性中等职业学校，跻身于全省600多所中等职业学校前13所强校之列。学校占地面积19.98万平方米，建筑面积14.68万平方米，教职员工504人，专任教师331人，实验实训场所面积2.6万平方米，全日制在校学生5736人。
Gitの使い方を覚えるにあたって、まず知っておきたいのは――git-cloneだのgit-commitだのは当然として――「操作をミスったときにどのように回復するか」である。それを実現するのは、次の３つのコマンドだ。 git-commit --amend git-reset git-reflog git-commit --amend あるファイルをコミットしたとしよう。 $ (edit...) $ git commit -am 'メッセージ生成処理を実装したよ。'しかし、しばらくして彼は気づいた。 def create_massage(param) ...typoしてる！massageじゃない、messageだ！マッサージを作ってどうする！ 慌てるな。まずは直してステージに上げるんだ*1。 def create_message(param) ...$ git add .そして…。 $ gi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
