タグ

GitとSCMに関するlibero18のブックマーク (27)

  • Gitの仕組み - homebrewをフォークするためのGit&GitHub入門 中編 - A Way of Code

    前回:Gitのセットアップ 前回、GitHubを使うためのセットアップをしていきました。 今回はGitGitHubを学んでいきます。 (さらに次回はhomebrewをforkしていきます) 注意: Gitを知らない人がいきなりGitHubを触ったときのメモなので、間違っているところがあるかもしれません。 CVSやSubversion等のバージョン管理ツールの知識がある前提で書いています。 あくまでメモなので説明が至らないところが多々あります。ざっと読み流して、Gitを実際に触ってから読み返したほうが分かりやすいと思います。 目次 1. Gitの構成 1.1 リポジトリ 1.1.1 blobオブジェクト 1.1.2 treeオブジェクト 1.1.3 commitオブジェクト 1.1.4 tagオブジェクト 1.2 ステージングエリア 1.3 作業ツリー 2. リモートリポジトリとローカルリ

    Gitの仕組み - homebrewをフォークするためのGit&GitHub入門 中編 - A Way of Code
  • Gitのセットアップ - homebrewをフォークするためのGit&GitHub入門 前編 - A Way of Code

    homebrewのFormulaを直したくてフォークしようと思いっ立ったものの、GitGitHubの使い方が分からなかったのでメモしました。 フォーク homebrewを使っていると、欲しいパッケージ(Formula)が無かったり、オプションパラメータを直したくなることがあります。 そんなときはGitHubでフォークしましょう。 フォークをすると、homebrewのオリジナルを自分のGitHubにコピーして編集することが出来ます。さらに、追加あるいは編集したFormulaは、pull requestをすることで、家にマージしてもらうように依頼できます。configureの調整で苦戦したあなたの労力は無駄じゃないんです!(鼻息荒く 目次 1. GitHubアカウントの作成 2. Gitのインストール 3. SSHキーの設定 4. Gitの設定 1. GitHubアカウントの作成⇒アカウン

    Gitのセットアップ - homebrewをフォークするためのGit&GitHub入門 前編 - A Way of Code
  • バージョン管理のワークフロー

    新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?naoki koyama

    バージョン管理のワークフロー
  • はじめてgitをつかったのでコマンドを復習します

    はじめに こんにちは川崎です。最近はじめてgitを使う機会がありましたので復習してみます。 このエントリーは私がgitを使い始めたばかりのログを元にして、まとめた内容にしています。 gitをインストール、コマンドを使う準備 gitを使うにはgitのインストールが必要です。使っている環境に合わせてgitをインストールします。 私の環境はmacなのでportsでインストールしました。 $ sudo port -d selfupdate $ sudo port install git-core +gitweb +svn インストールが完了したかどうかはgit --versionコマンドで確認できます。 $ git --version git version 1.7.3 gitのversionが表示されたのでインストールされているようです。準備完了です。 はじめてgitを使うときは gitを使うた

    はじめてgitをつかったのでコマンドを復習します
  • Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineering

    こんにちは。インフラの sotarok です。 先日から Git 関連の話をしている通りですが、社内で Git を使い始めています。 今日は、Git を使った日々の開発〜リリースまでのフローや、そうしたものの運用と、それをサポートするために作ったツール git-daily の紹介をしたいと思います。 ソフトウェア開発とウェブ開発の違い いやウェブ開発も広義のソフトウェア開発なのですが、ここでいうソフトウェア開発とは、クライアントアプリケーションやライブラリのようなものを指すと思ってください。 実際、ウェブ開発をしている方は感じていることだとは思いますが、両者の開発フローはかなり異なるものです。もちろん社風や開発の方針等によって色々あるとは思いますが、主に次のような特徴が挙げられると思います: ソフトウェア開発 アプリケーションはクライアントで動作する リリース間隔は比較的長く、次のバージョ

    Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineering
  • Gitを使った分散開発管理15 – git-flowを使ってみる | DevelopersIO

    git-flowを使ってブランチの管理 いままでGitについてのさまざまな機能をご紹介してきました。 まだまだほかにも機能があり自由なスタイルでソース管理できるGitですが、自由すぎてどうしようか迷うかもしれません。 今回ご紹介するものは、実際に開発を進めていく中での運用を補助するプラグイン、 git-flowについてご紹介します。 git-flowとは? 「A successful Git branching model」※1 と呼ばれるGitのブランチモデルでの運用を補助するプラグインです。 このモデルにそったgit-flowのブランチモデルは下記のような特徴があります。 中央リポジトリとみなす、originを用意 originはmasterとdevelopのブランチを持つ masterはリリース用のブランチで、リリースしたらタグ付けする。(SVNでいう trunkとtag) deve

  • git-flow によるブランチの管理

    今回は分散バージョン管理システムgitと共に用いる「ブランチモデル」について紹介していただきます。gitを使ってみて、その高機能さをどう使えば良いか悩まれた方は、ぜひ稿をご一読ください。gitそのものの使い方については解説していませんので、その際には『 実用git 』などの書籍を参考にしてください。 git-flow は Vincent Driessen 氏によって書かれた A successful Git branching model (O-Show 氏による日語訳) というブランチモデルを補助するための git 拡張です。 git-flow を利用する前には、まずこの文章を一読することをおすすめします。 その骨子については、 Voluntas 氏のブログ が参考になります。 git を使うメリットの 1 つは、そのブランチモデルです。しかし gitを使っていると、その高い柔軟性か

    git-flow によるブランチの管理
  • A successful Git branching model を補助する git-flow を使ってみた - Twisted Mind

    git-flow という git の運用を補助するプラグインを使ってみたので、その過程をメモしてみました。 そもそも git を採用理由なども書いていきたいと思います。 git を採用した理由 まず何よりも git を採用した理由ですが、日語のがたくさんある。Subversion のように気軽にブランチを切ったりマージが出来ない方法では「開発スピードにバージョン管理がついてこれない」という結論に至りました。 そこで svn から git へ以降の準備を進めています なぜ hg や bzr ではないのか git-svn を前々から使っていて rebase のありがたみや branch を気軽にきる運用になれていたからというのもありますが、なにより身近に詳しい人が多いというのが一番です。 Tower や GitX という素敵な GUI があるのも魅力の一つですね。 A successful

    A successful Git branching model を補助する git-flow を使ってみた - Twisted Mind
  • Git入門 ゼロから始めるGitドリル

    gitの勉強をしつつ取ったノートを記事化しました。一応これを読めばざっくりとした導入やSVNとの違いが分かってもらえるように書いたつもりです。svnを使った経験があることを前提に進めていきます。 svnの場合、一つのレポジトリに対して認証のあるユーザが変更を報告していくユースケースをとっています。gitの場合は、個々のローカルマシンにリポジトリが分散されて配置され、お互いに変更を報告しあうユースケース。これはLinuxの伝統的なバザール方式の開発を想定しています。そのため例えばカフェや電車で開発したり、マスターはgithubやgitfarm(Git Hosting参照)にしておいて時々ローカルの変更を報告することも可能です。 目次 インストール 基操作 Gitリポジトリの作成 ブランチの作成。 タグ ファイルを無視する 索引の理解 取り消し 導入 --hardと--softの違い 一個の

    Git入門 ゼロから始めるGitドリル
  • msysGitのGit bashで日本語を使えるようになるまで - sinsengumi血風録

    最近、ようやくGitを使い始めました。サクサク感があっていいですね。あとGithubの存在が大きい。 で、表題なんですが、 僕はWindows派でmsysGit使ってるわけですが、デフォルト状態(Git Bash)ではコミットログの日語が化けて出たりと何かと不便です。 そこで、いろいろ設定して日語が表示できるようになろうという感じです。 lessとnkfをインストール 以下を参考に、lessとnkfを導入します。 http://sourceforge.jp/magazine/09/02/12/0530242/3 inputrc set meta-flag on set input-meta on set output-meta on set convert-meta off set kanji-code utf-8 profile export GIT_PAGER="nkf -s |

  • Git日本語対応備忘録

    ※2012/4/12追記 UTF-8対応版のGitが正式にリリースされたので、この記事の手順は基的に不要になります。 詳しくはこちらをどうぞ。 Git-1.7.10-preview20120409.exe のGit Bashで日本語入力する方法 — 久々にGit環境作ったら日語対応方法を忘れていたので、自分のためにメモ。 Gitのインストール UTF-8ファイル名対応版 Git for Windowsからダウンロードし、msysGitをインストールします。 まずは日語を扱えるようにする Gitのインストールが終わったら、次にGit Bashで日語が扱えるようにしましょう。 nkfのダウンロード、インストール nkf.exe nkf32.dll Windows用の詳細情報 : Vector ソフトを探す!などからnkf.exeをダウンロードし、%ProgramFiles%\Git\b

    Git日本語対応備忘録
  • コミットメッセージの書き方 - 2012-02-21 - ククログ

    はじめに 「分かりやすいコードを書く」、「コードと一緒にテストも書く」等はソフトウェア開発において大切なことです。しかしそれと同じくらい大切なことして「分かりやすいコミットメッセージを書く」があります。これはあまり着目されていなく、見過ごされていることです。 今回は、コミットメッセージの分かりやすさの大切さ、そして、分かりやすくするための書き方を説明します。 コミットメッセージとその大切さ バージョン管理システムとコミット 現在、ほとんど全てのソフトウェア開発ではSubversionやGitなどのバージョン管理システムを使っています。バージョン管理システムを使うことによるメリットというのは、ソフトウェアの変更が記録されていくことにあります。 具体的なメリットは3つあります。 ソフトウェアの調査がしやすくなることです。現時点でのコードと、そして変更の履歴とを組み合わせることで、それらから非常

    コミットメッセージの書き方 - 2012-02-21 - ククログ
  • git初心者向けのTipsなど - os0x.blog

    gitの基的なcommandしか使ってないって人向けのtips集です。 エイリアスの設定 $ git config --global alias.co "checkout" とすると、 ~/.gitconfig に [alias] co = checkout のように追記されます。 このようにgit configを叩いてもいいですし、~/.gitconfigを直接編集しても大丈夫です。 とりあえず、 [alias] co = checkout # checkout長い… st = status -sb # シンプルなstatus pr = pull --rebase # pull するときにmergeコミットを作らない fo = fetch origin ro = rebase origin # branchでfoしてroすればmasterにrebaseできる rc = rebase -

    git初心者向けのTipsなど - os0x.blog
  • GitHubへpull requestする際のベストプラクティス - hnwの日記

    みなさん、Git使ってますか?僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、

    GitHubへpull requestする際のベストプラクティス - hnwの日記
  • msysGit(Git for Windows)がいよいよ公式に UTF-8 をサポート! - てっく煮ブログ

    git最近、Git について勉強しています。Windows で Git をやるなら Cygwin と msysGit(Git for Windows) がメジャーなようです。Cygwin Git のいいとこ悪いとこCygwin は UTF-8 な日語ファイル名にも対応しており、Cygwin の中で閉じて Git を使っている分には何不自由なく使えるのでお勧めです。ただし、次のような悲しいポイントがあります。 Cygwin 版 Git は、Windows 向けの GUI な Git ソフト(TortoiseGit や Git Extensions)との相性が悪い Windows のエディタやマージツールと連携しようとするとパスのポリシーが違うのでうまくいかないnkf を噛ませようとしても、Cygwin 用の nkf バイナリは公式配布されておらず、わざわざ Cygwin 上で make す

  • 「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とビールとパンケーキ by @sotarok

    チーム開発において、「チケット/Issue」「TDD」「コードレビュー」など、ソースコードの変更に対する効果的な開発フローについてよく考えるのだけど、なんにしてもこのあたりは非常に課題が多く、各社各コミュニティで色々なやり方が模索されているポイントだと思う。 で、まぁご多分に漏れず僕もよく考えるわけだけど、現状その過程で Pull Request こそが非常に効果的なのではないか、と思うので、ちょっとまとめてみようかと思う。 もちろん、言うまでもないようなことだよ、という人もいるかもしれないけど、そういう人がたくさんいると、非常に喜ばしいことだね。 Pull Request とは GitHub でこう呼ばれているので、こう呼ぶことにするが、ここでは、複数のリポジトリ/ブランチ間でのオープンな patch のやりとりのことだと考える。 あと、自分が使っているのが Git なので、ここでは G

    「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とビールとパンケーキ by @sotarok
  • GitHub - hatena/Git-for-Designers: はてなのデザイナ向けの Git 入門ドキュメントです。

    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 - hatena/Git-for-Designers: はてなのデザイナ向けの Git 入門ドキュメントです。
  • git - 簡単ガイド

    アッド & コミット 変更されたファイルを選択します。 git add <filename> git add * を実行するとIndexに追加されます。 これは基的な作業の一つです。 変更を実際に適用するには git commit -m "Commit message" を実行します。 変更がHEADに入りましたが、 リモートリポジトリには未だ入っていません。 変更のプッシュ この時点で、変更がローカルリポジトリのHEADに適用されました。この変更をリモートリポジトリに適用するには git push origin master を実行し、masterの代わりに適用のブランチ名を入れます。 もし既存リポジトリをクローンせずに使用した場合 git remote add origin <server> を実行すると、リモートリポジトリを登録する事が可能です。 これで変更を特定なリモートリポジト

  • Git/Github超入門:猿でもできるPull Request · DQNEO日記

    Git/Github初心者のみなさんこんにちわ! Pull Requestを送ってみたいけど、やり方がわからない? 間違ったPull Requesするのがこわくて躊躇している? もったいない! そんなみなさんに、Pull Requestを送るための最小の手順をご紹介します。 昨日ちょうどEthnaにPull Requestを1件送ったので、これを題材にして説明します。 以下、Githubのアカウント取得、gitのインストール、SSH鍵の設定は終わっているものとして解説をすすめます。 Pull Requesを送る最小手順 1.ブラウザでプロジェクト画面を開きます。 例:https://github.com/ethna/ethna 2.forkボタンを押します。 3.以下、自分のPCで作業 git clone git@github.com:DQNEO/ethna.git cd ethna

    Git/Github超入門:猿でもできるPull Request · DQNEO日記
  • Git初心者が絶対に覚えておくべきコマンド - idesaku blog

    Gitの使い方を覚えるにあたって、まず知っておきたいのは――git-cloneだのgit-commitだのは当然として――「操作をミスったときにどのように回復するか」である。それを実現するのは、次の3つのコマンドだ。 git-commit --amend git-reset git-reflog git-commit --amend あるファイルをコミットしたとしよう。 $ (edit...) $ git commit -am 'メッセージ生成処理を実装したよ。'しかし、しばらくして彼は気づいた。 def create_massage(param) ...typoしてる!massageじゃない、messageだ!マッサージを作ってどうする! 慌てるな。まずは直してステージに上げるんだ*1。 def create_message(param) ...$ git add .そして…。 $ gi

    Git初心者が絶対に覚えておくべきコマンド - idesaku blog