Recent changes (last updated April 2026): Added a more theoretical section on Merkle DAGs. This list is now automatically generated. This article is an attempt at explaining the Git version control system from the bottom up, that is, starting at the most fundamental level moving up from there. This does not sound too easy, and has been attempted multiple times with questionable success. But there’
Radicle is a sovereign {code forge} built on Git. Synopsis Radicle is an open source, peer-to-peer code collaboration stack built on Git. Unlike centralized code hosting platforms, there is no single entity controlling the network. Repositories are replicated across peers in a decentralized manner, and users are in full control of their data and workflow. The Radicle heartwood repository. Reposito
#!/bin/sh user=`git config github.user` git remote show ${user} > /dev/null 2>&1 has_repo=$? git fetch --all --prune modified=`git status | grep modified | wc -l` if [ $modified -gt 0 ] ; then git stash ; fi branch=`git branch | grep '*' | cut -f 2 -d ' '` git checkout master git pull --rebase origin master if [ $has_repo = 0 ] ; then git push ${user} master; fi if [ $branch != 'master' ] ; then i
これをみるとinputやfalseはLF -> CRLFの自動変換を行わないので、これらを選んでしまいそうですが、 大規模開発で多数の開発者がtrueでインストールしてしまった場合、わざわざ変更をしてもらうまでの悪影響があるのか?がわからなかったので、それについて調べた結果を記載しようかと思います。また、これを書くきっかけとなった私のチームではまった落とし穴について書こうと思います。 core.autocrlfをtrueに設定をした場合 core.autocrlfをtrueに設定をした場合について整理します。 チェックアウトやコミットした場合の動きや、開発者がCRLFでファイルを作成した場合の動きは以下のようになります。 上記の図から確かにwroking directory上ではCRLFとLFが混在してしまう可能性がありますが、 repository上のファイルがLFである以上、core.
github.com GitHub の適当なリポジトリを Scaffolding の元ネタに使っちゃおうぜ というツールを作った。 Git で Scaffolding なので GISC 。大文字でも小文字でも可。gisc という名前にしたら disc っぽかったのでそういうロゴにした。ちなみにロゴは会社帰りに iPhone のメモアプリで描いた(便利!)。 使い方 インストール。 npm install -g gisc jinjor/gisc リポジトリの example ディレクトリをコピって my-project を作る。デフォルトだとサーバーが github.com 、プロトコルは https 、ブランチは master 。 depth は常に 1 。キャッシュはしない。 gisc get jinjor/gisc example my-project これでもまだ長いので alias
多くのユーザーがその柔軟さ故に Git を分散型バージョン管理システムとして採用しています。特に Git のブランチとマージのモデルは、分散型の開発ワークフローを実現する強力な方法となっています。この柔軟性が大半のユースケースに機能する一方で、それほど美しく扱いきれないこともいくつかあります。そのようなユースケースの一つは、monorepo という大きな一枚岩のリポジトリで Git を使用することです。この記事では、Git を使用して monorepo を扱う際の課題について説明し、その問題を緩和するヒントを提供します。 monorepo とは? さまざまな定義がありますが、我々は monorepo を以下のように定義します。 論理プロジェクトを二つ以上含むリポジトリ (iOS クライアントやウェブアプリケーションなど) 各プロジェクトはほとんど関連がなく、疎結合、または異なる方法で繋がっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く