案件で「作業の差分を納品してくれ」とか言われることってよくあります。 今までは手作業でディレクトリ作って、ファイルをコピーしてましたが、 もう、そんなうんざりする作業とはおさらばできそうです。 git archive と git diff の合わせ技で差分を出力できる事がわかったからです。 例えば、一個前のコミットから現在のコミットまでの差分を取り出したい時は、 git archive --format=zip --prefix=root/ HEAD `git diff --diff-filter=d --name-only HEAD^ HEAD` -o archive.zip まずは、git archive について。 --format=zip を付けるとzipで固めてくれます。 --prefix=root/ は抽出したファイルをrootディレクトリに入れた状態にしてくれます。 -o a
こんにちは!長屋です。最近は学生時代からのあだ名、めぐたん が社内でも浸透してきました。笑 入社してから本格的に触るようになったGitにもだいぶ慣れてきた…と言いたいところですが、見慣れないコマンドにはやはり躊躇してしまいます。 今回は私にとってその一例であった差分抽出がテーマです。使うシーンは、例えば「更新したファイルだけを集めてzipファイル化したい」というとき。手作業でひとつずつファイルを集めてくることなく、一発でzipファイルが完成します! 基本のコマンド まずは差分ファイルを抽出+zipファイル化の基本的な使い方をご紹介します。下記のような状況を想定します。 修正前のデータがリモートのmasterブランチにある 作業用にrevisionブランチを作成し、修正を行ってコミット masterとrevisionブランチ間の差分がほしい こんなときに使うコマンドがこちらです。 $ git
あらかじめ読んでおくもの JavaScriptでGitを実装するKickstarterプロジェクト、28時間で資金調達 Git の仕組み (1) Git の仕組み (2) Gitの内側 js-gitとは gitをjavascriptで実装しちゃったjs-git。 わざわざgitをjavascriptで実装したからにはブラウザで使うでしょう? js-gitは「なんらかの形で表現された.gitディレクトリ」の中身をあれこれするためのAPI集です。 この「なんらかの形で表現された.gitディレクトリ」には、オンメモリとかnodejsのfs標準ライブラリのラッパとかindexedDBとかWebSQLとかいろいろあります。DOMStorage系がないのが気になりますがあんな容量でローカルリポジトリとして使うのは難しいでしょう。localStorage使いたかったらlocalStorage-dbをご自
ないですか?私はありました。 「Repository」メニューから「Repository Settings...」を実行して、「Edit Config File...」ボタンをクリックします。 すると、テキストエディタでカレントリポジトリの.git/configファイルが開くので、以下のような感じで末尾に追加されたgitflowの設定のみ消せばいいです。 [gitflow "branch"] master = master develop = develop [gitflow "prefix"] feature = feature/ release = release/ hotfix = hotfix/ support = support/ versiontag = Register as a new user and use Qiita more conveniently You get
morimorihogeです。残暑やばい。 ※元々は2014年に書いた記事ですが、2020年になっていろいろと事情も変わっているので2020年revise版として更新しました。 弊社ではバージョン管理システムにGitを使っています。 数ヶ月以上一緒にやっているある程度ツーカーなメンバーだけのプロジェクトなら問題無いのですが、案件によっては協力会社の方が一時的にJOINしたり、新規参入メンバーの参加などで、これまでGitを使ったことがない、または本格的なチーム開発でGitを使ったことがない人が参加することもあります。 ※2020年現在では流石に全くGitを使ったことのない開発者というのはほぼ見なくなりましたが、チーム開発できちんと運用に乗せて使ったことがない、という所は今でもそこそこあるようです。 Gitは自由度の高いシステムですが、その分概念を覚えることが必要なため、導入の敷居が高い方だと
GitHubのポータブルなクローン「GitPrep 2.3」が、2016年8月6日にリリースされました。 待望の「isseu機能」が追加され。「バグ管理」がGitPrep上で可能になりました。 その他、バグ修正、機能強化が含まれています。 「issue機能」の追加。「バグ管理」が可能に。 マークダウン記法で、テーブルをサポート マークダウン記法で、foo_bar_bazが正しく記述できるようになりました 上部のタブにissuesが追加されています。 ぜひGitPrepのサンプルを試してみてください。ポータブルな本物のGitHubシステムであることが実感できると思います。 GitPrepの特徴 初めて利用される方のために、GitPrepの特徴をご紹介! GitHubのクローン。GitPrepは使い慣れたGitHubと同じインタフェースを持っています issueシステムのサポート ポータブル。
Git操作をGUIで行えるSourceTreeは、私にとって今では無くてはならない存在です。 コレのお陰で、ターミナル恐怖症のデザイナーさんにもGitでファイルの変更を管理してもらえるようになって、デザイナーさんとの連携がとても楽になりました。 もう、これなしでは開発したくないと思えるほど便利です。 でもSourceTreeのいくつかの機能はお世辞にも直感的とは言えず、間違った操作を誘発する危険性をはらんでいます。私もハマって結構大変な目に会いました。 私が、そして私のような方が同じ過ちをおかさないように、ここにハマりそうなSourceTree操作を記録しておきます。 リベース手順 例えば、developブランチから分岐したfeature/hogeブランチで作業している途中で、他の開発者のコミットがdevelopブランチにマージされた場合、後々大きなコンフリクトが発生するのが怖いので、早め
こんにちは、エンジニアの王です。今回は、Git初心者を悩ませるリベースについて解説してみたいと思います。 リベースが初耳 リベースを聞いたことはあるけど、使っていない 不安を抱えながらも、リベースをなんとなく使っている 上記に当てはまる方は、ぜひ読んでくださいね。 リベースで何ができる? コミットが綺麗になる! 以上です! この一言に尽きる! 具体的にどのように綺麗になるかというと…… コミット履歴がわかりやすくなる コミットメッセージを後から変える コミットの順序を後から変える 2つ以上のコミットを1個に統合する 一度コミットした内容を編集する といった具合でしょうか? 整理整頓が好きな方は、ぜひリベースを使いこなしていただきたいと思います! マージとリベース 2つのブランチの変更点を統合するとき、Gitの最も一般的なやり方は、マージとリベースを使うことです。マージは初回で説明したので、
これをみるとinputやfalseはLF -> CRLFの自動変換を行わないので、これらを選んでしまいそうですが、 大規模開発で多数の開発者がtrueでインストールしてしまった場合、わざわざ変更をしてもらうまでの悪影響があるのか?がわからなかったので、それについて調べた結果を記載しようかと思います。また、これを書くきっかけとなった私のチームではまった落とし穴について書こうと思います。 core.autocrlfをtrueに設定をした場合 core.autocrlfをtrueに設定をした場合について整理します。 チェックアウトやコミットした場合の動きや、開発者がCRLFでファイルを作成した場合の動きは以下のようになります。 上記の図から確かにwroking directory上ではCRLFとLFが混在してしまう可能性がありますが、 repository上のファイルがLFである以上、core.
gitで変更した覚えの無いファイルに差分が出ていたので、 作業ディレクトリの変更を破棄したのに、 git statusで差分が出続けて困ったのでメモ。 症状 gitではgit checkout -- <file> ってコマンドを叩くと、 作業ディレクトリの変更を破棄できます。 $ git checkout -- hoge.txt $ git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: hoge.txt
Gitで別々に作ってたリポジトリをコミットログを残したまま1つにしてしまいたい時のめも。 例えばkankore_repoとkuchikukan_repoという2つのリポジトリが別々にあったとします。 これらを別々のリポジトリで管理するのが大変になってきたのでkankore_repo内の'destroyer'ディレクトリに kuchikukan_repoで管理していた全てをコミットログを残したまま入れてしまいたい。そんな感じです。 図で書くと /kankore # kankore_repo リポジトリのあるディレクトリ |--- .git /kuchikukan # kuchikukan_repo リポジトリのあるディレクトリ |--- .git これを ↓ のような感じにしたいのです! /kankore # kankore_repo リポジトリのあるディレクトリ |--- .git |--
平素よりQA@ITをご利用いただき、誠にありがとうございます。 QA@ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA@ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年2月28日(金)15:00をもちましてQA@ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA@ITの7年間で皆さまの知識
ソースコードが既に存在するようなディレクトリ内で git init --bare を実行することは良くない git コマンドの使われ方です。 既に @yasu が挙げたように、config ディレクトリが既に存在していると、件のような実に気持ちの悪いエラーと共に、処理が止まります。 $ mkdir git_share_test $ cd git_share_test/ $ mkdir config $ git init --bare fatal: Out of memory? mmap failed: Invalid argument $ ls HEAD config hooks refs branches description info このエラーが示された時点で、共有レポジトリ用のファイルが生成されてしまっているので、一つ一つ消しましょう。(config 以外) 以下説明。 git
はじめに このようなページを作ってみました。 PC版 スマホ版 いわゆる自己紹介ページというやつです。 なんかポートフォリオというか自分らしさを表現したいと思って作りました。 さらに踏み込んだ内容はブログに書きましたので、見てみてください。 【作ってみた】GitHub.ioで自己紹介ページ で、なにを使って作ったかというとプログラマー御用達のGitHubです。 GitHubにはWebに静的ページを組める様に GitHubPages というものが用意されています。 プロジェクトとレポジトリが一体になっているのでGitHubを使ったことがある人にはわかりやすいかと思います。 GitHub Pagesとは GitHubPagesにWebSiteを公開する方法は二通りあります。 自分のアカウントのページ(User or Organization site) プロジェクトごとのページ(Project
自分で作ったWebページをリポジトリとして公開して、なおかつそのページをGitHub Pagesで表示させる方法です。やってみれば簡単だけどそもそもGitHubほとんど使ったことなかったので時間かかってしまいましたorz 1.ローカルでWebページの作成 公開したいwebページを作ってください。 2.GitHubにリポジトリ作成 GitHubのユーザーページに行って好きな名前でリポジトリを作成してください。 3.ローカルでファイルを追加してadd→commit→push まずは作成したリポジトリをローカルにクローンします; git clone https://github.com/ユーザー名/リポジトリ名.git クローンしたリポジトリのディレクトリに移動してください; cd リポジトリ名 作成したhtmlファイル等をディレクトリ内にコピーしてください。 cssやらjsやらimagesやら
感想。めっちゃよかった。 実際に一通り使ってみた情報をまとめてGitBookで公開までしてみたので、詳細は以下のURLからどうぞ。 gomachan46.gitbooks.io 概要についてはgitbook.com側のページからでも見れて、htmlの他pdfでのDLとかも出来て便利! www.gitbook.com 今回の情報をまとめたリポジトリは以下。 github.com 所感 ちょっとGitBookの良さを活かして階層化とか無駄にして書いたので内容の割に長文化しましたが、とても簡単に、そして良い感じに文書の公開までを行うことが出来ました:) 使い方もはじめに要点だけ抑えてしまえばほぼ難しいことはないので、学習コストもほとんどかからない良いツールだと思います。 gitbook.comとGitBookコマンドが良い感じに分離されているのも素敵ですね。 これから文書をちょっとまとめて書きた
Gitで間違ったコミットをリモートリポジトリに push してしまった後に、それを無かったことにするには、リモート側での作業が必要だと思っていたのですが、ローカルからの操作でもできることがわかったので備忘録的に書いておきます。 次の状態にあるとします。アルファベットはコミットだと思ってください。 リモート: A-B-C master ローカル: A-B-C-D masterローカルで変更を加えてDの状態になっています。 git push すると次のようになるのですが、 リモート: A-B-C-D master ローカル: A-B-C-D masterここで、D は間違いだったと気づきました。 リモートリポジトリの master のバックアップ用のブランチを作ります。これは必須ではありませんが、念のため。 % git push origin master:master_bakこれで次の状態に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く