Non interactive git clone (ssh fingerprint prompt)Stack Exchange Network Stack Exchange network consists of 183 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers. Visit Stack Exchange
SourceTreeの使い方 | コミットの再編集・変更方法 - ICS MEDIA
Gitでの開発で、こんな体験はありませんか？ 3つ前のコミットのメッセージにミスがあった。修正したい・・・ このコミットの順番入れ替えたいなぁ このコミット、ホントは要らなかったから削除したいなぁ …… 実はそれGitでできるんです！今回はGitクライアントソフトのSource Treeソース・ツリーでコミットログを修正する便利な機能「rebase interactiveリベース・インタラクティブ」を解説します。 コミットの再編集ができる機能とは？ Gitではコミットを再編集する機能を「git rebase interactive」といいます。たとえば、コミットの入れ替えや編集、統合、削除ができます。正確に説明すると、コミットそのものを編集するのではなく、新しくコミットのコピーを作成して1つずつコミットを組み立てる機能になります。 Source Treeでコミットログを編集しよう Sour
インデントコミットで真犯人がわからなくなった場合の git blame
config_param :queued_chunk_flush_interval, :time, :default => 1 を追加したコミットがどれかを探したいとします。 しかし、git blame を見るとこんなかんじに、インデントコミットによってほぼ全ての履歴が上塗りされていてどれだかわからない、みたいな状況にどうやって真犯人を探そうかという話です。 1. git blame -w を使う インデントコミットを無視したいだけであれば git blame の -w オプションが使える。-w は比較の際に whitespace を無視してくれるオプション。git diff にもあるよね。 $ git blame -w lib/fluent/output.rb ... (省略) 14d01c71 (Masahiro Nakagawa 2013-03-27 03:56:51 +0900 1
Githubにpushしたら自動テーマ更新する恐怖のWordPressプラグインを作った | 高橋文樹.com | プログラミング
この投稿は 10年 前に公開されました。いまではもう無効になった内容を含んでいるかもしれないことをご了承ください。 WP-Dというブログがありまして、そちらで2ヶ月ほど前に「もうFTPを利用することは止めて、Gitを使おう。そのほうがメリットが多いよー」 という記事がはてなブックマークでホッテントリ入りするということがありました。 ブコメの反応をまとめると…… DevOpsとかいってんのに世間はまだこのレベルか嫌になるな FTPとGitって違うじゃん、何言ってんの サイトの管理をGitでできるわけないじゃん という感じでした。 この記事を書いたメガネさんはデザイナー／ディレクター出身で黒い画面を勉強中、言葉足らずな部分はあったと思いますが、それらの心ないブコメを読み、大変傷つきました。そして傷心のあまり失踪、渋谷セルリアンタワーの屋上でカラスについばまれている無惨な腐乱死体として発見されま
もう巨大なデータをgitignoreしなくていい！ ~git-mediaの使い方~ - 3度の飯と最新技術
はじめに gitはコミットごとにレポジトリ内のファイル全てをスナップショットとして保存するというリッチな 設計になっている。 それがgitの便利さの所以なのだが画像データや音声データのようなバイナリデータを持とうとすると 少しの変更でもそのたびにコピーが生じてファイルサイズ分の容量が増えることになり、あっという間にレポジトリが 肥大化してしまう。 特に学習結果をファイルに保持してテスト等に使いまわすようなプログラムを管理しようとすると アルゴリズムのパラメータを少し変えるたびに100kB近い容量が増えていき、実にイケてない。 普通なら.gitignoreに*.xmlと書いてデータ自体は手動管理したり、シンボリックリンクにして別ディレクトリに置いてそれだけrsyncで同期するようにしたりするんだが 過去の実験時の状態に戻れなかったり、毎回rsyncするのは不便だった。 なんか無いかなーと思っ
Gitonomy – PHP製のGit管理サーバ
おお、これは企業で使えそうですよ！ 企業によっては外部にソースコードを預けられないため、自社でGitサーバを構えているところも多いでしょう。しかしそうなると管理画面が欲しくなります。GitHubの管理画面は優秀で、ああいったWebブラウザ上でリポジトリの情報を見たいと思うはずです。 そこで使ってみて欲しいのがGitonomyです。デザインの格好いい、Gitリポジトリマネージャです。 Gitonomyの使い方 GitonomyはPHP + Symfonyの組み合わせで作られていて、Webブラウザ上でGitリポジトリの操作が一通りできるようになっています。ユーザはプロジェクト単位にグループに入り、そこで権限管理される仕組みです。 ソーシャル機能はありませんが、企業ユースであれば十分ではないでしょうか。社内でGitサーバを立てている場合はぜひ導入を検討してみてください。 GitonomyはPHP
Git作業スタイル: リモートレポジトリに保存しつつキリのいいところで変更をまとめる - Qiita
あらまし 大きな作業をする場合、こまめにローカルレポジトリのブランチにコミットして、何かあったときにすぐに戻せるようにしたくなります。 また、パフォーマンス改善など、実験や研究の色合いの強い作業は、試行錯誤しながらブランチに"とりあえず"保存しつつ、「あっちのほうが良かったかな〜」と思ったときに取り出せるようにしておきたくなるものです。 また、ローカルレポジトリだけでなく、リモートレポジトリに置いたほうがチームみんなで共有できたりしていろいろ便利です。 ですが、最終成果物はなるべく少ないコミットにしないと、マージが大変です。 メインブランチにこんなコミットが入るとゲンナリしますよね？ $ git log --oneline bcdef12 Revert foo abcdef0 Add foo cdef123 Refactor bar again def1234 Refactor bar e
空コミット便利！git commit --allow-emptyでgitを使った開発フローを改善 - fukajun - DeepValley -
何か？ git commitのオプション--allow-emptyご存知でしょうか？ これは、オプションの名前の通り空のコミットの作成を許可するオプションです。 通常変更がないとコミットが作れないようになってるので 空コミットを作るにはこのオプションを指定する必要があります。 add(もしくはrm)もしない(stageに何も載せない)で commitしたときの注意文には登場するので知ってましたが使ってませんでした。 最近、開発フローの中で使い道を思いついて使うようになったので紹介です。 その1 空Pull Request作れる プルリクって、基準になるブランチから変更されたコミットがないと作れないと思ってます。 でも、変更はないんだけどプルリクのcommentに変更の「概要」「目的」「ビジネスインパクト」「どの数値が改善するのか」など色々さきに書いておきたいこととかありますね。 考えてる内
Gitで特定コミットのファイルだけをzipで納品するコマンド - atskimura-memo
ちょいネタです。ちょうどGitで特定コミットのファイルだけをzipで納品する必要があったので。 git：特定コミットのファイル一式を抽出＆zip保存。ワンクリックで。 | ラスタッタPぃやぁ をとても参考にさせていただきましたが、ちょっと変更したのでメモ代わりに書いておきます。 こんなコミットログがあったとして、 $ git log --oneline --graph * c000004 コミット4 * c000003 コミット3 * c000002 コミット2 * c000001 コミット1 「コミット2からコミット3まで変更ファイルだけをください」と言われたら、以下のようにすればOKです。 $ git archive --format=zip c000003 `git diff c000003..c000001 --name-only` -o ~/Desktop/c000003.zip
Gitコンフリクト解消ガイド（git mergetoolの使い方） - Qiita
ファイル編集がコンフリクトした場合 下記はよくある（忌々しい）コンフリクト画面ですね。 皆さんはコンフリクトのmergeはどんな方法でやっていますでしょうか？ vimやemacsで直接編集している方が多いイメージですが、実際開いてみると、下記のように差分が表示されていると思います。 この画面を見ただけではどのようにmergeすればよいのかわかりません。（Objective-CのARC/MRC双方の開発経験がある人は目をつぶってください・・） gitにはこのようなコンフリクトのmergeを支援するgit mergetoolコマンドが搭載されています。 このままEnterキーを押すと下記のような画面が立ち上がります。 画面幅の都合でフォントが小さいのですが、ここで「mergeしたい差分が作られる直前の状態」と「mergeしたい差分」に注目してみます。 この2つを見比べると、@propertyの
Git-ftp - Git×FTPな運用をサポート！ MOONGIFT
Gitは便利な仕組みです。例えばGitリポジトリからデプロイできる仕組みを使えばSCPなどでファイルをアップロードする必要もありません。とても便利です。しかしそういった方法の取れないレガシーな運用を余儀なくされている環境もあるでしょう。 例えばFTPを使っている場合、GitリポジトリにコミットしてもファイルアップロードはFTPクライアントで行うと言った面倒なスタイルになります。それを解決してくれるのがGit-ftpです。 Mac OSXであればインストールは簡単で、brewで行えます。DebianやUbuntuでもaptを使ってできます。Windowsの場合はCygwinを使って行う必要があります。 $ brew install git-ftp インストールが終わったら、ローカルのリポジトリに移動してinitサブコマンドを実行します。 $ git ftp init -u <user> -p
Web制作者のための実践Git | 第1回 適切な履歴の作り方
上記の例の場合、変更した箇所が近いため同じhunk（変更の塊）として表示されています。ですので、hunkをさらに分割する必要があります。そのためにはsを選択します。そうすると次のような表示になります。 Split into 2 hunks. @@ -1,5 +1,5 @@ <ul> <li><a href="/">Home</a></li> - <li><a href="/about.html">About</a> + <li><a href="/about.html">About</a></li> <li><a href="/help.html">Help</a></li> </ul> Stage this hunk [y,n,q,a,d,/,j,J,g,e,?]? 変更が分割されて閉じタグ忘れだけの変更が表示されています。ここでyを押してこの変更をステージングします。すると次は以下の表
git による分散作業パターン | GREE Engineering
分散バージョン管理を華麗に扱いたい堀口です。 GREE Advent calendar 2013 の 14 日目として参加させていただきます。 お二人に続き Haskell の話をしようかと思ったのですが、急遽無難な開発の話に変更しました :o Java や C++ には OOP の概念が必要であったように、分散作業の認識が薄いまま git や Mercurial を使うことは長期的に不幸をもたらします。 とあるプロジェクトにて、その一部を副産物のミドルウェアとして抽出すべく、アプリケーションと分離したい 不具合があったので原因を探りたいが、依存関係が複雑すぎるのでコードを読む量を減らしたい テストやレビュー、提案、リファクタの運用を強化したい よそのプロジェクトに迷惑を掛けないように、そこのツールを改良して使いたい。 いままで何気なく「こんなもんだろう」と思って手間をかけていませんでした
初心者から一歩抜け出すためのGitの業 〜 git add -p - Qiita
diff --git a/git-add.md b/git-add.md index 356ee59..dbf3428 100644 --- a/git-add.md +++ b/git-add.md @@ -1 +1,5 @@ # git-add + +- add line-a +- add line-b +- add line-c っていう変更があったとして、通常なら全部コミットするか、vimで開いて編集して別のコンソールでコミットした後、編集をロールバックするとか、そういうアナログな感じのことをやらなきゃいけないし、実際俺も最初の頃はそうしていた。 ところがどっこい、Gitにはちゃんとそれを回避する方法がある。 試しにgit add . -pしてみよう。すると、以下のように表示されるはずだ。 diff --git a/git-add.md b/git-add.md index 356
初心者から一歩抜け出すためのGitの業 〜 git rebase -i - Qiita
前回とは記事を分けることにした。長くなるから。 今回は、だれでもやったことがあるであろう、「え、ちょ、3つ前のコミットにtypo見つけちゃったよ！！」に対応する。 やりかたはいくつかある。例えば、最初に思いつきそうなことが、 そのコミットまでgit resetを繰り返して、編集して、もう一回git commitしていく である。だけど、前の編集内容を覚えてなきゃいけないし、「Gitを使ってるくせに」的なアナログ感を感じざるをえない……ので、もっと上手い方法は無いのか。 ある。 iはinteractiveのことだ。多分。man git-rebaseをちゃんと読めば書いてあるのかもしれない。英語だけど気になる人は読んでみて欲しい。 で、このコマンド、何ができるのか。試しにやってみよう。 git log --onelineしたら、こんな感じのログがあった。
pull request を利用した開発ワークフロー
pull request を利用した開発ワークフローの話しですが、あんまりプルリの話ししてないし、コードレビュー的なお話しが多いです…。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub Importer
http://altarf.net/computer/server_tips/1446
http://ftploy.com/
GitHub - gitbucket/gitbucket: A Git platform powered by Scala with easy installation, high extensibility & GitHub API compatibility
