Gitのデータモデル
近藤です。こんにちは。Gitは様々な利用の仕方ができますが、その基盤となるモデルは8個だけの簡単なモデルです。これらのモデルを理解していない状態でGitを利用すると、あたかもリポジトリが壊れたように見えてしまいます。Gitは難しいと言われますが、そういう感想を持つ人はGitのモデルを理解していない事が多いようです。 今回はGitを構成する中心モデルと、基本的なコマンドを実行した時のオブジェクト関係を解説します。 基本概念 Gitの基本概念は大きく2つにわかれます。 GitObject Reference GitObjectはGitで管理するオブジェクトです。CommitなどがGitObjectです。Gitリポジトリである.gitを開くとobjects配下にあるファイルがGitObjectです。GitObjectはそのコンテンツをハッシュ化した文字列を元に、先頭2文字で配置フォルダ、残りの文
Gitの最初のコミットは空コミットにしよう
# リポジトリ作成 git init # 最初のコミット git commit --allow-empty -m "first commit" 解説 Gitの最初のコミットを修正したいとなると以下のようなことをする必要がある git commit --amend で最初のコミットを修正する(コメントで教えてもらいました!) この方法なら楽にできますね git rebase -i --rootでrebaseする git update-ref -dで参照を更新する 参照 First commit が git rebase -i できない問題 → git rebase -i --root でできる 初回のコミットを取り消したいときにはgit update-refを使う 上記のよう面倒くさいので first commit は空コミットにしておくと良い。 こうすることで2回目以降が本質的に意味のある
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リポジトリをメンテナンスして軽量化する - Qiita
この記事はGit Advent Calendar 2015の8日目の記事です。 Gitリポジトリのメンテ？ Gitリポジトリにあるファイルは .git がバージョン管理をしています。 今回はその .git をメンテナンスする話です。 はじめに リポジトリに容量の大きいファイルをコミットしてしまった git clone がやたらと時間がかかる（知らない間に容量の大きいファイルがコミットされている可能性がある） 複数あるリポジトリを統合したい こんな悩みを持ったことはないでしょうか。大型のプロジェクトでないと発生しないと思うので、個人プロジェクトではなかなか遭遇することはないでしょう。 今回は上記を解消するための リポジトリメンテナンス方法 をご紹介します。 !! 注意 !! Gitリポジトリのメンテナンスは破壊的なため、Gitのコマンドを理解している方のみ行ってください。 この記事を読んで実
Git/GitHub 社内勉強会コンテンツ (最小限の手順まとめ) Git-it SourceTree - Qiita
概要 Git/GitHub 社内勉強会コンテンツ (最小限の手順まとめ)。 本記事は、Git-it で学習を進める際の、副資料。 はじめに Git-it という、Git/GitHub学習のための素晴らしいアプリがある。 Git-it (Git/Github 勉強アプリ) https://github.com/jlord/git-it-electron/releases/tag/3.1.0 それを使った、社内勉強会用コンテンツ。 しかしながら、Git-it では、プルリク - レビュー - マージ の開発の流れが理解しづらいので、その部分を、あとから追加で実施する。 ブランチの状態を可視化する目的もあり、Git管理アプリ SourceTree を併用しながら学習を進める。 SourceTree https://ja.atlassian.com/software/sourcetree GitH
人間らしい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の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 rebaseの影響で同内容のコミットが量産される件について - Qiita
こうしてコミットhogehoge3が作成された。 ここで問題。 ブランチ"feature/fuga" にも、コミットhogehoge3を反映したい。 このとき、どういう操作をすればいい？ feature/fugaにて を再度行えばいい？ （つまり、 hogehoge1, hogehoge2, fugafuga1, fugafuga2 から hogehoge1, hogehoge2, hogehoge3, ffuuggaa1, ffuuggaa2 にする） ただ、feature/fugaがローカルにのみ存在している場合はそれでもいいが、 既にリモートにpushされていた場合、コミットのSHA-1が変化してしまい、 同内容のコミットが複数現れることになってしまうのでは…？ fugafuga1とffuuggaa1の内容は同じだが、SHA-1が違うので別のコミットとみなされてしまうはず。 …えーと
サーバの/etcを自動的にGitとかにコミットとかプッシュしてくれるetckeeperを使う - Qiita
はじめに インフラを担当しています。 一人が管理できるホストには限りがあるなと思っていて、補助ツールがなければ10台ぐらいが精一杯かと思っています。 補助ツールを使うことで100台ぐらいまでは行けるんじゃないかと思っていて、そのためのツールを探していました。 普段のサーバ管理でやっていることを書いてみます。 チューニングなどでconfの調整 過去に他のホストで導入した設定の適用 バックアップと復元、移設 これらはetcを管理することで実現できそうですね。 過去にはSubversionを使って手作業で管理していましたが、この辺りを(半)自動化してくれるetckeeperというツールがあるということで試してみました。 インストールと初期設定 yumにもaptにもあります。 CentOSの場合にはepelを入れておきます。
[新人教育] 何も知らない人がGitとGitHubを独学で知る - Qiita
一通りやりましたがめちゃオススメです。 画面の指示に従って進めていくだけで Gitの概念からプルリクエストのフローまで学べます。 ※実際にプルリクエストを送ることができます。 ※章末ごとに正しく操作できているかのチェック機能があります。 所要時間は、Git使い慣れてる人で1時間未満。 未経験者でも3時間あればなんとか！(ハマり具合による) Git・GitHub始めたばかりの人から復習したい人まで！ また、研修でも使えると思います。 日本語版も出来たみたいですのでぜひお試しあれ！ ...と勝手に宣伝。 [git-it-electron(概要)] https://github.com/jlord/git-it-electron#user-content-git-it-desktop-version [ダウンロードページ(日本語版)] https://github.com/jlord/git-i
![[新人教育] 何も知らない人がGitとGitHubを独学で知る - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/c4d82e6a6e6fca5cf7fbdaf994ac8ef11637763f/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU2JTk2JUIwJUU0JUJBJUJBJUU2JTk1JTk5JUU4JTgyJUIyJTVEJTIwJUU0JUJEJTk1JUUzJTgyJTgyJUU3JTlGJUE1JUUzJTgyJTg5JUUzJTgxJUFBJUUzJTgxJTg0JUU0JUJBJUJBJUUzJTgxJThDR2l0JUUzJTgxJUE4R2l0SHViJUUzJTgyJTkyJUU3JThCJUFDJUU1JUFEJUE2JUUzJTgxJUE3JUU3JTlGJUE1JUUzJTgyJThCJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz1kOGJlZmViOWQ0MDQ4MDcxYzE5NTJlNzU1NWM4ZTk2Ng%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBpa2VuamkmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTdjNDNjNTJlMjExZjZlY2IxMGQyMzM5NGZkZmQ3ZWUw%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4gZ2lmdGVl%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3Da21fc58da4a14ff468039b5829ff4e02)
How would Git handle a SHA-1 collision on a blob?
This probably never happened in the real-world yet, and may never happen, but let's consider this: say you have a git repository, make a commit, and get very very unlucky: one of the blobs ends up having the same SHA-1 as another that is already in your repository. Question is, how would Git handle this? Simply fail? Find a way to link the two blobs and check which one is needed according to the c
新人さんにより良いコミットメッセージを書いてもらうための対話式スクリプト - Qiita
作ったもの コミット時に対話式で質問を表示させるものをつくりました。 ↓こんな感じ↓ 回答の内容をつなげたものがコミットメッセージになります。 質問リストは別のファイルで自由に設定できるので、 チーム内でコミットメッセージへ書いて欲しい内容をゆるく共有したい場合に。 How to use スクリプト本体はこちら #!/bin/sh set -e # core.editorに設定したいもの # merge,rebaseなどの時に起動する CORE_EDITOR=vi # commitじゃなかった場合(mergeとかrebaseとか)の場合はCORE_EDITORに渡す if [[ ! "$1" = *COMMIT_EDITMSG ]]; then $CORE_EDITOR $1 exit 0 fi CURRENT_DIR=$(cd $(dirname $0); pwd) MSGLIST_FI
GitHubで署名されたコミットにバッジが表示されるようになったので設定してみる - Qiita
まずはこちらの画像をご覧ください。 GitHubのコミット履歴ですが、コミットのSHAの左に見慣れないものが表示されていますね。 クリックするとこのような情報が表示されます。 実は、2016/4/6からGitHubはGPGによりデジタル署名されたコミットやタグにバッジを表示するようになりました。 この記事はその設定ガイドです。私の環境はWindowsですが、すべてコマンドラインとブラウザ上での操作なのでMacやLinuxでも同じように行えます。 1. GPGのインストール Git for Windowsを使っている場合は、GPGが同梱されているため追加のインストールは不要です。 それ以外の方はパッケージマネージャを使ってインストールするか、こちらからツールをダウンロードします。トップにはソースコードのリンクが掲載されており、バイナリのダウンロードリンクは下のほうにあります。 画面の指示に従
git push --force でなく git push --force-with-lease を使う - valid,invalid
前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある 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 する際には
雑に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
Git コミットメッセージのプラクティスまとめ - 酒と泪とRubyとRailsと
最近、自分のGitのコミットログを読み返してみたら、すごく分かりづらかったので勉強も兼ねて、Gitのコミットログのプラクティスを勉強してみました！ 🐰 Gitのコミットメッセージの書き方次のサイトを参考にさせていただきつつ、簡単にまとめてみました！ Gitのコミットメッセージの書き方 | プログラミング | POSTD Gitのコミットメッセージの書き方 - Qiita 書き方を知ることのメリットGitのコミットメッセージをわかりやすく残すことで、その変更どんな目的で具体的にどんなことを修正したかを 次の変更を行う人に伝えることができ、次の人の修正する時間を節約できる。 具体的にどんなことを書くべきかどのように変更を行ったかは、コードを見れば分かる。もしわからないのなら、コードにコメントを書くべき。 変更した理由を明らかにすることに焦点を絞り、変更前がどうで、何が問題で、今はどのように機
本当は怖くない！デザイナーがGitを大好きになった♡５つの理由 - Qiita
（この投稿は2014/04/23に書かれたものです。nanapi TechBlogから転載しました。） こんにちは！もうすっかり春ですね❀ nanapiの永田ゆにこですヾ(°◡°)ﾉﾞ さて、わたしはデザイナー職ですが、使いこなせているか使いこなせていないかはさておき、Gitが大好きです♡ 最初は「難しそう…」と嫌厭する気持ちもありましたが、いまでは苦手意識など吹き飛び大好きに♡ 今回はデザイナーのわたしがGitを大好きになった5つの理由をご紹介したいと思います。 その１：本当はそんなにむずかしくなかったよ！ そもそもGitはなにが便利？! Gitとはバージョン管理システムです。どんなことをやってくれるかというと例えば、同じファイルを複数人で作業しても、Gitがいい感じでひとつにしてくれたり、別の人によって上書きされてしまいそうになると忠告してくれたりします。 ありがちな「同じファイルを触
git pull と git pull --rebase の違いって？図を交えて説明します！ | KRAY Inc
はじめに こんにちは、クレイの亀井です。ここ最近一気に気温が上がりましたね。顔に重点的に汗をかくタイプの私には憂鬱な季節がやってまいりました さて、今月正式リリースしました(！) DocBase プロジェクトではクレイ外部のデザイナーの方と一緒に開発しています。SourceTree で Git を使っている方で、軽いデザイン修正などは弊社の Rails プロジェクトに直接手を加えてプルリクエストを送ってくれます。 こちらのデザイナーさんに「プルリクエストを送る際は、作業ブランチで git pull --rebase origin master してから送ってもらえますか？」とお願いすると「pull はわかるんですけど、この --rebase ってなんですか？これつけると何が変わるんですか？」と質問がきたのです。 作業ブランチで git pull --rebase origin master
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
既に git 管理しているファイルをあえて無視したい - Qiita
GitHub - k4rthik/git-cal: github like contributions calendar on terminal
