GitHub - jj-vcs/jj: A Git-compatible VCS that is both simple and powerful
Jujutsu is a powerful version control system for software projects. You use it to get a copy of your code, track changes to the code, and finally publish those changes for others to see and use. It is designed from the ground up to be easy to use—whether you're new or experienced, working on brand new projects alone, or large scale software projects with large histories and teams. Jujutsu is unlik
法律をGitHubのプルリクエスト機能を使って修正するその一部始終が公開中
アメリカ合衆国の首都ワシントンでは、法律がGitHubを使用して管理されています。法律のオープンデータ化を推進するサービス「GovTrack」の創設者であるジョシュア・トーベラーさんが条文のタイプミスを見つけてからプルリクエスト機能を使って修正するまでの流れが海外ニュースメディアのArs Technicaで公開されています。 How I changed the law with a GitHub pull request | Ars Technica https://arstechnica.com/tech-policy/2018/11/how-i-changed-the-law-with-a-github-pull-request/ ある日、トーベラーさんが法律を調査していた時に条文の参照が誤っていることを発見したとのこと。問題となったのは「公開政府省は、第2編第5章のIの実施に関して助
【gitコマンド】いまさらのrevert - Qiita
===== 20190430追記 ===== わかりにくい表現を修正しました。 内容の変更はしていません。 ===== 追記ここまで ===== ちょこちょこ使う機会はあったのですが、いまいち使いこなせていなかったrevertについて改めて調べました。 revert とは 既存のコミットを取り消すためのコマンドです。 「取り消したいコミットを打ち消すようなコミットを新しく作成する」という処理によって、既存のコミットを取り消します。 新しくコミットを追加しているだけなので、既存コミットの履歴が消えるわけではありません(コミットログをみると残っています)。 どんな変更があったのかということが(revertしたということも含めて)残るので、リモートにpushされて公開されているコミットに対しても安全に使うことができます。 「既存のコミットを元に戻す」という点について、同じような機能を持つコマンド
Emoji Prefixに学ぶgitのコミットの分け方 - dackdive's blog
こちらの記事を読んで。 http://memo.goodpatch.co/2016/07/beautiful-commits-with-emojis/ この記事では、Emoji Prefix というコミットメッセージに関するルールについて紹介している。 どんなルールかというと、「コミットメッセージの先頭には、コミットの内容に合った Emoji をつけましょう」というものらしい。 Prefix に使える Emoji の種類をルール化し、コミットメッセージにはいずれかの Emoji を必ずつけるように徹底することで コミットの内容がわかりやすくなるだけでなく、粒度も揃うという効果が期待できるようだ。 以下、記事から引用。 最も期待している効果は、コミットが綺麗になることです。 開発の現場では「インデントの修正と機能の修正を同じコミットにしないでください 😭 」といった悲痛な叫びをよく耳にしま
【今日からできる】コミットメッセージに 「プレフィックス」 をつけるだけで、開発効率が上がった話 - Qiita
はじめに 今まで commit message を「なんとなく」書いていたが、プレフィックスをつけることで、コミットメッセージに対する考え方が変わった。 そのおかげで開発効率が上がったので、その内容をシェア。 プレフィックスをつけるってどういうこと？ 以下のようにコミットメッセージの先頭に、なんらかの文字をつけること。 feat: xxx という機能を追加 fix: yyy で発生するバグを修正 refactor: zzz の機能をリファクタ のように feat, fix, refactor などがプレフィックスです。 最近 OSS の Contribution Guide などでよく見かけます。 導入したプレフィックスルール Angular.js/DEVELOPERS.md Angular.js の開発者ガイドに書いてあるメッセージを参考にしました。 以前のコミットメッセージ（例 ちなみ
NetBSD Blog
Hello all, the repository conversion setup for NetBSD CVS -> Fossil -> Git has found a new home. Ironically, on former cvs.NetBSD.org hardware. This provides a somewhat faster conversion cycle as well as removing anoncvs.NetBSD.org from the process. This should avoid occasional problems with incomplete syncs. Two other changes have been applied at the same time: The Fossil repositories have moved
Gource - a software version control visualization tool
Introduction Software projects are displayed by Gource as an animated tree with the root directory of the project at its centre. Directories appear as branches with files as leaves. Developers can be seen working on the tree at the times they contributed to the project. Gource includes built-in log generation support for Git, Mercurial, Bazaar and SVN. Gource can also parse logs produced by severa
gettextとバージョン管理システムの相性の悪さを解消する案 - 2013-11-14 - ククログ
Gettextという翻訳の仕組み1はフリーソフトウェアではよく使われています。いくつか不便な点はありますが、長年使われている仕組みでツールが揃っていることが理由でしょう。不便な点の1つである、「バージョン管理システムとの相性の悪さ」を解消する案が浮かんだので紹介します。 どうしてバージョン管理システムと相性が悪いか gettextでは.poファイルに翻訳したテキストを書きます。翻訳したテキストは自動生成ではない情報なのでバージョン管理対象です。ということで、.poファイルはリポジトリーに入れます。 バージョン管理システムと相性が悪い原因は、.poファイルに翻訳したテキスト以外のいろいろな情報が入っていることです。中でも、「どこに翻訳対象のメッセージがあったか」は自動生成できる情報で、量も多く、通常であればバージョン管理しない情報です。しかし、バージョン管理したい.poファイルの中に含まれて
Meld
Meld Visual diff and merge tool Meld helps you compare files, directories, and version controlled projects. It provides two- and three-way comparison of both files and directories, and has support for many popular version control systems. Meld helps you review code changes and understand patches. It might even help you to figure out what's going on in that merge you keep avoiding. File comparison
マージでコンフリクトした際にどちらかのブランチの内容を適用 (git merge, conflict, checkout, --ours, --theirs) - いろいろ備忘録日記
相変わらずGit勉強中です。 以下自分用のメモです。 マージでコンフリクトした際に、実際に相違点を見て 手動でマージするのが普通ですが、場合によっては どちらかのブランチの内容を全適用したいときがあります。 バイナリファイルの場合とかがそうですね。 今まで （というか今日まで） バイナリファイルでコンフリクトしたら やり方がわかってなくてオロオロしてました。で、Git使いこなしてらっしゃる 方々のページで勉強。情報を公開してくださっている方に感謝 m(_ _)m Gitでマージしたバイナリファイルがconflictした場合の解決策 http://blog.digital-squad.net/article/151034635.html マージでバイナリファイルがコンフリクトした場合のGitの動作と対処方法 http://blog.ruedap.com/entry/20110720/git_
DVCS-Autosync: A personal Dropbox replacement based on Git | Rene Mayrhofer's virtual home
Family cloud
Ditz
Current project status: see the ditz ditz page. Current project news: see the blog and mailing list archives. Ditz is a simple, light-weight distributed issue tracker designed to work with distributed version control systems like git, darcs, Mercurial, and Bazaar. It can also be used with centralized systems like SVN. Ditz features a simple, clean commandline interface, a robust plugin architectur
Shibu's Diary: Bitbucket買収？そもそもそれ何？という人のためのBitbucket紹介
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 9/29の水曜日に、Atlassian社がBitbucketを買収するというニュースがありました。これにより、今まで有料だったようなサービスが無料で提供されるようになりました。買収したのは、Jiraなどの開発ツールで有名な会社です。とはいえ、Python界隈の人以外にはあまり注目されてこなかったサイトだとは思うので、BitBucketを紹介します。僕はソースコード管理ではメインで使っています。 買収されたBitbucketって何ですか？ Bitbucketは何者か？一言で言えば、Mercurial版のgithubです。以上。 これで分かる方はここの説明はすっとばしてくれて構いません。いわゆる、プロジェクトのホスティングサービスの一つです。ソフトウェア開発に必要な仕組みが備わって
tDiary.org
開発リポジトリのGit移行について かねてから開発者メーリングリストで相談していましたが、先日開発リポジトリをGitに移行しました。 tDiary on GitHub 現在、有志の手によってモダンな環境への移植トライアルがいくつか行われており、今後それら成果を取り込むためには運用が柔軟なGitをメインのリポジトリにするのが最適であるという判断です。今後のtDiaryの開発は上記Git上で行われます。 なお、この移行と同時に、pluginをcore/misc/の下に移動し、pluginリポジトリを廃止しました。 以下に、現存する各種リポジトリの扱いについて述べます。 GitHub上のリポジトリの扱い 開発のためのメインリポジトリはGitHub上のものを利用します。このリポジトリへの直接コミットは主要開発メンバ(執筆時点では、ただただしと柴田博志)のみが可能です。 他の開発者は、自身の環境(G
Island Life - gitのワークフロー
About 南の島のプログラマ。 たまに役者。 Practical Schemeの主。 WiLiKi:Shiro 最近のエントリ 米国の大学進学無限cxr高校受験Defense振り返ってみると2019年は色々学んで楽...覚えるより忘れる方が難しい(こともある)眼鏡のつると3DプリンタIris Klein Acting ClassSAG-AFTRA conservatory: Voice Acting創作活動って自分を晒け出さねばならないと...More... 最近のコメント Jessica Kirkpatrick on CLtL2 (2025/06/28)shiro on 歳を取ると時間が速く過ぎるのは、新しいことに挑戦しないから? (2023/03/14)1357 on 歳を取ると時間が速く過ぎるのは、新しいことに挑戦しないから? (2023/03/01)ベアトリーチェ on ハイポハ
#22 Gitメンテナ 濱野 純 | gihyo.jp
今回のゲストは、分散バージョン管理システムGitのメンテナで『入門Git』（注1）の著者、濱野純さんです。Linuxカーネルの開発者、Linus Torvaldsさんから引き継いでGitのメンテナになった経緯から、対談スタートです。 （撮影：武田康宏） Gitに関わった経緯 弾：Gitに関わったきっかけは？ 濱：2005年の4月にLinuxカーネルのバージョン管理システムとして使われていたBitKeeperが使えなくなる[2]からということで、Linus君がいろいろありものを探したんだけど、使えるものがなくて、誰かがいいのを作ってくれるまでのつなぎというつもりで、とりあえず自分でもコードを書いた、というアナウンスをしました。それをカーネルメーリングリスト（ML）で見ていたんですが、たまたまボクの本業がプロジェクトとプロジェクトの合間だったんです。なんかおもしろそうなこと始まってるじゃん、
debiancdn
「AWSが大好きで、大好きすぎるのに日本にないものだからクラウドをつくる」 というようなことを2009年に Lightning Talks (2009-07-18) – 日本Ruby会議2009 に参加したときに懇親会で話をしたことを思い出しました。 そんなわけで、 超絶久しぶりにブログに記事を書くことに。なんと10年ぶりだなんて驚きです！ こんにちは、あらき(X: @ar1)です。 経歴は、LinkedInにほぼ載っていますのでご興味ある方はコチラをどうぞ。 知っている人は知っていたかもしれませんが、AWSで13年と8ヶ月働いたことをお伝えします。 AWSのSAとして、まだまだやれることがあると思う中での決断となりました。そして、さくらインターネットに来てから半年が経ちました。その区切りとしてこの記事を書きます。 冒頭に書いたように、自分は過去に2回ほどクラウド作りを試みたことがあります
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
FreeBSD.org Git mirror
Inouetakuya
gource - Project Hosting on Google Code