Capistrano3でSCMを使わずにdeployする - Qiita
Capistrano3ではSCMからソースコードを取得してビルドする、というのが当然とされていて、Capistrano2のscm:noneにあたるものを用意してくれよ/したよという人には「RakeとSSHKit使えばいいじゃん」と返しているようです。 working copyからアップロードするのはいかん、という主張なのだけれども、そうはいってもCIで出来たビルドをアップロードするとかあるわけで、「gitをstubで置き換えればいいんじゃない？」というのと同じで scm:none 相当を自分で作ってしまえば良い。git でないのに git という名前は気持ち悪いので。 none.rbと対応するタスクを用意して
空コミット便利！git commit --allow-emptyでgitを使った開発フローを改善 - fukajun - DeepValley -
何か？ git commitのオプション--allow-emptyご存知でしょうか？ これは、オプションの名前の通り空のコミットの作成を許可するオプションです。 通常変更がないとコミットが作れないようになってるので 空コミットを作るにはこのオプションを指定する必要があります。 add(もしくはrm)もしない(stageに何も載せない)で commitしたときの注意文には登場するので知ってましたが使ってませんでした。 最近、開発フローの中で使い道を思いついて使うようになったので紹介です。 その1 空Pull Request作れる プルリクって、基準になるブランチから変更されたコミットがないと作れないと思ってます。 でも、変更はないんだけどプルリクのcommentに変更の「概要」「目的」「ビジネスインパクト」「どの数値が改善するのか」など色々さきに書いておきたいこととかありますね。 考えてる内
Gitコンフリクト解消ガイド（git mergetoolの使い方） - Qiita
ファイル編集がコンフリクトした場合 下記はよくある（忌々しい）コンフリクト画面ですね。 皆さんはコンフリクトのmergeはどんな方法でやっていますでしょうか？ vimやemacsで直接編集している方が多いイメージですが、実際開いてみると、下記のように差分が表示されていると思います。 この画面を見ただけではどのようにmergeすればよいのかわかりません。（Objective-CのARC/MRC双方の開発経験がある人は目をつぶってください・・） gitにはこのようなコンフリクトのmergeを支援するgit mergetoolコマンドが搭載されています。 このままEnterキーを押すと下記のような画面が立ち上がります。 画面幅の都合でフォントが小さいのですが、ここで「mergeしたい差分が作られる直前の状態」と「mergeしたい差分」に注目してみます。 この2つを見比べると、@propertyの
GitHub のプルリクエストを fetch しとくと便利 - HWPS別館
GitHub や GHE を使って多人数で開発していると，プルリクエストを横断して試す必要が頻繁に発生すると思います． プルリクエストを次々に試したり，#30 と #31 をマージした結果を試したい！なんてケースもあるのではないでしょうか． GitHub では git ls-remote すれば分かるように，プルリクエストの番号と対応したブランチがリモートに存在しているので，これを取得してみます． .git/config に追記（あるいは git remote add とかで適当に） [remote "pr"] url = git@github.com:yourusername/yourrepos.git fetch = +refs/pull/*:refs/remotes/pr/* あるいはこんな感じ（丸投げ）: https://gist.github.com/3342247 git fe
Emacs のソースコードを Git から取得してみた
emacs - Git Repositories Emacs のソースコードは Git(ぎっと) でも公開されているので、 Git Repository から取得してみました。 まず、Git というのは分散型バージョン管理システムです。CVS や Subversion は集中型バージョン管理システムなので、操作や考え方が少し 違います。 分散型バージョン管理については、以下のページにわかりやすくまとめら れています。 Git/分散レポジトリって何が嬉しいの - かWiki 作業者が個別にリポジトリを持てるので、commit 権がないプロジェクトの 修正を管理できる点が良さそうですね。 以下のページも面白いです。アリスの遅れている作業を、ボブが手伝って います。 アリスとボブのコラボレーション、gitをちゃんと理解したい！ - ザリガニが見ていた…。 これで、Git の概要が分かりました。コ
図で分かるgit-mergeの--ff, --no-ff, --squashの違い - アジャイルSEを目指すブログ
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
git-svnを利用した運用を考える - Qiita
最近、諸事情あってsubversionからgitへプロジェクトの半ばでバージョン管理を変更しました。その際にちょっと変わった形でgit-svnの運用を行う事になったのでやりかたに関して簡単にログを残しておきます。 プロジェクトを取り巻く事情 今まではSubversion(仮にメインとします)を用いた運用を行っていたのですが、気軽にtrunkに対してコミットする事が出来ない事情がありました。では、メインSubversion上にbranchをたてればいいじゃんという話になるのですが、ブランチすら気軽に切る事が出来ない状態でした。その上、メインのSubversionにコミットすることが可能なのはコミッターだけとなっておりコミッターの負担が増えつつありました。 今までの運用 今まではメインSubversionとは別に 同期しないSubversion(仮にローカルとします)を別途立てて、なんと手動で
Git ブランチ操作のまとめ
個人的なメモ その２ その１は [2010-04-29-1] にあるよ。 Git では、たった一日の作業でもブランチを作ることが良くある。基本ブ ランチは修正が終わったら master に merge して削除、つまり使い捨て。 別な作業が入ったら、master から新たにブランチを作る。 cvs とか svn だと、作業単位毎にディレクトリを掘って cvs checkout と かしていたけど、Git はこれをブランチ操作のみでできる点が超便利。 ただ、他に違わず、ブランチ操作も複雑なのでメモメモ。 (1) ローカルブランチの確認 % git branch (2) リモートブランチの確認 % git branch -r (1) + (2) % git branch -a (3) ローカルブランチ bar の作成 % git branch bar (4) ローカルブランチ bar への切り
美しき git log –graph のエイリアス
git log --graph --pretty=oneline でもいいんだけど、情報として物足りない。 エイリアスの設定によりこんな感じに美しくすることが可能です。 .gitconfigのエイリアスは下記のように設定します。 [alias] lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative lga = log --graph --all --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-com
GitHubへpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineering
こんにちは。インフラの sotarok です。 先日から Git 関連の話をしている通りですが、社内で Git を使い始めています。 今日は、Git を使った日々の開発〜リリースまでのフローや、そうしたものの運用と、それをサポートするために作ったツール git-daily の紹介をしたいと思います。 ソフトウェア開発とウェブ開発の違い いやウェブ開発も広義のソフトウェア開発なのですが、ここでいうソフトウェア開発とは、クライアントアプリケーションやライブラリのようなものを指すと思ってください。 実際、ウェブ開発をしている方は感じていることだとは思いますが、両者の開発フローはかなり異なるものです。もちろん社風や開発の方針等によって色々あるとは思いますが、主に次のような特徴が挙げられると思います： ソフトウェア開発 アプリケーションはクライアントで動作する リリース間隔は比較的長く、次のバージョ
Git と GitHub を体験しながら身につける勉強会行ってきた - 予定は未定Blog版
9/18（土） 15：30～ GitとGitHubを体験しながら身につける勉強会（名古屋） : ATND 行ってきました。 なんかいろいろと話すことになったんですけど、あの場で言いそびれたこととか、もっとこう説明してればよかったなぁ、って部分の補足も兼ねたエントリです。 長文注意。 ショートカット git add の話 git add -p/git reset -p の話 リビジョン番号がない話 ブランチの話 git-completion の話、__git_ps1 の話 コミットの指定の話 reset の話 rebase と merge の話 公開したものの rebase の話 stash の話 TortoiseGit、HG、SVNのはなし 全体を通して git add の話 Git と SVN では、add に限らず、同じ名前のサブコマンドでも意味が異なるものがいくつかあります。 その中
git log で変更・追加されたファイルを表示する - yuumi3のお仕事日記
git log で変更者、変更日時等の変更履歴が表示されますが、変更されたファイル名を表示するには --stat, --numstat, --name-status, --name-only などで知ることができます。 % git log --stat commit 801fe8c4bd09f91bb2172640c4857acc52f89135 Author: Yuumi Yoshida <yy@ey-office.com> Date: Sun Aug 3 12:15:30 2008 +0900 バグ対応 upload.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) commit 609aa81ec0a489cdac4cb2398918758f609a47e4 Author: Yuumi Yoshida <yy@ey-
広島Git勉強会 201306 - やりなおせるGit入門 - そんなこと覚えてない
広島Git勉強会 に参加しました。 1セッション喋りました。 はじめからgit reset と git checkoutあたりを説明しようと思ってたのですが、「元に戻せること」を主眼においていろいろ考えました。 結果として、「危険」「少し危険」なコマンドを定義して、よくわからない時どうすればいいのか伝えられるか試みてみました。 「危険」なコマンドはワークツリーにした変更が消えてしまう恐れがあるもの。 「少し危険」なコマンドはgit reflogなどを利用しないと追えなくなるコミットができてしまうもの。 と定義して、そこを強調しながら説明してみました。 スライドはこちらに。 結局、難しかったのか簡単だったのか、周りの空気を読む余裕が僕にはまだまだ足りなくて、「経験値を積まないといけないなぁ」と、思うのでした。 追記 ブクマのコメントなどなどに返信 「git commit の -m はそろそろ
www.codebreak.com – このドメインはお名前.comで取得されています。
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年5月時点の調査。
SubversionとGitコマンド対応表 - 発声練習
勉強と備忘録として 前提 SSHでログインできるサーバーに中央リポジトリを置き、リモートで作業するモデルを想定。 サーバー：servername.hoge.jp Subversionリポジトリ /path/to/repos Gitリポジトリ /path/to/repos.git クライアント 作業ディレクトリ /path/to/works リモートリポジトリの作成 Subversionコマンド サーバーにて % svnadmin create /path/to/reposクライアント側にて % cd /path/to/ % svn import works svn+ssh:///servername.hoge.jp/path/to/repos/works -m "Comment"Gitコマンド サーバーにて（参考: Gitリモートリポジトリ構築 CapmNetwork） % mkdir /
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://qiita.com/T_Hash/items/325cffc755fc1ff91928
http://blog.inouetakuya.info/entry/20120826/1345979787
http://papix.hateblo.jp/entry/2013/05/22/032747
powerful-code.com-蒙城县郭侠熟食有限责任公司-网站