巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社
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)
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年10月時点の調査。
小規模開発には git-flow よりも GitHub Flow で捗る - TMD45INC!!!
これまで CVS や Subversion ではなかなか敷居の高かった「ブランチを切って作業する」というワークフローが、分散型バージョン管理、とくに Git の登場でとても手軽に取り入れやすくなりました。 Git のブランチを活用するためのワークフローとして有名なものに git-flow と呼ばれているモデルがあります。正しい名称は「A successful Git branching model」で、git-flow はこのモデルの導入を補助してくれる Git 拡張の名称だそうです。 A successful Git branching model（@oshow さんによる日本語訳） git-flow の解説～導入までは以下の記事に詳しく書かれています。 git-flow によるブランチの管理 - O'Reilly Japan Community Blog これはあくまで ”モデル” な
Learn Git Branching
A interactive Git visualization tool to educate and challenge!
Learn Git Branching
An interactive Git visualization tool to educate and challenge!
「こわくない Git」というスライドを発表しました - kotas.tech
社内向けに「こわくない 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
8. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) 例: 受け取ったパッチを取り込んだ人 ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー（説明は省略） 1つ前のコミットのリビジョン 例: 4717e3cf182610e9e82940ac45abb0d422a76d77 9. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Co
Try Git In Your Browser
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
Git ログの圧縮法 - 野良C++erの雑記帳
何かのプロジェクトをバージョン管理をしていると，しばしば， こまめにコミットしたい その方が修正とかも効きやすいし，変更も追いやすい ログも細かくなる分だけ分かりやすくなる でもログが細かすぎるのは嫌だ 後でざっと見返すときは大雑把な方がいい 半端な状態のリビジョンを扱いたくない という板挟みになります． で，そういったとき， Git なら， 「基本的には大雑把な履歴で管理するけど，細かいログも残す」 という事が可能なので，その方法について軽くまとめてみました． 基本 master ブランチとは別に作業用ブランチを用意し（例えば work とか），普段はそこで細かく commit します． $ git checkout -b work （作業） $ git commit -am "A" （また作業） $ git commit -am "B" （もいっちょ） $ git commit -am
Ubuntu ServerにJenkinsをセットアップしてGitレポジトリと連動するまでのまとめ - jiska
さくさく行きます。 前提条件 Jenkins, Gitレポジトリのあるサーバー共にUbuntu Server 11.10 (64bit) です。 Gitレポジトリの管理にはgitosisを使用します。 git clone, pullにはsshを使用するので公開鍵登録を行います。 sshのポートは標準の22ではなく10022を使用します。 Jenkinsのインストールとセットアップ 公式ページ ( http://pkg.jenkins-ci.org/debian/ ) を参考にしつつPPAを追加してapt-get installします。 Gitのプラグインも一緒にインストールします。 $ wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add - $ echo "deb http:
Git で集中リポジトリーに push したら、自動でワーク・ディレクトリーにも反映させる
やりたいのは、こんなこと。 ローカル PC「foo」で HTML ファイルを編集してる コードを書き終えたので、サーバー「bar」の中にある集中管理リポジトリーへ push 自動でサーバー「bar」内の公開用ディレクトリーに情報が反映される 2. から 3. の間のタイムロスを、ほとんど 0 にしたい。 こうゆう時、git の hook を使う。 リポジトリーの用意 リポジトリーの構成を、実際のコマンドを例に書いておく。 まずはローカル PC「foo」上に hoge-html プロジェクトを作成。 you@foo ~% mkdir hoge-html you@foo ~% cd hoge-html you@foo hoge-html% git init you@foo hoge-html% touch main.html you@foo hoge-html% git add main.ht
GITLAB: Self Hosted Git Management Application
1. Keep your source code at your server! Your own lite app for projects/repositories hosting on your server. Fast, secure and stable solution based on ruby on rails. 2. Use Git! We use git as version control system for projects 3. Browse source-code, issues, comments. Manage team access to repository
イラストでわかる！git入門の入門
こんにちは、アシアルの志田です。 社内でもgitが浸透し、皆バージョン管理といえばgitだよね、という空気になってきました。 ですが、これまでバージョン管理システムを使ったことがない人にオススメしても、 「gitて…まあ…そりゃ…ねえ、いつかやらないといけないけど…」 「ギット？ジット？俺はgiはジと読む派なので、gitは胡散臭いと思う」 「そもそもバージョン管理して何が嬉しいの？なんか難しそうでいやだ」 というような反応ばかりでした。 きっとみんな、gitって難しくて訳のわからんもんだと思っているのでは？と思い、 今回はgit入門の入門、gitってなんだ？というところから、簡単にgitを使う際の流れについてご説明します。 ちょっと不安を覚えるようなイラストがついていますので、頑張って読んでください。 バージョン管理ってなに？ プログラムを書いていて、こんなことありませんか？私はあります…
git pullの詳細な挙動を追ってみる - hokaccha memo
git push/pullは何気なく使ってるけど実はよくわかってなかった。ことのきっかけはこういう質問。 hogeというリモートブランチをローカルのhogeブランチにもってきたい hogeをローカルのmasterにはマージしたくない pullでなんかこんな感じでいけそう？ $ git pull origin hoge:hogeでもこれは間違えで、なぜか今いるブランチ（master）にhogeがmergeされるし、期待してる動作じゃない。正解はこう。 $ git branch hoge origin/hogeもしくはチェックアウトも同時にするなら $ git checkout -b hoge origin/hogeこう。自分は普段後者のやり方でやってたけど、なんで上のはダメで下のが正解なのか説明できなかったのでちゃんと調べてみた。 入門Gitと実用Git、あとhelpを参考にした。 ブランチ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git-flowでもgithub flowでもない、Git本家推奨のワークフロー
More Git and GitHub Secrets
layer8.sh
GitHub Flow (Japanese translation)
GitHub - rosylilly/git-tasukete: gitで助けて欲しい時に
