Git での開発を数年間経験した後、徐々に日々の仕事の一部として、より高度な Git コマンドを使うようになりました。私は Git rebase を見つけてすぐにそれを毎日の仕事に使いました。リベースに精通している人は、どれだけ強力で魅力的なツールであるのか知っているでしょう。しかし、リベースには、初めてリベースを触ったときにはわからなかったのですが、いくつかの課題があることに気が付きました。これを説明する前に、マージとリベースの違いをおさらいしておきましょう。 最初に、feature ブランチを master にマージする例を考えてみましょう。マージすることにより、新しいマージコミット g を作成します。下のコミットグラフではマージした際に何が起こるのかを説明しています。また、開発が盛んなリポジトリでよく見かける「線路」のようなグラフになっているのが見て取れるでしょう。 マージの例 ある
こんにちは、@yoheiMuneです。 今日は、gitで開発していて「あっちょっと元に戻したいな」という時の手順をブログに書きたいと思います。 引用:http://flic.kr/p/6zJjzs 作業の変更を取り消す gitを使って開発している場合に、作業前に戻したいなっていうことありませんか? そんな時に行うことができる変更取り消しの手順を説明します。 変更取り消しの手順は、以下3つの段階別に対応する必要があります。 add前の変更を取り消す addしたけどcommitしていない変更を取り消す commitを取り消す それでは、それぞれの状態別に取り消す方法を見ていきましょう。 add前の変更を取り消す pullしてきたあとに、変更したものの、やっぱりもとの状態に戻したいという場合のリセット方法です。 ここでは、addもcommitもしていないファイルが対象です。 取り消し方法には、以
ここ2年ぐらいで俺が働いた現場はみんなgitを採用している。就職エージェントと面談するときもgit経験の有無をよく訊かれるし、今ではVSSやCVSどころか、SVNですら時代遅れになってきて、SVNを使っている現場は「レベルが低い」「保守的・旧態依然」という雰囲気すら感じる。 俺としては4-5年前からgit(GitHub)を使っているし、gitを使うこと自体に抵抗はない。一通りの基本操作はできるし、人並みにはできると言っても差し支えはない。 …が、正直gitの良さがあまり見えてこない。 もし俺が中規模以上のプロジェクトのリリースを本格的に管理する側であれば全然違った感想を持ったかもしれない。でも一人の開発者として、せいぜい10人程度のプロジェクトで利用する限り、「gitで良かった」という状況があまり思い当たらない。 ではgitの何が気に食わないのか書いていきたい。 ①gitは馬鹿には難しい
gitのコマンドって、コマンド名だけでは動作が想像できないものが多いですよね…。けど、勉強していく中で呪いのように見かける言葉。 『rebaseすんなし』 ドユコトー?ってことでまとめ。 pull = fetch + merge(rebase)! まず。 gitの主な動作はpush・fetch・merge・rebaseで出来ます。 push rebase pullはー?っていうと、fetch して mergeする = pull。 ちなみに、fetch して rebase する = pull --rebase。 要するに、pullは使わなくてOK!ってことです。 使わなくていい理由はこちらの記事が分かりやすかったです。ご参照ください。 Git pullを使うべきでない3つの理由 mergeするとどうなるの? mergeは2種類ある!その1・・・Fast-Forward topicブランチは
はじめに こんにちは、クレイの亀井です。ここ最近一気に気温が上がりましたね。顔に重点的に汗をかくタイプの私には憂鬱な季節がやってまいりました さて、今月正式リリースしました(!) DocBase プロジェクトではクレイ外部のデザイナーの方と一緒に開発しています。SourceTree で Git を使っている方で、軽いデザイン修正などは弊社の Rails プロジェクトに直接手を加えてプルリクエストを送ってくれます。 こちらのデザイナーさんに「プルリクエストを送る際は、作業ブランチで git pull --rebase origin master してから送ってもらえますか?」とお願いすると「pull はわかるんですけど、この --rebase ってなんですか?これつけると何が変わるんですか?」と質問がきたのです。 作業ブランチで git pull --rebase origin master
以前も一度調べて解決したがまたしても同じことを調べてしまったのでメモしとく githubにて新しいレポジトリを作成してそこにローカルにあるレポジトリをpushしたい場合、基本的にレポジトリ作成時に表示される以下の案内通りやってもうまくいかないことがある。 touch README.md git init git add README.md git commit -m "first commit" git remote add origin https://github.com/username/hoge.git git push -u origin master自分の場合はこれでやったらpushを行った段階で以下のエラーが出た。 error: The requested URL returned error: 403 while accessing https://github.com/u
こんなブランチ構成だとする。 $ git branch -a * master ios7 remotes/origin/HEAD -> origin/master remotes/origin/ios7 remotes/origin/master ios7のブランチを消したい。 まずはローカルブランチを削除 $ git branch -d ios7 Deleted branch ios7 (was 57c1b0b). リモートブランチも削除 $ git push origin :ios7 To https://xxx.git - [deleted] ios7 確認 $ git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/master ちゃんと消えた! push で消すのとか、:hoge で指定
この投稿は 「Git Advent Calendar 2014 - Qiita」 の 2日目の記事です。 2年前の 「Git Advent Calendar 2012 - Qiita」 では、「Gitコマンド総選挙」と題して、本当に使える Git コマンドのベストテン発表というネタを書いたのですが、今振り返ってみても、Git コマンドって、よく使うものから普段あまり使わないものまで様々なコマンドが取り揃えられていて至れり尽くせり感がある一方で、Git 初心者が覚えるにはぶっちゃけ 数が多過ぎて辛い ですよね。 そこで今回は、Git 初心者がプルリクできる ようになるまでに覚えるべきコマンドを絞りに絞って、9つだけ紹介したいと思います(9つでも多いよ!というツッコミは受け付けません!)。 【コマンド その1】 git clone 【コマンド その2】 git log 【コマンド その3】 g
プルリクエスト/レビューを取り込んだ、よりシンプルなGitHub Flowの運用を図解する:Gitブランチを使いこなすgit-flow/GitHub Flow入門(終)(1/2 ページ) 数回にわたってgit-flowとGitHub Flowを使ったGitの活用テクニックを紹介します。最終回は、GitHubが採用している、git-flowよりシンプルな構成のブランチ管理フローについてです。5つの運用ルールや開発の流れを図を交えて解説します。 本連載「Gitブランチを使いこなすgit-flow/GitHub Flow入門」では、これまでgit-flowについて解説してきました。git-flowはプロダクトを厳格にリリースすることを念頭にフローが考えられていますが、プロジェクトによっては、冗長過ぎると感じることもあるかもしれません。本連載の最終回となる今回は、git-flowに比べシンプルなブ
さくらのVPS(v3) 2GB プランへの環境構築メモ 11。今回は Git 関連の続き。Gitolite と GitHub の push をフックする方法などについて書く。 Gitolite への push をフックする 前回 Gitolite をセットアップしてリポジトリを Redmine へ表示するところまで書いた。しかしそのままでは Gitolite の push がミラーリングされたリポジトリに反映されず内容は古いままとなる。この問題への対処方法は 2 通りある。 ミラーリングされたリポジトリ上で git fetch を定期実行 Gitolite 上で push を検知して、ミラーリング先リポジトリに対して git push --mirror を実行 方法 1 なら crontab を利用することになるだろう。たとえば 10 分間隔ぐらいで git fetch させるなど。しかし
8. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) 例: 受け取ったパッチを取り込んだ人 ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー(説明は省略) 1つ前のコミットのリビジョン 例: 4717e3cf182610e9e82940ac45abb0d422a76d77 9. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Co
gitでは様々な方法でコミットログを書き換えることができます。 その一例として一度行った変更をなかったことにする方法を4つ紹介します。 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。 $ $EDITOR $ git commit -am 'foo' $ $EDITOR $ git commit -am 'bar' $ $EDITOR $ git commit -am 'baz' のように適当な区切りでコミットして行ったものの、 結局全部要らないからなかったことにしたいということはままあります。 解答1: git reset –hard HEAD~{n} コミットしたもの全てを歴史から消し去りたい場合は git reset --hard を使います。 この例の場合は3回のコミットを全てなかったことにしたいので、 以下のコマンドで消し去ることができ
gitの操作方法覚えたいならオフィシャルのこのページがおすすめです。 日本語で書いてあって、全体的に網羅してて申し分ない。 Git - Book 従来プログラム書いたりする人でないと、なかなかgitを使う機会がないと思うのですが ミドルウェアの設定ファイルの管理とかもgitでやった方がいいなと思うことがあったので とてもカジュアルなgitの操作方法をメモっておきます。 サーバエンジニアとか、インフラエンジニアとか呼ばれてる人で、 日々サーバ上の設定ファイルを、hogehoge.conf.日付でバックアップしてる人へ gitを使ってカジュアルに運用したらいいと思う。という内容の戯言でございます。 etckeeperは?という方はetckeeper使ってみたらよいかと思います。 gitのコマンド絶対覚える気がなくて、設定ファイルは全て /etc/ 配下で 自分でコミットとかしないし。って人向け
前回に引き続き、今回も Vim + Git ネタですが・・・。 vimshell や fugitive.vim を使っているとほとんどの操作を Vim 上で実現できるます。でも、gitk だけは別ウィンドウで起動しなければならず面倒だと思っていました。 Vim 上で gitk 的なことを行うプラグインがないかと思っていたら gitv.vim というものがありました。 インストール というか github gregsexton/gitv 使い方 コマンドモードで :Gitv と打てばブラウザモード(後述)で起動します。 gitk --all 相当のことは :Gitv --all でいけます。 また、 :Gitv! のように ! をつけるとファイルモード(後述)で起動します。 ブラウザモード 左のウィンドウにコミットのグラフ、右のウィンドウにコミットメッセージとそのコミットでの変更点が表示され
GitHubのイベントである「The GitHub poweredby Agile渋谷 〜日本のSOCIAL CODINGの今を見る〜」の懇親会を受付始めました@HIROCASTERでございませう。 イベント参加者以外でも参加可能のため、イベントは補欠だったけど、どういうふうにGitHubを使っているのか聞きたい人は、ご参加ください。(イベント参加者優先で、空気読んで登録してください) イベントではGitHubの話をするので、Gitが使えることが前提になっています。 そこで、Gitの基本操作方法を学べる「githug」を紹介します。 githug Gazler/githug「githug」はgitの基本操作を実践的に学ぶための良いソフトウェアです。 特に他のバージョン管理システムを使ったことのある人がgitの基本操作だけを学ぶだけならちょうど良い。 インストールgemで公開されているのでイ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く