Gitを用いてVisual Studio開発をしよう
ソースコードの変更管理ツールを使いこなすことはエンジニアにとって重要なスキルです。これまで、バージョン管理といえばSubversionがよく利用されていましたが、最近ではGitが人気を集めています。最新版のVisual StudioにおいてもGitが標準でサポートされるようになり、MicrosoftもASP.NETや.NET Core Frameworkの開発をGitHubで行っています。そこで本稿では、Visual StudioでGitを使用する方法についてチュートリアル形式で解説します。 クライアントツールとして「Visual Studio Express 2013」を、Gitのリモートリポジトリとして「Visual Studio Online」を使うことで、無料で簡単にGitの使い方を学ぶことができます。 Gitについて Git（ギット）とは、Linuxで有名なリーナス・トーバルズ氏
GitBucket - 立ち上げ簡単なScala製GitHubクローン
GitHubを使ってプロジェクトのソースコードを管理しているというケースが多くなっていますが、それでもコードを外部サービスに配置してはいけないといった規定があるケースは多いです。そうなるとGitHubを使うことはできません（Enterprise版を買えばいけますが）。 しかしGitで管理し、さらにWebベースの使い勝手が良いUIが欲しい…なんてわがままを考えてしまう方に使ってみて欲しいのがGitBucketです。 GitBucketの使い方 GitBucketはScala製で、TomcatなどのWebアプリケーションサーバと連携できます。さらに単体でも動作が可能で、Mac OSXであればHomebrewでインストールできます。 $ brew install gitbucket インストールが終わって立ち上げると、 http://127.0.0.1:8080/ でサーバが立ち上がります。 な
Git入門 v1.1.0
Frontrend Vol.6 powered by CyberAgent, Inc. http://frontrend.doorkeeper.jp/events/6907 で発表したプレゼン資料です。 こういう資料に対する投げ銭的なのがどうなるのか気になっていたので、もしよろしければ・・・！15円からできるソーシャルカンパサービスだそうですm(_ _)m http://kampa.me/t/dev
git の運用指針 - Cube Lilac
ソフトウェア開発に関しては、これまでほぼ一人で完結していた*1ので git の運用方法もかなり適当だったのですが（ただのコミットマシーン状態）、今回、同一プロジェクトに対して複数人でコミットしていく形になっているので、その状態だとやはりまずいなと言う気がしてきました。ググっていると「なるほど」と思う記事もたくさんあったので、それらの記事を元に自分のプロジェクトの「git の運用指針」を情報共有のために記載しておこうと思います。 前提 まず始めに、現在のプロジェクトの状況は下記のようになっています。 開発は 1 人のメインコミッタ（私）と数人のサポートコミッタ（アルバイト等）で行われる メインコミッタはフルタイム、サポートコミッタは週に数時間〜10時間程度の勤務形態 サポートコミッタに対しては、基本的に 1 機能（1 チケット）を 1 人で完結するように作業を配分するが、時間的な兼ね合いもあ
特集：GitHub通のためのリニューアルまとめ – ビジネスを成功に導く5つの仕掛け | ゆっくりと…
これまでも サービスAPI の更新や、それに伴う UI の変更など、小刻みな機能向上が図られていましたが、昨年11月、GitHub の ヘッダ、フッタが新しくなった のを皮切りに、12月には Gist のリニューアル と GitHub トップページのリニューアル が立て続けに行われました。 また今年1月には、ユーザー数が、アカウントベースで300万人を超えた そうです。 小さくかつ素早く、不断のサービス向上を図る姿勢が、ここまでユーザーを惹き付けた理由なのでしょう。 一方、公式ブログ を追いかけていくと、単に Git のリポジトリ・サーバーとして便利で使い易くする以上に、「自然に人が集まる魅力的なコミュニティ」を目指し、「誰もが気軽に参加できるオープンソース・コミュニティを創る」という意気込みのようなものを感じました。 人が集まれば、それだけビジネスの機会も増えるというワケです。 そこで今
GitHub創設者が語る"立ち上げから利用者300万人までの軌跡" に行ってきた。 - techlog
GitHub創設者が語る"立ち上げから利用者300万人までの軌跡" に行ってきた。 GitHub創設者が語る"立ち上げから利用者300万人までの軌跡" | PeaTiX togetterはこちら。 GitHub創設者が語る"立ち上げから利用者300万人までの軌跡" - Togetter 印象に残ったことだけピックアップして書く。 立ち上げから利用者300万人までの軌跡 PJ Hyett(Github, Inc. COO) Scott Chacon (Github, Inc. CIO) Err the blog クリスと一緒に立ち上げたブログ。これを通じてRubyコミュニティのなかでは有名になった。 大企業が嫌で Err Free というRubyのコンサルをやる会社を起こした。でもコンサルはクライントが上司になるようなものだった。 dogtimeという犬向けのソーシャル・ネットワークを作った
paperboy & co.でやったこと - Simple, Slowly
paperboy & co.（以下、ペパボ）に入社して6ヶ月が経ちました。 ちなみにペパボはどんなことをやっているかというと、サイトのホスティングやドメインの提供など、主にインターネットの場所を提供することをやっています。 僕は担当しているサービスは昔からあるサービスでレガシーコードなのです。 で、この6ヶ月で業務をやりつつ開発環境の改善をけっこう頑張ってやっていました。 入社当時はどんな状態かというと、以下のような感じです。 一つの環境をみんなで開発していた サーバ上のファイルにsambaでアクセスして開発していました。 誰かがファイルを変更していると同じファイルは触れません。 FTPで手動でファイルをアップロードしていた デプロイの自動化ができておらず、FTPクライアントで手動でアップロードしていました。 バージョン管理ツールの本来の使い方ができていない 本来であれば、バージョン管理ツ
How GitHub Uses GitHub to Build GitHub
Build features fast. Ship them. That’s what we try to do at GitHub. Our process is the anti-process: what’s the minimum overhead we can put up with to keep our code quality high, all while building features as quickly as possible? It’s not just features, either: faster development means happier developers. Slides Video References Merlin Mann’s “Mud Rooms, Red Letters, and Real Priorities” sinatra_
おすすめzsh設定 - 2011-09-05 - ククログ
他の人がzshを使っているのを見ていると、「もっと便利に使えるのに」と、もやっとしたり、「え、その便利な機能ってなに？」と、発見があったりします。だれかに「この設定をすると便利ですよ」と話しやすくするために、今のzshのおすすめ設定をここに記しておきます。 もし、Emacsも使っている場合はおすすめEmacs設定もどうぞ。 ディレクトリ構成 長年漬け込んできたzshの設定がそこそこの量になっているので、以下のようなディレクトリ構成にして分類しています。主に、zsh標準機能の設定と追加パッケージの設定を分けるためにこうしています。 ~ ├── .zshrc # シェルを起動する毎に読み込まれる。 │ # ~/.zsh.d/zshrcを読み込んで │ # 標準機能の追加設定を行う。 ├── .zshenv # ログイン時に一度だけ読み込まれる。 │ # ~/.zsh.d/zshenvを読み込ん
gitでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
「こわくない Git」というスライドを発表しました - kotas.tech
社内向けに「こわくない Git」というタイトルのスライドを作って発表しました。 対象者は「マージがなんとなく怖い」「エラーが怖い」「リベース使うなって言われて怖い」と、Git が怖いと思っている人です！ こわくない Git from Kota Saito 発表中に出た質問など 補足も兼ねて、上のスライドを発表した際に出た質疑応答などをここに書いておきます。 Q: 常に Non Fast-Forward (--no-ff) でいいのでは、と思えるけど git merge がデフォルトだと Fast-Foward or Non Fast-Forward (--ff) なのはなぜ？ A1: Non Fast-Forward だと、確かにメリットが多いのですが、1点だけデメリットがあります。特に差分が無い状態で git merge --no-ff すると、空のマージコミットが作られてしまうのです。
こわくない Git
8. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) 例: 受け取ったパッチを取り込んだ人 ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー（説明は省略） 1つ前のコミットのリビジョン 例: 4717e3cf182610e9e82940ac45abb0d422a76d77 9. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Co
天下一gitconfig大会
天下一gitconfig大会(サイボウズ社内git勉強会@2012/11/20)の@teppeisの資料です。 ぎっとぎとにしてやんよ GistDeck gistでmarkdown書いたらbookmarkletでプレゼンになるよ。 ↓これをBookmarkに登録してこのページで実行してみよー！ javascript:(function()%7Bvar%20s%3Ddocument.createElement(%27script%27)%3Bs.setAttribute(%27src%27,%27https://raw.github.com/teppeis/gistdeck/fix/gistdeck.js%27)%3Bdocument.getElementsByTagName(%27head%27)%5B0%5D.appendChild(s)%3B%7D)()%3B 複数行のcodeとかが微
gitconfigに設定するWindowsのいろいろなエディタのオプション - みちしるべ
WindowsでGitを使ってて、人に聞かれて困ることの1つにコミットメッセージで 使用するエディタの設定がある。 使用しているエディタがバラバラ、かつ、utf-8の指定の仕方もエディタそれぞれなので 使ってる本人がヘルプ等で調べなきゃならなくなる。 コマンドオプション、起動オプション等に項目に載ってると思うのだが 結構手間取ったりする。 とりあえず、周りの人が使ってるエディタで分かったものをまとめ 間違いがあったら、修正してください。 注意事項 'C:/Program Files (x86)/Hidemaru/Hidemaru.exe' //fu8秀丸のコマンドラインに設定するUTF-8のオプションは「/fu8」だ。 gitconfigに設定する場合は、オプションであることを示す/を足す必要があるので 「//fu8」になる。
Git pullを使うべきでない３つの理由 · DQNEO日記
git pullは使わなくてもよい 初心者はgit pullを使わない方がよい 我々ソフトウェアエンジニアは勉強が大好きなので、コマンドがあるとそれを勉強して使いこなさなければいけないと考えがちですが、ときには「覚えない、使わない」という発想も大事なのではないでしょうか。 以下にその理由をのべます。 git pullは使う必要がない git pullを使わないとできないこと、というのはありません。 使わなくても全然困りません。 git fetchとgit mergeとgit rebaseだけですべての用は足せます。 私はチーム開発でGitを本格的に使い始めて数か月経ちますが、普段の作業でgit pullを使ったことはないしそれで困ったこともありません。 git pullを使わなければ、余計な落とし穴に落ちない git pullには落とし穴があります。 初心者はたいていその穴に落ちます。 「
危なくないgitこと、うちのチームのgit戦略草案(ver. 2)
履歴 恥を忍んで記事を公開させていただいたおかげで、いろいろフィードバックいただきました。フィードバックを取り込んで更新を行なっています。 2012/11/16: cherry-pickしやすいように、というくだりのところは論理通ってないので削除しました。 1 pull req. 1 commitの原則をやめました。言いたいことであった「試行錯誤の過程を入れないで」を丸パクリしました！ > id:kazuho その他表記修正、クリアコードさんの記事に説明丸投げなど。 まえがき gitでトラブった！という話を何度か聞いたことがあります。なんでトラブッてるんだろう…と話を聞いたところ、同一のリモートブランチに対して複数人・複数環境から操作が行われているようです。極端な例を挙げると、masterブランチしか存在しておらず、コミットログをキレイにするためと称してgit pull –rebaseを常
Git - 組織の管理
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
.gitconfigに設定してるaliasなどのまとめ - ( ꒪⌓꒪) ゆるよろ日記
22:56 @thinca さんからの指摘を追記 @yuroyoro あとお節介ですが、n個前とdiffなら HEAD^ より HEAD~ の方がいいと思いますよ。両者では若干意味が違います。~なら HEAD~3 と数字が書けるのも利点です。あと個人的にはwhatchangedよりlog --statの方が見やすくて好きです。 2010-10-08 22:30:52 via Tween to @yuroyoro @yuroyoro URL このgitconfigの記事に関して質問なのですが、core.excludesfile は $HOME で動きますか?以前試した時ダメで、~/ なら動いたのでこちらを使ってるんですが。 2010-10-08 22:20:49 via Tween to @yuroyoro 「そんな.gitconfigで大丈夫か?」 そんなわけで、仕事でもモリンモリンにgi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git でどすこいする方法 - Qiita
既に git 管理しているファイルをあえて無視したい - Qiita
