Conventional Commits
Conventional Commits 人間と機械が読みやすく、意味のあるコミットメッセージにするための仕様 Conventional Commits 1.0.0 概要 Conventional Commits の仕様はコミットメッセージのための軽量の規約です。 明示的なコミット履歴を作成するための簡単なルールを提供します。この規則に従うことで自動化ツールの導入を簡単にします。 コミットメッセージで機能追加・修正・破壊的変更などを説明することで、この規約は SemVer と協調動作します。 コミットメッセージは次のような形にする必要があります: 原文： <type>[optional scope]: <description> [optional body] [optional footer(s)] 訳： <型>[任意 スコープ]: <タイトル> [任意 本文] [任意 フッター] あな
[Git] .gitignoreの仕様詳解 - Qiita
対応バージョン この記事の内容は、少なくともGitのバージョン2.19.1までは対応している。 もし最新のGitで新しい動きがあれば随時更新する。 基本 .gitignoreを使うと無視する（Gitのトラッキングの対象外とする）ファイル or ディレクトリを指定できる。 .gitignoreは複数のディレクトリに置くことができる。 深い階層の.gitignoreに書かれた指定の方が優先順位が高い。（後に解釈される） .gitignore内の記述は上の行から順に以下のように解釈される。 /を含まない行（fileなど） .gitignore以下の全サブディレクトリ下にあるこの名前のファイル or ディレクトリを無視する 末尾以外にのみ/を含む行（/file, /path/to/file, path/to/fileなど） .gitignoreが置いてあるディレクトリをカレントディレクトリとする相
![[Git] .gitignoreの仕様詳解 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/61bcac80a1da9fdcc62997a7502b04ccd6936e47/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-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCR2l0JTVEJTIwLmdpdGlnbm9yZSVFMyU4MSVBRSVFNCVCQiU5NSVFNiVBNyU5OCVFOCVBOSVCMyVFOCVBNyVBMyZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9MGNmOWFiNjA3ZWI2ZGJiYmE3YzNjOWUzZjA4MzYyNzY%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBhbnFvb3FpZSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MWI2YjM3NTQ2NWU2MzcxNDBlNWEzZjNkY2NjMTI2MTQ%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Dd88115df7ea0f316615170ac01433804)
CircleCIでgit-pr-releaseする | おそらくはそれさえも平凡な日々
git-pr-releaseそのものの説明に関してはninjinkunの以下のエントリを参照ください。 git-pr-releaseのすすめ さて、現職に入社したら、git-pr-releaseが使われていたのですが、リリース担当者が手元で実行するフローになっていました。しかし、git-pr-releaseの本場であり発祥の地でもある、はてな社では、git-pr-releaseはCIに作らせるものであったので、それに倣って、こちらも現職で利用しているCircleCIに作らせるようにしてみた。 手順 .git-pr-releaseをrepositoryに配置する GIT_PR_RELEASE_TOKEN をCircleCIに登録する .circleci/config.yml にjobを設定する おまけ machine accountを作るといいよ Triage(トリアージ)権限が便利 1.
美容内服薬ラボットメディカルクリニック【公式】
オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。
gitレポジトリ内のディレクトリを別のgitレポジトリ以下に移動する - Qiita
具体的には repo-A/dir1/dir2/dir3 を repo-B/dir4/ 以下に入れたい。 つまり、 repo-B/dir4/dir3 としたい。 repo-Aの履歴を書き換え、移行後の形に整える cd /tmp git clone https://github.com/repo-A cd repo-A/ git filter-branch -f --subdirectory-filter dir1/dir2/dir3/ -- --all # dir3以外のファイルを消し、dir3以下のファイルがrepo-A以下に展開される。 git filter-branch -f --tree-filter "mkdir dir3 && git mv -k * dir3/" # 履歴の書き換え。dir3ディレクトリを作って、mv。 git filter-branch -f --tree-f
GitLocalize - Continuous Localization for GitHub Projects
Here's what makes GitLocalize a great fit for GitHub-based localization projects: Your repository is the single source of truth. GitLocalize tracks changes in both the source and translated documents and pulls them into the project. Translations added on GitLocalize are sent to the repository via a pull request. Have existing translations that need to be imported? No problem! Those will be synced
【今日からできる】コミットメッセージに 「プレフィックス」 をつけるだけで、開発効率が上がった話 - Qiita
はじめに 今まで commit message を「なんとなく」書いていたが、プレフィックスをつけることで、コミットメッセージに対する考え方が変わった。 そのおかげで開発効率が上がったので、その内容をシェア。 プレフィックスをつけるってどういうこと？ 以下のようにコミットメッセージの先頭に、なんらかの文字をつけること。 feat: xxx という機能を追加 fix: yyy で発生するバグを修正 refactor: zzz の機能をリファクタ のように feat, fix, refactor などがプレフィックスです。 最近 OSS の Contribution Guide などでよく見かけます。 導入したプレフィックスルール Angular.js/DEVELOPERS.md Angular.js の開発者ガイドに書いてあるメッセージを参考にしました。 以前のコミットメッセージ（例 ちなみ
ベアリポジトリとノンベアリポジトリ：理論編〜GitでWordpressのテーマを管理 - トリコロールな猫
[2016/12/19追記]「「MBAでスクリプトを書き、リモートサーバ上で実行する」をGitで実現する - Qiita」を公開しました。ここと同じ仕組みでWordpressでなくRubyスクリプトを管理する方法です。 早く公開したかったのに思いのほかハマってちょー頑張った@nekotricolorです。 「バージョン管理システムとは何か〜GitとSubversionの違い」からの「VirtualBox上にインストールしたUbuntuにSSHで接続する」の続きです。 この記事には理屈しか書いていませんので、実際の設定は「ベアリポジトリとノンベアリポジトリ：実践編〜GitでWordpressのテーマを管理」を参照ください。 お題：「Gitを使って、本番環境のWordpressのテーマを、複数のPC上にあるローカルのテスト環境で確認してから更新できるようにする」 ノンベア（non-bare）リ
Git で複数のリポジトリをまとめたり、逆に切り出したりする - Qiita
~/repo1/subdir に ~/repo2 を入れる あるリポジトリのサブディレクトリに別のリポジトリの中身を入れたいとき。たとえば、あるリポジトリのサブディレクトリを切り出して別のリポジトリとして管理しているものを、元のリポジトリに合流させたいとき。 cd ~/repo1 git remote add repo2 ~/repo2 git fetch repo2 # サブディレクトリの内容に repo2 の内容をマージする # （repo2 と内容が似ているサブディレクトリを自動で判別） git merge -s subtree repo2/master # ↑でうまくいかないときにはパスを指定する↓ git merge -X subtree=subdir repo2/master # そもそも ~/repo1/subdir が存在しないときには↓ git read-tree --p
Git、GitHubを教える時に使いたい資料まとめ - Qiita
0. はじめに 業務で技術指導を行うにあたり、Git、GitHubについて説明する機会が多くなってきました。そこで、そんな時に使えそうな資料を整理してみました。 今後も新しい資料を見つけたら、随時更新していきたいと思います。またおすすめがあれば、是非ご紹介ください。 0.1. 読者対象 本記事の対象は、以下の様な方々です。 Git、GitHubの使い方について、他のメンバーに説明、指導する必要がある。 Git、GitHubの使い方について自習したい。 本記事にて紹介する資料は、以下の様な方々を想定して選別しています。 コンソールの操作にはある程度慣れている。 Subversionなど、他のバージョン管理システムの使用経験がない。 1. インタラクティブなチュートリアル Webブラウザ上で動作するインタラクティブ（対話的）な教材です。gitコマンドなどの環境構築は不要で、環境を破壊してしまう
git で特定のディレクトリだけをclone して管理する - それマグで！
git clone するとガッツリとれちゃうんだ。 でも、git ってそういうもんだし、git フォルダを git でネストすりゃいいんだけど。。。 git で特定のフォルダだけを取り出したい。 github.com が不可視のプライベート・レポジトリの数に上限があるので、どうしてもgitレポジトリの数を増やせないとか。だから特定フォルダを取り出したいとかね。 git 初心者が混じってると、なんでも全部突っ込んできてツライ。もちろん教育が必要なんだけど、先輩を教育するのも忍びないし、何よりまだソコまで至ってなかったり。。。とりあえず、管理してる全部のサイトを一個のgit フォルダに突っ込んだりしちゃうんだよ。 SVNを使ってたりしたので、全部を入れなきゃダメって思ってるところあるし そういう時に、まとめてcloneしたり、ずっとデータをダウンロードしてくるのはつらいものがある。 そんな時に
Git初心者に捧ぐ！Gitの「これなんで？」を解説します。
はじめましてこんにちは、今年新卒でKRAYに入社しました亀井と申します。 会社のみなさんからは「あさちゅん」と呼ばれております。どうぞよろしくお願いします。 突然ですが、みなさん使ってますか？ Git。 KRAYではバリバリ活躍してるGitですが、 「よくわからない……」と頭を抱えてる方も多いですね。 わたしも抱えてます。 正直、KRAYに入社するまでターミナルを使ったことすらなく、 Gitも入社してから使いだしたので初心者もいいところです。 そんなわたしが1日約200回×3ヶ月ターミナルでGitコマンドを打ち続けて やっとわかってきた、Gitの「これなんで？」を解説します。 主にGit初心者、Gitについて理解を深めたい人向けです。 もくじ なんでcommitする前にaddしなきゃいけないの？ ブランチってなんのために分けるの？ HEADってなんなの？ 消したファイルもコミットしなきゃい
git pull と git pull --rebase の違いって？図を交えて説明します！ | KRAY Inc
はじめに こんにちは、クレイの亀井です。ここ最近一気に気温が上がりましたね。顔に重点的に汗をかくタイプの私には憂鬱な季節がやってまいりました さて、今月正式リリースしました(！) DocBase プロジェクトではクレイ外部のデザイナーの方と一緒に開発しています。SourceTree で Git を使っている方で、軽いデザイン修正などは弊社の Rails プロジェクトに直接手を加えてプルリクエストを送ってくれます。 こちらのデザイナーさんに「プルリクエストを送る際は、作業ブランチで git pull --rebase origin master してから送ってもらえますか？」とお願いすると「pull はわかるんですけど、この --rebase ってなんですか？これつけると何が変わるんですか？」と質問がきたのです。 作業ブランチで git pull --rebase origin master
How to undo (almost) anything with Git
Open SourceProductHow to undo (almost) anything with GitOne of the most useful features of any version control system is the ability to "undo" your mistakes. In Git, "undo" can mean many slightly different things. One of the most useful features of any version control system is the ability to “undo” your mistakes. In Git, “undo” can mean many slightly different things. When you make a new commit,
gitやcurlやwgetでGitHubにアクセスするとcertification errorになる原因を調べてみた - このブログはURLが変更になりました
中の人に裏を取ったわけではなく私の推測です。間違っているかもしれません。 2010年11月から2011年5月末までの状況(gitやwgetでcertification error) 2010年11月頃、GitHubではすべてのアクセスにSSLを使うよう仕様が変わった。 この時、SSL証明書にはワイルドカード証明書(*.github.com)が使われていた。 *.github.comのワイルドカード証明書にgithub.comは含まれないのだが、SSL証明書にはX509v3 Subject Alternative Name(subjectAltName)が設定されている*1ため、subjectAltNameに対応したクライアントであれば問題ない。 しかし、wgetの最新版1.12はsubjectAltNameに未対応*2。wgetではcertification errorが出ていた。 参考
gitにおけるコミットログ/メッセージ例文集100
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
GitHub - x-motemen/git-pr-release: Release pull request generator
Creates a "release pull request", whose body consists of features list or pull requests that are to be released into production. It's especially useful for QA and pre-release checks. git-pr-release automatically collect pull requests merged into master branch and generates the content of the release pull request. Suitable for branching strategy like below (similar to git-flow): Feature branches ar
GitのHEAD^ HEAD~やらダブルドット トリプルドットやら
こんにちは。monipla facebookを担当している佐藤（ま）です。 アライドでは「大佐」と呼ばれております。 最近Gitの操作にも慣れてきましたが、SourceTreeは未だ手放せません。 さて今回は、関連性はありませんが「HEAD^ HEAD~」と「ダブルドット/トリプルドット」について書いていきたいと思います。個人的に最初少しとっつきにくかったので。 HEAD^とHEAD~ まず、HEADとは「今いるブランチの最新コミット」のことですね。 つまり「git show HEAD」とすれば最新のコミット情報が見れることになります。 なのでHEADを起点にすればわざわざハッシュを指定しなくてもコミットログを見ることができます。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Introduction | 技術文書をソフトウェア開発する話
gitbook.com | 技術文書をソフトウェア開発する話