← HOME - a blog about xit RSS ██╗ ██╗██╗████████╗██╗ ██████╗ ██████╗ ╚██╗██╔╝██║╚══██╔══╝██║ ██╔═══██╗██╔════╝ ╚███╔╝ ██║ ██║ ██║ ██║ ██║██║ ███╗ ██╔██╗ ██║ ██║ ██║ ██║ ██║██║ ██║ ██╔╝ ██╗██║ ██║ ███████╗╚██████╔╝╚██████╔╝ ╚═╝ ╚═╝╚═╝ ╚═╝ ╚══════╝ ╚═════╝ ╚═════╝ XIT IS COMING - March 4, 2025 I'm working on a new version control system called xit (pronounced like "zit"). To paraphrase JFK: I do thi
A few days ago, a video produced by @t3dotgg was posted to his very popular YouTube channel where he reviews an article written by the Graphite team titled “How GitHub replaced SourceForge as the dominant code hosting platform”. Theo’s title was a little more succinct, “Why GitHub Won”. Being a cofounder of GitHub, I found Greg’s article and Theo’s subsequent commentary fun, but figured that it mi
今回の記事の内容はGitHub共同創業者のScott Chacon氏の「Pro Git」と同氏の今年の「So You Think You Know Git」（Gitがわかっているとでも思っているか？）発表をベースにしている。 コンフィグ ここでコンフィグにてデフォルトとして指定して損がないオプションをいくつか紹介します。 git rerere git rerereは"reuse recorded resolution"（記録ずみ解決方法を再利用）の略語になっている。 名の通りマージコンフリクトがどう解消されたかを記録し、次に同じようなコンフリクトが発生した際、同様の解決方法を自動的に適用するためのコマンドです。 また、基本的にデフォルトにしてもときに差し支えないため、ぜひgit config --global rerere.enabled trueを実行してみてください。 git main
はじめに Git Graphという拡張機能を使います。 Git GraphとGitLensという拡張機能を使います。[1] また、gitから開かれるエディタをvscodeにしておきます。 コミットのまとめかた（1分未満でできるよ） ステータスバーのGit Graphのボタンをクリックして、Git Graphの画面を開きます。 まとめたいコミットの一つ前のコミット（今回だとinit）を右クリックして、「Rebase current branch on this Commit...」を選択します。 「Launch Interactive Rebase in new Terminal」にチェックを入れて「Yes, rebase」をクリックします。 こんな画面が開きます。 まとめたいコミットを上から順にpickからsquashに変更します。最後の一つはpickのままにしておきます。そして「STAR
先日ホットエントリーに上がっていた以下の記事を読んでやる気を出して整理した。 jvns.ca 記事からは以下を取り入れて、あとは不要なものを消したりして回った。 branch.sort -committerdate ブランチをコミット時刻で並べる diff.algorithm histogram diff のアルゴリズムを histogram にする (参照) rebase.autosquash = true rebase するときに --autosquash って書かなくてよくなるやつ 最終的には見せていいところだけ残して以下のようになった。 [ghq] root = ~/local/src [alias] c = commit b = branch d = diff di = diff --cached st-pull = !git stash && git pull && git s
あるレポジトリのサブディレクトリ配下を別のレポジトリへ履歴付きで移行する - $shibayu36->blog; の逆バージョン。 あるレポジトリでずっと開発していたが、やっぱりモノレポの中に入れたいとなって、履歴付きでモノレポの特定のサブディレクトリ配下に移動したい時があった。たとえば https://github.com/shibayu36/go_todo_app の履歴をすべて https://github.com/shibayu36/go-playground のgo_todo_appディレクトリに移したいみたいなケースだ。この時コミット履歴としてはgo-playgroundのgo_todo_app/配下で初めから開発していたかのように移したい。 この解決策として Gitのサブツリーのマージについて - GitHub Docs にあるように、サブツリーマージという方法も取れる。しか
はじめにTIG真野です。 秋のブログ週間2023 の3本目は、設計ドキュメントをGit管理して腐らせないようにがんばってみた話をします。 前段として6年前、「我々はいかにシステム開発におけるドキュメント腐る問題と戦えば良いのか」という記事を書いたのですが、その後の試行錯誤はどこにも残していないことに気づきました。普段のフューチャー技術ブログですとちょっと引け目を感じるテーマですが、秋の夜長を楽しむため読み物成分を多めに書くというテーマのこのブログリレーにピッタリな気がするため、この機会をお借りします。 ドキュメントも色々な種別があるかと思いますが、この記事では設計ドキュメントを指すことにします。設計ドキュメントは開発メンバーが参照するもので、ステークホルダーへの説明資料に引用して使うことはあれど、主目的は異なるという前提です。Design Docの場合もありますし、システム構成図、ERD、
Note 本記事の内容は Linus 氏の発言が人を傷つける場合に筆者がそれを良しと考えるといった意図はございません 少し古い記事になるが、 Linus Torvalds 氏 の GitHub に対する苦言が記事になっていた。 LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan Linus 氏が GitHub について苦言を呈するのは今に始まったことではない（後述）が、 別に GitHub のすべてを否定しているわけではない。[1] では一体何が不満なのか。Linus 氏の理想とする git の開発フローを考察した上で、整理してみたい。 Linus 氏の理想 結論からいうと、 「意味あるコミットを作れ」「コミットを大事にしろ」 という思想が伺える。 では 「意味あるコミット」「大事にされたコミット」 とは何なのか。 筆者な
Sapling is a new Git-compatible source control client. Sapling emphasizes usability while also scaling to the largest repositories in the world. ReviewStack is a demonstration code review UI for GitHub pull requests that integrates with Sapling to make reviewing stacks of commits easy. You can get started using Sapling today. Source control is one of the most important tools for modern developers,
validates :name, presence: true, length: {maximum: 10, minimum: 20}
最近の自分が、どんな風に Git を使ってるか、メモを残しておこうかなと思ったので書くことにした。こういうの、以前に書いたかもしれない？と思ったらあった↓ bufferings.hatenablog.com この頃はコマンドだけ使って操作してたけど、最近は JetBrains の IDE から一部操作するようになったのだ！便利！ エイリアス 話に入る前に、使ってるエイリアスを紹介。自分で考えるの苦手なのでこの設定ファイルをコピーしてきて使ってる↓ https://github.com/timcharper/git_osx_installer/blob/master/assets/etc/gitconfig.default#L23-L41 とは言いつつ、最近おもに使ってるのは git l くらいかな l = log --graph --all --pretty=format:'%C(yell
Gitって難しい。簡単にぐちゃぐちゃの状態になっちゃうし、失敗を直す方法を知ろうとしたところでまじくそ不可能。Gitのドキュメンテーションって卵とニワトリの問題みたいなところがあって、ハマりから抜け出すために知ってないといけない事柄の名前をあらかじめ知っていないと、どうやって問題を解決したらいいのか検索することすらできないんだよね。 だからここに、私が遭遇したことのあるよろしくない状況から、最終的にどうやって抜け出したかをフツーの日本語で書いていこうと思う。 くっそー、超絶やらかした。お願い、Gitには魔法のタイムマシンがあるって言って？ git reflog # こうすると、Gitでやったことがすべてのブランチに渡って全部見えるよ！ # どのブランチにも HEAD@{index} ってインデックスがあるはずだから # やらかす前のやつを見つけて git reset HEAD@{index
はじめに 複数 git アカウントを1つの PC で使い分けたいとき（「社用と私用両方から github 使いたい」等）、 社用と私用アカウントを使い分けたいとき（「社用アカウントで github, 私用アカウントで gitlab」等）、 ありますよね。手順まとめます！ 重視した点 めちゃくちゃ細かく書きました。 自分が PC 新調して再設定する度に細かい所忘れ去っており思い出すのに苦労しているので（おっさんおつ）、 忘れ去っててもサクサク設定出来るように。。 やりたい構成 最初にイメージしやすく構成を書きます。 適当に、アカウント2つ（社用、私用）、それぞれに git ホスティングサービス2つ利用、の状況を考えます。 図にするとこんな感じ。 「アカウント1つ目で gitbucket と github、アカウント2つ目で github と gitlab」 としていますが、これはあくまで例で
緊急新人エンジニア応援企画！ ということで自分が Git のエイリアスとして設定している便利コマンドを紹介していく。 直前のコミットに追いコミットする (git fixit) git commit --amend --no-edit もろもろ整えて git push しよう、とすると「あっちょっと修正したい」となるのはよくあること。その際いちいちコミットメッセージを書いて rebase するかというとそんな面倒はとりたくなく、一撃で終わらせたい。--no-edit でコミットメッセージを編集せずに --amend できる。 git fixit に設定している。git commit の引数をそのまま受け付けるので、git fixit -a や git fixit <file> のように使える。 メインブランチに戻る (git com) f() { remote_head=$(git symb
Summary 何となくでも良いのでconventional commitの仕様にしたがってcommitを作る 変更はPR作る直前までcommitしない 3.レビュー以前の変更はfixupとforce pushで既存のcommitに入れる。追加のcommitは作成しない 解説 1. 「何となくでも良いのでconventional commitの仕様にしたがってcommitを作る」について conventional commitとは、「人間と機械が読みやすく、意味のあるコミットメッセージにするための仕様」です。（公式から引用https://www.conventionalcommits.org/ja/v1.0.0/ ) この仕様(の特にコミットメッセージのタイトル部分)に従ってコミットを作るようにします。 タイトル部分の仕様はこんな感じです。 <type>[optional scope]:
仕事でGit使うときとか普段とは違う会社のメアドでコミットとかしたいんだけど、cloneするたびに git config user.email とかするのメンドイよね〜 というかもうだいぶ有名な設定だと思うんだけどたまに知らない人いるので書いておくと includeif 使うと特定のディレクトリ以下のときに読み込む設定を変更できるので便利です。 で、ここまでは普通にGitのマニュアルにも書いてあるんだけど ghq と組み合わせると最高便利になるのでそのへんの設定を書いておきます。 といっても普通に設定するだけだけど .gitconfig には下記のように書いておいて [ghq] root = ~/src [includeIf "gitdir:~/src/github.com/launchableinc/"] path = ~/.config/git/launchable.inc ~/.co
こんにちは、SWETでCI/CDチームの前田（ @mad_p ）です。 SWETではCI/CDチームの一員として、Jenkins運用のサポートや、CI/CD回りのノウハウ蓄積・研究をしています。 はじめに Gitリポジトリをクローンすると、ローカルフォルダにはそのリポジトリの全体がダウンロードされ .git というフォルダに格納されます。ブランチをチェックアウトすると、ブランチ内のファイルがワーキングツリーとして展開されます。この様子を図にするとこのようになります。 この .git とワーキングツリーの使うディスク容量を節約しようというのが今回のお話です。特にJenkinsにおいて、大きめのGitリポジトリをクローンしてくる場合に課題があり、いろいろ工夫してみたので、その結果を紹介します。同じCI/CDチームの加瀬による記事「大規模リポジトリで高速にgit cloneするテクニック」と内容
はじめに 僕はSVN脳患者である。SVN脳とは、SubversionのポリシーでGitを理解しようとしたり、使おうとしたりする病気で、中年プログラマに発症例が多い(気がする)。それまでSubversionを使ったことがない人がGitを使う場合には問題にならなかったことが、SVN脳患者がGitを使おうとすると問題になることが多い。特に、SVN脳を発症したプログラマは、そうでない人に比べてGit学習コストが爆発的に増大する。最初からGitに触れた人は、なぜSVN脳患者がGitを理解できないのかを理解できないだろう。 これは、SVN脳患者である僕1が、なぜGitを長いこと理解できなかったかをつらつら書くポエムである。病人の書いたポエムであるからして、所謂マサカリの類はほどほどにしていただきたい。 以下、「SVN脳患者」という大きな主語を多用するが、要するにこれは僕のことであり、言うまでもなくSu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
