もうGitは怖くない： 自信を持って使いたいあなたへ - 檜山正幸のキマイラ飼育記 (はてなBlog)
2014初頭に書いた「WindowsにおけるGit利用環境は整った： Git for Windows と SourceTree for Windows」の最後の文： ブランチは、Gitのなかで最も重要でありながら最も分かりにくい概念でしょう。表面的な言葉に騙されず、先入観を持たず、SourceTreeの視覚的表示（樹形図）の力を借りながら学習するのが、理解への一番の近道です。 そんへんの詳しいことはまたの機会に述べるかも知れません。 1年半以上たってしまいましたが、「またの機会」がやって来ましたよ。ええ、Gitの説明をします、ブランチを中心に詳しく。 「基礎編」と「ブランチ編」で2回に分けようかと思ったけど、長大な記事として一挙公開。これからGitを使う人が対象ではありません。Gitが何をやっているのか、自分が何をやっているのかイマイチ自信が持てない方向けです。 ブランチやマージって、なん
いざというとき覚えておきたいgitコマンドまとめ - Qiita
まだあわてるような時間ではございません。 インデックス 1.コミットメッセージを間違えちゃった! -- 直前のコミットのやり直し 2.そろそろブランチを整理しなきゃ! -- ブランチの名称変更と削除 3.間違ってコミットしちゃった! -- コミットを取り消す3つのリセット 4.別のブランチをプッシュしちゃった! -- リモートブランチのリセットと削除 5.コミットの順番を間違えちゃった! -- コミットログの並べ替えと削除 6.コミット細かすぎィ! -- コミットログの統合と編集 7.あのコミットさえあれば…! -- 他のブランチのコミットを適用する 8.やばい!ハードリセットしたら消えちゃった! -- 過去の状態の復元 9.masterにマージ後にバグ発生!どうする!? -- コミットを打ち消すコミット 1.コミットメッセージを間違えちゃった! -- 直前のコミットのやり直し エディタが
git reset についてもまとめてみる - murankの日記
前回 git diff を図に書いてみたところ、自分の中で意外と整理できたので、これまたなんとなく使っていた git reset についてもまとめてみた。 とりあえず結論を先にまとめよう。 git reset とは？ HEAD の位置を変更するコマンド。 オプションによってインデックス、ワーキングツリーの内容も変更できる。 git reset のオプションは？ --soft、--mixed(オプションなしと同等)、--hard オプションがあり、影響度の小さい順に以下のようになる。 --soft HEAD の位置のみを変更する。インデックス、ワーキングツリーには影響なし。 --mixed (またはオプションなし) HEAD の位置とインデックスを変更する。ワーキングツリーには影響なし。 --hard HEADの位置、インデックス、ワーキングツリーをすべて変更する。 さて、git reset
初心者でもわかる！リベースの使い方を解説します | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
こんにちは、エンジニアの王です。今回は、Git初心者を悩ませるリベースについて解説してみたいと思います。 リベースが初耳 リベースを聞いたことはあるけど、使っていない 不安を抱えながらも、リベースをなんとなく使っている 上記に当てはまる方は、ぜひ読んでくださいね。 リベースで何ができる？ コミットが綺麗になる！ 以上です！ この一言に尽きる！ 具体的にどのように綺麗になるかというと…… コミット履歴がわかりやすくなる コミットメッセージを後から変える コミットの順序を後から変える 2つ以上のコミットを1個に統合する 一度コミットした内容を編集する といった具合でしょうか？ 整理整頓が好きな方は、ぜひリベースを使いこなしていただきたいと思います！ マージとリベース 2つのブランチの変更点を統合するとき、Gitの最も一般的なやり方は、マージとリベースを使うことです。マージは初回で説明したので、
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
Git-flowって何？ - Qiita
git-flowとは、プラグイン(ツール)のことです。。 Vincent Driessen氏がブログに書いた"A successful Git branching model" というブランチモデルの導入を簡単にする git プラグインである。 参考資料： ・ http://hm-solution.jp/lifehack/post2475.html ・ http://d.hatena.ne.jp/Yamashiro0217/20120903/1346640190 Git-flowイメージと各ブランチの役割 master: プロダクトとしてリリースするためのブランチ。リリースしたらタグ付けする。 develop: 開発ブランチ。コードが安定し、リリース準備ができたら master へマージする。リリース前はこのブランチが最新バージョンとなる。 feature branches: 機能の追加。
非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog
前提: GitHub flow を使っていてCIサーバーはJenkins 最近ちょっと開発フローの改善をして、とてもよく機能してて満足しているので紹介してみる。 この改善をやる前の悩み: pull-requestでコードレビューはできるのだけど、cssとかjavascriptなどの見た目や動作の変更ってコードだけだとわかりにくい。レビューする人が各自ローカル環境で実行するのもだるい。 コードを読まないデザイナーとかプロダクトオーナーとかの人が、pull-requestのレビュープロセスに簡単に参加できない(非開発者全員のところでローカル環境設定するのはだるすぎる)。 コード的にokに見えてmasterにmerge後、何か問題(特に仕様的な問題や、デザイン的な問題)が発生した場合、「修正branchを作ってpull-request」というフローを再度回さないといけない。最初のpull-req
GitHubだけがgitじゃないんだからね!! gitリポジトリサービス4つ。 | WP-E (仮)
巷ではGitHubやらgitが盛り上がっていますね。 ぼくはGitHubあまり使わないのですが、なんか独自の機能が一杯あって難易度高い感じ。 消してディスっている訳では無いです。jQuery のプラグインとかでよくお世話になってるし、いずれ何か公開したいなーと夢見ている訳で。 Private Repository は有料なのでこれもぼくみたいなチキンにはハードル高い(誰もお前のことなんて見てねえよ、ってのはお約束)。 ここでタイトルに戻ってくるわけですが、主に無料で仕える Private Repository を探してみませう。 Bitbucket アンリミテッドプライベートリポジトリ 5ユーザーまでリポジトリを共有できる 今のところ最強。みんなこれつかうといいと思う。 で終わってもつまらないのでちょこっと紹介。 管理画面はシンプルで見易いし、機能もそんなにないから迷わない。 ログインして
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-flowの基礎知識
いまさら聞けない、成功するブランチモデルとgit-flowの基礎知識：Gitブランチを使いこなすgit-flow／GitHub Flow入門（1）（1/2 ページ） 数回に渡ってgit-flowとGitHub Flowを使ったGitの活用テクニックを紹介します。初回は、ブランチ管理の課題と効率的にバージョン管理できる5つのブランチモデルと、ブランチの管理を簡単に行えるツール「git-flow」について。 Gitなどの次世代のバージョン管理ツールの特徴として、ブランチの機能を高度に活用できるという利点があります。Gitのブランチを生かしたツール・フローとして「git-flow」「GitHub Flow」が注目を浴びていますが、本連載では数回に渡ってgit-flowとGitHub Flowを使ったGitの活用テクニックを紹介します。初回は、git-flowの概要を紹介します。 効率的にバージョ
【Git入門者向け】イメージで理解するGitコマンド事始め - きのこる庭
ご無沙汰です。連載企画を書き進めると豪語しておきながら かなり経過してしまいました。連載企画の方は時間を見つけつつ少しずつ書き進めていければと思います、申し訳ございません。 さて、最近周囲の方にGitの解説をする機会が増えてきたため、今回はGitの基本コマンドに関連する説明をします。 対象読者 ・何らかの理由でGitを使う事になったが、コマンドが多くてよくわからない方。 ・コマンドごとの意味は何となく理解しているけど、イマイチピンと来ない方。 (※「そもそも何故Gitを使う必要があるのか」「バージョン管理とは何か」といった点については ノンプログラマ向けの連載企画として後日記載させていただければ幸いです) 解説するコマンド git init, git add, git commit, git status, git log, git branch, git checkout, git me
Gitでブランチを操作する
対象読者 今回の対象読者は下記の通りです。 Windowsに関する基礎的な知識 Gitに興味がある方 Subversionなどの別のバージョン管理システムを利用したことがある方 必要な環境 Git for Windows（フリー） Git Extensions（フリー） ブランチとは 何らかのバージョン管理システムを利用したことがある開発者ならば、あえて説明する必要もありませんが、ここで簡単にブランチについて説明します。一言で言えば、バージョン管理システムにおけるブランチとは、任意のリビジョンから別系統の履歴を管理していくために作成される分岐のようなものです。ブランチとは「分岐、枝」を意味し、本系統の方は「幹」に例えてトランクと呼ぶのが一般的です（図1）。 一般的な開発ではトランクで主な開発作業を繰り返します。開発が収束しリリースにむけてトランクとは別に履歴管理をしていきたい場合、ブランチ
「WordPressサイト制作におけるデプロイメントを考える」フォローアップ #wckansai | Waviaei
先の投稿でも書いたとおり、6月7〜8日開催されたWordCamp Kansai 2014に参加し、公募枠で登壇してきました。 セッションを聞いてくださった皆様、ありがとうございました。 セッションのタイトルは「WordPressサイト制作におけるデプロイメントを考える〜Gitとデプロイメントサービスの活用〜」です。概要はというと、WordCamp Kansaiのサイトからの引用になりますが： 現在WordPressサイトの構築や更新には、FTPもしくはSFTPソフトを利用したデプロイメントが主流です。サイト全体の引っ越しであれば、あるいはrsyncやscpといったコマンドを使う場合もあるでしょう。しかし手動で行う作業や、不慣れなコマンドを使うことにより、ミスしたり、時間が掛かったりしませんか？ 一方で、最近は開発にGitを用いたVCを実践している、あるいは検討、勉強しているという方も少しず
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種類のブランチ 各リポジトリが自分のブランチを
.gitignoreの存在を我々は見過ごしてはならない。 - Qiita
とか書いてある。 同じように、バージョン管理の必要性がなかったり、していると不都合がおきる、 sqlite3のDBファイル キャッシュが入るtmpフォルダ プロセス監視のpidファイル 等はignoreしておくべきです。（デフォルトで.gitignoreに書かれていますが） .gitignore自体はignoreにするべき？ それを ignore するなんて とんでもない！ .gitignoreはプロジェクト全体で共有しておくと、環境が変わっても（パソコンが変わっても）ignoreされるファイルやフォルダは 一緒な"はず" なので、ignoreはしなくて大丈夫です。 一緒な"はず" ？ 環境が変わるってことはもしかしたら他人が使うこともあるのです。 たとえば、僕みたいにEmacsとVimとSublimeを併用するときには、同じ人でありながら違う環境でコードを書くことさえあります。一般的にあ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git-resetは結局何を戻すのか - Qiita
What effect does the `--no-ff` flag have for `git merge`?
ごりゅご.com