執筆・編集のためのGit（GitHub）ワークフローを考えてみた
まとまった量の文章を執筆・編集するのにバージョン管理システムを使うことは、少なくとも技術文書においては特別なことではなくなりました。 原稿が汎用のテキストファイルの場合には、バージョン管理システムとして、GitやMercurialなどのソフトウェア開発用のツールを使いたいことが多いと思います。 実際、GitHubやGitBucketを利用して技術書やドキュメントの原稿を共同執筆するという話はとてもよく聞きます（知っている世間が狭いだけかもしれないけど）。 とはいえ文章の執筆・編集という作業には、プログラムのソースコードを開発する作業とは違う側面もいっぱいあります。 そのため、ツールとしてはソフトウェア開発用のバージョン管理システムを利用する場合であっても、そのワークフローについては、執筆・編集ならではの工夫が多少は必要なのかなと考えています。 もちろん、同じソフトウェア開発でもプロジェクト
gitk クローンみたいな Vim プラグイン作った - Qiita
agit.vim 上のスクリーンショットのように、Git のログ、カーソル位置のコミットで変更されたファイル一覧、ファイルの差分が1画面で見れます。 agit.vim 同様のプラグインに gitv というのもあります。僕も何度かブログで紹介しています。 vim で gitk 的なことを行う gitv が便利 tig なんて目じゃない！ Git のログ系 Vim プラグイン gitv ＆ gitv をGit 統合インターフェース化する最強の設定 gitv でも大変便利なのですが、僕にとってはいろいろ不満がありました。 具体例を挙げると なんかもっさりしている。とくに Windows で マルチバイト文字の扱い 変更されたファイル一覧だけ見たいのに見れない (folding でなんとかするしかない) Pull Req を送ろうにも、ソースが汚いのと fugitive に強く依存しているので修正
The Git Parable
The Git Parable 19 May 2009 - San Francisco Git is a simple, but extremely powerful system. Most people try to teach Git by demonstrating a few dozen commands and then yelling “tadaaaaa.” I believe this method is flawed. Such a treatment may leave you with the ability to use Git to perform simple tasks, but the Git commands will still feel like magical incantations. Doing anything out of the ordin
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - kmnk/vim-unite-giti: unite source for using git
Git - git-rev-parse Documentation
