pre-commit
pre-commit A framework for managing and maintaining multi-language pre-commit hooks. Git hook scripts are useful for identifying simple issues before submission to code review. We run our hooks on every commit to automatically point out issues in code such as missing semicolons, trailing whitespace, and debug statements. By pointing these issues out before code review, this allows a code reviewer
Go製のCHANGELOGジェネレータを作った - wadackel.me
はじめに タイトルにある通り、git-chglog という Go 製の CHANGELOG ジェネレータを作りました。 git-chglog/git-chglog https://github.com/git-chglog/git-chglog Git を使用したコミットとタグからなる情報を元に CHANGELOG を作成するためのツールです。 まだまともなサンプルが用意出来ていないのですが、以下は Angular のリポジトリで試しに作ってみたイメージです。 2018/02/20 時点の Angular のコミット数がおよそ 9600 程度で、生成までの時間が 2.5〜3.5s なので、まぁストレスなく使えるレベルの速度かなと思います。 僕が普段仕事としている Web Front-End 界隈では、conventional-changelog というツールが存在し、恐らく最も使われていま
英語のコメントや issue で頻出する略語の意味 (FYI, AFAIK, ...) - Qiita
〔提案に対して〕いいと思う；問題ないと思う；〔コードレビュアーが、問題ないコードに対して〕レビュー終了；（コードの）承認
Git - 作業内容への署名
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
データのバージョン管理が可能な分散データベースNomsをさわってみる - Qiita
はじめに データベースやデータのバージョン管理をしたいと思ったことはありませんか？ データのバージョン管理が簡単にできれば、好きなタイミングのデータで分析したり、移行データを必要な各断面で管理したり、データが更新されたトレースを取ることもできるかもしれません。 そんなことが簡単にできればいいのになーと思っていたのですが、先日Tech Crunchの記事でGitの考え方を取り入れたNomsというデータベースを知りました。Googleで検索してみても日本語の情報があまり出てこなかったため、（どんなものかいまいち分かっていないのですが）とりあえずインストールからさわってみるまでを書いておきます。 Git - attic-labs/noms TC - コンテンツ・アドレッサブルで多バージョン分散データベースNomsのAttic Labsが$8.1Mを調達 Nomsとは Gitの考え方を取り入れたデ
gitにおけるコミットログ/メッセージ例文集100
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
Gitでコンフリクトが起きても大丈夫！ コンフリクトを解消させる3つの方法
本連載「こっそり始めるGit／GitHub超入門」では、バージョン管理システム「Git」とGitのホスティングサービスの一つ「GitHub」を使うために必要な知識を基礎から解説していきます。具体的な操作を交えながら解説していきますので、本連載を最後まで読み終えるころには、GitやGitHubの基本的な操作が身に付いた状態になっていると思います。 連載第4回目の本稿のテーマは「コンフリクトが発生したときの対処方法」です。 前回の「Git初⼼者でも分かるGitブランチの作成、確認、切り替え、マージ、削除の⼿順」までで「ブランチ作成」から「マージ」までの一連の操作を行いました。前回行った一連の操作では片方の「second」ブランチだけで変更を進めたので、変更内容が複数ブランチ間で「コンフリクト（衝突、競合）」することなく簡単にマージできました。しかし、実際の開発では変更内容がコンフリクトしてしま
GPG鍵を作って運用し、Git(hub)やMercurialで自分が書いたコードに署名をする - kuenishi's blog
自分が書いたコードに署名をしておくことはプログラマの常識であり基本動作です（かくいう私もメールは署名してないけど…）。なので私も一人前のプログラマになるべく、自分が書いたコードに署名をするようにしてみた。 GPG 鍵を作ったり準備したり GnuPGのインストール@MacOS $ sudo port install gnupg 鍵をつくります。有効期限は2年間。もし秘密鍵が漏れた場合でも、2年経てばほとぼりが冷める。 $ gpg --gen-key gpg (GnuPG) 1.4.20; Copyright (C) 2015 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent p
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が決まる、という
中の人に聞いたGitHub flowの本当の使い方 - Qiita
背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること
読みやすいREADMEを書く | Yakst
いくつかのオープンソースプロジェクトを公開している筆者からの、読みやすくユーザーにやさしいREADMEを書くためのアドバイス。 この記事は、Rowan Manning氏による「Writing a Friendly README」(2016/3/14)を翻訳したものです。 あなたのプロジェクトのREADMEは、かなり重要です。そこはプロジェクトに初めて来た人が大抵最初に見るであろう場所であり、唯一のドキュメントであることもよくあります。あなたのオープンソースプロジェクトにとってのREADMEは、企業にとってのウェブサイトのようなものです。ウェブサイトはユーザーエクスペリエンスの注目を集めるところですが、READMEがユーザー観点で考えられることはほとんどありません。 この記事では、分かりやすいREADMEを書くために役立ち、開発者(ユーザー)の要求に見合い、開発者がプロジェクトを初めて見たの
「Git 2.9」リリース、「git diff」や「git log」での表示変更などが行われる | OSDN Magazine
Git 2.9.0は3月に公開されたバージョン2.8からのアップデートとなる。 UI、ワークフロー関連では、Gitリポジトリへのプッシュ時にメールで通知を送信する「git-multimail 1.3.1」がサポートされた。また、「git diff」や「git log」などのコマンドでファイル名のリネームをデフォルトで確認できるようになった。オプション設定によってこれを無効化することも可能。 新たに「interactive.diffFilter」設定変数が加わった。これを利用して、「git add」コマンドでインタラクティブに変更点を追加するための「-i」オプションを使用した際のdiff表示方法をカスタマイズできる。そのほか、git tagコマンドでは明示的に「-a」や「-s」オプションを指定していない場合でも「annotated tag」を生成できるようになった。「tag.forceSig
gitでタグ名に日付を含めているのはダサい - アジャイルSEの憂鬱
この記事は私の考えるタグの使い方なので、もし間違っている事や反論のある方は ぜひコメントやブログを書いてください。読みます！ タグを打つ意味 そもそも、なぜgitでタグを打つのか？ これは下記のような理由だと思う。 sha1でコミュニケーションするのは一般的に難しい*1 コミットとは別にデプロイなどのイベントをリポジトリ内で扱うため そもそも、gitのタグとは gitのタグはタグオブジェクトという形でgitのリポジトリ内に保存されます。*2 タグオブジェクトには下記の情報が含まれます。 タグを作成した日時 タグ作成者 タグを作成した理由 タグを付けたコミットのsha1 日付つきのタグとは タグの名前に日付情報がつけられたものです。 $ git tag -m "bump tag" 1.0.0-`date "+%Y%m%d_%H%M%S"` $ git tag -l 1.0.0-2014060
Git 2.7 の優れた新機能 | Atlassian Japan 公式ブログ | アトラシアン株式会社
Git 2.6 からわずか 2 カ月後、膨大な機能と修正、そして性能の向上を果たした Git 2.7 がリリースされました。ここでは Bitbucket チームが興味を持った新しい機能を紹介します。 git worktree の完成 Git 2.5 で導入された素晴らしい git worktree コマンドを使うと、複数のリポジトリブランチからのチェックアウトやブランチ上での作業を、異なるディレクトリで同時に行うことができます。たとえば、簡単な修正をする必要があるけどワーキングコピーを汚したくない場合、次のように新しいブランチを新しいディレクトリにチェックアウトすることができます。 Git 2.7 には、リポジトリのワークツリー (および関連するブランチ) を表示する git worktree list サブコマンドが追加されています。 ワークツリーをサポートする git bisect コ
分散型バージョン管理ツール「Git 2.5」リリース
分散型バージョン管理ツール「Git」の開発チームは、最新版となる「Git 2.5.0」を7月27日（現地時間）にリリースした。Gitのメンテナーを務めているのは、米Googleの濱野純（Junio C Hamano）氏。 UIやワークフロー、および機能面での新機能は、bashの補完スクリプトへのいくつかのオプションの追加、git diffコマンド使用時と--ws-error-highlightオプション併用時の背景の塗り潰し、git helpで表示されるコマンドリストのグループ分け、git p4でファイルがすでに開かれている際の正確なファイルタイプの認識などが追加されている。 パフォーマンスや内部実装については、既存のオブジェクト名に使用されるunsigned char [20]のstruct object_idへのコンバート、for_each_ref()コールバック機能によるstruct
Gitの便利な-pオプション四兄弟 - エンジニアをリングする
この記事はGit Advent Calendar 2014の6日目の記事です！ （更新がお昼になってしまいました、ごめんなさい＞＜） みなさん！ Gitの-pオプション使ってますか？ 今日は便利な-pオプションを使えるコマンドと、使いどころをご紹介します！ 紹介する内容 git add -p git stash -p git log -p git stash show -p git checkout -p git add -p きっとこれが一番有名ですね！ 追加したい変更を、ファイル単位ではなく差分のブロックごとに追加していくことができます。 Git管理されているindex.htmlに、以下の修正を加えたとしましょう。 ヘッダーのメニューの文字を小文字から大文字に変更 Contactに新しいリンクを追加 このまま両方まとめてコミットしてコミットメッセージに両方の内容を書いておくというのもひ
「Git 2.2」リリース、細かな機能強化や性能改善が行われる | OSDN Magazine
分散型バージョン管理システム「Git」開発チームは11月26日、最新の安定版となる「Git 2.2.0」をリリースした。細かな機能強化と性能の改善が特徴となる。 Git 2.2は8月に公開されたバージョン2.1に続く最新版。この間、77人の貢献者が参加し、合計で550件以上の変更があったと報告している。 ワークフローとユーザーインターフェイス関連では、「git fast-export」コマンドにレポジトリの内容や履歴を送信せずに問題点を報告できる「–anonymize」オプションが加わった。また、「git config」コマンドを「–edit –global」オプション付きで実行した際に、ユーザーごとのグローバル設定ファイルが存在しない場合スケルトンファイルを元にした設定ファイルが生成されるようになった。 「git push」コマンドでは、GPG署名付きのプッシュを実行できる「–signe
GitLab flowから学ぶワークフローの実践 | POSTD
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「Git 2.4」がリリース、複数ブランチへのプッシュ可能な--atomicオプションが追加
日本語版 : IBM Bluemix
