(訳注：2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注：2015/11/1、いただいた翻訳フィードバックを元に記事を再修正いたしました。) 訳： プロジェクトが長引くほど、私のGitのコミットメッセージは情報が薄くなっていく。 イントロダクション | 7つのルール | ヒント イントロダクション：なぜ良いコミットメッセージを書くことが重要か Gitのリボジトリのログをランダムに閲覧すると、ひどいコミットメッセージを目にすることがあります。例として、私が昔書いたSpringにコミットした これらのgem を見てみましょう。 $ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009" e5f4b49 Re-adding ConfigurationPostProcessorTest
Gitは速く柔軟性がありますが、理解に時間のかかる分散型バージョン管理システムです。Gitを始める前に次を理解しておきましょう。 通常のバージョン管理 分散型バージョン管理 本 や 学習書 、 指南書 はGitを理解するのに役に立ちました。しかし、その他にもGitの理解に至ったきっかけがありますのでご紹介します。 ステージング・エリアがある Gitにはステージング・エリアがあります。繰り返しますが、 ステージング・エリアがあるのです 。 これには混乱しました。リポジトリ（「オブジェクトデータベース」）とステージング・エリア（「インデックス」と呼ばれる）の両方がGitにはあります。チェックインには2段階あります。 git add foo.txt インデックスにfoo.txtを追加します。これだけでは、チェックインは完了していません。 git commit -m "message" リポジトリ
2014初頭に書いた「WindowsにおけるGit利用環境は整った： Git for Windows と SourceTree for Windows」の最後の文： ブランチは、Gitのなかで最も重要でありながら最も分かりにくい概念でしょう。表面的な言葉に騙されず、先入観を持たず、SourceTreeの視覚的表示（樹形図）の力を借りながら学習するのが、理解への一番の近道です。 そんへんの詳しいことはまたの機会に述べるかも知れません。 1年半以上たってしまいましたが、「またの機会」がやって来ましたよ。ええ、Gitの説明をします、ブランチを中心に詳しく。 「基礎編」と「ブランチ編」で2回に分けようかと思ったけど、長大な記事として一挙公開。これからGitを使う人が対象ではありません。Gitが何をやっているのか、自分が何をやっているのかイマイチ自信が持てない方向けです。 ブランチやマージって、なん
git管理下のファイルのdiffを見るとき、デフォルトのdiffはちょっとわかりにくいし、diffしながら編集出来なくて不便なので、何か良いdiffツールはないか探してました。 最近はSublime Text2で開発しているので、プラグインを調べてSublimergeというのがあるらしいことを発見。試してみます。 インストールする Mac OS X Lionでやっていきます。 Pacakage Controlを使用してインストールするので、入れてない場合は是非入れておきましょう。プラグインのインストールがコマンド数回だけで出来るようになります。 この辺参考に。 https://sublime.wbond.net/installation http://d.hatena.ne.jp/xyk/20131001/1380610973 まずはSublime Textを開いている状態で、contro
はじめまして。サーバサイドエンジニアの @DQNEO です。 今日はGitのつくりかたをご紹介します。 C言語学習教材としてのGit Gitと同じものをゼロから作って何の意味があるのか？と思いますよね。 私がこの再発明をやり始めた動機は「C言語を書けるようになりたい」でした。 実際に途中までやってみたところ、 C言語がチョットデキるようになった Gitの内部構造に詳しくなった というメリットが得られました。 C言語を勉強する題材は、テトリスとかWebサーバとか他にいくらでもあるのですが、Gitを実装してみるのはかなりおすすめです。理由は下記の通りです。 内部構造が意外と単純 (ローカルで動かす分には)ネットワークの知識が不要 普段使っているツールで外部仕様がわかっているので、やるべきことが明確 余談ですが、本家Gitのソースコードを参考にしようと思って読んでいたら、Linus Tovals
ある日、 PR の内容を見ずにマージすることを岡島（ピッチャーの）というらしい 笑った— いのうえ (@a_know) 2015, 9月 10 ということで、脳天気に笑っていたら、 @a_know むしろイキナリmasterリポジトリに直接pushするパターンですね！— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 という話になり、そしてなぜだか、 @a_know push -fと同様、Gitの運用アンチパターンとかどこかに纏めがほしいですねー。 #ブログ待ってます— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 というはなしになったので、本当に必要として頂いているのかどうかはともかく、 Git / GitHub でぼくやぼくの職場で気をつけていそうなことをまとめてみる。 もくじ もくじ GitHub Flow に沿って開発する 基本
タイトルは大げさです。割と当たり前の話です。 ハードディスクの整理中にRailscastsのメモが出てきまして 懐かしいなぁ、 Ryan Bates(@rbates)さん 元気かなぁと Twitterを覗いてみたところ How to write a Git commit message: http://t.co/D31dVh1lks— Ryan Bates (@rbates) 2015, 7月 28 なかなか興味深い記事をtweetされていました。 Git の commit messageに 規律をもたらそうぜ、ってのは どうやら日本人だけじゃないようです。 元記事( How to Write a Git Commit Message ) Introduction 著者の過去と現在のcommit logを対比しています。 一貫して、この緑と赤の対比が見やすいので、記事も読みやすいです。 ま
MS Wordで書かれた原稿を電子書籍化する作業を行ったのですが、個人的には使い慣れたRe:VIEWで管理したいものです。 そこで、MS Wordをテキストファイル化してRe:VIEWファイルに書き換えることにしました。 docx2txtを使ってMS Wordをプレーンテキストに変換する ワードファイルのテキストをコピペしてテキストファイルに置き換えるのは流石に面倒ですし、ヒューマンエラーも発生しそうです。 そこで、何か良い方法はないかと思って、おもむろにGoogleで『docx2txt』と検索してみると、まったく同じ名前のソフトウェアを発見することができました。 Docx to Text convertor ページはややレトロですが、ツール自体はメンテナンスもされているようで、これを導入することにしました。 リポジトリ作成 まずはリポジトリの作成です。とりあえず、次のようなファイル配置を
はじめに これは ドリコム Advent Calendar 2014 の5日目です。 4日目は、@ka_nipan さんによる ドリコムを支えるデータ分析基盤 です。 自己紹介 @gussan ドリコム歴は10年になります。 アーキテクチャ設計、ミドルウェア・ライブラリ及び社内ツールの開発運用等を担当しています。 本日の話 2年前の12月、メインのソースコードリポジトリをSubversionからGitLabへ移行しました。 本日はGitLabへの移行と運用の話をします。 GitLabに決めた理由 選択肢としてはGitLab, GH:E, Stash等がありました。 メインの機能はどれも十分な機能を有していましたが、 GitLabを選んだ主な理由としては以下の3つです。 継続的にメンテナンス・リリースがなされている 社内にある技術で運用可能である(Rails, MySQL, Redis) も
Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 （2014年12月17日追記） 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど！と思ったコメントをもとに少し修正・加筆してみました。 （2022年1月4日追記） 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目：変更内容の要約（タイトル、概要） 2行目 ：空行 3行目以降：変更した理由（内容、詳細） 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 （多すぎても悩むので
インストール方法から参考リンクまで。 自分の勉強ついでに、Tigについて基本の すべてをまとめてみました。 合わせて読みたい 【おすすめ】MacのFinderをカスタマイズする魔法のコマンドたち 【おすすめ】これからWebする人はここ読んどけ(HTML/CSS/JS/Ps/Ai.etc) 【おすすめ】Qiitaを使い倒す方法一覧 Tigとは 定義 Tig is an ncurses-based text-mode interface for git. It functions mainly as a Git repository browser, but can also assist in staging changes for commit at chunk level and act as a pager for output from various Git commands. 要
もし図の表示がおかしかったら、このページの SVGでないバージョンを試して下さい。 SVG の画像処理を中止しています。 (SVG の画像処理を再開) このページのオリジナルは、Mark Lodato さんが執筆した A Visual Git Referenceです。 このページでは、よく使われる git のコマンドを簡潔に図を用いて説明します。 git について少し知識があるなら、このページはその知識を整理するのに役立つかもしれません。このページがどのようにして作られたのか興味があるなら、私のGitHub リポジトリを見て下さい。(日本語訳の GitHub リポジトリ) 内容 基本的な使い方 凡例 コマンドの詳細 Diff Commit Checkout 分離HEADでの commit Reset Merge Cherry Pick Rebase 技術メモ 基本的な使い方 上記4つのコマ
Git使ってます？Git。 覚えなくちゃなあ…でもあれ正直よくわかんないんだよなあ…。そんなデザイナー結構いるんじゃないかと思いますが（いてくれ！）いかがでしょうか。 一応、ご存じない方のために概要を抜粋。 Git（ギットまたはジット）は、プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムである。もとはLinuxカーネルのソースコード管理に用いるためにリーナス・トーバルズによって開発され、それ以降ほかの多くのプロジェクトで採用されている。Linuxカーネルのような巨大プロジェクトにも対応できるように、動作速度に重点が置かれている。現在のメンテナンスは濱野純 (Junio C Hamano) が担当している。 Wikipediaより つまりGitとは、コードや画像の修正・変更ごとにファイルの状態を記録し、それぞれのバージョンを管理することができるシステム
※ 本スライドの内容を解説した、電子書籍を販売中です。 <a>http://p.booklog.jp/book/86773</a> 「Git（ギット）」や「バージョン管理」という言葉は聞いたことはあっても、なんだか難しそうなイメージを持っているかも知れません。 特に、プログラマーやエンジニアのツールであって、デザイナー・マークアップエンジニア・ディレクターの方は「自分には無縁」と思っているのではないでしょうか。 しかし、Gitはプロジェクトに関わるすべての方が使えると、コミュニケーションツールとしての役割も果たし、非常にスムーズにプロジェクトを進行させることができます。 このイベントでは「ノンプログラマの方」を対象に、Gitのよく使う部分だけをピックアップしてわかりやすく紹介、今日から使えるテクニックや便利なポイントを紹介していきます。Read less
#Gitチートシート ##用語 ###リポジトリ バージョン管理システムにおいて，プログラムやファイルを蓄積しておく場所． Gitではローカルリポジトリとリモートリポジトリの二種類のリポジトリを扱える． ###ローカルリポジトリ 現在作業中のリポジトリ．主に自分のPCや開発サーバーなどで作業する場合はローカルリポジトリとなる． また，リモートリポジトリからリポジトリをクローンして，自分のPC上やサーバー上に環境を構築することもできる． ###リモートリポジトリ 外部にあるリポジトリ．リモートリポジトリはローカルリポジトリを通じて作業を行う． 複数人での作業やインターネットに公開する場合に利用できる． ###ワーキングツリー ユーザーが編集したり新しいファイルを作成したりする場所． ###インデックス ワーキングツリーでの編集後，リポジトリへのコミットの前に次のコミットの対象となる状態を保持
こんにちは@a_suenamiと申します。 これはGit Advent Calendar 2012の17日目の記事になります。 前日はid:akiyokoさんのGitコマンド総選挙でした。 Gitの内部構造 みなさんはGitがどういう風にデータを管理しているか意識したことはありますか？ コマンドの使い方に関するTipsはよく見かけるのですが、なかなかデータ構造に着目した解説は少ないのが実情かと思います。 そこで本日は僕が以前社内で行ったGit勉強会の話をもとにして、Gitの内部でどのようなデータがやりとりされているのかという話をしたいと思います。以下が以前僕が社内で勉強会をしたときの資料です。 http://www.slideshare.net/asuenami/git-15199548 タイトルの通り、非プログラマ向けの内容なのですが、PART2ではGitの内部構造を擬人化して説明すると
Windowsで利用できるGUIのGitクライアントの1つに「TortoiseGit」がある。TortoiseGitはまだ開発段階のソフトウェアではあるが、2009年6月5日にリリースされたバージョン0.7.2.0では多くの機能が実装され、実用的に動作するようになった。本記事ではこのTortoiseGitを用いて、Windows環境でGitによるバージョン管理を行う方法について解説する。 近年、「Git」という分散バージョン管理システムが注目を浴びている。しかしGitはWindowsサポートが弱く、またGUIで利用できる使いやすいクライアントがなかったため、特にWindowsユーザーには導入や利用へのハードルが高かった。そこに登場したのが、Windowsのエクスプローラに統合され、GUIでGitによるバージョン管理が行えるツール「TortoiseGit」である。TortoiseGitはまだ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: Web制作者のためのGit入門 (Mynavi Advanced Library): 大杉充 (著), 外村和仁 (著), CodeGrid (編集): 本
