タグ

gitに関するegakuのブックマーク (12)

  • 君には1時間でGitについて知ってもらう(with VSCode) - Qiita

    おことわり この記事はプログラミング&業務未経験の新入社員に、Gitについて1時間程度で説明した内容をもとに作ったものです。自分がもし誰かにGitについて教えて貰える立場にいたら、最初にこれを教えて貰いたかったという気持ちで作りました。 とりあえず「1人のプロジェクト」で「1時間で」Gitをそこそこ知って使えるようになることを目的としています。実際のチーム開発ができる水準までこの記事だけで達することはできませんが、今後Gitを使う必要がある人にとって学習の足がかりになれば幸いです。 それと、新入社員に教えるという都合上、表現がやや正確でなくざっくりしたところがあるかもしれませんが、質の悪い誤解を招くようなものでなければご容赦下さい。 全体像 まずはGitとは何かをざっくり分かって貰った後で、VSCode上での操作を行って頂きます。 Windowsでの説明を行いますが、Macの方は適宜読み替

    君には1時間でGitについて知ってもらう(with VSCode) - Qiita
    egaku
    egaku 2019/05/15
    GitとGitHubの違い
  • 分散バージョン管理Git/Mercurial/Bazaar徹底比較

    分散バージョン管理Git/Mercurial/Bazaar徹底比較:ユカイ、ツーカイ、カイハツ環境!(3)(1/5 ページ) Subversionとは一味違う「分散バージョン管理」とは? 最近、Linuxをはじめ、Ruby on RailsMySQL、OpenSolarisなどのオープンソースプロダクトが次々と分散バージョン管理システムを導入し始め、「Git」「Mercurial」「Bazaar」といった、分散バージョン管理システムが注目を浴びています。 稿では、バージョン管理ツールのデファクトスタンダードであるSubversion(以下、SVN)と分散バージョン管理システムを比較しながら、メジャーな分散バージョン管理システムであるGit、Mercurial、Bazaarについて紹介していきます。 集中型と分散型 最初に、集中管理方式(または、集中型)のバージョン管理システムと分散管理

    分散バージョン管理Git/Mercurial/Bazaar徹底比較
  • GitoriousとRedmineを使った開発 - ひかえめプロジェクト

    注意: このマニュアルは完成版ではありません. 準備 サーバ管理者がやること Gitorious及びRedmineを運営しているサーバ管理者が最初にするべきことを示します.まずは,プロジェクトのリモートリポジトリをGitoriousに作成します. どこかで git init masterブランチ,developブランチを作成 Gitoriousで新しいリポジトリを作成(このリポジトリがプロジェクトのリモートリポジトリとなります.) 作成したリポジトリにmasterブランチとdevelopブランチを push ここまでで,プロジェクトのリモートリポジトリが完成です.続いて,このリモートリポジトリとRedmineが連携できるように設定します. Gitoriousはリモートリポジトリをハッシュ値のパスで管理しているので,分かりやすいパスで参照できるようにする 参考 リモートリポジトリにフックスク

  • Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineering

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

    Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineering
  • 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 ブランチ操作のまとめ

    個人的なメモ その2 その1は [2010-04-29-1] にあるよ。 Git では、たった一日の作業でもブランチを作ることが良くある。基ランチは修正が終わったら master に merge して削除、つまり使い捨て。 別な作業が入ったら、master から新たにブランチを作る。 cvs とか svn だと、作業単位毎にディレクトリを掘って cvs checkout と かしていたけど、Git はこれをブランチ操作のみでできる点が超便利。 ただ、他に違わず、ブランチ操作も複雑なのでメモメモ。 (1) ローカルブランチの確認 % git branch (2) リモートブランチの確認 % git branch -r (1) + (2) % git branch -a (3) ローカルブランチ bar の作成 % git branch bar (4) ローカルブランチ bar への切り

  • アリスがチャレンジなコードを書く時、git branchをちゃんと理解したい! - ザリガニが見ていた...。

    アリスとボブのGitシリーズがになりました! アリスとボブのGit入門レッスン アリスは迷っていた。現状のshowメソッドは固定されたメッセージしか出力しないが、理想的にはユーザーの条件によって変化させたいと。 しかし、その機能を実装するためには結構な大改修になってしまう。果たして今の自分の技術でちゃんと完了させることが出来るだろうか?この機能追加をやるべきか、このままにするか...。 アリスはこの修正が失敗に終わった時のことを考えて、ボブに連絡しておくことにした。「失敗したらごめんね。」と。(なんて無責任なアリス...。) 連絡を受けたボブは、アリスの機能追加には大賛成。ボブ:「ただし、新しいブランチを追加して、そこで作業くれ。」と。アリス:「ブランチ???」 アリスはブランチを理解できていないが、とりあえず、ボブに説明された手順をそのままやってみることにした。アリス:「習うより、慣れ

    アリスがチャレンジなコードを書く時、git branchをちゃんと理解したい! - ザリガニが見ていた...。
  • せっかちな人のための git 入門 - git をインストールし、共同で開発できる環境を整えるまで - 僕は発展途上技術者

    subversion に代わる新しいソース管理システムということで git が注目されているようだ。 » Git - Fast Version Control System subversion と大きく違うところは、分散されたレポジトリがローカルマシンに置かれている点。これは、ネットにつながっていなくてもソースをコミットできるということで、最近は電車のなかでもコードを書いたりする僕にはうってつけ。 マニュアルやチュートリアルは充実しているのだが、僕はとりあえず最初にツールを触ってみて、ざっと全体像をつかみ、それから細部を調べたい質なので、もっとてっとり早く体験できるガイドを探したところ、あまり適切なものが見つからなかった。 そこで、レポジトリを作り、それをリモートにあるサーバーに置いたあと、subversion で言えば svn commit や svn update などにあたるコマン

  • TortoiseGit - MikanLibraryWiki

  • tortoisegitでclone実行時に「Network error: Connection timed out」のエラーが表示され失敗する(WindowsXP)

    gitプロジェクトを管理することになったので、tortoisegitを入れてみました。 cloneを実行してプロジェクトを落とそうとしたとき、PuTTY Fatal Errorがでて失敗したので、 その時の解決方法です。 環境 WindowsXP TortoiseGit 1.5.2.0 git version 1.7.0.2.msysgit.0 PuTTY 0.60-JP_Y-2007-08-06 ちなみに、 PuTTY Fatal Error 「Network error: Connection timed out」 のエラーダイアログの「OK」ボタンを押すと↓のようなエラーが表示されました。 git.exe clone --progress -v "ssh://プロジェクトURL" "C:\Documents and Settings\sakuma85\workspace\test

  • 私がSubversionをやめてGitに移った理由 | エンタープライズ | マイコミジャーナル

    Javalobby - The heart of the Java developer community バージョン管理システムにGitやMercurialなどの比較的新しい分散型バージョン管理システムを採用する事例が増えている。もともとOSSプロジェクトで採用するバージョン管理システムは中央集権型のCVSが多かった。しかしCVSは厄介な面もあり、こうした問題を解決した同じく中央集権型のSubversionがCVSの次期候補として注目されていた。 CVSからGitへ、Fedora 13以降 止まらないGit人気、JRubyも移行 - 対抗馬はMercurial Git人気が止まらない、今度はGnome Gitバージョン管理システム採用拡大、Perl 5も移行 7つのバージョン管理システムを知る しかし現在のところ、バージョン管理システムは分散型のMercurialとGitに注目が集まって

    egaku
    egaku 2011/07/04
  • A successful Git branching model を翻訳しました

    Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら: http://nvie.com/posts/a-successful-git-branching-model/ (翻訳の公開と画像の利用は人より許諾済みです) このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト仕事でもプライベートでも)で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書

    A successful Git branching model を翻訳しました
    egaku
    egaku 2011/07/04
  • 1