GitHub - evilmartians/lefthook: Fast and powerful Git hooks manager for any type of projects.You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
direnvを使って複数のgitコミッタ名を切り替える - MANA-DOT
例えば会社のPCでこっそり個人的なリポジトリで作業してgithubにpushする場合、 うっかり会社用のgitコミッタ名(本名@会社名.co.jp みたいなアドレスとか)で commit/pushしてしまい、紐付けるつもりのなかったネットの人格と本名/会社名が紐付いてしまう というのは皆が恐れるところであると思います。 そこで、direnv を利用するといい感じに切り替えられることができたので、共有いたします。 direnv zimbatm/direnv あるディレクトリに .envrc というファイルを置いておくと、そのディレクトリ以下に cd した時に .envrc の内容の環境変数が読み込まれるという代物です。 例えば、 - home ├ .envrc // export SOME_ENV=hogehoge ├ c └ a ├ .envrc // export SOME_ENV=fu
Gitのtagとpull requestのマージ履歴からChangelogを自動生成する `ghch` | おそらくはそれさえも平凡な日々
https://github.com/Songmu/ghch mackerel-agent のリリースフローでは、前回のリリース以降の、pull requestのマージ履歴を拾って、そこからChangelogを自動生成するということをおこなっている。 これは、1年半前くらいにPerlで書いていたのだが、この度汎用的にしてGoで書きなおした。それが ghch。前回打ったsemverっぽいgit tag以降のマージ履歴を抽出してくれる。例えば、こういう風にmackdownで出力がされる。 % ghch --format=markdown --next-version=v0.30.3 ## [v0.30.3](https://github.com/mackerelio/mackerel-agent/releases/tag/v0.30.3) (2016-04-27) * retry retire
最低限押さえておきたいGitの超基本的な作業フロー、5つのコマンドまとめ
本連載「こっそり始めるGit／GitHub超入門」では、バージョン管理システム「Git」とGitのホスティングサービスの一つ「GitHub」を使うために必要な知識を基礎から解説していきます。具体的な操作を交えながら解説していきますので、本連載を最後まで読み終えるころには、GitやGitHubの基本的な操作が身に付いた状態になっていると思います。 連載第2回目の本稿のテーマは「Gitの基本的な作業フローを学ぶ」です。 前回の「初心者でもWindowsやmacOSでできる、Gitのインストールと基本的な使い方」でも「Gitの基本的な作業フロー」を扱いましたが、かなり急ぎ足な解説となってしまいました。今回は、作業フローの各要素について、前回よりも詳しく解説していきます。 「Gitのインストール」や「初期設定」については、前回の記事で解説したので、そちらを参考にしてください。また「バージョン管理シ
雑にgit cloneして管理していたリポジトリ群をghq管理下に移行してスッキリさせる - 平常運転
このエントリは はてなデベロッパーアドベントカレンダーの21日目のエントリです。 developer.hatenastaff.com id:motemen さん作のリポジトリ管理ツールであるところの ghq を最近ようやく使い始めたところ大変便利だったのですが、いかんせん手元の~/work/や~/hobby/にはすでにgit cloneしたリポジトリが山ほど転がっています。今回、それをghq管理下のディレクトリにさっと移してghqライフをスタートさせた話をします。 ghq ghq そのものについての説明は作者のid:motemenさんのエントリが詳しいので、そちらをご参照ください。 motemen.hatenablog.com 代表的な使い方は↓こういう感じで、まぁだいたいどういうことかわかっていただけるのではないかと思います。 [asato@praline01 ~]$ ghq get g
レビューしやすいPRの作り方 - 大きいPRを複数に分割する - - Qiita
こんにちは、freee でエンジニアをしている @nasa4w です。 この記事は freee Engineers Advent Calendar の10日目です。 今回は大きな機能を複数のPRに分割する話をします。 freeeでも絶賛模索中の取り組みなので現在進行形の話ですm(_ _)m まとめ - 今回作ったブランチとPR - 長くなってしまったので結論をさきに置いておきます。PRを複数に分割する場合のゴールはこんな感じ。 Why?（なぜこうしたか） こうすることで、常に work ブランチを使って動作確認ができる レビューする PR を２つに分割できる view の PR と logic の PR レビュー指摘の反映は、topic_view, topic_logic ブランチに commit すればOK work ブランチにはこの2つのブランチを merge しなおすだけでOK PR
GitHubでFork/cloneしたリポジトリに追従する - memo.xight.org
Summary GitHubでFork/cloneしたリポジトリに追従する備忘録 Fork元のリポジトリを指定 $ git remote add upstream https://github.com/caskroom/homebrew-cask.git Fork元のリポジトリを追従してoriginにpush $ git checkout master $ git pull upstream master $ git push origin master $ git checkout my_branch $ git rebase master $ git push origin my_branch -f Reference GitHubでFork/cloneしたリポジトリを本家リポジトリに追従する - Qiita http://qiita.com/xtetsuji/items/555a1e
GitFlow considered harmful - End of Line Blog
Posted on 2015-05-03 This post is part of a series of articles on working with the Git source control system. GitFlow considered harmful Follow-up to 'GitFlow considered harmful' OneFlow – a Git branching model and workflow Implementing OneFlow on GitHub, BitBucket and GitLab GitFlow is probably the most popular Git branching model in use today. It seems to be everywhere. It certainly _is_ everywh
開発フロー研修 @ Wantedly - Qiita
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、
master への push を禁止するローカル git hook の正しい書き方 - 永遠に未完成
GitHub などで Pull Request ベースで開発をしていると、master には間違っても push したくないわけです。 GitHub 側には残念ながら master への push を禁止するような設定はできないので、仕方ないのでクライアント側の Hook で対応しようってことになり、この方法についてググるとこことかこことか、いくつか方法を紹介しているページが出てくるんですが、どれもやり方が間違っている*1ので、正しい方法を紹介。 何がまずいのか 上記に挙げた方法では、細かい部分は違ってたりするけど、git symbolic-ref HEAD を使って現在ブランチを見て、master だったら push を禁止する、という方法を取っている。 しかし、push はカレントブランチから行われるとは限らない。dev ブランチにいるときに git push origin maste
Github上にyumリポジトリを立てる - Qiita
はじめに Redhat/CentOS/Fedoraなどで使われているRPMを管理するコマンドyumはとても便利です。 yumリポジトリは自分で立てることができて、自作のRPMを公開したり、公式リポジトリに含まれないRPMを利用したり出来ます。 今回はGithub上にyumリポジトリを立ててみます。 yumリポジトリの仕組み yumリポジトリはftpかhttpでアクセスできる環境であれば、特に他に必要な条件はありません。 単純にはApacheを立ててRPM類を公開するだけでyumリポジトリになります。 ただし、単純にRPMを置くだけではなく、どのようなRPMがあるかなどのメタ情報を含むXMLファイルなどを所定の場所に置いておく必要があります。 Github Pagesとは Github PagesはGithubの提供する静的なHTMLコンテンツの公開サービスです。(無料) Github上にg
git-browse-remote で現在のブランチに対応するプルリクエストを一発で開く - 詩と創作・思索のひろば
お、GitHub /pull/ブランチ名てpull-req開ける "Open the GitHub web interface to create the new pull request · Issue #688 · gi…" https://t.co/ESkRKfL6zA— azu (@azu_re) January 28, 2015 マジで……というわけで、現在のブランチや作業ディレクトリなどをもとに いいかんじに GitHub （など）をブラウザで開いてくれる git-browse-remote にこれに対応する機能を追加したバージョン 0.2.0 をリリースしました。 インストール／アップグレード RubyGems.org にアップロードされているので、 gem install git-browse-remote でインストールできます。 使い方 git browse-remo
pplog開発のコードレビューから学ぶpull requestによる自律的行動とコミュニケーション - ppworks.jp
pplogの過去のポエムを複数単語で絞込できるようになりました。 pplogは、自身と向き合い想いを言語化するためのサイトだったりします。（色んな使い方があります） 最新のポエムだけが他人に見えますが、 自分の 過去のポエムを見る機能があります。 この過去ポエムは検索機能が付いているのですが、先日まで複数単語で絞り込むことが出来ませんでした。 pull requestが来た id: shootaさんからpull requestを頂きました。 勝手にやった！まさにこれだ！と思いました。 よし、コードレビューをしよう！ 命名に突っ込んだ これを見て思うところがありました。 search_word_arrays = params[:keyword].gsub(/ /," ").split() 私は言った for文にナニカを感じた し、Cぽい！ search_word_arrays = param
Linux ユーザーのための Git と Github 入門
原文はこちらです。 ※この記事は「チュートリアル」からの転載です。 Git は、Subversion、CVS、Mercurial などのバージョン管理システムから移行するのに最適な分散管理システムです。複数の開発者が同時に 1 つのプロジェクトに貢献していて修正量が膨大な時に有効な道具です。無料の Github を使って git 入門をしましょう。 git は、他のバージョン管理システムとは考え方が異なります。昔の RCS はファイルの変更履歴を取得しており、その内容は、コンフィギュレーション ファイルを見るとわかるようになっていました。Git は、もっとファイル システムのスナップショットに似た発想でできています。すべてのコミットや状態は、完全なスナップショットの形で格納され、従来の差分ファイルは存在しません。Git はスナップショット間の変更のみを記録し、変更がないファイルはリンクする
コマンドラインからgithubを検索してgit cloneをする with ghs, peco and ghq - Qiita
コマンドラインからgithubを検索してgit cloneをする with ghs, peco and ghqGoGitGitHubPecoGhq ghqとpecoを組み合わせてGithubリポジトリを簡単に取得するために、Githubリポジトリをコマンドラインから検索するghsコマンドを作りました。 sonatard/ghs トライアルページ ghs - CodePicnic 更新履歴 2017/04/15 0.0.10リリース 依存ライブラリのgo-githubの下位互換性がなくなったため、ビルドできなくなっていたバグを修正しました 2016/05/14 0.0.9リリース -k, --forkオプションを追加しました 検索結果にforkしたリポジトリを含める(true)、含めない(false),forkしたリポジトリだけ表示(only)を指定することができます。 検索結果が0件だった
サイバーエージェントのGitHub活用 ～ 導入から運用体制、開発フロー、勉強会による現場への普及活動まで
また、Organization[1]の数も360を超え[2]、リポジトリ数もOrganizationのものだけでも2000近く作られています[3]。 新規のプロジェクトは基本的にGitを利用しており、既存プロジェクトもほとんどがSubversion（以下SVN）などからGitに移行しました。 本記事では、Ameba事業本部がどのようにGitを組織内に普及させていったか、その運用体制、現場でどのように利用されているのかをご紹介します。 [1] 複数アカウントをまとめるグループ機能です。リポジトリは個人単位だけでなく、Organization単位で作ることもできます。 [2] プロジェクト単位で1つのOrganizationを用意しています。 [3] 個人アカウントで作成したり、他からforkしたリポジトリは除いた数です。 GitHub Enterprise導入への道のり GHE導入以前の標準
GitHubでForkしたリポジトリで元のリポジトリの変化を追う
B! 42 0 0 0 vim-markdownをアップデート で vim-markdown をアップデートした、という話をしましたが、 このレポジトリはもともとForkしたもので、元のレポジトリの変化を追いつつ アップデートしたので(というか今回は元のレポジトリのアップデートをマージしただけ) その流れについてまとめておきます。 レポジトリ設定 Fork元のレポジトリにつなげる 元のレポジトリのアップデートをmasterにpull modをmaster(=Fork元の最新版)にrebase mergetoolでマージ originにpush 操作の取り消し等 ファイルの変更の取り消し commitの取り消し commitのやり直し rebaseを取り消す pushの取り消し レポジトリ設定 plasticboy/vim-markdown というレポジトリをForkして rcmdnk/vi
Qiita で人気の Git & GitHub ノウハウ #githubkaigi - by shigemk2
@yuku_t Qiitaに載ってた GitHub Cheet Sheet 入門Git コンフリクト発生時の問題 もとの状態がよくわからなくなるとき merge.conflictstyle もとの祖先を表示さす git stash save pop indexしたものがstashされる --all --inclide-untracked --keep-index(index treeをそのまま残す) 全く新しいworking directoryがほしい git-new-workdir シンボリックリンクを貼ってくれるところがgit cloneと違うところ。 編集もstashも同期される。 diff-highlight git-core/contrib git diff & apply $ git diff -w | git apply --cached w 空白文字 cached inde
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gitでやらかした時に使える19個の奥義 - Qiita
入門書には載ってない Git & GitHub Tips
