SQLiteがバージョン管理システムとしてGitを採用しない理由
GitはLinuxカーネルのソースコード管理に用いるために開発された分散型バージョン管理システムで、GitリポジトリをホスティングするGitHubのユーザー数は1億人を超えます。一方、軽量データベースのSQLiteの開発においてはGitではなくFossilというバージョン管理システムが利用されており、SQLiteの開発陣が「なぜGitを使用しないのか」という理由を公式サイトで説明しています。 Why SQLite Does Not Use Git https://sqlite.org/whynotgit.html なお、Fossilがどんな機能をもつバージョン管理システムなのかについては下記の記事を読むと分かります。 GitとGitHubの機能をひとつのバイナリに詰め込んだ「Fossil」レビュー - GIGAZINE 1：Gitは適切な状況認識を提供しない SQLiteにどんな変更が加え
大きなGitリポジトリをクローンするときの工夫を図解します - DeNA Testing Blog
こんにちは、SWETでCI/CDチームの前田（ @mad_p ）です。 SWETではCI/CDチームの一員として、Jenkins運用のサポートや、CI/CD回りのノウハウ蓄積・研究をしています。 はじめに Gitリポジトリをクローンすると、ローカルフォルダにはそのリポジトリの全体がダウンロードされ .git というフォルダに格納されます。ブランチをチェックアウトすると、ブランチ内のファイルがワーキングツリーとして展開されます。この様子を図にするとこのようになります。 この .git とワーキングツリーの使うディスク容量を節約しようというのが今回のお話です。特にJenkinsにおいて、大きめのGitリポジトリをクローンしてくる場合に課題があり、いろいろ工夫してみたので、その結果を紹介します。同じCI/CDチームの加瀬による記事「大規模リポジトリで高速にgit cloneするテクニック」と内容
git でコミットが消えた場合に簡単に復帰する方法 - Qiita
git 初心者がよくやってしまう失敗だと思います。git のブランチというものを把握すればなんてことのない問題なので、再度失敗しないようにまずは git のブランチについてよく理解することが必要です。 さて、このコミットが消えた、という状態ですが、ようするにコミットがどのブランチにも所属していないため、ログに表示されていない状態となります。 このようなコミットは git reflog コマンドを使えば追うことができます。 $ git reflog 8598194 HEAD@{1}: commit: 4 a734caa HEAD@{2}: commit: 3 5e85532 HEAD@{3}: checkout: moving from caseB to 5e85532 5e85532 HEAD@{4}: checkout: moving from master to caseB 18de5
Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々
Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな
コミットはスナップショットであり差分ではない
Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと
Gitでよく使用するコマンドをGIFアニメで解説
Gitでよく使用するコマンドが何を行っているかをGIFアニメで解説した記事を紹介します。 Gitのマージ、リベース、リセット、チェリーピック、フェッチ、プル、リフログなど、コマンドを実行した時にブランチはどのように相互作用し、履歴にどのような影響を与えるのか視覚的に学べます。 🌳🚀 CS Visualized: Useful Git Commands by Lydia Hallie 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに Gitのマージ（fast-forward, no-fast-forward） Gitのリベース（rebase） Gitのリセット（reset, revert） Gitのチェリーピック（cherry-pick） Gitのフェッチ（fetch） Gitのプル（pull） Gitのリフログ（re
Gitで巨大プロジェクトを扱うときに少し便利なupdate-ref｜TechRacho by BPS株式会社
ビルドに時間がかかる（数十分～数時間以上）プロジェクトを扱うときに役立つかもしれない、Gitの小ネタです。 Gitには git help しても出てこない（ git help -a すれば出る）便利なコマンドがたくさんあり（※）、そのうちの1つ update-ref のご紹介です。 ※他には例えば update-index --assume-unchanged なども有名ですね。 どんなときに欲しくなるか こんな感じの、あるヘッダファイルに多数のソースファイルが依存するプロジェクトがあったとします。 repos |- common.hpp |- source1.cpp |- source2.cpp |- source3.cpp |- source4.cpp |- source5.cpp |- ... まずは master ブランチにいます。 $ git status On branch m
Gitのalias機能で超効率的に作業する
皆さんGitは使っているでしょうか？Subversionを使用してソースコードを管理していた頃が少し懐かしいですね。 最近は開発者以外もGitを使ってプロジェクトにコミットすることも増えていると思います。そのような人たちは git add, git commit, git push のような基本コマンドのみしか使わないと思いますが、Gitを使いこなせることは作業の効率アップへと繋がるので是非もっと習得して欲しいと思っています。 alias機能を使って効率アップ！gitのaliasはコマンドで定義されているのではなく、.gitconfigに記述される形で利用することが可能です。 .gitconfigに直接記述することも可能ですし、コマンドで定義することも可能です。 設定方法 — 直接記述よく使われる、自分の.gitconfigを例にします。Vimで~/.gitconfigを開き、[alias
美容内服薬ラボットメディカルクリニック【公式】
オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。
[転載] gitにおけるコミットログ/メッセージ例文集100
gitにおけるコミットログ/メッセージ例文集100の転載 例文を組み込んだAlfred Workflowを作りました: Alfred Git Commit Message Example 以下転載: gitにおけるコミットログ/メッセージ例文集100 私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじ
![[転載] gitにおけるコミットログ/メッセージ例文集100](https://cdn-ak-scissors.b.st-hatena.com/image/square/1ef26f6cb4349557952890dbe3e567f7f98dc151/height=288;version=1;width=512/https%3A%2F%2Fgithub.githubassets.com%2Fassets%2Fgist-og-image-54fd7dc0713e.png)
[git] gitconfigで会社用アカウントと個人用アカウントを楽に使い分けする - Qiita
概要 やむを得ない事情でgitアカウントが複数あり、会社用アカウントと個人用アカウントなどを分けたいケースがあると思います。 そういったときは、会社用アカウントで作業するフォルダと個人用アカウントで作業するフォルダを分け、gitconfigの includeIf で このフォルダ配下ならこのアカウントを使うよ という設定を書いてあげるとよさげです。 ベースとなるgitconfigを作り、分けたいアカウントの数だけ[user]だけ描いたgitconfigを作ってincludeIfで参照するといい感じだと思います。 ベースgitconfig 省略 # workフォルダの時会社用gitアカウントに切り替え [includeIf "gitdir:~/project/work/"] path = ~/.gitconfig-work # otherフォルダの時は個人用アカウントを使用する [inclu
![[git] gitconfigで会社用アカウントと個人用アカウントを楽に使い分けする - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/b93b7191581244406063b2129d31854db1b647d8/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-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCZ2l0JTVEJTIwZ2l0Y29uZmlnJUUzJTgxJUE3JUU0JUJDJTlBJUU3JUE0JUJFJUU3JTk0JUE4JUUzJTgyJUEyJUUzJTgyJUFCJUUzJTgyJUE2JUUzJTgzJUIzJUUzJTgzJTg4JUUzJTgxJUE4JUU1JTgwJThCJUU0JUJBJUJBJUU3JTk0JUE4JUUzJTgyJUEyJUUzJTgyJUFCJUUzJTgyJUE2JUUzJTgzJUIzJUUzJTgzJTg4JUUzJTgyJTkyJUU2JUE1JUJEJUUzJTgxJUFCJUU0JUJEJUJGJUUzJTgxJTg0JUU1JTg4JTg2JUUzJTgxJTkxJUUzJTgxJTk5JUUzJTgyJThCJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz1hMGQ3NDhjOWUyNTQzNWM5OGJjMzg2MGM5YzdjZTllYQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBBbmNpZW50X1NjYXBlcyZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9M2JkNDExZjQxOTBhODY2YWJkM2JhNWUxNWQ1MGU5YTI%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-44KG44KB44G_%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%3D7fc2e1d75076d53ee1a09d9ae404281d)
git-updateがクソ便利 - くりにっき
git-sync にインスパイヤされて作りました qiita.com ソースコード gist.github.com モチベーション 例えばトピックブランチで作業してて、リポジトリのmasterが更新されたから最新のmasterを取り込んでrebaseするってことよくやると思うのですが、その時にいちいち git checkout master git pull --ff git checkout topic_branch git rebase master みたいなことをやるのが大変なのでサブコマンドにしました。 *1 3ヶ月くらい使ってるけど割と開発が捗ってます。 ~/.gitconfig のaliasにも up = update で登録してるので、1時間に1回くらいは g up 叩いてるんじゃないかなｗ https://github.com/sue445/dotfiles/blob/65
Git で変更を patch ファイルにする / patch コマンドで適用する - Qiita
上記の例は patch を作成した時の階層と同じ階層で適用する場合。 -p オプションとは -p オプションは、パッチを適用するディレクトリのことを示している。 git diff コマンドで作成した patch ファイルだと、diff で表示される、変更ファイルのパスが、リポジトリ直下になる。 そのため、同じ階層にいる状態で patch を適用するときは -p0 オプションを使えば良い。 -p オプション使用例 man patch に書かれている -p の使用例が大変わかり易いので、以下翻訳しつつ引用する。 -p数字 または --strip=数字 オプションで使用する 別ディレクトリに存在するファイルにパッチを当てたいときに有効である。 以下の様なファイルの場合 /u/howard/src/blurfl/blurfl.c -p0 パス指定を変更しない /u/howard/src/blurf
追跡ブランチ (tracking branch) というブランチが何なのか調べた - snowlongの日記
まとめ 追跡ブランチを指定する git checkout -b fb_track origin/develop あとから追跡ブランチを指定する git branch --set-upstream-to origin/[branch-name] 追跡ブランチ (tracking branch) という概念がわからない 以前、「tracking branchを指定していないからgit pull してもこのブランチには更新されないよ〜」と言われたことがあり「？？？」となったまま疑問を解消せずに放置を決め込んでいた。 いちおうGit/Githubは操作することはできるけど、きちんと理解したいな、疑問点はすぐに解決しないとなと思いたち調べてみました(1年以上放置してきた疑問だけど:p)。 master とorigin/masterの違い まずは、「master とorigin/masterの違い」に
【git stash】コミットはせずに変更を退避したいとき - Qiita
「とあるブランチで作業中だけど、いますぐやりたいことができた。作業がすごく中途半端だからコミットはしたくない。」 というときに、stashが使えます。 stashを使用すると、コミットしていない変更を退避することができます。 stashで現在の変更を退避して、今すぐやりたい作業をして、退避させていた変更を戻して作業を再開することができます。 変更を退避する コミットしていない変更がある状態で上記のコマンドを実行すると、変更した部分が退避されます。 ワーキングディレクトリ上は差分がない状態になります。 「コミットしていない変更」とは、addしたものもaddしていないものもどちらも含まれます。 -u は --include-untracked の略です。新規作成ファイル(追跡対象に含まれていないファイル)も退避することができます。 退避した作業の一覧を見る 以下のコマンドで退避した作業の一覧を
rebase について - ぐるぐる～
rebase 便利だよ、というだけのエントリです。 AA で書いてる部分は時間があれば画像に置き換えます。 rebase とは ブランチを作成した場所を変更することと理解しています。つまり、そのブランチの「親」を変更する、ということです。 もう少し動作に踏み込むと、指定したコミットの後ろに現在のブランチで行ったコミットをリプレイするように適用します*1。単なるリプレイではなく、その過程をいじくれるのが rebase のすごいところです。 単純な rebase はたとえばこんな感じです。 以下のようなリポジトリの状態があったとして (現在チェックアウトされているブランチは dev ということを表すのに * を使っています)、 1---2---3 *dev / A---B---C---D master次のコマンドを実行します。 $ git rebase masterこれにより、リポジトリの状態
tigから git rebase -i したらいろいろ捗った - くりにっき
git dtコマンド - razokulover publog を見て自分もgitのコマンドをカスタマイズしてるのを思い出したので普段よく使っているのを紹介します。 対象者 作業途中はtmpコミットをたくさん作って、最後に git rebase -i でコミットを整えている人 前置き gitのタイプ数を減らす gitコマンドを使う時に毎回 git と3文字タイプするのは時間の無駄なのでエイリアスつけるのをおすすめします ~/.bash_profile とか ~/.bashrc 辺りに下記を書きます。 alias g='git' これで g だけでgitコマンドが使えます git-now iwata/git-now tmp コミットのための独自サブコマンド git-now - アジャイルSEを目指すブログ 最速でtmpコミットするためのコマンド。Macなら brew install git-
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - isotai/git-tips: 最もよく使われるgitの小技と裏技
特定のファイルだけgit stashする - $shibayu36->blog;
Gitでブランチを作るのを忘れてmasterにコミットしてしまったときの対処法 - Qiita
