Gitのオブジェクトの中身
はじめに Gitのインデックスの中身、Gitのブランチの実装に続く、Gitの中身を見てみようシリーズです。Gitが管理するオブジェクトの種類や中身について見てみます。基本的にはPro Gitの10. Gitの内側をまとめなおしたものです。 オブジェクトの種類 Gitは、内部でファイルやコミットを「オブジェクト」として.git/objects以下に保存しています。オブジェクトには以下の4種類があります。 blobオブジェクト： ファイルを圧縮したもの。ファイルシステムの「ファイル」に対応 treeオブジェクト： Blobオブジェクトや別のTreeオブジェクトを管理する。ファイルシステムの「ディレクトリ」に対応 コミットオブジェクト： Treeオブジェクトを包んだもの。コミットのスナップショットに対応するTreeオブジェクトに、親コミット、コミットメッセージなどを付加する タグオブジェクト：
【GitHub】少人数のチームで開発するときのGitHubのブランチ運用Flow - Qiita
概要 少人数のチームでGitHubを用いてプロダクト開発するときのブランチ運用フローについて． GitHub Flowを参考にシンプルさと運用のしやすさを重視している． チームの全員が6つのルールを守るだけで，masterが綺麗な状態で保たれる． 全体像 6つのシンプルなルール 1. master は本番環境にデプロイされているバージョン 2. develop はテスト環境にデプロイされているバージョン 3. feature ブランチ（作業ブランチ）は develop から分岐する 4. feature ブランチは頻繁に push する 5. pull-request（PR）で develop にマージする 6. マージされた feature ブランチは削除する 実際の作業例 1. develop からある機能を実装する作業ブランチを作る
Git を少しでも高速、安全に使う方法を紹介 - アジャイルSEの憂鬱
はてブを眺めてたら、なんか Git の記事がバズってたので、便乗して Git の話を書いてみた。 Oh, shit, git! http://ohshitgit.com/ 「Oh shit, git!」を簡単に和訳してみた。(追記あり) - Qiita https://qiita.com/KaminoHiroki/items/391fb421e94e82c00128 基礎知識 git-reset は危ない git reset --hard は作業ディレクトリにコミットしていない変更があった場合、全てを吹き飛ばしてしまう可能性があります。 使う前に必ず git status を実行して、作業ディレクトリの状態を確認をした方が良いです。 git-checkout は遅い checkout コマンドは作業ディレクトリの状態を変更します。このとき ファイルアクセスが発生するため遅い です。 git
Git - Book
The entire Pro Git book, written by Scott Chacon and Ben Straub and published by Apress, is available here. All content is licensed under the Creative Commons Attribution Non Commercial Share Alike 3.0 license. Print versions of the book are available on Amazon.com. The version found here has been updated with corrections and additions from hundreds of contributors. If you see an error or have a s
コミットメッセージの書き方
コミットメッセージにはどのような情報を残すべきだろうか？はじめにこの記事ではGitのコミットメッセージの重要性と良いコミットメッセージの書き方を説明します。いままで良いコミットメッセージについて考えてこなかったかたも一度立ち止まって考えてみてくれると嬉しいです。 対象読者GitやGitHubを業務で使っている人「良いコミットメッセージ」をあまり意識しない人目次Gitを使ったソフトウェア開発で、なぜコミットメッセージが重要なのか？コミットメッセージの書き方の1例を紹介まとめGitを使ったソフトウェア開発で、なぜコミットメッセージが重要なのか？ソフトウェア開発において、良いコードとはどんなコードでしょうか？ 私は「 他人が読みやすく、理解しやすいコード」だと考えています。ソフトウェアにバグは必ず出ます。そのバグを修正する時間を最短にできるような、読みやすい、理解しやすいコードが良いコードだと思
git のチカラで未知の言語でもオムニ補完 - Qiita
デモ オムニ補完とは？ オムニ補完は vim 界隈でわりとよく耳にする言葉ですが、IDE よろしくメソッド名などをいい感じに補完する機能です。 Emacs でも perl の変数名とかメソッド名をいい感じに補完してくれるperl-completion.el とか、 C/C++ の IDE モドキ CEDET などがあります。 auto-complete.el に最初から入っている CSS の補完も、プロパティ名によって補完候補を変えてくれたりかなりオシャレです。 なにをやったの？ オムニ補完は便利なのですが、エディタがその言語のことを良く知っているか、あるいは言語処理系側がいい感じに補完候補を探してエディタに報告してくれる機能を持っていないと基本的には実装できません。なので、言語ごとに別々のプラグインを入れるのが普通で、設定のほうはわりと面倒です。 そこで今回は git の力を借りて、言語
なぜあなたのPull Requestは読まれないのか - Qiita
Pull Requestを出してレビューしてもらってから反映。 どこにでもあるありふれた開発フローに付きまとう、どこにでもあるありふれた問題。 「Pull Requestがレビューされない」 もちろん開発フローにレビューが含まれている以上、レビューをしないメンバーにも非がないとは言えませんが、多くの場合はレビューされないPRには問題があるものです。 デカい 兎にも角にもデカいPRは読むのがつらいです。 もちろん要件が明記されていないなど、他にもPRが読みにくくなる原因はたくさんありますが、一番はこれです。 極端な話、1行変更のPRは他に何も書かれていなくても実装内容を察することができますが、10ファイル100行の差分と箇条書き20点の要件が書かれたPRは内容を把握するだけで一苦労です。 しかし、このこと自体は数カ月でもコードを書いていれば自然と勘づくもの。 問題はなぜPRが大きくなってしま
gitレポジトリで一番活発に編集されているファイル - Qiita
git ls-files -z | \ parallel -0 -j32 -I. -- \ echo -n . \\\ \; \ git log --format=oneline . \| \ wc -l | \ sort -k2 -nr | \ head これでランキングが出せる。ただし体感ではコミット数のO(n2)で遅くなっていくぽく感じるので、歴史のあるレポジトリほど遅くなっていくので要注意ではある。 Rubyの場合だとこんなかんじ zsh % git ls-files -z | parallel -0 -j32 --line-buffer -I. -- echo -n . \\\ \; git log --format=oneline . \| wc -l | sort -k2 -nr | head -n 30 version.h 5295 io.c 1519 configure.
Dangerで始めるPull Requestチェック自動化 - コネヒト開発者ブログ
こんにちはー！こねひとちほーのえんじにあのフレンズ@Utmrerだよー！ 今回はPull Requestを自動でチェックしてくれるDangerについて紹介します。 Pull Requestでのコミュニケーション Pull Requestのレビューは不具合の指摘やコーディングスタイルの統一、より良いコードのための提案などのために行われます。 ですが、次のようなコミュニケーションをしたことはありませんか…？ タイトルにIssue Idを含めてもらえますか？ WIPみたいなんですがレビューして大丈夫ですか？ Base branchが間違ってます、変更してください。 変更履歴のdocsを更新してください。 このような「実装とは関係のない指摘」はできるだけ減らし、自動化したいものです。それを実現するのがDangerです。 Dangerとは DangerのGitHubには次のように書かれています。 F
最近のgitを使った開発フローについて - その手の平は尻もつかめるさ
最近のgitを使ったWebアプリケーションのプロジェクトの開発フロー (主にブランチ運用) について記すものです． なお前提としてGitHub Enterpriseを利用しています． git-flow 大上段に構えたもののあまり特殊なことはしていなくて，基本的にgit-flowをそのまま踏襲しています． git-flowについてはしっかりした解説記事がインターネット上に数多く存在しますからそれらを参考にしていただければと思いますが，ざっくり説明すると masterブランチ，developブランチ，releaseブランチ，featureブランチ及びhotfixブランチがある masterブランチは常にリリース可能な状態になっている (すなわち現在本番で稼働しているアプリケーションのコードと等しい) developブランチは開発中の状態で，ステージング環境等に上がっている releaseブラン
わたしのGit/GitHubの使い方 | TRIAL DANCE
この記事は feedforce advent calendar 2016 18日目の記事です。 昨日は tsub の ぼくの情報収集方法 でした！この記事を読んで私も早速 のぼりーさんのクラウドインフラPodcast を購読しました！ こんにちは、未だに洗濯機を買ってないことを社内の人達に心配されている mizukmb です。私もコインランドリー生活には限界を感じているので、そろそろ買おうと思います。 さて、今回は私流の Git/GitHub 活用術についてお話しようと思います。 HHKB にテプラを貼った話はまた今度にしようと思います。 自己紹介 @mizukmb 2016年 新卒入社 Webエンジニア ボドゲ部 音ゲー部（自称） 1. Git: masterブランチは削除する Git, GitHub を使い始めてよくあるのが 誤って master ブランチで作業して push してしま
これまで知らなかったGit機能を調べたまとめ - Qiita
変更のdiffを見ながらコミットメッセージを書く 教えてもらってから活用してる。見ながら書いたほうが具体的に書けるような気がする。 $ git commit -v 変更のdiffを見ながらコミットメッセージを編集できます # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch commit-v # You are currently bisecting, started from branch 'test-git-bisect'. # # Changes to be committed: #>modified: fruits.txt # # -------
Gitを実践的に使うために参考にすべき記事20選
チームで開発を行うときにGitのスキルは必要不可欠なものとなってきています。以前、Git初心者向けにスライドをまとめたものを紹介しましたが、今回はGit（GitHub）をさらに活用するために参考にしたい記事を紹介します。 この記事は以下のような方におすすめです！ ・ブランチをどのように運用すれば良いのかわからない。 ・コミットメッセージの書き方にいつも悩んでしまう。 ・issueやPull Requestをもっとうまく活用したい。 ・Git�やGitHubに関する便利なテクニックを知りたい。 ・間違ってコミットしてしまったけど対処法がわからない。 今回は、運用編、コミットメッセージ編、issue編、Pull Request編、テクニック編、問題解決編と５つの内容で分類してみました。実践的な読み応えのある記事ばかりなので、ぜひ参考にしてみてください。 運用編 中の人に聞いたGitHub fl
gitにおけるコミットログ/メッセージ例文集100
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
Gitのデータモデル
近藤です。こんにちは。Gitは様々な利用の仕方ができますが、その基盤となるモデルは8個だけの簡単なモデルです。これらのモデルを理解していない状態でGitを利用すると、あたかもリポジトリが壊れたように見えてしまいます。Gitは難しいと言われますが、そういう感想を持つ人はGitのモデルを理解していない事が多いようです。 今回はGitを構成する中心モデルと、基本的なコマンドを実行した時のオブジェクト関係を解説します。 基本概念 Gitの基本概念は大きく2つにわかれます。 GitObject Reference GitObjectはGitで管理するオブジェクトです。CommitなどがGitObjectです。Gitリポジトリである.gitを開くとobjects配下にあるファイルがGitObjectです。GitObjectはそのコンテンツをハッシュ化した文字列を元に、先頭2文字で配置フォルダ、残りの文
人間らしいGitのエイリアス | POSTD
断固としてコンピュータ言語を拒絶する 私の知っている最も一般的な .gitconfig は、ユーザ名の設定だけが記されたものです。そして、その次に一般的なものはこれです。 [alias] ci = commit cia = commit -a cam = commit --amend cama = commit --amend -a cl = clean cldf = clean -df res = reset resa = reset HEAD ... # 82 more 4-character aliases このコンフィグは、要するにあなたの頭の中のスペースをキーストロークに置き換えます。短縮コマンドのエイリアスを覚えれば、タイピング数の節約が可能です。しかし私はこれが好きではありません。私はタイプミスをしますし、睡眠不足なこともたまにあるので、このエイリアスではやりづらくなってしま
Git のコンフリクトを解決する 14 のヒントとツール | Atlassian Japan 公式ブログ | アトラシアン株式会社
Git はコードのマージを非常に得意としています。マージとはローカルで高速、そして柔軟に行えるものです。当然のことですが、異なるブランチから誰かがコンテンツをマージするたびにコンフリクトが発生します。コンフリクトを解決するには、主な変更点を把握して見抜かなければなりません。コンフリクトの解決は、時には多くの作業が必要になります。 開発者にはそれぞれ好みのコンフリクト解決方法があります。そのため同僚ライターのダン・スティーブンが以前、Questions for Confluence を使用して社内の人に質問していました。 返ってきた回答と洞察はアトラシアン社員だけではなく、もっと多くの人に役立つものでした。そこで私たちが Git コンフリクトを解決するさまざまな方法を以下に詳しく注釈付きで紹介します。皆さまの毎日のコーディング作業に役立つアイデアや方法がここで得られることを願います。 セット
SVNを捨ててGitを使うべき5つの理由 - Qiita
まえがき 私はGit好きの人間です。 もっと言えば、Gitを愛している（Git Lover）と言ってもいいくらいです。 そんな私がなぜこんなタイトルの記事をいまさら書こうと思ったかというと、 いまだにGitの便利さを知らず、Subversionを強い理由もなく使い続ける開発者が多いからです。 そんなわけで 「会社にGit/GitHubを導入するための説得する」 という目的でこの記事を書こうと思います。 Gitの良さってなんだろう？ 実は私もこれまで強く意識して考えたことはありませんでした。 Gitを使い出したら、 それがあるのが当たり前でGitなしの開発など考えられなくなっていたからです。 そういう意味では、Gitって 中世における自動車 に近いものがあるのかもしれません。 その時代、移動手段といえば馬が普通であり、 自動車などが普及するとは誰も考えなかったわけです（たぶん）。 それが今で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
あるgit commitがどのpull requestでmergeされているかをAPIでシュッと取ってくる方法 - その手の平は尻もつかめるさ
GitHub English Challenge Cheat Sheet - Qiita
