複数の作者を持つコミットを作成する - GitHub Docs
必要な共作者情報 コミットに共作者を追加する前に、各共作者に使う適切なメールアドレスを知っておく必要があります。 共同作成者のコミットが投稿としてカウントされるようにするには、GitHub.com のアカウントに関連付けられているメールを使う必要があります。 メールアドレスを非公開にしておきたい人がいる場合、その人のプライバシーを保護するために、GitHub が提供する no-reply メールを使う必要があります。 そうしない場合、コミットメッセージで共作者のメールアドレスが公開されます。 ご自分のメールアドレスを非公開にしておきたい場合、Git の操作のために GitHub が提供するno-reply メールアドレスを使い、他の共作者に、no-reply メールアドレスをコミットのトレーラーに載せるよう依頼できます。 詳しくは、「コミットメールアドレスを設定する」を参照してください。
大きなGitリポジトリをクローンするときの工夫を図解します - DeNA Testing Blog
こんにちは、SWETでCI/CDチームの前田（ @mad_p ）です。 SWETではCI/CDチームの一員として、Jenkins運用のサポートや、CI/CD回りのノウハウ蓄積・研究をしています。 はじめに Gitリポジトリをクローンすると、ローカルフォルダにはそのリポジトリの全体がダウンロードされ .git というフォルダに格納されます。ブランチをチェックアウトすると、ブランチ内のファイルがワーキングツリーとして展開されます。この様子を図にするとこのようになります。 この .git とワーキングツリーの使うディスク容量を節約しようというのが今回のお話です。特にJenkinsにおいて、大きめのGitリポジトリをクローンしてくる場合に課題があり、いろいろ工夫してみたので、その結果を紹介します。同じCI/CDチームの加瀬による記事「大規模リポジトリで高速にgit cloneするテクニック」と内容
Commit together with co-authors
ProductCommit together with co-authorsWith faster onboarding for junior developers, increased code quality, and more thorough code review, it's easy to see why more developers than ever are writing code collaboratively. Your team's (and… With faster onboarding for junior developers, increased code quality, and more thorough code review, it’s easy to see why more developers than ever are writing co
Highlights from Git 2.23
CommunityOpen SourceHighlights from Git 2.23Take a look at some of the new features in the latest Git release. The open source Git project just released Git 2.23 with features and bug fixes from over 77 contributors, 26 of them new. Here’s our look at some of the most exciting features and changes introduced since Git 2.22. Experimental alternatives for git checkout Git 2.23 brings a new pair of e
Gitのコマンドを簡単に探せるGit Explorerの使い方 & プルリクエストを送る方法 - りんごとバナナとエンジニア
gitexplorer.com 今朝会社で話題になっていたので見てみたのですが、エンジニア1年目の頃にこのサイトがあれば...！と思うくらい良かったです。 どんなサイト？ Gitのコマンドを、よくあるシチュエーション別に簡単に探せるサイトです。 gitコマンドは新人エンジニアにとっては本当に鬼門です。commitを間違えて、戻すやり方を必死でGoogle検索して、いざコマンドを打ってみたら予想外の変更が起きてしまい、収拾がつかなくなる...というようなことは、誰でも一度は経験したのではないでしょうか。そんなときこのサイトを使うと、正しい方針をすぐに調べることができます。 使ってみよう このサイトはムダな機能がなく、とてもシンプルなデザインです。どうやって使えばいいのか大体わかりますね。 ちなみにDark Modeにもできます。こちらの方がエンジニアっぽいでしょうか。 まずやりたいことをプル
git grepでマッチしたワードを含んだ関数名を表示する/関数スコープ全体を表示する #git - My External Storage
git 2.17にすると使える(？)-Wオプション(とついでに-p)が便利すぎたのでメモ。 2018/04/11現在、Macならばbrew upgrade gitで2.1.7に更新できる。 Git 2.17 is now available https://blog.github.com/2018-04-05-git-217-released/ （？なのは https://git-scm.com/docs/git-grep/ を見ると2.15とかでも使えそうな気配がするから） TL;DR git grep -Wで検索結果にマッチしたワードを含む関数スコープを全て表示してくれる git grep -pで検索結果にマッチしたワードを含んだ関数の名前を表示してくれる git grep https://git-scm.com/docs/git-grep/ git grepサブコマンドを使うとgit
Git2.9のキレイなdiffを出すためのconfig - Qiita
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 2.9 has been released
Open SourceGit 2.9 has been releasedThe open source Git project has just released Git 2.9.0, with a variety of features and bug fixes. Here's our look at some of the most interesting new features: Faster… The open source Git project has just released Git 2.9.0, with a variety of features and bug fixes. Here’s our look at some of the most interesting new features: Faster and more flexible submodule
Gitのコミットハッシュ値は何を元にどうやって生成されているのか | メルカリエンジニアリング
こんにちは。サーバサイドエンジニアの @DQNEO です。 前回の「Gitのつくりかた」に続いてGitのコアな部分のお話です。 Gitのコミットハッシュ値とは何か Gitを使っていると必ずコミットハッシュ値というものが出てきます。9e47c22みたいなアレです。 これはある特定のコミットを指し示すIDとして使うことができます。 では質問です。 このコミットハッシュ値は「何を元に」「どうやって」計算されているでしょうか？ 「ある特定のコミット」とはそもそも何なのか この問題を考える前に、まず「コミットとは何か」を明らかにしておきましょう。 コミットというと「コミットする行為」すなわち「動作」のことを想像するかもしれません。 しかしGitの内部構造的観点から言うと、Gitが管理記録しているのはコミット行為の結果生成されたデータの方です。 この「コミットによって生成されたデータ」のことを「コミッ
gitの新人研修でtigを使うことをおすすめする理由 - Qiita
はじめに ４月まで残すところ２ヶ月と迫り、新卒などを対象とした新人研修の準備が始まっている頃かと思います。 新人研修の中でgitを教える際に、筆者はtigの活用をおすすめしています。 講師の立場からすれば、短い時間に高効率でgitの本質を伝えることができます。 研修生の立場では、tigを利用して簡単で直感的にgitリポジトリを閲覧・操作することができます。 tigを使うとどうしてそうなるのか、いくつかの理由を以下に紹介します。 セットアップが簡単ですぐ使い始められる tigは依存関係が少なくポータブルな実装でありインストールが簡単です。 会社から提供する開発サーバーであっても、社員ひとりひとりが所有するPCやMacであっても、 yumやbrewなどのパッケージマネージャから少ない手順でインストールすることができます。 一例: CentOS6.4にgit tigインストールと使い方 - Qi
空コミット便利！git commit --allow-emptyでgitを使った開発フローを改善 - fukajun - DeepValley -
何か？ git commitのオプション--allow-emptyご存知でしょうか？ これは、オプションの名前の通り空のコミットの作成を許可するオプションです。 通常変更がないとコミットが作れないようになってるので 空コミットを作るにはこのオプションを指定する必要があります。 add(もしくはrm)もしない(stageに何も載せない)で commitしたときの注意文には登場するので知ってましたが使ってませんでした。 最近、開発フローの中で使い道を思いついて使うようになったので紹介です。 その1 空Pull Request作れる プルリクって、基準になるブランチから変更されたコミットがないと作れないと思ってます。 でも、変更はないんだけどプルリクのcommentに変更の「概要」「目的」「ビジネスインパクト」「どの数値が改善するのか」など色々さきに書いておきたいこととかありますね。 考えてる内
今さら聞けないgit pushコマンド - Shoichi Matsuda's diary
id:koogawaさんのgitの記事を読みました。 これを読んでそういえばみんな知ってるのかなと思った点があるので書いておきます。 取り上げるのはgitのpush周りのお話です。 （これ以降の記事中のリモートは全てoriginとします。） このコロンは何？？ リモートブランチの削除で以下のようなコマンドを実行すると思います。 git push origin :hoge コロンが付いていますがこのコロン正体、正しく説明できますか？ 実用Git 作者: Jon Loeliger,吉藤英明(監訳),本間雅洋,渡邉健太郎,浜本階生出版社/メーカー: オライリージャパン発売日: 2010/02/19メディア: 大型本購入: 7人 クリック: 287回この商品を含むブログ (44件) を見る pushコマンドの実体 普通、ローカルブランチをリモートに反映する際のコマンドはこんな感じです。 git p
複数人での Git 開発に便利な 3 つのコマンド - Qiita
こんにちは、 rosylilly です。すっかり Advent Calendar のことを忘れていて、大急ぎで記事を書いています。ちゃんと予定は管理しておかないといけませんね…… ということでいつも使っているコマンドの中で 3 つほど紹介されていなかったものがあったので紹介しようと思います。 git grep コマンド 特定の語句が含まれているファイルを検索し、そのファイルでその語句が含まれている行数などを調べるコマンドです。 通常の grep コマンドなどを利用してもいいのですが、コマンドがわかりにくいのと、対象として指定するファイルを指定するのが面倒です。 その点 git grep だと、 git が管理しているファイルだけが検索対象になるので、手軽にリポジトリから検索することが出来ます。 また、オプションを使うことでより柔軟な検索も実現出来ます。一部を紹介しておきますので、man g
A successful Git branching model を翻訳しました
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら： http://nvie.com/posts/a-successful-git-branching-model/ （翻訳の公開と画像の利用は本人より許諾済みです） このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
GitHub初心者はForkしない方のPull Requestから入門しよう // qnyp blog
2013/08/13 GitHubの新デザインに対応するために記事内容・画像をアップデートしました。 こんにちは、ブログ記事を書くのが約2年ぶりのruedapです。 さっそくですが、Pull Request（プルリクエスト）機能を使ったことはありますか？ GitHubの代表的な機能で、「pull req」や「PR」とも略されたりして、名前はよく聞きますよね。 この記事は、Gitはいちおう入門済みで、GitHubも使い始めたけど、Pull Request機能はまだ使ったことがない、そんな人に向けた 簡単な方のPull Request の入門記事です。 もう1つのPull Requestについて Pull Request機能の解説としてよくあるのは「他の人のリポジトリを自分のGitHubアカウントにFork（コピー）してきて、変更を加えて、それを元のリポジトリに取り込んでもらうようにリクエスト
イケててヤバいGit入門 | GREE Engineering
この投稿はGREE Advent Calendar 2013 20日目の記事です。 プロデューサーの皆さん、みりっほー。進捗どうですか？私はダメです。ごめんなさい。（´・ω・｀） WG事業部の二宮です。今日はアイマス駆動開発の話をしようかと思ったのですが、急遽Gitの使い方の話に変更しました(Inspired by 堀口先生)。 アイマス駆動開発の話が気になる方は、是非一緒に飲みに行きましょうw ※この記事では、ツールにGitやGitHubを利用することを想定しております。 Gitをスマートに使いたい グリーでは、基本的にA successful Git branching model（有志の方による日本語訳）にのっとって開発しています。 Gitについて基本的な考え方の部分は堀口さんの記事で言及されているので、私は現場で具体的にどのような使い方をしているのかについて書きたいと思います。 と
空のディレクトリをgitで管理するには.gitkeepを使う（.gitignoreは使わない） - YomuKaku Memo
gitを使ってバージョン管理を行う際に、プロジェクト全体のツリー構造をそのまま管理する目的で、中身が何も無いディレクトリもgitの管理下に置きたい場合があります。 何も対応しないと、gitは空のディレクトリをバージョン管理してくれません。 中身が空のディレクトリをgitのバージョン管理下に入れるためには、当該の空ディレクトリの中に .gitkeep というファイルを作成してからgitで管理します。 実例 Railsのアプリケーションを新しく作成する場合を例に用います。 $ rails new test_application $ cd test_application $ ls -l vendor/plugins （vendor/pluginsは中身が空なので何も出力されません） 上のように、vendor/pluginsは中身が空です。 このディレクトリをgitの管理下に入れるために、次の
GitHub トレーニングチームから学ぶ Git の内部構造のノートです。 曖昧なところもあるので、間違いがあったら教えてください！ http://connpass.com/event/3808/
GitHub トレーニングチームから学ぶ Git の内部構造のノートです。 曖昧なところもあるので、間違いがあったら教えてください！ http://connpass.com/event/3808/ Graphs, Hashe, and Compression, Oh My! 登壇者：@matthewmccull Hashesについて 従来の CVCS （集中バージョン管理システム）のリビジョン番号は連番。 SVN はサーバーにデプロイした時点でリビジョン番号1と設定される。 Git は SHA1 をつかっている。40桁の16進数のフィンガープリントがついてる。これは理論上は重複しない大きさ。こうすることで単純で強固な DVCS （分散バージョン管理システム）がつくれる。 新しいファイルを追加すると、.git/objects/55/7db03de...(SHA1 finger print)
git による分散作業パターン | GREE Engineering
分散バージョン管理を華麗に扱いたい堀口です。 GREE Advent calendar 2013 の 14 日目として参加させていただきます。 お二人に続き Haskell の話をしようかと思ったのですが、急遽無難な開発の話に変更しました :o Java や C++ には OOP の概念が必要であったように、分散作業の認識が薄いまま git や Mercurial を使うことは長期的に不幸をもたらします。 とあるプロジェクトにて、その一部を副産物のミドルウェアとして抽出すべく、アプリケーションと分離したい 不具合があったので原因を探りたいが、依存関係が複雑すぎるのでコードを読む量を減らしたい テストやレビュー、提案、リファクタの運用を強化したい よそのプロジェクトに迷惑を掛けないように、そこのツールを改良して使いたい。 いままで何気なく「こんなもんだろう」と思って手間をかけていませんでした
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - so-fancy/diff-so-fancy: Good-lookin' diffs. Actually… nah… The best-lookin' diffs. :tada:
