git submodule は癖がすごいとの噂だったが素直につきあっていけそうという話 | DriftwoodJPmemo. 以前にちょっと調べたときに git submodule は癖がすごいようだったので後回しにしていました。
master ブランチにマージ済みのリモートブランチをまとめて削除する git-prune-remote-branch というスクリプトを作った - @kyanny's blog
必要になったのでそういうものを作りました。 https://github.com/kyanny/git-prune-remote-branch パスの通ったところに置いて Git のワーキングディレクトリで実行すると master と develop にすでにマージ済みのリモートブランチを全部削除します。 --noop で dry-run モードになるので実際に消す前に確認もできます。なんで master だけじゃなく develop も？というと、僕のチームで gitflow を使っているからです。 $ git clone git://github.com/kyanny/git-prune-remote-branch.git $ git-prune-remote-branch --noop $ git-prune-remote-branchgit push --mirror じゃダメなの
空コミット便利！git commit --allow-emptyでgitを使った開発フローを改善 - fukajun - DeepValley -
何か？ git commitのオプション--allow-emptyご存知でしょうか？ これは、オプションの名前の通り空のコミットの作成を許可するオプションです。 通常変更がないとコミットが作れないようになってるので 空コミットを作るにはこのオプションを指定する必要があります。 add(もしくはrm)もしない(stageに何も載せない)で commitしたときの注意文には登場するので知ってましたが使ってませんでした。 最近、開発フローの中で使い道を思いついて使うようになったので紹介です。 その1 空Pull Request作れる プルリクって、基準になるブランチから変更されたコミットがないと作れないと思ってます。 でも、変更はないんだけどプルリクのcommentに変更の「概要」「目的」「ビジネスインパクト」「どの数値が改善するのか」など色々さきに書いておきたいこととかありますね。 考えてる内
First commit が git rebase -i できない問題 → git rebase -i --root でできる - 納豆には卵を入れる派です。
git init してから一番最初のcommit内容を、2番目のcommitと一緒にまとめたい、と後で思った。 よーし、git rebase -i HEAD~~からのfixupで… $ git rebase -i HEAD~~ fatal: Needed a single revision invalid upstream head~~えっ・・・(ΦωΦ) 一番最初のcommitはgit rebase -i HEADほにゃららでは遡れないのか・・・一番最初のcommitはgit rebase -i できないのか・・・？— TAE ✅ (@ken_c_lo) April 21, 2013 @ken_c_lo それ方法あったら知りたいですねー。調べた限りでは無さそうなのもあって、自分でリポジトリ作る時はgit flow initを使って最初に空のInitial commitを作るようにしてます
gitの歴史上からpasswordを完全に削除したい - (ﾟ∀ﾟ)o彡 sasata299's blog
2014年05月19日10:17 Git gitの歴史上からpasswordを完全に削除したい git で管理しているプロジェクトで「あっ、しまったパスワードが紛れ込んでしまった…！」みたいなことがあって「どうしたらいいんやー＞＜」と思っていたんですが、git filter-branch という最強のコマンドを使えばなんとかなるんですね。 今回は PASSWORD という文字列を含む行を git の歴史上から完全に削除するというのをやってみました。sed -e '/xxx/d' が xxx という文字列を含む行を削除 (delete) するコマンドです。 git filter-branch --tree-filter "find . -type f -exec sed -i '' -e '/PASSWORD/d' {} \;" そうすると PASSWORD という文字列を含む行の痕跡が奇麗
gitとsubversionのコマンド対応表 – cyclogy
備忘録がわりにいつも忘れてしまうgit(git-svn)とsubversionのコマンドの対応表をまとめました。 コマンド対比表 subversion git git-svn 更新 svn update git pull git svn rebase コミット svn commit git add → git commit git commit -a (gitコミット後) git svn dcommit git push <url> 追加 svn add <file> git add 削除 svn rm <file> git rm <file> 移動 svn mv <file> git mv <file> 変更取り消し svn revert <file> git checkout <file> ログ svn log git log 差分 svn diff git diff スイッチ svn
GitHubとJenkins連動 自動デプロイ 開発環境設定編 at ITエンジニアmegadreamsの開発日記
前回の記事でGitHubとJenkinsを用いた自動デプロイ環境の概要をご説明しました。 GitHubやJenkinsと連携した開発環境作成でのrsyncとの出会い 今回は、その環境を実現するための設定手順を書いて行きたいと思います。 大きく４つの手順があります。 Jenkinsのインストール Apacheの設定 JenkinsとGitHubの連携 自動デプロイ設定 開発環境 ・CentOS 6.2 ・Apache がインストール済み Jenkinsのインストール まずは、Jenkinsのインストール 通常ならば、運用するサーバとJenkinsが動いているサーバを分けるべきですが、サーバコストの都合などで今回は同一サーバ上で動かすことにします。 ApacheサーバとJenkinsサーバが同じport80で待つことはできないので、jenkinsをport:8080で動かすことにします。 また
continuous commit のお供、git rebase を決定的に刷新する最強ツール Uchronie をリリースしました - tomykaira makes love with codes
2013-07-13 continuous commit のお供、git rebase を決定的に刷新する最強ツール Uchronie をリリースしました Scala Git いままで git rebase -i に何度泣かされたことでしょう。 git は最高のツールですが(他の SCM に勝るという意味ではありません)、あれは非常に出来がわるい。 テストを回すたびに自動コミットする continuous commit のプラクティスを採用している私達にとって、 interactive rebase は頭痛の種でした。 (continuous commit については Continuous Commit (kyon_mm さんの発表資料)、最近の git の使い方について - tomykaira makes love with codes など)。 git-rebase--interact
GitHubでの開発をもっと便利にしてくれるコマンド·Node GH MOONGIFT
Node GHはnode.js/JavaScript製、BSD Licenseのオープンソース・ソフトウェアです。 オープンソースをよく使うプログラマーであればGitHubを便利に使っているのではないでしょうか。そんな方にお勧めしたいのがNode GHです。GitHubのAPIを使ってより便利なコマンドを提供してくれるソフトウェアです。 インストールします。npmを使ってできるので簡単です。 最初に認証が求められます。IDとパスワードを入力します。 GitHubのリポジトリに移動して操作します。isコマンドは課題をリストアップする機能です。 isの後に文字をつけることで新しい課題を登録できます。 そして課題を一覧で確認します。この時の番号がコメントの時に使います。 さらにその課題番号に対して--commentを付ければコメントもできます。 ntでアクティビティを取れます。 その他、Node
git? tig! | Atlassian Japan 公式ブログ | アトラシアン株式会社
私は Git の大ファンですが、そのためほとんどの UI (ユーザーインターフェース)、特に IDE に統合されているものに関してはそれほどの大ファンではありません。これらの UI は複雑でややこしいのです。これらはいくつかの一般「VCS」言語をコマンドにマップしようとします。または隠しすぎるので、何が起こっているのか理解しずらくしてしまいます。更にひどい場合： Tcl/Tk で書かれています… 端的に言えば、私はこれらの UI を信頼していません。 コマンドラインは私のためのものです。自分のコマンドラインは好きなので、これは素晴らしいものです。ほとんどいつでも履歴の「グラフィック」ビューを見られることや、コミットを準備している時に少し助けてもらえるのは良いことです。 tig で入力する。tig はテキストモード、 Jonas Fonseca によって書かれた git 用の ncurses
Windowsマシンでgit svnを使ってみる
ちょっとした開発プロジェクトにアサインされて、既存のコードベースを教えてもらったら、 Subversionのリポジトリが送られてきて残念、、なんてよくある話なのですが、 2013年にSVNってのもなぁということで、git-svnを使ってみることにしました。 社内にはgitのリポジトリあるのでどっかでシレっとそっちにpushして今後はこっちで、、とか？ｗ ＃とは言え、私のGitレベルは↓の本が積んである状態なのですが…。 ■ git svnがどんな感じかを知る とりあえずマニュアルのページをサクっと流し読みしてみます↓ https://www.kernel.org/pub/software/scm/git/docs/git-svn.html コマンドは『git svn～』って感じで、init, fetch, clone, rebase,,って馴染みなコマンドが 羅列されてるけどpushするの
git の運用指針 - Cube Lilac
ソフトウェア開発に関しては、これまでほぼ一人で完結していた*1ので git の運用方法もかなり適当だったのですが（ただのコミットマシーン状態）、今回、同一プロジェクトに対して複数人でコミットしていく形になっているので、その状態だとやはりまずいなと言う気がしてきました。ググっていると「なるほど」と思う記事もたくさんあったので、それらの記事を元に自分のプロジェクトの「git の運用指針」を情報共有のために記載しておこうと思います。 前提 まず始めに、現在のプロジェクトの状況は下記のようになっています。 開発は 1 人のメインコミッタ（私）と数人のサポートコミッタ（アルバイト等）で行われる メインコミッタはフルタイム、サポートコミッタは週に数時間〜10時間程度の勤務形態 サポートコミッタに対しては、基本的に 1 機能（1 チケット）を 1 人で完結するように作業を配分するが、時間的な兼ね合いもあ
RedmineとGitを連携させる（認証統合） - torutkのブログ
第4回shinagawa.redmine勉強会に参加してきた - torutkの日記にて、岡本隆史さんの発表にRedmineとGitの連携（認証統合）がありました。この参加レポートで次のように書いていました。 中央リポジトリはRedmineでも、Git利用OKとのことです。Redmine 2.1ではGit認証統合が搭載され、Redmineのロールに基づきリポジトリのread権・write権の制御ができるそうです。この話は知りませんでした。gitoliteでssh鍵を使ってユーザー管理するの大変だなぁと思ってました。なお、設定は、Apacheの設定ファイルにいろいろ記載するようです。Gitリポジトリ名に制約があるようです。 しかし、Gitは軽くさわってみた程度です。Gitサーバーの立て方が未知のままです（gioliteは途中で挫折）。が、意を決して構築してみました。ので、たぶんに試行錯誤が含
リポジトリ - Redmineガイド
注1: バージョン管理システムの適切なコマンドがRedmineと同じサーバにインストールされている必要があります。 例えばRedmineからSubversionリポジトリにアクセスする場合、svnバイナリをRedmineが稼働するホストにインストールする必要があります。 注2 : バージョン管理システムのコマンドはRedmineから実行できるようパスが取っているなどしている必要があります。 以下のいずれかの方法があります。 コマンドにが置かれているディレクトリにPATHが通っている: もしコマンド名がデフォルトのものとは異なる場合は、Redmineの設定ファイルで呼び出すコマンド名を変更できます Redmineの設定ファイルでフルパスを指定することもできます。 最後に、「管理」→「設定」画面の「リポジトリ」タブ内「使用するバージョン管理システム」で、バージョン管理システムを有効にするのを忘
git で複数のリモートリポジトリに一度に push したりする。 - D.
git リポジトリの .git/config には remote origin となる URL がテキストで書かれている。 [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = ssh://user@host/~user/git-bare/repo.git [branch "master"] remote = origin merge = refs/heads/master なお、これらの値は git config -l で参照することもできる。このうち remote.origin.url を書き換えることで pull/push の対象
Git pullを使うべきでない３つの理由 · DQNEO日記
git pullは使わなくてもよい 初心者はgit pullを使わない方がよい 我々ソフトウェアエンジニアは勉強が大好きなので、コマンドがあるとそれを勉強して使いこなさなければいけないと考えがちですが、ときには「覚えない、使わない」という発想も大事なのではないでしょうか。 以下にその理由をのべます。 git pullは使う必要がない git pullを使わないとできないこと、というのはありません。 使わなくても全然困りません。 git fetchとgit mergeとgit rebaseだけですべての用は足せます。 私はチーム開発でGitを本格的に使い始めて数か月経ちますが、普段の作業でgit pullを使ったことはないしそれで困ったこともありません。 git pullを使わなければ、余計な落とし穴に落ちない git pullには落とし穴があります。 初心者はたいていその穴に落ちます。 「
gitのoriginのurlを変更する。 - 僕の今さら日記
mirahを最初にインストールした時に、 git://github.com/headius/mirah.git の方から持ってきてて、あとから git://github.com/mirah/mirah.git の方が最新なことに気づいて、別にそのまま新たにcloneしてくればいいんですが、 originを変えれないのかな?と思ったのでメモ。 **追記** @murachue さんより教えていただきまして、 % git remote set-url origin <新しいリポジトリURL> が普通とのこと。明らかにこっちのほうが自然なかんじですね! @murachue さんありがとうございます!! 使用した感じは以下のとおりです。 regina% git remote -v origin git://github.com/headius/mirah.git (fetch) origin gi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gitでハッシュ値を取得 - Qiita
図とコマンドで分かる！ git-flowによる開発の流れと使い方
GitLab
