先日bundler 1.13.0がリリースされたようで、早速試したみたところ、Gemfileに:githubショートハンドを使用しているとwarningが出るようになっていました。 # Gemfile # Bundle edge Rails instead: gem 'rails', github: 'rails/rails' gem 'rails', github: 'rails/rails' # Use sqlite3 as the database for Active Record gem 'sqlite3' # Use Puma as the app server gem 'puma', '~> 3.0' # Use SCSS for stylesheets gem 'sass-rails', github: "rails/sass-rails" The git source `
こんにちは、エンジニアの王です。今回は、Git初心者を悩ませるリベースについて解説してみたいと思います。 リベースが初耳 リベースを聞いたことはあるけど、使っていない 不安を抱えながらも、リベースをなんとなく使っている 上記に当てはまる方は、ぜひ読んでくださいね。 リベースで何ができる？ コミットが綺麗になる！ 以上です！ この一言に尽きる！ 具体的にどのように綺麗になるかというと…… コミット履歴がわかりやすくなる コミットメッセージを後から変える コミットの順序を後から変える 2つ以上のコミットを1個に統合する 一度コミットした内容を編集する といった具合でしょうか？ 整理整頓が好きな方は、ぜひリベースを使いこなしていただきたいと思います！ マージとリベース 2つのブランチの変更点を統合するとき、Gitの最も一般的なやり方は、マージとリベースを使うことです。マージは初回で説明したので、
問題 gitにはadd、blame、commitなどの標準のサブコマンド以外にも独自のサブコマンドを定義できます(正確にはこの機能の名称はaliasですし、本来はそういう用途で導入されたものだとも思うのですが、私としてはこの説明の方がしっくりくるので以降ではaliasとは呼びません)。標準サブコマンドに対する単純なエイリアスを定義したり、単に外部コマンドを実行するだけのものなら何も問題はありません。 しかし、ちょっと複雑なものを定義しようとすると話は少々面倒になってきます。処理自体をスクリプトとして分離してそれを実行するだけのサブコマンドを定義するのも一つの方法なのですが、gitのサブコマンドとして定義するようなケースではスクリプトを分離するほどの規模でない場合が多く、もし分離するとなると管理対象のファイルが増えるため面倒です。できるだけ単一の設定ファイル(~/.gitconfig)に定義
git-merge の--ff, --no-ff, --squashの違いをまとめてみた。 git helpから引用 まずは、git helpを読みましょう git merge --helpから引用（抜粋） NAME git-merge - Join two or more development histories together SYNOPSIS git merge [-n] [--stat] [--no-commit] [--squash] [-s <strategy>] [-X <strategy-option>] [--[no-]rerere-autoupdate] [-m <msg>] <commit>... git merge <msg> HEAD <commit>... git merge --abort OPTIONS --ff, --no-ff Do not gene
はじめに こんにちは、クレイの亀井です。ここ最近一気に気温が上がりましたね。顔に重点的に汗をかくタイプの私には憂鬱な季節がやってまいりました😩💦 さて、今月正式リリースしました(！) Doc...
この記事は Git Advent Calendar 6日目の記事です！ Git submodule って最初わかりにくいと思うので、基本的な説明をしようと思います。 git submodule とは git submodule は、外部の git リポジトリを、自分の git リポジトリのサブディレクトリとして登録し、特定の commit を参照する仕組みです。 Subversion でいうところの、external と似ています。 さて、解説のため、手元に、リポジトリA (/path/to/a) とAの submodule として、よく使う例として Bootstrap (元Twitter Bootstrap) を登録してみます。 git submodule を理解するうえで重要なのは、 リポジトリAが指し示すsubmoduleとしてのBootstrapのcommit 現在のBootstr
git blame 使い方 ファイルの各行がどのコミットのものか調べる file.txt に対して git blame file.txt とすると、 各行毎にコミットのハッシュ値、著者、時間が表示される。 git blame の出力を変更する -f コミットのファイル名を表示する -s 著者とタイムスタンプを表示しない -l ハッシュ値を短縮しないで表示する 行番号で指定した範囲の各行がどのコミットのものか調べる 「-L」オプションで範囲を指定できる。 行番号で指定するには数字を二つコンマで区切って指定する。 また、「+」と「-」を使ってオフセットを指定できる。 git blame -L 5 file.txt git blame -L ,5 file.txt git blame -L 5,10 file.txt git blame -L 5,+3 file.txt git blame -L
ステージを理解して git をもっと便利に使う(その2)
前回から引き続き、「ステージを理解して git をもっと便利に使う」というテーマでコマンドを紹介します。 今回は git diff --cached です。 ●git diff --cached 使用例 git diff --cached 前回覚えた git add でstageする/しないを使い分けると、困ったことがひとつ出てきます。 それは git diff が「index」と「ワーキングコピー」の差分だけを表示すること、つまり一旦git addでstageした内容はgit diffで表示されなくなってしまうことです。 前回の復習として、git add直後の「最新のコミット」と「index」、「ワーキングコピー」の関係を思い出してみましょう。 「最新のコミット」≠「index」＝「ワーキングコピー」 git diffは「index」と「ワーキングコピー」の差分だけを表示するので、「最新
天ぷらを大量に食べました。油でギットギトです。というわけで、gitで共用リポジトリにpushした変更を取り消す方法です。gitって、ローカルのリポジトリを使う参考記事は多いですが、共用リポジトリを使う記事は少ない気がしますね。でも、githubのユーザーは多いと思います。 490円のServersMan@VPS (CentOS 5) をGitサーバーにする会。 - このブログは証明できない。 追記 2010-12-03 ：重要！注意を書いたつもりが書き忘れてました。共用リポジトリをいじるので、複数人で使ってる場合は他の人に影響がでますよね。注意！！ あ。間違えてcommitしちゃった。しかも、共用リポジトリにgit pushしちゃった。しかも、50万円もする布団買っちゃった。まず、間違えてcommitしただけなら、git resetを使います。 $ git reset --soft HEA
最近の更新 (Recent Changes)2016-04-25FrontPage 2014-04-08機能一覧 今後対応を予定している機能 2013-02-16新規メンバーのミッション 2012-12-22リリース手順 2012-11-25議事録一覧 最新リリース情報setucocms (1.6.1)2013-03-24 21:20 Wikiガイド(Guide)Wikiの文法 リンクの種類と文法 ブロックプロセッサ 拡張文法 サイドバー プロジェクトWikiでの広告設定 サイドバー (Side Bar)このサイドバーについて このサイドバーの編集 上: Git導入／操作まとめ 前: Git導入／操作まとめ 次: 開発中のGit操作リファレンス Git導入〜各種設定ここでは、初めてSetucoCMSプロジェクトの開発に参加する人が行うべき、Gitのインストールと設定をまとめています。 Ou
早く公開したかったのに思いのほかハマってちょー頑張った@nekotricolorです。 「バージョン管理システムとは何か〜GitとSubversionの違い」からの「VirtualBox上にインストールしたUbuntuにSSHで接続する」の続きです。 この記事には理屈しか書いていませんので、実際の設定は「ベアリポジトリとノンベアリポジトリ：実践編〜GitでWordpressのテーマを管理」を参照ください。 お題：「Gitを使って、本番環境のWordpressのテーマを、複数のPC上にあるローカルのテスト環境で確認してから更新できるようにする」 ノンベア（non-bare）リポジトリとベア（bare）リポジトリ 違いがよくわからなかったこの2つですが、理解してみれば単純で、 ノンベアリポジトリはワーキングディレクトリを持つ ベアリポジトリはワーキングディレクトリを持たない。更新情報だけを持
いままでなんとなく使ってきたけど、ようやく使い方が分かったような気がするのでメモ。 前提知識 インデックスとワーキングツリーが理解できていること HEAD が何か分かっていること git diff ワーキングツリーとインデックスの差分を表示。 git add した後にさらに修正したけど、そういえばどの時点で git add したのかなー、というときに使う？ git add したらすぐにコミットする自分には関係なさそう。 git diff --cached HEAD とインデックスの差分を表示。 git add して、コミットする前に差分を確認したい時に使うんだと思う。 自分は git diff よりもこっちの方をよく使う。 git diff HEAD HEAD とワーキングツリーの差分を表示。 前にコミットした時からどれくらい編集したか確認したい時に使う。 HEAD の部分はコミット(HE
pull request を利用した開発ワークフローの話しですが、あんまりプルリの話ししてないし、コードレビュー的なお話しが多いです…。
git にはコミットした内容を取り消す方法がいくつかありますが、いったんリリースしたコンテンツの公開期間が終了してその内容を取り下げたいような場合は、git revert でリリース時のコミットを打ち消すコミットを作るのがお作法です。 今回まさにそういう状況になったんですが、リリース時のコミットが複数回にまたがっており、それも 先のエントリ で書いたように他の対応と入り交じってコミットされてしまっています。 こういう場合にどう revert すればいいかという話です。 revert の基本的なところ 例えば 3a0e871f というコミットを打ち消したい場合は、 git revert 3a0e871fを実行すれば、 Revert "xxx 対応" This reverts commit 3a0e871ff60411ca89fa07c7f2b4d426fa04285d.のようなメッセージがみ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
