Note 本記事の内容は Linus 氏の発言が人を傷つける場合に筆者がそれを良しと考えるといった意図はございません 少し古い記事になるが、 Linus Torvalds 氏 の GitHub に対する苦言が記事になっていた。 LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan Linus 氏が GitHub について苦言を呈するのは今に始まったことではない（後述）が、 別に GitHub のすべてを否定しているわけではない。[1] では一体何が不満なのか。Linus 氏の理想とする git の開発フローを考察した上で、整理してみたい。 Linus 氏の理想 結論からいうと、 「意味あるコミットを作れ」「コミットを大事にしろ」 という思想が伺える。 では 「意味あるコミット」「大事にされたコミット」 とは何なのか。 筆者な
はじめに Emacs では git の操作をサポートする magit という有名なパッケージがあります。しかし magit は Github が提供するプルリクエストや issue の操作はサポートしていません。そこで magit のサブモジュールとして作られたのが forge です。このパッケージをインストールすれば、github でプルリクエストを出したり、issue を眺めたりすることが可能になります。本記事では forge のインストールと操作方法、実際に使った感想を紹介したいと思います。 インストールと初期設定 M-x list-packages を実行し forge をインストールします。執筆時点の最新版は 20191204.1349 です。パッケージ一覧に forge が無い場合はおそらくリポジトリに melpa が追加されていないのでこのあたりを参考に設定して、リトライしま
少し前に SHA1 の衝突の話題がありました(Announcing the first SHA1 collision)。 Git はリポジトリ内のオブジェクトの識別にSHA-1ハッシュを使っており、衝突が起きたときにどういう動作になるかが気になったので調べてみました。 (2021.09.22) 実装に手を入れた時の挙動を tags/v2.33.0 で再確認して更新しました。 blob のオブジェクトID Git リポジトリにおいてファイルは blob という種類のオブジェクトで表現されます。まずはじめにSHA1が衝突している2つのファイルがどう扱われるか見てみましょう。 上述のリンク先からPDFファイルをダウンロードすると ファイルサイズが一致 SHA1が一致 ファイルの内容は異なる(SHA256は異なる) という2つのファイルが入手できます。 ~/Downloads$ ls -a . .
About removing sensitive data from a repository When altering your repository's history using tools like git filter-repo or the BFG Repo-Cleaner, it's crucial to understand the implications, especially regarding open pull requests and sensitive data. The git filter-repo tool and the BFG Repo-Cleaner rewrite your repository's history, which changes the SHAs for existing commits that you alter and a
「間違ったコミットをリモートにpushしちゃった！取り消したい！」ってときの操作。上イメージのようにgithubに誤ったpushをした場合を想定して解説してみます。 下記コマンド打つ。 HEAD~2は「直前の２つのコミットを修正対象とする」という意味になります。３つ前のコミットを取り消したい場合はHEAD~3としてください。するとこんな画面が出てくる。 取り消したいコミットを削除して保存します。この場合、２行目のコミットが誤りなので２行目を削除して保存します。うまくいくとこんなメッセージ。
目次 はじめに Git を使ったことがない方へ 生のデータが見たい方へ Git の全体像 .git の中身 Git オブジェクトデータベース 4種類のオブジェクト リファレンス リファレンスのリファレンス 大きなツリー Git オブジェクトの ID と 中身 ハッシュ関数 SHA1 の簡単な説明 tree と blob オブジェクト tree と blob の参照関係 ルートツリーの ID でツリー全体を識別する commit オブジェクト リファレンスとブランチ ブランチ ブランチ先頭を指すリファレンス HEAD リファレンス detached HEAD 2種類のタグ 一時待避 (stash) インデックス キャッシュとしての役割 マージ Fast-Forward マージ non Fast-Forward マージ rebase reset 2種類のブランチ 各リポジトリが自分のブランチを
濱野さんの「入門Git」を初めて読んだ時、いきなり 第二章から Git の構造の説明を始めてしまう構成に「Git<の使い方>入門」じゃなくて「Git<の作り方>入門」でしたかーっ（さすがメンテナですね）、、と思ったことを覚えています。 入門Git 作者: 濱野純(Junio C Hamano)出版社/メーカー: 秀和システム発売日: 2009/09/24メディア: 単行本購入: 31人 クリック: 736回この商品を含むブログ (155件) を見る それは結構楽しい体験で、それまで全く思っても見なかった「Git作ってみたいな」という うずうずとした衝動がわたしに芽生えるきっかけでした。それ程に Git の設計はシンプルで 手に終えそうで、それでいて「うまくいく仕組み」が備わっている、興味深いものだったのです。まさにハックと呼ぶにふさわしいそれは、VCS全般に抱いていた「しっかり綿密に作りこ
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
公開日時: 2012-06-22 22:30 Javaでgitのサーバーを立てたり、gitのクライアントを作成しようとする場合に使用できそうなライブラリ等をまとめます。 Javaのgitサーバー、クライアントや使用例 JGit JavaによるGitの実装。EDL（new-style BSD）ライセンス。 http://eclipse.org/jgit/ Gitblit JavaによるGitの実装。Apache License, version 2.0 「Gitblit GO」「Gitblit WAR」「Gitblit Express」の3種が用意されている。 「Gitblit GO」はSingle-Stack Solutionとして全ての依存がバンドルされており、付属のJettyを使ってこれだけでgitのサーバーを立てられる。 「Gitblit WAR」は文字通りWAR。好みのコンテナでサ
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
社内向けに「こわくない Git」というタイトルのスライドを作って発表しました。 対象者は「マージがなんとなく怖い」「エラーが怖い」「リベース使うなって言われて怖い」と、Git が怖いと思っている人です！ こわくない Git from Kota Saito 発表中に出た質問など 補足も兼ねて、上のスライドを発表した際に出た質疑応答などをここに書いておきます。 Q: 常に Non Fast-Forward (--no-ff) でいいのでは、と思えるけど git merge がデフォルトだと Fast-Foward or Non Fast-Forward (--ff) なのはなぜ？ A1: Non Fast-Forward だと、確かにメリットが多いのですが、1点だけデメリットがあります。特に差分が無い状態で git merge --no-ff すると、空のマージコミットが作られてしまうのです。
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
push したら誰かが先に push していたので失敗した。 なので pull したが、コンフリクト (競合) は発生しなかったので何も確認せずにそのまま push した。 何も問題なさそうですね。 ・・・本当ですか？ 例えばこんな状況を考えてみましょう。 最初の状態 A さんと B さんと C さんが登場します。 作っているのは Web ページで、コードはこんな感じ。 <html> <head> <title>hoge</title> <style> .menus { overflow: auto; } ul { margin: 0; padding: 0; list-style-type: none; } .button { float: left; width: 100px; margin: 0; padding: 10px 0; text-align: center; backgr
Gitさんはいくつかのタイミングで好きな処理をフックできる賢い子です。 $GIT_DIR/hooks配下にタイミングごとのスクリプトが用意されていて、それを書き換えることで任意の処理を行わせることが出来ます. タイミングなどの詳しい説明はman githooksに書かれています。（最初にこれを見ていれば僕の数時間は失われなかったのに） 今回やりたかったのは、ローカルでWebサイトをこねくりまわして、気に入ったらコミットしてリモートにpush、そうすると自動的に公開用のディレクトリでpullするというものです。 やったことは、リモート側で $ cat path/to/repos/hooks/post-receive #!/bin/sh (cd /path/to/site/directory; git --git-dir=.git pull) $ chmod +x path/to/repos/
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git-flowでもgithub flowでもない、Git本家推奨のワークフロー