Gitで日本語長文のdiffをとる方法 - Qiita
（この記事はここからの転載です） 課題 日本語の長文をgitで管理していると、ほんのちょっとの変更でもdiffでは行丸ごと変更されたことになり、変更点がよくわからないことがある。 二泊三日で小説を書く過激なイベントNovelJam 2018参加作品である高橋文樹氏の「オートマティック クリミナル」は、GitHubを使って執筆されている。小説では、git diffの欠点がはっきりでる。高橋氏は参加レポートで、こう書いている。 あと、今回得た重要な知見なのですが、Githubではある程度以上テキストが長くなってくると、数文字の調整で全部差分として判定されたりするので、小説には向いてないかなーと思いました。小説は行の移動とかがよく発生するので、GithubじゃなくてGitとの相性かもしれません。 普通にdiffを取る 確かに、普通にdiffをとるとその通り。コマンドラインで「オートマティック ク
Gitをバックエンドにしたタスク管理bot
Gitをバックエンドにしたタスク管理bot posted at 2017-12-04 00:00:10 +0900 by kinoppyd この記事は、ドワンゴ Advent Calendar 2017 の4日目の記事です。 TL; DR すごい簡単なゆるいタスク管理のバックエンドに、内容アドレスファイルシステムとしてのGit使うのもまあいいんじゃないの？ とおもってGemを作った。 ゆるいタスク管理システムが必要だった 通常、仕事のタスク管理はJIRAとかRedmineとかGithubとかTorelloとかなんかそういう専用のやつを使うと思います。とはいえ、「もう今日は帰ってるけど、明日こののプルリク見てください」とかSlackで伝えたり、「このプルリクレビュー通ってるんで、明日マージしといて」とかSlackで伝えたり、その程度のことをチケットにするのも妙な感じです。デイリーミーティング
Gitでコメントを無視して差分を見る - tmtms のメモ
古いRubyのコードのコメントを独自のRDoc形式からYARD形式に変換して、さらにその後にプログラムを変更したんですが、その後に差分を見ると大量のコメントの差分が表示されて、実際のコードの差分が何かわからなくなったりしたので、コメントを無視して差分を取る方法を調べてみました。 普通にgit diffするとこんな感じ: diff --git a/hoge.rb b/hoge.rb index 8fa6659..0561977 100644 --- a/hoge.rb +++ b/hoge.rb @@ -1,8 +1,8 @@ -# == ほげクラス +# ほげクラス class Hoge - # === ほげ - # +str+ 何か + # ほげ + # @param str [String] 何か def hoge(str) - 123 + 456 end end プログラムとしての変
コミットメッセージの書き方
コミットメッセージにはどのような情報を残すべきだろうか？はじめにこの記事ではGitのコミットメッセージの重要性と良いコミットメッセージの書き方を説明します。いままで良いコミットメッセージについて考えてこなかったかたも一度立ち止まって考えてみてくれると嬉しいです。 対象読者GitやGitHubを業務で使っている人「良いコミットメッセージ」をあまり意識しない人目次Gitを使ったソフトウェア開発で、なぜコミットメッセージが重要なのか？コミットメッセージの書き方の1例を紹介まとめGitを使ったソフトウェア開発で、なぜコミットメッセージが重要なのか？ソフトウェア開発において、良いコードとはどんなコードでしょうか？ 私は「 他人が読みやすく、理解しやすいコード」だと考えています。ソフトウェアにバグは必ず出ます。そのバグを修正する時間を最短にできるような、読みやすい、理解しやすいコードが良いコードだと思
俺のオレオレgit-flow | おそらくはそれさえも平凡な日々
背景 一昨年末くらいにgit-flowを採用していた 良いんだけど、結構めんどくさいなーと思うところがあった 去年頭の新規開発からはgithub-flowを採用(と言うかごく普通のGit運用) masterのテスト通ったらjenkinsさんが開発サーバー反映してくれて捗る ただ本番をそれで運用するわけにもいかない リリースタイミングとかある masterはデザイナーやME(=gitに不慣れな人たち)がカジュアルに画像やテンプレをpushできる(それで構わない) git-flowとgithub-flowの中間くらいのフローで運用することに git-flowの気に入ってる点とそうじゃない点 気に入っている点 並列ブランチを走らせるというのは良い(git-flowの場合、masterとdevelop) hotfixが便利 めんどくさい所 releaseブランチ毎回作る必要性をあまり感じない バー
広島Git勉強会 201306 - やりなおせるGit入門 - そんなこと覚えてない
広島Git勉強会 に参加しました。 1セッション喋りました。 はじめからgit reset と git checkoutあたりを説明しようと思ってたのですが、「元に戻せること」を主眼においていろいろ考えました。 結果として、「危険」「少し危険」なコマンドを定義して、よくわからない時どうすればいいのか伝えられるか試みてみました。 「危険」なコマンドはワークツリーにした変更が消えてしまう恐れがあるもの。 「少し危険」なコマンドはgit reflogなどを利用しないと追えなくなるコミットができてしまうもの。 と定義して、そこを強調しながら説明してみました。 スライドはこちらに。 結局、難しかったのか簡単だったのか、周りの空気を読む余裕が僕にはまだまだ足りなくて、「経験値を積まないといけないなぁ」と、思うのでした。 追記 ブクマのコメントなどなどに返信 「git commit の -m はそろそろ
「こわくない Git」というスライドを発表しました - kotas.tech
社内向けに「こわくない Git」というタイトルのスライドを作って発表しました。 対象者は「マージがなんとなく怖い」「エラーが怖い」「リベース使うなって言われて怖い」と、Git が怖いと思っている人です！ こわくない Git from Kota Saito 発表中に出た質問など 補足も兼ねて、上のスライドを発表した際に出た質疑応答などをここに書いておきます。 Q: 常に Non Fast-Forward (--no-ff) でいいのでは、と思えるけど git merge がデフォルトだと Fast-Foward or Non Fast-Forward (--ff) なのはなぜ？ A1: Non Fast-Forward だと、確かにメリットが多いのですが、1点だけデメリットがあります。特に差分が無い状態で git merge --no-ff すると、空のマージコミットが作られてしまうのです。
Gem-src - masarakki's blog
gem-src がすごく便利。 よくあるパターン 1. gemのソースコードを読みたい時 gemを使ってるとソースをがっつり追いたくなる時がありますが、そんな時どうしてますか? 最近編み出したのが、とりあえずインストールされたgemをgitに突っ込むというワザです。 rvmを使っているのでこんな感じに。 $ cd ~/.rvm/gems/ruby-1.9.4-p194@hoge/gems/hoge_gem $ git init; git add . $ git grep hogehoge これでも十分に便利ですけど、gemのディレクトリまで行くのが面倒ですよねー。 2. gemに Pull Request したい時 gemの名前は知っていても誰が作ったかなんて覚えてませんよね。 hubコマンドもユーザ名がわからないと使えません。 (なぜか hub clone rails はできるんだけどな
【翻訳】Gitをボトムアップから理解する
John Wiegleyさんの "Git from the bottom up" を翻訳しました。 元PDFはこちらからダウンロードできます： http://newartisans.com/2008/04/git-from-the-bottom-up/ 元記事のライセンスがクリエイティブコモンズのBY-SAであったため、この翻訳もBY-SAとなります。 ライセンスを守って自由にご利用ください。（詳しくは記事内の最初にも書いてあります） 翻訳ミスの指摘や改善の提案等があればブログコメントやTwitter(@oshow)などで遠慮なくどうぞ。 Git をボトムアップから理解する Wed, 2 Dec 2009 by John Wiegley 私が Git を理解しようと調査した時、高級なコマンドの視点から眺めるよりボトムアップ式に理解することが役立った。そしてボトムアップ視点で見る Git が
subversionを使っていた人がgit便利だなと感じたこと - (ﾟ∀ﾟ)o彡 sasata299's blog
2009年05月25日05:42 Git subversionを使っていた人がgit便利だなと感じたこと 最近は subversion も使いますが、git を使うことも多くなってきました。モジュールの配布なども git のものが多くなってきて、そろそろ git を使えるようになっておかないとまずい気が・・。ってことでちょっと勉強してみたのでまとめてみます。 そもそも「 subversion と git は何が違うの？」っていう話ですが、主な違いは以下の通りです。【参考】に挙げたサイトが分かり易いと思います。 subversion ・単一リポジトリ（リポジトリは一つだけ） ・commit したら即反映 ・add するのは新規にファイルを追加するときだけ ・リビジョン番号は数字 ・考えるのは『ローカル（ checkout した場所）』と『リポジトリ』の2つだけ git ・分散リポジトリ（マス
A successful Git branching model を翻訳しました
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら： http://nvie.com/posts/a-successful-git-branching-model/ （翻訳の公開と画像の利用は本人より許諾済みです） このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
イラストでわかる！git入門の入門
こんにちは、アシアルの志田です。 社内でもgitが浸透し、皆バージョン管理といえばgitだよね、という空気になってきました。 ですが、これまでバージョン管理システムを使ったことがない人にオススメしても、 「gitて…まあ…そりゃ…ねえ、いつかやらないといけないけど…」 「ギット？ジット？俺はgiはジと読む派なので、gitは胡散臭いと思う」 「そもそもバージョン管理して何が嬉しいの？なんか難しそうでいやだ」 というような反応ばかりでした。 きっとみんな、gitって難しくて訳のわからんもんだと思っているのでは？と思い、 今回はgit入門の入門、gitってなんだ？というところから、簡単にgitを使う際の流れについてご説明します。 ちょっと不安を覚えるようなイラストがついていますので、頑張って読んでください。 バージョン管理ってなに？ プログラムを書いていて、こんなことありませんか？私はあります…
homebrewアップデート/アンインストール - CROSS HOPE
homebrewを使っていて、ちょっとわからなかったことや覚えておくと良いコマンドをまとめてみました。 もしかして、みなさん知っている情報だったらすみません…。 homebrewのヘルプは brew -h で見られるのだけど、マニュアルは brew man ではなくて man brew。…いつまで経ってもマニュアル見られないわけですね。 homebrewのアップデート homebrewそのものが更新された場合や、Formulaが追加・変更された場合に実行するコマンドはこちら。 ときどき実行すると良いかもしれません。更新されていた場合はgithubからインストールされます。 $ brew update (追記 2011-08-04)「エラーが出ちゃった！」というときは。 上のコマンドを実行したら、エラーが出ちゃってあわわわわ！ そんなときは、以下のページを参考にしてみてください。 http:
はじめてgitをつかったのでコマンドを復習します
はじめに こんにちは川崎です。最近はじめてgitを使う機会がありましたので復習してみます。 このエントリーは私がgitを使い始めたばかりのログを元にして、まとめた内容にしています。 gitをインストール、コマンドを使う準備 gitを使うにはgitのインストールが必要です。使っている環境に合わせてgitをインストールします。 私の環境はmacなのでportsでインストールしました。 $ sudo port -d selfupdate $ sudo port install git-core +gitweb +svn インストールが完了したかどうかはgit --versionコマンドで確認できます。 $ git --version git version 1.7.3 gitのversionが表示されたのでインストールされているようです。準備完了です。 はじめてgitを使うときは gitを使うた
gitでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
知識ゼロから git を使えるようになるまで（Mac OS X にインストールする編）
知識ゼロから git を使えるようになるまで（Mac OS X にインストールする編） 2008年10月16日 00:28未分類 git をやってみたいなーと思いつつ なかなか手を出せてなかったんだけど、 きっかけがあったのでやってみることにした。 で、せっかくだから勉強しながらメモをとっておくことにした。 まとめながらの方がよく理解できると思うし あとからわからなくなったときに見直せるし 似たような環境の人の参考になるかもしれないし。 勉強しながらのメモなので 脱線したり表現が変だったりするのは気にしない方向で。 現状 これを書き始める時点で、 git についてほどんど知らない。 何か Subversion のようなもので、 分散リポジトリで、 かなり便利らしいということだけ。 git はともかく Mac についてもいかにわかってないか晒すことになるけど だから勉強するんですね。 今回の
git-svnの使い方を覚えた - idesaku blog
分散SCMを使いたい！と思う今日この頃。 仕事ではSVN（Subversion）を使っているのだが、ちょっとしたお試し編集をするためにブランチを作ることに抵抗がある。ブランチは欲しい、大きめな変更をコミット無しで行いたくない、やはり少しずつコミットして進めていきたい。しかし、変更が全て記録されてしまうのがいただけない。ログが残るのは良いことなのだが、本当に使うかどうか未知数な実験的プログラミングのログまで残したくない。使うと決まってから初めて残すようにしたいのだ。 すまん、これまで一緒に仕事をしてきた人々よ。俺はこれまで「ログが残って困ることがなんかある？いらなきゃ無視すればいいだけなんだから、気にするな。ブランチでもなんでもバンバン作ってしまえ！」とうそぶいてきているわけだが…ハッタリかましてました！本当は俺も抵抗があるのだ。 そこで、分散SCMだ。さらにいうと、SVKがいまひとつ気に入
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Code Archive - Long-term storage for Google Code Project Hosting.