タグ

gitに関するnaruogaのブックマーク (11)

  • 第406回 Node.js製のGitBookでお手軽に電子書籍作成 | gihyo.jp

    GitBookはMarkdownで記述しGitで管理しているドキュメントを、簡単にHTMLPDF、EPUB、MOBIなどで公開できるサービスです。今回はこのGitBookで使われているgitbookコマンドを用いて、Ubuntu上でドキュメントを生成する方法を紹介します。 今風な文書執筆・公開環境としてのGitBook 人類の進化は文書の作成と共にあります。より良い文書の存在が、質の高い教育、確実な情報の伝達、技術文化の進歩を導いてきました。連載が掲載されているgihyo.jpでも、今年の新春特別企画に「ドキュメントの構造化による、良いドキュメントの作成方法」が掲載され注目を集めているように、いかにより良い文書をよりお手軽に作成できないか苦心されている方も多いことでしょう。 今回紹介する「GitBook」は、技術者であれば使っている人が多いであろう「Git」と「Markdown」を使

    第406回 Node.js製のGitBookでお手軽に電子書籍作成 | gihyo.jp
    naruoga
    naruoga 2016/02/07
    この記事を見ながら今書きかけの原稿をLibreOffice Writerからgitbookに移行した。説明が丁寧で神
  • OSTree: OSイメージとパッケージシステムの間にGitのアプローチを

    May 23, 201426 likes10,179 viewsAI-enhanced description This document discusses OSTree, a system for deploying and managing operating system updates using Git-like technologies. It describes how OSTree works with Linux distributions and containers to provide atomic operating system updates using technologies like Git, Docker, and chroot. OSTree aims to provide fast, reliable operating system updat

    OSTree: OSイメージとパッケージシステムの間にGitのアプローチを
    naruoga
    naruoga 2015/04/13
    ぼくはものを知らないなあ。お仕事の関係で手元で環境作って色々試す的なことが増えそうなので、こういうアプローチは引き出しにたくさん入れといたほうがいい気がした
  • カーネルハッカー・小崎資広の「コードを読む技術」 | サイボウズ式

    サイボウズ・ラボの西尾 泰和さんが「エンジニアの学び方」について探求していく連載の第2回(毎週火曜日に掲載、これまでの連載一覧)。「WEB+DB PRESS Vol.80」(2014年4月24日発売)に執筆した「エンジニアの学び方──効率的に知識を得て,成果に結び付ける」の続編です。(編集部) 文:西尾 泰和 イラスト:歌工房 この連載では「エンジニアの学び方」をテーマにインタビューを行い、どういう「学び方」をしているのか探求していきたいと思っています。第1弾は、富士通エンジニアとしてLinuxカーネルの開発に参加されている小崎資広さんです。 Linuxカーネルは、ソースファイルだけで3万5000個以上、行数にして1500万行を超える、巨大ソフトウェアです。小崎さんが、どうやってこの巨大なソースコードと戦っているかは、きっと「エンジニアの学び方」の参考になるはずです。

    カーネルハッカー・小崎資広の「コードを読む技術」 | サイボウズ式
    naruoga
    naruoga 2014/08/12
    gitのログからコード追っていくというのは翻訳のための変更箇所を探すためにやってたけど通常のコードリーディングにも使えるのかあたりまえだな。LibreOfficeのコード読む参考にしよう
  • テストファーストなGitワークフローについて - kazuhoのメモ置き場

    Gitのワークフローに関する話題が、また盛り上がっているようなので、僕が好んで使っているワークフローについて書きます。 対象としているソフトウェアは、GitHubGitHub Enterprise等を使って開発されている、リリースブランチを切らずにmasterにリリースタグを打っていくだけで十分な程度の、ウェブサービス(の部品)やオープンソースプロジェクトです。 まず、以下の2点を原則として考えています。 origin masterを壊さない origin masterの(1st parentをたどるツリー)にテストを通らないcommitを入れないよう努めます 変更の主題を常に明確にする 前者の理由は、masterをいつでもリリース可能な品質に保つためと(←12:44追記)git bisectするときに困らないようにするため。そして、これらの原則から、以下のようなワークフローで作業するこ

    テストファーストなGitワークフローについて - kazuhoのメモ置き場
    naruoga
    naruoga 2014/02/04
    ぼくの周りはテストファーストとはいってないみたいだけど、これはシンプルでわかりやすいルールだな。ふむふむ。
  • git-flowでもgithub flowでもない、Git本家推奨のワークフロー

    このドキュメントは git.git (訳注: Gitプロジェクトのgitリポジトリ) それ自身で使われているワークフローの要素を書きとめ、 それを使いたいと思わせることを意図しています。 多くのアイデアが一般に適用できますが、 より少人数が参加する小さなプロジェクトで 完全なワークフローを必要とするのは稀です。 私たちはクイックリファレンスのためにひとまとまりの ルール をとりまとめ、 文章でそれぞれのルールへの動機を与えます。 言葉通りにとらないようにしてください; 重視すべきなのは、この文書のようなmanページの記述よりも あなたがそうすべき理由の方です。

    naruoga
    naruoga 2014/02/04
    とても実務的でよいワークフローだと思った。まあ、自分の現場がこれでがっちりやれるかどうかというと、また別なんだけど、指標としてはね。
  • 覚え書き。 文字化けしない Msys Git 導入法

    なぜか2バイト文字ガン無視で作られたGitちゃん。そんなGitWindows環境で使うと、簡単に文字化けする。そこをなんとか、ようやく日語に対応しつつあるMsysGitを使って文字化けしないように導入する方法をどうぞ。 MsysGitは最近(2012年現在)、ようやくUTF-8(UTF-8N)環境に対応したと謳っているWindows向けのGitクライアント。自分はこのMsysGitでGitを使っている。だが実際、使ってみると文字化けしたので、ちょっと工夫が必要なよう。また前提として、ファイル名はMS932、中身はUTF-8で書くとする。 MsysGitを入れる まずは普通にMsysGitを入れる。ここのDownloadから「Git-1.7.XX-previewXXXXXXXX.exe」とかをダウンロードして、実行しよう。 インストール中に聞かれる設定項目はほとんどたいしたことないので、

    naruoga
    naruoga 2012/11/01
    おいらも勤め人だからWindows使わんといかんこともあるのですお……
  • gitで誤ったブランチに対して行った変更を正しいブランチへ移す(cherry-pick編) | Webシステム開発/教育ソリューションのタイムインターメディア

    gitでは様々な方法でコミットログを書き換えることができます。 その一例として誤ったブランチに対して行った変更を正しいブランチへ移す方法を紹介します。 問題 これまで「新機能Xを追加する」という設定で以下のトピックについて解説していました: gitでコミットの順序を入れ替えるgitで複数のコミットを1つにまとめるgitで1つのコミットを複数のコミットに分割する これにはまず としてこの作業用のトピックブランチを作成してそちらで作業を行うのが普通です。 しかし git branch を実行したところで安心してしまい、 git checkout を忘れて全く違うブランチで作業を行ってしまう というミスは時々やってしまいます (git checkout -b という方法もありますがここではそれも忘れていたとしましょう)。 例えば以下のような状況だったとしましょう: $ git branch ma

    gitで誤ったブランチに対して行った変更を正しいブランチへ移す(cherry-pick編) | Webシステム開発/教育ソリューションのタイムインターメディア
    naruoga
    naruoga 2012/10/30
    cherry-pickは最近ようやっと使い方を覚えてきたけど、こないだ操作ミスってひどい目にあったので……
  • git reset についてもまとめてみる - murankの日記

    前回 git diff を図に書いてみたところ、自分の中で意外と整理できたので、これまたなんとなく使っていた git reset についてもまとめてみた。 とりあえず結論を先にまとめよう。 git reset とは? HEAD の位置を変更するコマンド。 オプションによってインデックス、ワーキングツリーの内容も変更できる。 git reset のオプションは? --soft、--mixed(オプションなしと同等)、--hard オプションがあり、影響度の小さい順に以下のようになる。 --soft HEAD の位置のみを変更する。インデックス、ワーキングツリーには影響なし。 --mixed (またはオプションなし) HEAD の位置とインデックスを変更する。ワーキングツリーには影響なし。 --hard HEADの位置、インデックス、ワーキングツリーをすべて変更する。 さて、git reset

    git reset についてもまとめてみる - murankの日記
    naruoga
    naruoga 2012/10/30
    git resetもなー、ただ戻るだけならピンとくるんだけど、あたまごちゃごちゃになるのでまとめを保存しておくなり
  • Gitを使いこなすための20のコマンド | OSDN Magazine

    LinuxカーネルやRuby on RailsPerlなど、近年多くの大規模プロジェクトで採用されているバージョン管理システムが「Git」だ。Gitには非常に多数のコマンドが用意されているが、日常的に使用するコマンドは20個程度と言われている。記事では、Gitを使いこなすために覚えるべき20個のGitコマンドを紹介する。 LinuxカーネルやRuby on RailsPerlなど、近年多くの大規模プロジェクトで採用されているバージョン管理システムが「Git」だ。Gitには非常に多数のコマンドが用意されているが、日常的に使用するコマンドは20個程度と言われている。記事では、Gitを使いこなすために覚えるべき20個のGitコマンドを紹介する。 なお、Gitの基的な考え方や使い方については分散バージョン管理システムGit入門でも紹介しているので、そちらも参照してほしい。

    Gitを使いこなすための20のコマンド | OSDN Magazine
    naruoga
    naruoga 2012/10/30
    基本は基本なんだけどねー、revertとかshow-branchとかあんまり使わないからなあ。まあ、習うより慣れろなんだけど
  • git/コミットログを修正する方法 - TOBY SOFT wiki

    はじめに † gitでコミットログを修正したいです。 Redmineとかで、refs #10とかcloses #10とかつけるとコミットログにチケットを関連付けられますが、これがよく書き忘れるんですね…。 直前のコミットログを修正する方法あるみたいです。 直前のコミットログ以外も修正する方法はないのかな…。 (Subversionだとhookスクリプトで許可できますよね。分散型だとやっぱり無理?) ↑ 直前のコミットログを修正する方法 † 直前のコミットログの修正は"git commit --amend" でよいみたいです。 例えば、 $ git commit -m "fixed xxx bug" : # コミット完了! # あ!しまった!"refs #(チケット番号)"つけるの忘れてた! # (私が使うプロジェクト管理ツールRedmineではrefs #13 のようにすると # コミット

    naruoga
    naruoga 2012/10/30
    ぼく粗忽だかんねー。git rebase は毎回使い方忘れてググってるので、ブクマしとくことにした
  • 1