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
Intuitive UI at ScaleSapling makes development easier than ever before by simplifying common source control workflows and providing easy-to-use UIs while also scaling to the largest repositories in the world. Integrate with GitSapling client also supports cloning and interacting with Git repositories and can be used by individual developers to work with GitHub and other Git hosting services. Stack
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes 第20回 Googleのソースコード管理システム ― Piper/CitC (中井悦司) 2017年7月 はじめに 今回から2回に渡り、2016年に公開された学術記事「Why Google Stores Billions of Lines of Code in a Single Repository」をもとにして、Google社内で利用されているソースコード管理システムのPiperとCitCを紹介します。この記事では、Googleにおけるソースコード管理の仕組みやPiper/CitCの機能に加えて、そのメリット／デメリットが議論されています。 今回は、まずは、Googleにおけるソースコード管理の仕組みと、その考え方を紹介していきます。 ソース
Overview A Glossary of Common Terms A Quick Guide to Mozilla Applications Getting Started Getting Set Up To Work On The Firefox Codebase Working On Firefox Working on Firefox Bug Handling Firefox User Guide Firefox DevTools User Docs Source Code Documentation Governance Firefox Front-end DOM Editor Style system (CSS) & Layout Graphics Processes, Threads and IPC Firefox DevTools Contributor Docs To
これはなに？ はじめに AGCあれこれ Temporary I HOPEHOPEHOPE ASTRONAUT NOW LOOK WHERE YOU ENDED UP ふと気になりました いい時代ですね 1201&1202エラー なにそれ？ カ、カルマンフィルターだー！！！ カルマンフィルターの開発経緯 その他面白コメントアウト集 TRASHY LITTLE SUBROUTINES（つまんないサブルーチン） NUMERO MYSTERIOSO（神秘の数字） OFF TO SEE THE WIZARD COME AGAIN SOON HONI SOIT QUI MAL Y PENSE（悪意を抱く者に災いあれ）、NOLI ME TANGERE（私に触れるな） PINBALL_GAME_BUTTONS_AND_LIGHTS.agc おわりに 反省 参考文献 これはなに？ この記事はeeic Adv
アメリカ合衆国の首都ワシントンでは、法律が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の実施に関して助
Pijul is a free and open source (GPL2) distributed version control system. Its distinctive feature is to be based on a theory of patches, while still being fast and scalable. This makes it easy to learn and use, without any compromise on power or features. Commutation In Pijul, independent changes can be applied in any order without changing the result or the version's identifier. This makes Pijul
20190430追記 わかりにくい表現を修正しました。 内容の変更はしていません。 追記ここまで ちょこちょこ使う機会はあったのですが、いまいち使いこなせていなかったrevertについて改めて調べました。 #revert とは 既存のコミットを取り消すためのコマンドです。 「取り消したいコミットを打ち消すようなコミットを新しく作成する」という処理によって、既存のコミットを取り消します。 新しくコミットを追加しているだけなので、既存コミットの履歴が消えるわけではありません(コミットログをみると残っています)。 どんな変更があったのかということが(revertしたということも含めて)残るので、リモートにpushされて公開されているコミットに対しても安全に使うことができます。 「既存のコミットを元に戻す」という点について、同じような機能を持つコマンドにresetが存在します。 resetコマンド
こちらの記事を読んで。 http://memo.goodpatch.co/2016/07/beautiful-commits-with-emojis/ この記事では、Emoji Prefix というコミットメッセージに関するルールについて紹介している。 どんなルールかというと、「コミットメッセージの先頭には、コミットの内容に合った Emoji をつけましょう」というものらしい。 Prefix に使える Emoji の種類をルール化し、コミットメッセージにはいずれかの Emoji を必ずつけるように徹底することで コミットの内容がわかりやすくなるだけでなく、粒度も揃うという効果が期待できるようだ。 以下、記事から引用。 最も期待している効果は、コミットが綺麗になることです。 開発の現場では「インデントの修正と機能の修正を同じコミットにしないでください 😭 」といった悲痛な叫びをよく耳にしま
はじめに 今まで commit message を「なんとなく」書いていたが、プレフィックスをつけることで、コミットメッセージに対する考え方が変わった。 そのおかげで開発効率が上がったので、その内容をシェア。 プレフィックスをつけるってどういうこと？ 以下のようにコミットメッセージの先頭に、なんらかの文字をつけること。 feat: xxx という機能を追加 fix: yyy で発生するバグを修正 refactor: zzz の機能をリファクタ のように feat, fix, refactor などがプレフィックスです。 最近 OSS の Contribution Guide などでよく見かけます。 導入したプレフィックスルール Angular.js/DEVELOPERS.md Angular.js の開発者ガイドに書いてあるメッセージを参考にしました。 以前のコミットメッセージ（例 ちなみ
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
叩くべきは木魚ではなくエンターキー。お寺生まれのCTOが出家と家出の狭間で、ついに見つけた自分がやるべきこと。 1. 昔、何していたの？実家がお寺で父親がお坊さんという一般的な家庭で育ったため、普通に生きていきたいと思っている将来の夢はサラリーマンという少年でした。タイトルに木魚とありますが、実家は浄土真宗なので木魚は叩きません。正式にはリンと呼ばれる、金属製のかねを叩きます。じつはこのかねの音は、音階の"レ"に調音されていて、お経を唱えだすときの音程調整に使われます。浄土真宗トリビアでした。本堂からは以上です。 お寺の後継ぎを人に相談すると、周りの大人は口をそろえて、後を継いだ方が良いよと言いました。そのころは子供だったのでみんなが言うことを真に受けてしまい、みんなが勧めるくらい人気なら他の誰かがなるだろうと思い、安心してお寺を継がずに他の道に進むことにしました。お寺を継がないと決めたの
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という翻訳の仕組み1はフリーソフトウェアではよく使われています。いくつか不便な点はありますが、長年使われている仕組みでツールが揃っていることが理由でしょう。不便な点の1つである、「バージョン管理システムとの相性の悪さ」を解消する案が浮かんだので紹介します。 どうしてバージョン管理システムと相性が悪いか gettextでは.poファイルに翻訳したテキストを書きます。翻訳したテキストは自動生成ではない情報なのでバージョン管理対象です。ということで、.poファイルはリポジトリーに入れます。 バージョン管理システムと相性が悪い原因は、.poファイルに翻訳したテキスト以外のいろいろな情報が入っていることです。中でも、「どこに翻訳対象のメッセージがあったか」は自動生成できる情報で、量も多く、通常であればバージョン管理しない情報です。しかし、バージョン管理したい.poファイルの中に含まれて
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勉強中です。 以下自分用のメモです。 マージでコンフリクトした際に、実際に相違点を見て 手動でマージするのが普通ですが、場合によっては どちらかのブランチの内容を全適用したいときがあります。 バイナリファイルの場合とかがそうですね。 今まで （というか今日まで） バイナリファイルでコンフリクトしたら やり方がわかってなくてオロオロしてました。で、Git使いこなしてらっしゃる 方々のページで勉強。情報を公開してくださっている方に感謝 m(_ _)m Gitでマージしたバイナリファイルがconflictした場合の解決策 http://blog.digital-squad.net/article/151034635.html マージでバイナリファイルがコンフリクトした場合のGitの動作と対処方法 http://blog.ruedap.com/entry/20110720/git_
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
