ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
アクセスキーのコミットを抑止できて安全便利な 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
Learn Git Branching
A interactive Git visualization tool to educate and challenge!
1つのgitリポジトリに複数の作業ディレクトリを作る - Qiita
（commit or stash + checkoutすらめんどいことだって、あるんですよ・・） そもそもリポジトリと作業ディレクトリの違いって？ gitリポジトリには、コミットされている内容やブランチなどの全ての情報がつまっています。一方で作業ディレクトリは、リポジトリ内のあるcommitの内容を、ファイルとして書き出したものになっています。 git-new-workdirコマンド gitリポジトリに紐づく新たな作業ディレクトリを作成します。 ただし、デフォルトでPATHが通っていません。Fedoraあたりなら /usr/share/doc/git-1.7.10.2/contrib/workdir/git-new-workdir に、homebrewなら /usr/local/Cellar/git/1.7.12.4/share/git-core/contrib/workdir/git-n
Travis CIからgh-pagesへデプロイする設定 via SSH/git push
最近はGitHubリポジトリのgh-pagesブランチでサイトを公開する機会が増えているのですが、 リポジトリが更新されたら自動でサイトも更新できるようにしたいです。 以前は、GitHub Access Tokenを発行して、Travis CIのconfig(secret)にそのTokenを埋め込んで、Tokenを使ってpushをしていました。 しかし、GitHub Access Tokenは簡単に発行できるとはいえリポジトリ単位で管理できる権限となっていないため、Tokenが漏れてしまうと管理ができないという問題があります。 (実際 git push url-with-secret >/dev/null 2>&1などしないと簡単に漏れてしまう) Best Practices in Securing Your Data - Travis CI そのため、最近はSSH鍵を使ってリポジトリへp
gitの良さがいまだに分からない - 負け犬プログラマーの歩み
ここ2年ぐらいで俺が働いた現場はみんなgitを採用している。就職エージェントと面談するときもgit経験の有無をよく訊かれるし、今ではVSSやCVSどころか、SVNですら時代遅れになってきて、SVNを使っている現場は「レベルが低い」「保守的・旧態依然」という雰囲気すら感じる。 俺としては4-5年前からgit(GitHub)を使っているし、gitを使うこと自体に抵抗はない。一通りの基本操作はできるし、人並みにはできると言っても差し支えはない。 …が、正直gitの良さがあまり見えてこない。 もし俺が中規模以上のプロジェクトのリリースを本格的に管理する側であれば全然違った感想を持ったかもしれない。でも一人の開発者として、せいぜい10人程度のプロジェクトで利用する限り、「gitで良かった」という状況があまり思い当たらない。 ではgitの何が気に食わないのか書いていきたい。 ①gitは馬鹿には難しい
gitにおけるコミットログ/メッセージ例文集100
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
中の人に聞いたGitHub flowの本当の使い方 - Qiita
背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること
あのコミットをなかった事に。git rebase -i の使い方
以前、Gitの使い方、よく使うGitコマンド という記事を書きましたが、git rebase -i の項目に書き足したいことが増えてきたので別エントリに切り出し、内容を見直しました。 git rebase -i を使うと、最新のコミットから指定したコミットまでの歴史を対話式に改変することができます。具体的には以下のことができます。 コミットメッセージを変更するコミット内容を修正するコミットを分割するコミットをまとめるコミットを削除する 私個人の利用シーンとしては、開発ブランチを master にマージする前（プルリクを送る前）にコミットの整理に使うことが多いです。一発できれいなコミット履歴を作るのは難しいので、散らかったコミットを後から整理するのによく使います。Git って便利だなあと思う瞬間です。 目次 rebase -i の使い方 reword コミットメッセージを変更する edit
git commit --fixup とは何か - 詩と創作・思索のひろば
git commit --fixup というオプションの存在を最近知って調べた。 ヘルプとリリースノートより "git commit" learned the --fixup and --squash options to help later invocation of interactive rebase. Git v1.7.4 Release Notes --fixup=<commit> Construct a commit message for use with rebase --autosquash. The commit message will be the subject line from the specified commit with a prefix of "fixup! ". See git-rebase(1) for details. 1.7.4 から入って
もうGitは怖くない： 自信を持って使いたいあなたへ - 檜山正幸のキマイラ飼育記 (はてなBlog)
2014初頭に書いた「WindowsにおけるGit利用環境は整った： Git for Windows と SourceTree for Windows」の最後の文： ブランチは、Gitのなかで最も重要でありながら最も分かりにくい概念でしょう。表面的な言葉に騙されず、先入観を持たず、SourceTreeの視覚的表示（樹形図）の力を借りながら学習するのが、理解への一番の近道です。 そんへんの詳しいことはまたの機会に述べるかも知れません。 1年半以上たってしまいましたが、「またの機会」がやって来ましたよ。ええ、Gitの説明をします、ブランチを中心に詳しく。 「基礎編」と「ブランチ編」で2回に分けようかと思ったけど、長大な記事として一挙公開。これからGitを使う人が対象ではありません。Gitが何をやっているのか、自分が何をやっているのかイマイチ自信が持てない方向けです。 ブランチやマージって、なん
A successful Git branching model » nvie.com
Note of reflection (March 5, 2020) This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea. Du
GitHubで複数アカウントを使う場合のSSH configファイルの設定
Security Software GitHubで複数アカウントを使う場合のSSH configファイルの設定※当サイトにはプロモーションが含まれています。 GitHubにsshでアクセスする場合、使用する鍵ファイルをsshのconfigファイルに指定していると思います。GitHubの仕様上、複数のアカウントを使うと必然的にSSHの鍵もそれぞれ用意することになるわけですが、そうなると github.com という1つのホスト(というかドメイン)に対して複数の設定が必要になります。この設定方法についてのメモです。 これはGitHubに限った話ではなく、任意のホストに対して複数のssh鍵(やその他の設定)を使い分けることができます。 以下の状況を仮定しますアクセスするホスト(またはドメイン)github.com設定するアカウントとそれぞれの鍵ファイルへのパスfoo アカウント~/.ssh/gi
ネイティブと働いて分かった英語コミットメッセージの頻出動詞10つ
ウッ ここで詰まる事は往々にしてあります. 特に急いでる時の煩わしさは甚だしいです. どうせならそれっぽい英語を使いたいのでOSSや同僚のコミットメージの語彙の出現確率を調べてみましたら、 もちろんfeatureによってコミットメッセージの付け方など数多あるものの、一定の頻出パターンは見い出せたので筆を取りました. （英語勉強しないと..） 方法 github.com/rails/railsのコミットメッセージ内における各動詞の出現確率を求め、 またOSSと仕事でのコミットメッセージの趣向も変わってくる事も勘案するため、 （仕事でDeprecateとか滅多に使わんし） 同僚に聞きつつ10つあげてみた. 以下列挙 （例は実際の同僚やOSS上でのコミットメッセージです.） Add *A to *B AをBに加える
Gitのコミットメッセージの書き方 - Qiita
Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 （2014年12月17日追記） 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど！と思ったコメントをもとに少し修正・加筆してみました。 （2022年1月4日追記） 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目：変更内容の要約（タイトル、概要） 2行目 ：空行 3行目以降：変更した理由（内容、詳細） 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 （多すぎても悩むので
View Issue/Pull Request buttons for Gmail
ProductView Issue/Pull Request buttons for GmailIf you're a Gmail user who gets GitHub notifications via email, you'll notice that we've added subject-line links to issues and pull requests on notification messages. You can use these… If you’re a Gmail user who gets GitHub notifications via email, you’ll notice that we’ve added subject-line links to issues and pull requests on notification message
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ghqでリポジトリ管理とpeco連携で快適git生活 - Qiita
ギットクエスト
github/gitignore at master - GitHub
コンセプトから理解するGitコマンド
