タグ

gitに関するdiary193のブックマーク (19)

  • Gitと連携するツールとしてのVim - Qiita

    はじめに Vimといえば、みなさんご存じテキストエディタですが、テキストエディタである以前に一つのCLIコマンドでもあります。そんなCLIコマンドの利点一つにThe UNIX philosophyの定理として提唱されている『7. Use shell scripts to increase leverage and portability. (シェルスクリプトによって梃子(てこ)の効果と移植性を高める)』というものがあります。 今回は私も普段の仕事で利用しているVimの梃子としての側面をご紹介できればと思います。 GitコマンドとVim 今回Vimと組み合わせるのはシステム開発で避けては通れぬバージョン管理システムGitです。私は普段Gitを使用するときにはSourcetreeやGitKrakenなどのGUIクライアントを利用せずにCLIで操作をしています。 皆さんこう思われるかもしれません

    Gitと連携するツールとしてのVim - Qiita
  • Git2.0がリリース!一足早く新機能を紹介するよ · DQNEO日記

    Git2.0がまもなくリリースされるようです。 Git v2.0 Release Notes リリースノートをもとに、一足早く新機能と変更点の紹介をしてみます。 (各機能についてはまだ動作確認しておりませんので、ここがおかしいなどあればご指摘ください) 引数なしのgit pushが安全になりました。 When "git push [$there]" does not say what to push, we have used the traditional "matching" semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). In Git 2.0, the default is no

    Git2.0がリリース!一足早く新機能を紹介するよ · DQNEO日記
    diary193
    diary193 2014/03/23
  • Git Subtree: Alternative to Git Submodule | Atlassian Git Tutorial

    Products Featured Developers Product Managers IT professionals

    diary193
    diary193 2013/11/22
    subtree. submoduleとの使い分け方を知るには、submoduleでの問題を知る必要があるな
  • Git Submodules: コアコンセプト、ワークフロー、コツ | Atlassian Japan 公式ブログ | アトラシアン株式会社

    Git を使った開発では、サブモジュールを使うことによって、他のプロジェクトを自分のコードベースに取り込めるようになります。それも、他のプロジェクトの履歴を分離しつつ、あなたのプロジェクトの履歴と同期できるようになるのです。これはベンダーライブラリ問題や依存関係問題を解決する便利な方法です。git に関してはいつもそうですが、このアプローチもかなり自己流なのでうまく出来るようになるまで少しばかり研究することをお勧めします。submodules に関する好例や詳しい説明はすでに公開されているので、ここでまた繰り返すのはやめることにします。この記事では submodule という機能を最大限に活用するのに役立つであろういくつかの面白い情報を共有したいと思います。 目次 コアコンセプト 考えられるワークフロー 初めての人向けの役に立つコツ サブモジュールを自分のフォークしたリポジトリで置き換える

    Git Submodules: コアコンセプト、ワークフロー、コツ | Atlassian Japan 公式ブログ | アトラシアン株式会社
  • Git submodule の基礎 - Qiita

    この記事は 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 submodule の基礎 - Qiita
    diary193
    diary193 2013/11/22
    submodule と submoduleのupdateについて
  • A successful Git branching model » nvie.com

    Note of reflection (March 5, 2020) This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea. Du

    A successful Git branching model » nvie.com
    diary193
    diary193 2013/11/10
  • Git flowの活用事例

    ↓のv1.1.0版の方が、より見やすく改善したものになってます! http://www.slideshare.net/matsukaz/git-28304397 社内で開催したGit勉強会の資料。 SVNとの比較や、Gitの内部構造と各コマンドの関係、ブランチやリモートリポジトリとの関係を分かりやすく説明したつもり。 こういう資料に対する投げ銭的なのがどうなるのか気になっていたので、もしよろしければ・・・!15円からできるソーシャルカンパサービスだそうですm(_ _)m http://kampa.me/t/dev

    Git flowの活用事例
    diary193
    diary193 2013/11/08
  • cloudpack Night #7で発表しました / Roadworkerというツールを作りました - so what

    cloudpack Nightの発表資料 Gitを使ったRoute53の管理 from Sugawara Genki Roadworkerについて Chef/Puppet的にRoute53を管理するツールです。 Git使ってRoute53を管理できるようになります。 https://bitbucket.org/winebarrel/roadworker http://rubygems.org/gems/roadworker

    cloudpack Night #7で発表しました / Roadworkerというツールを作りました - so what
  • GitHubとJenkins連動 自動デプロイ 開発環境設定編 at ITエンジニアmegadreamsの開発日記

    前回の記事でGitHubとJenkinsを用いた自動デプロイ環境の概要をご説明しました。 GitHubやJenkinsと連携した開発環境作成でのrsyncとの出会い 今回は、その環境を実現するための設定手順を書いて行きたいと思います。 大きく4つの手順があります。 Jenkinsのインストール Apacheの設定 JenkinsとGitHubの連携 自動デプロイ設定 開発環境 ・CentOS 6.2 ・Apache がインストール済み Jenkinsのインストール まずは、Jenkinsのインストール 通常ならば、運用するサーバとJenkinsが動いているサーバを分けるべきですが、サーバコストの都合などで今回は同一サーバ上で動かすことにします。 ApacheサーバとJenkinsサーバが同じport80で待つことはできないので、jenkinsをport:8080で動かすことにします。 また

  • 脱GitHub初心者を目指す人のREADMEマークダウン使いこなし術 | ゆっくりと…

    README がキチッと書かれているプロジェクトって、どんなに小さくても立派に見えますよネ。 GitHub の場合、大抵はマークダウン記法で書かれた README.md とか README.markdown とかいう名前のファイルが、HTML に変換 (マークアップ) されて表示されていることはご存知でしょう。 マークダウン記法自体はとても簡単なのですが、GitHub では GitHub Flavored Markdown (略して GFM) という GitHub 用にアレンジされたマークダウン・エンジンが採用されていて、一般のマークダウン・エディタでチェックしてからコミットしても、意図通りの見た目にならないことが多々あります。私 (もちろん GitHub 初心者です!) の場合、README ファイルだけで10回以上もコミットしてしまいました。「マークアップ (レンダリング) を気にして

  • CUI で Git 使うなら入れておきたいツールまとめ | バシャログ。

    ブランコ と同い年だったことが判明しました。みなさん、こんにちは nakamura です。あいつも昭和 55 年会か・・・。 Git をコマンドラインで使う利点は色々ありますが、git コマンド以外にも便利なツールがいくつかあるっていうのもひとつかなと思います。今日はそんな中でも個人的にこれないと困るわーっていうのを独断と偏見でご紹介したいと思います。 tig Index of /tig これはけっこう有名かも。いわゆるリポジトリブラウザです。カラフルで見やすいし、その場で任意のコミットの差分も見れちゃうのでリポジトリブラウザとしては git コマンドよりも格段に高機能です。 gitolite Hosting git repositories sitaramc/gitolite gitolite は Git リポジトリを管理するためのツールです。ドキュメントを少し読んでみれば分かりますが、

    CUI で Git 使うなら入れておきたいツールまとめ | バシャログ。
    diary193
    diary193 2013/05/18
  • GitとJenkinsを使ってChefを運用する - GeekFactory

    Chefはリポジトリをバージョン管理する仕組みを持っていますが、チームでの協調作業を考えるとバージョン管理システムを使う方が運用しやすいと考えます。稿では、GitとJenkinsを使ってChefを運用するための1つのパターンを考えます。 以下があることを前提とします。 Chef Server Chef Client Gitリポジトリ Jenkins 基的な考え方 CookbookをGitリポジトリで管理します。開発者がgit pushすると同時にChef ServerのCookbookが更新されるようにします。これにより、GitリポジトリとChef Serverが同期されるようになります。 また、後続ジョブとして各サーバでChef Clientが実行されるようにします。ビルドパイプラインを組むことで、Staging EnvironmentにおけるChef Client、Producti

    GitとJenkinsを使ってChefを運用する - GeekFactory
    diary193
    diary193 2013/03/02
    JenkinsをObserverにしてChef Cookbookの適用を行う、なるほど。aws的にはSNSとSQSを使うとこだろうけど、ジョブの履歴と紐づいたログが残せるのがJenkinsを利用したときのメリットか。
  • github/gitignore at master - GitHub

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    github/gitignore at master - GitHub
    diary193
    diary193 2013/02/26
  • git stash save で一時退避した変更を、誤って git stash clear で消してしまったときの回復法 - t-wada の日記(旧)

    一年くらい前から git を使い始め、ここ半年くらいは毎日の開発に git を使っています。昨日 git stash という機能を使っている時に失敗してしまい、何人かの方にアドバイスいただくことによって無事回復することが出来たので、感謝の印として、そして運悪く同じ問題に遭遇してしまった人たち(私もまたやるかも)へのメモとして記しておきます。 御託はいいから、早く回復法を知りたい人のためのまとめ $ git fsck | awk '/dangling commit/ {print $3}' 候補の sha1 がいくつか出てくる(長く開発していると、結構多く候補が出てきます) $ git show --summary 候補のsha1 一つ一つの sha1 の内容を確認 $ git cherry-pick -n -m1 見つけたsha1 いきさつ 私の作業のやりかたでは、 タスク毎にブランチを切

    git stash save で一時退避した変更を、誤って git stash clear で消してしまったときの回復法 - t-wada の日記(旧)
    diary193
    diary193 2013/02/02
    git stash clear した場合の復旧方法
  • こわくない Git

    「マージがなんとなく怖い」「リベースするなって怒られて怖い」「エラーが出て怖い」 Git 入門者にありがちな「Git 怖い」を解消するため、Git のお仕事(コミット、ブランチ、マージ、リベース)について解説します。Read less

    こわくない Git
    diary193
    diary193 2012/11/23
    mergeとrebaseの仕組みと比較。丁寧で分かり易い。CVSやSVN出身なのでrebaseは知らなかったし使うこともないだろうと思ってたけど、GitHubなどでpull requestする場合のマナーらしい。気に留めておこう。
  • プロとしての行為 Act as Proffesional

    Gitのブランチをどのタイミングで切って、マージしていくかなども非常に大切ですが、ブランチやマージをするよりも頻繁におこなうコミットについて、あらためて基に立ち返ってみましょう。 一つ一つのコミットを綺麗に積み重ねていくことは、ブランチを切るタイミングやマージ、歴史の改編などを容易にすることができます。コミットが綺麗に積み重ねられていないとマージや歴史改変で苦労するでしょう。 Gitのベストプラクティス(原文)に乗っかるためにもgit commitする前に以下のようなことをチェックしましょう。 Gitの操作に慣れている人はPushやMergeをする前に今回紹介するようなことを元にしてコミットの歴史を綺麗に整えましょう。 1コミットに1つの対応1コミットにはあれこれ詰め込めすぎるべきではありません。例えば以下のような2つのことがあったとします。 Aの機能を追加Bの機能のバグを修正2つの対応

    プロとしての行為 Act as Proffesional
    diary193
    diary193 2012/09/05
    はてブコメント的にはgit commitはお手軽に、git pushの際に意識しろってことらしい
  • Gitのベストプラクティクスっぽいもの - Sexually Knowing

    tbaggery - A Note About Git Commit Messages A successful Git branching model » nvie.com Commit Often, Perfect Later, Publish Once—Git Best Practices だいたいこれらに書いてあることを考えている。 基的にGit Successful Branch Modelで運用する。git-flowを入れて使っているけど、手でやってもそんなに面倒ではないし好きなようにしたらよさそう。 Subversionを個人で使っていたころはブランチはよくわからないけど恐しいものだったけど、Gitを使いはじめてだいぶ親しめるようになった。 文字通り、ブランチ、枝である。気軽に扱えるということは理解の助けにもなる。 コミットの単位 論理的に最小限度のコミットをつくる。「こう

    Gitのベストプラクティクスっぽいもの - Sexually Knowing
    diary193
    diary193 2012/04/11
    「コミットの単位は自分の脳のバッファの量に合わせる」
  • ソーシャル化するOSS開発者たち - @IT

    ロング・テール理論の名付け親で、雑誌「Wired」の編集長としても知られるクリス・アンダーソン氏が3月12日付けのブログでオープンソースソフトウェア(OSS)プロジェクトの運営体制に関する誤解を指摘をしている。 アンダーソン氏によれば、多くの人はオープンソースプロジェクトというのは草の根から立ち上がり、自律的に組織化し、民主的に運営されているという誤った認識を持っている。ところが現実はまったく逆で、1人か2人の「慈悲深い独裁者」によって運営されている、という。 これはオープンソースプロジェクトに参加していたり、あるいは日常的に成果物を利用している人であれば、そういうものだと首肯するかもしない。メーリングリストで客観データに基づいて議論したり、リーダーを民主的に選ぶようなプロジェクトもあるかもしれないが、おおかたのオープンソースプロジェクトには、それを開始し、中心に位置し続ける“独裁者”がい

  • Git(ギット)勉強会メモ - kinneko@転職先募集中の日記

    さすがに開発者は的確な解説と、質問にもズバズバ答えるのだなぁ。 Gitのメンテナが日人の方だったというのは、今回はじめて知りました。 プレゼン資料については、アメリカに帰られたらWebで公開されるということでしたが、PDFで分けてもらったので、ご希望の方がいれば送ります。中身は英語ですが(^^;。 # さっそくアップロードされたようです。http://www.kernel.org/~junio/200810-tut.pdf というわけで、twiterでメモを流していたけど、途中で挫折したので、手元のメモを貼っておきます。 間違いがあったら指摘してね。 自分用メモなので、意味不明なとこはご勘弁を。 gitギット。イギリス英語で「やなやつ」。 kernel bitkeeper商用のバージョン管理システムを使っていた。 方針がかわって、無料で使えなくなってしまった。 svnを使うの?cvsを使

    Git(ギット)勉強会メモ - kinneko@転職先募集中の日記
    diary193
    diary193 2008/10/07
    Linuxカーネル界隈の話かと思ってたら思いの外メジャーになりつつあって驚き
  • 1