Help us understand the problem. What is going on with this article?
brewでインストールされたパス/usr/local/binよりも、もとのgitがあるパス/usr/binのほうが、優先順位が高くなっているのが原因。 zsh + oh-my-zshを利用しているのだが、.zshrcを書き換えることで優先順位を変えた。
Git 2.9 has been released https://github.com/blog/2188-git-2-9-has-been-released 昨日キレイなDIFFが出せるgit2.9がリリースされました。 homebrewで brew upgrade git な感じでアップグレードすれば2.9は入るのですが、 このキレイなDIFFは標準では有効になってないので、記事にあるとおりに設定を行いましょう。 だいたい以下のような感じのコマンドうてばいいと思います。 下準備:diff-highlightにPATHを通す まぁ通さずに直接読んでもいいんですが、通しておきましょう。 homebrewでいれるとdiff-highlightさんは↓あたりにいるのでPATHを通しておきましょう。 export PATH=$PATH:/usr/local/Cellar/git/2.9.0/s
Git Extras Little git extras. Screencasts Just getting started? Check out these screencasts: introduction (archive.org link) -- covers git-ignore, git-setup, git-changelog, git-release, git-effort and more Installation See the Installation page. Commands Go to the Commands page for basic usage and examples. GIT utilities -- repo summary, repl, changelog population, author commit percentages and mo
前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある git push --force でなく、最後に fetch したタイミング以降に他人が push していたら失敗する git push --force-with-lease を使う方が良い。 --force considered harmful; understanding git's --force-with-lease - Atlassian Developers Quipper では GitHub flow のような開発フローを採用している。 各開発者が feature branch を作成し、master / develop branch へ pull request を作る流れだ。 他人と修正箇所が重なってコンフリクトした際には rebase が必要で、 rebase 後の内容を push する際には
はじめに こんにちは、クレイの亀井です。ここ最近一気に気温が上がりましたね。顔に重点的に汗をかくタイプの私には憂鬱な季節がやってまいりました さて、今月正式リリースしました(!) DocBase プロジェクトではクレイ外部のデザイナーの方と一緒に開発しています。SourceTree で Git を使っている方で、軽いデザイン修正などは弊社の Rails プロジェクトに直接手を加えてプルリクエストを送ってくれます。 こちらのデザイナーさんに「プルリクエストを送る際は、作業ブランチで git pull --rebase origin master してから送ってもらえますか?」とお願いすると「pull はわかるんですけど、この --rebase ってなんですか?これつけると何が変わるんですか?」と質問がきたのです。 作業ブランチで git pull --rebase origin master
git fetch の裏側でどんな通信が行われてリモートリポジトリの内容が取得できるのか調べたのでまとめる。もともとは git の HTTP や SSH といったプロトコルでどのように実現されているか、というところに興味があった。Git v2.7.1 を基にしている。 事前準備 pack プロトコル pkt-line フォーマット Reference discovery Packfile negotiation Packfile の送受信 packfile への圧縮・packfile からの展開 各種トランスポートの実装 file トランスポート ssh トランスポート git トランスポート http(s) トランスポート まとめ 参考資料 事前準備 手を動かしてプロトコルを理解できるよう、gist の小さなリポジトリ を使う。適当なディレクトリ下に bare リポジトリとして clon
2015.3.14 追記 "鍵でやるべき"とブックマークコメントをもらいましたが、その通りです。SSH認証キーが設定できる環境なら鍵認証でやるべきです。鍵ペアを作成後に公開鍵をGithubに登録し、~/.ssh/configで以下のように設定しましょう。 Host github.com User git Hostname github.com IdentityFile ~/.ssh/{秘密鍵}SSH認証キーが設定できないような環境では、本記事を参考にしてください。 追記終わり Githubへpushするたびにユーザ名(Emailアドレス)/パスワードを聞かれて入力するのは面倒なので、省略したい。 MacとLinuxで確認しました。 1. ~/.netrc にユーザ名/パスワードを書く こんな感じで自分の$HOME直下に.netrcファイルを作成する。 machine github.com
Update 2018-07. The branching model described here is called trunk based development. I and other people who I collaborated with did not know about the articles that used this name. Nowadays there are excellent web resources about the subject, like trunkbaseddevelopment.com. They have a lot of material about this and other key subjects revolving around the area of efficient software development. W
Gitのコミット時に付けられるhashって衝突するんじゃね、と思って確認したことをメモしておく。 まず、ごくごく低確率ではあるけど衝突することはあるようだ。 How would git handle a SHA-1 collision on a blob? So what happens is that if we ever see a collision, the "earlier" object in any particular repository will always end up overriding. もし衝突が起きたら、そのレポジトリにおける過去のコミットは上書きされるよ。 あまりよろしくない挙動になっているようだ。 とはいえ衝突が起こる確率は天文学的な数字だし、偶然それが起こったとしてもちょっと過去のログが欠けるだけだから別にいいよね、ということになっている。 過去にお
読者の皆さまが普段使っているバージョン管理システムは何でしょうか?多くの会社さんと同様、KLabでは大多数のプロジェクトでGitを利用しています。 Gitでは全てのcommitについて名前とメールアドレスが記録されます。ところで、Git管理しているリポジトリ上で会社のメールアドレスと個人のメールアドレスが混ざることがありませんか? KLab社内では大半のプロジェクトでGitHub Enterpriseを利用している一方、一部プロジェクトや公開用のリポジトリについてはgithub.comも併用しており、それぞれで登録メールアドレスが異なっていたりするため、間違いが起こりやすい状況になっています。 本稿では、そんなときでもリポジトリごとに適切なメールアドレスでcommitできるような~/.gitconfigの書き方を紹介します。 具体的な手順 今回紹介する手順は、リポジトリをgit clone
最近、開発環境のテンプレート構築をしているのですが、「git commit するまえに考えるべき10のこと | Act as Professional – hiroki.jp by HIROCASTER」みたいに、ソースコードのバージョン管理を実際に始めるときに理解しておかないといけないことは、結構あるはずです。 それで、ソースコードのバージョン管理については、git commitするときに記録するコメントについて、いろいろと考えることもあります。Git Styleは「git/Documentation/SubmittingPatches at master · gitster/git · GitHub」にありますから、こういうのも参考になります。 英語で記述 一文の場合、文末にピリオドを付けない 主語は省く 時制は現在形 文頭の英単語は大文字 他にもないかなぁ、と探してみたら「Chang
オープンソースのバージョンコントロールシステム Apache Subversion(SVN)1.8 が6月18日リリースされた。この最新版は、およそ20か月前にリリースされた SVN 1.7 の後継バージョンであり、開発者に対して多くの新機能を提供するものだ。 SVN 1.8 はまた、「なぜ Git ではなく、SVN を使うのか?」という疑問への回答を与えてくれるリリースとなっている。 WC-NG 前バージョン SVN 1.7 の最大の目玉は、WC-NG(working copy next generation)の導入だった。WC-NG は、SVN 1.8 および今後のリリースで提供される新機能のベースとなっている。Apache Software Foundation の元議長であり、Apache Subversion プロジェクトの VP である Greg Stein 氏は、Int
タイトルは大げさです。割と当たり前の話です。 ハードディスクの整理中にRailscastsのメモが出てきまして 懐かしいなぁ、 Ryan Bates(@rbates)さん 元気かなぁと Twitterを覗いてみたところ How to write a Git commit message: http://t.co/D31dVh1lks— Ryan Bates (@rbates) 2015, 7月 28 なかなか興味深い記事をtweetされていました。 Git の commit messageに 規律をもたらそうぜ、ってのは どうやら日本人だけじゃないようです。 元記事( How to Write a Git Commit Message ) Introduction 著者の過去と現在のcommit logを対比しています。 一貫して、この緑と赤の対比が見やすいので、記事も読みやすいです。 ま
Gitの本格導入の前に、マージのコンフリクト解決に使用するマージツールについて調べてみたのでメモ。 コンフリクトした際に、テキストエディタで直接修正するのは非常に面倒。そこでmergetoolを使うとマージ作業をかなり楽にできます。 ただしデフォルトのmergetoolだと使いづらい。Googleで色々調べてみるとp4mergeがオススメそうなので試してみました。 参考サイト http://d.hatena.ne.jp/clover-leaf/20110126/1296058882 http://d.hatena.ne.jp/nakamura001/20110321/1300699836 インストール方法 こちらよりThe Perforce Visual Client (P4V)をダウンロードします。OSに合わせてダウンロードする。 ダウンロードしたファイルをインストール。p4mergeの
tl;dr Cron for GitHubで定期的にCIサーバーのフックを起動する CI側では、特定のブランチの場合のみ起動するスクリプトを用意する 自分のやりたい操作をして、git_httpsable-push, pull_request_create でPull Requestを送る 定期的にDependency UpdateのPull Requestを送る フックの起動 Cron for GitHubのschedulerはこのように設定した。 bundle exec cron-for-github clear --slug=metarubygems/carrion_crow --namespace=cron_for_tachikoma --verbose && bundle exec cron-for-github ping --slug=metarubygems/carrion_c
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く