タグ

Gitに関するsyuu256のブックマーク (111)

  • Git for Data「Dolt」というDBの話

    ここ最近、何やらデータベースの相談をされることが何やら多くなってきたmasamikiです。 今、とあるプロダクトの開発をしようと、要件まとめたり設計したりたりしてるのですが、この仕組みをやるためには…version管理いるなぁ…gitが欲しいなぁ……となってます。 そして、調べてみたところ、2年も前のものですがこんな記事を見つけました。 「DoltとDoltHubが我々の結論だ」とおっしゃってます。 Doltとは Doltは、Gitリポジトリと同じように、フォーク、クローン作成、ブランチ、マージ、プッシュ、プルできる最初で唯一のSQLデータベースです。(← by Google翻訳) おぉ、まさしく、そのままんま、これだ。 他にも、GitRows とかも使えそうかな…と思ってみていたものの、どうやら今の要件にあうのあはDoltっぽそう。 上記事だと、他にもdata.world(Microso

    Git for Data「Dolt」というDBの話
  • gitの10周年を記念したLinus Torvalsへのインタビューの翻訳

    10 Years of Git: An Interview with Git Creator Linus Torvalds | Linux.com gitの10週年を記念して、リーナス・トーバルズがインタビューに答えている。以下はその翻訳である。 なぜGitを作ったのか? トーバルズ:俺はソース管理ツールなんて作りたくなかったし、コンピューターの業界において最も興味がないものだと見なしていた(データベースは別だが)。それにソース管理ツールなんてどれも嫌いだった。しかし、BitKeeperがやってきてからというもの、ソース管理に対する見方が変わったね。BitKeeperは大抵のことを正しく行っていた。レポジトリのローカルコピーがあることと、分散マージはでかかった。分散ソース管理の何がいいかというと、ソース管理ツールの問題を吹っ飛ばせることだ。「誰が変更を行えるか」といった政治問題があるが、B

  • Git誕生10周年を記念した開発者のリーナス・トーバルズ氏のインタビュー

    プログラム開発の現場などで、ソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムとして用いられているGitは、2015年4月で誕生から10年を迎えました。この節目を記念し、Gitの生みの親であり、オープンソースOSの代表格であるLinuxの開発者でもあるリーナス・トーバルズ氏のインタビューが実施されています。 10 Years of Git: An Interview with Git Creator Linus Torvalds | Linux.com http://www.linux.com/news/featured-blogs/185-jennifer-cloer/821541-10-years-of-git-an-interview-with-git-creator-linus-torvalds ◆Git開発に至った経緯 Gitに関わる人の間ではよく知られ

    Git誕生10周年を記念した開発者のリーナス・トーバルズ氏のインタビュー
  • 図解 Git

    もし図の表示がおかしかったら、このページの SVGでないバージョンを試して下さい。 SVG の画像処理を中止しています。 (SVG の画像処理を再開) このページのオリジナルは、Mark Lodato さんが執筆した A Visual Git Referenceです。 このページでは、よく使われる git のコマンドを簡潔に図を用いて説明します。 git について少し知識があるなら、このページはその知識を整理するのに役立つかもしれません。このページがどのようにして作られたのか興味があるなら、私のGitHub リポジトリを見て下さい。(日語訳の GitHub リポジトリ) 内容 基的な使い方 凡例 コマンドの詳細 Diff Commit Checkout 分離HEADでの commit Reset Merge Cherry Pick Rebase 技術メモ 基的な使い方 上記4つのコマ

    syuu256
    syuu256 2014/08/21
  • 開発者(個人)のためのJenkins - Git Plugin編 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 「開発者(個人)のための」としているのは、別に自分でやっても良いんだけど Jenkins に任せられるなら任せたい、くらいのモチベーションを表現したつもりです。 環境 Ubuntu 14.04 LTS Jenkins 1.573 Bootstrap になって雰囲気が変わりましたね 初期設定 Jenkins 初期設定 Plugin のインストール Git Plugin 依存しているPluginも自動的にインストールされます。 Git Parameter Plugin は、ビルド時に Extended Choice Paramet

    開発者(個人)のためのJenkins - Git Plugin編 - Qiita
  • Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記

    誰でも知っていることだけど、LinuxというOSというかカーネルはLinus Torvaldsが学生のときに趣味で作ったのがはじまりだ。それは1991年ころの話で彼が21歳の頃だ。個人の趣味で作ったものが、いつの間にかに世界中のコンピュータだけでなく、携帯や家電や様々な機械の制御に使われている。 Linus Torvalds - Wikipedia 1994年ころには、PCで動く個人向けOSとしては十分な機能を持っていた。Xもあるし、gccなどのコンパイラもあるし、GNU Emacsやbashもあるので、ちょっとしたプログラムを作るには十分な機能を持っていた。 当時、勤め先のマシンはSunのワークステーションで仕事Linuxを使う機会は全然なかったのだけど、自宅のPCSlackwareのCDを入れてみたりした。日常的に使うことはなかったけど、1998年にOracleLinux版を出し

    Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記
  • とうとう Git 2.0 が現実のものに。便利な機能満載 | Atlassian Japan 公式ブログ | アトラシアン株式会社

    長い間待たれてきた git のメジャーバージョンアップがリリースされました。Changelog に目を通し、素晴らしい機能を見つけられることに興奮しています。過去の git リリースの情報をおさらいしたい場合は、バージョンアップのたびにその情報を特集してきた私の過去記事をご覧ください: 1.8.2、1.8.3、1.8.4、1.8.5、1.9。 このブログ記事では、今回のバージョンアップの一部しか取り扱うことしかできません。変更とバグ修正の完全リストをご希望の場合は、Changelog の完全版をご覧ください。 デフォルト設定一部変更: ユーザビリティの改善と混乱を解消 まず最初に、互換性に影響する変更を見ていきましょう。複数の変更がありますが、これらのアップデートは、初心者にとどまらず多くの人々を悩ませてきた誤解を解決するもので歓迎できると思います。これらの変更は、.gitconfig を

    とうとう Git 2.0 が現実のものに。便利な機能満載 | Atlassian Japan 公式ブログ | アトラシアン株式会社
    syuu256
    syuu256 2014/06/09
  • Git の仕組み (1) - こせきの技術日記

    目次 はじめに Git を使ったことがない方へ 生のデータが見たい方へ Git の全体像 .git の中身 Git オブジェクトデータベース 4種類のオブジェクト リファレンス リファレンスのリファレンス 大きなツリー Git オブジェクトの ID と 中身 ハッシュ関数 SHA1 の簡単な説明 tree と blob オブジェクト tree と blob の参照関係 ルートツリーの ID でツリー全体を識別する commit オブジェクト リファレンスとブランチランチランチ先頭を指すリファレンス HEAD リファレンス detached HEAD 2種類のタグ 一時待避 (stash) インデックス キャッシュとしての役割 マージ Fast-Forward マージ non Fast-Forward マージ rebase reset 2種類のブランチ 各リポジトリが自分のブランチ

    Git の仕組み (1) - こせきの技術日記
    syuu256
    syuu256 2014/06/09
  • develop ブランチなんてオワコン

    Yosuke Furukawa @yosuke_furukawa @sonots masterは絶対に安定して動作させたいとかそういう思想だよね。developブランチ、 develop で安定してきたらmasterにmergeするって思想だけど、僕も最近作ってない… 2014-05-30 11:16:02 そのっつ (Naotoshi Seo) @sonots @yosuke_furukawa master ブランチが絶対安定してるなら、今度は release ブランチいらない感ある。で、どちらかというと release ブランチを安定させて master ブランチで開発すれば良い。そのほうが github とも親和性高い感ある。 2014-05-30 11:38:51

    develop ブランチなんてオワコン
  • SourceTreeの使い方 - 初心者が習得すべき基本操作(diff, stash, tag, revert, cherry-pick) - ICS MEDIA

    SourceTreeの使い方 - 初心者が習得すべき基操作(diff, stash, tag, revert, cherry-pick) GitクライアントのSourceTreeソースツリーは無料で使えるGitアプリケーションとして人気があります。「SourceTreeの基的な使い方はバッチリ! だけど、まだまだ使っていない機能があるなぁ」なんて人も多いのではないでしょうか? そんな人へオススメの知っておくと便利な機能を5つ紹介します。 ※記事は2024年4月現在のmacOS 14.4.1、SourceTree 4.2.7で解説しています。Windows版のSourceTreeでも同じ手順で利用できます。 はじめに - SourceTreeとは? SourceTreeはGit / MercurialのGUIクライアントで、Atlassian社から無償で提供されています。Windows

    SourceTreeの使い方 - 初心者が習得すべき基本操作(diff, stash, tag, revert, cherry-pick) - ICS MEDIA
  • 巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社

    git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか? この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴

    巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社
    syuu256
    syuu256 2014/05/28
  • GitHub を用いた開発フロー テンプレート - ペパボテックブログ

    Development (開発の進め方) GitHub Flow の利用 レビューの実施 Testing (テスト) Deployment (リリースの仕方) Releases (リリース後の記録) References(参考文献) Appendix(付録) Release's notes の作成方法 History(更新履歴) 2014/03/15 Development (開発の進め方) GitHub Flow の利用 masterブランチは常にデプロイ可能な状態としなければならない テストが失敗する状態の場合、直ちに修正するべきである テストが失敗する状態の場合、デプロイすることは許されない 「新しい何か」に取り組む際は、 pull request を用いるべきである ブランチは master から作成し、ブランチ名は説明的な名前とすべきである(例: new-oauth2-scope

    GitHub を用いた開発フロー テンプレート - ペパボテックブログ
  • チーム開発においてGit初心者が踏みがちな地雷まとめ|TechRacho by BPS株式会社

    morimorihogeです。残暑やばい。 ※元々は2014年に書いた記事ですが、2020年になっていろいろと事情も変わっているので2020年revise版として更新しました。 弊社ではバージョン管理システムにGitを使っています。 数ヶ月以上一緒にやっているある程度ツーカーなメンバーだけのプロジェクトなら問題無いのですが、案件によっては協力会社の方が一時的にJOINしたり、新規参入メンバーの参加などで、これまでGitを使ったことがない、または格的なチーム開発でGitを使ったことがない人が参加することもあります。 ※2020年現在では流石に全くGitを使ったことのない開発者というのはほぼ見なくなりましたが、チーム開発できちんと運用に乗せて使ったことがない、という所は今でもそこそこあるようです。 Gitは自由度の高いシステムですが、その分概念を覚えることが必要なため、導入の敷居が高い方だと

    チーム開発においてGit初心者が踏みがちな地雷まとめ|TechRacho by BPS株式会社
  • LINE Serverの開発とリリースプロセス « LINE Engineers' Blog

    皆さんお元気ですか?LINEサーバー開発室でサーバ開発を担当している崔珉秀と申します。 この記事ではLINEのサーバーの開発とリリースプロセスについて述べたいと思います。 LINEの開発者はどんな形で開発しているのか、サービスに変更事項をどのように適用しているのか、お互い協力してより良い開発環境を得るためにどんな努力をしているのかをお伝えする機会になったらいいなと思います。 ここで述べるリリースプロセスは、LINEのサーバ開発の流れとソース管理システムの運用方法、そして番環境に変更事項を適用するまでの過程です。 LINEのServer Applicationはその役割とシステムの構成によって複数のServer Applicationに分かれて構成されています。 例えばNetwork通信及びProtocolなどを担当するApplication、messagingやsocial graph

    LINE Serverの開発とリリースプロセス « LINE Engineers' Blog
  • GitHub - gitbucket/gitbucket: A Git platform powered by Scala with easy installation, high extensibility & GitHub API compatibility

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - gitbucket/gitbucket: A Git platform powered by Scala with easy installation, high extensibility & GitHub API compatibility
  • Git作業スタイル: リモートレポジトリに保存しつつキリのいいところで変更をまとめる - Qiita

    あらまし 大きな作業をする場合、こまめにローカルレポジトリのブランチにコミットして、何かあったときにすぐに戻せるようにしたくなります。 また、パフォーマンス改善など、実験や研究の色合いの強い作業は、試行錯誤しながらブランチに"とりあえず"保存しつつ、「あっちのほうが良かったかな〜」と思ったときに取り出せるようにしておきたくなるものです。 また、ローカルレポジトリだけでなく、リモートレポジトリに置いたほうがチームみんなで共有できたりしていろいろ便利です。 ですが、最終成果物はなるべく少ないコミットにしないと、マージが大変です。 メインブランチにこんなコミットが入るとゲンナリしますよね? $ git log --oneline bcdef12 Revert foo abcdef0 Add foo cdef123 Refactor bar again def1234 Refactor bar e

    Git作業スタイル: リモートレポジトリに保存しつつキリのいいところで変更をまとめる - Qiita
  • もうFTPを利用することは止めて、Gitを使おう。そのほうがメリットが多いよー

    もうFTPを利用することは止めて、Gitを使おう。そのほうがメリットが多いよー 2014.02.26 | この方法お勧めです! | 覚えておきたい どもどもパープルことメガネこと大串です。 最近なにかと涙もろくなりまして、ちょっと身近な人のBlogとか読むだけでも熱いものがこみ上げたりしています。こういうことって今後も増えていくんでしょうね。母親がやたらめったらテレビに向かって泣いていたのも頷ける今日このごろです。 さてGitHubシリーズですね。前回は GitHubをつかって共同開発! サイトのデザインリニューアルしました !という記事を書きました。もちろん今も共同開発は続いておりまして、次のマイルストーンは月末を予定しております。達成率は25%ですが、なんとなかるでしょう。。。たぶん。。おそらく。 そしてきょうの題ですね。タイトルの通り、FTPをやめてgitでファイルの送信受信もして

    もうFTPを利用することは止めて、Gitを使おう。そのほうがメリットが多いよー
  • tigでgitをもっと便利に! addやcommitも - Qiita

    皆さん、tigコマンドを活用していますか? tigは、コンソール上で使えるgitブラウザです。実はずっと、ただのきれいなgit logだと思っていたのですが、当はそんなことはありません。かなり使えるやつなのです。 インストール ソースコード: https://github.com/jonas/tig インストール方法: https://github.com/jonas/tig/blob/master/INSTALL.adoc この辺りを参考にしてみてください。詳細は割愛します。 基の使い方 この状態の差分を扱っていきます。いつものこれだとこんな感じ。 git logが素敵にビジュアライズされてます。この画面をmain viewといいます。 ここでエンターを押すと、下半分に差分の詳細(diff view)が表示されます。 下矢印で、Unstaged changesの差分を見てみるとこんな

    tigでgitをもっと便利に! addやcommitも - Qiita
  • gitoriousのDockerfileあったのでbuildしてみた - Qiita

    OSSのGithubクローン、gitoriousがDockerfile形式でイメージを配ってたので試しにbuildしてみました。 https://gitorious.org/gitorious/gitorious-docker/source/799c49967663e0c379fc1b4089a2eb8fb7ceb072: やったこと Dockerの使える環境を用意してあること前提で書いてきます。 インストールなどは公式ドキュメント参照してください。 https://www.docker.io/gettingstarted/ $ git clone https://git.gitorious.org/gitorious/gitorious-docker.git $ cd gitorious-docker $ docker build -t gitorious/gitorious . $ .

    gitoriousのDockerfileあったのでbuildしてみた - Qiita
  • 分散バージョン管理システム「Git 1.9」が公開 | OSDN Magazine

    分散型バージョン管理システム「Git」の開発チームは2月14日、最新版となる「Git 1.9.0」を公開した。多くのサブコマンドが追加されるなど、多数の機能強化が行われている。 Git 1.9.0は2012年10月に公開されたバージョン1.8系に続くアップデートとなる。バージョンでは多くの機能が追加されており、一部後方互換性のない機能変更も行われている。 大きな変更点としては、HTTP経由でのトランスポートでGSS-Negotiate認証利用時に「100 Continue」メッセージを利用するように変更された点がある。これにより大規模なペイロードの再送を避けられるとしている。サブシステムではremote-bzr、remote-hgのバグを修正し、git q4、git svn、gitkも更新した。 ワークフローやUI関連では、従来は行えなかったshallowクローンで作成されたレポジトリか

    分散バージョン管理システム「Git 1.9」が公開 | OSDN Magazine
    syuu256
    syuu256 2014/02/17