開発環境の情報共有会でDash,SourceTree,Alfredの話をした - Glide Note
社内で開発環境についての情報を共有する会を開催した。 参加者全員が発表のスタイルで、ただ聞いてるだけの人がいないようにしたら いろいろな情報を共有出来て大変参考になった。 私は1日のほとんどをターミナル上で過ごすので、ここ数年GUIアプリにはあんまり関心が 無かったんですが、最近導入して便利だったやつを共有したら好評だったのでまとめておく。 Dash Dash - Documentation Browser, Snippet Manager - Kapeli ドキュメントブラウザ、スニペット管理ツール。ドキュメントをローカルにダウンロードして 利用するので高速。今日(2014/03/29)時点で130以上のドキュメントとAPIに対応していて、 プログラミング言語に加えて、MySQL、MongoDB、Puppet、Vagrantなどのドキュメントもある。 自作ドキュメントを追加することも可能
最低限の知識でGitの運用をする - console.lealog();
仕事で前向きにGit運用していくことになりました。 あくまでGitを使いこなす！とかではなく、最低限の運用ができるようになることを目標として。 CUIすらちんぷんかんぷんの素人に、Gitコマンド叩けっていうのは乱暴すぎると思うの・・。 というわけでそんな中、一通りこれだけ覚えてればどうにかなるやね、っていうコマンドのメモ。 こういう時どうすれば？みたいなのも、遭遇した限りメモ。 前提 特定の単一branchでの作業を想定。 branchの切り替えを含めた運用や他のbranchによって伸びたmasterの取り込みとかは無視。 そういう難しそうなところは、最低限の範囲外として見てます。 基本の流れ git status git add git commit git pull --rebase git push 正確なコマンドは後述するけど、流れとしてはたったコレだけ。 status git s
GithubでSSH通信した時に「Permission denied (publickey).」が発生した時の対処方法。 - 「ひとかじりのりんご」
Githubで、SSHキーを登録しても、上手くSSH通信出来なかったので、メモ書き。 まず、前提 SSHキーの作成、Githubへの公開鍵登録は、下記サイトが参考になりました。 初心者Git日記その五～GitHubにSSH公開鍵登録～ | SetucoCMSプロジェクト 問題が... 上記サイトの通りに作業を行い、通信確認を行いましたが、下記のメッセージが出てしまいました。 $ ssh git@github.com Warning: Permanently added the RSA host key for IP address '204.232.175.90' to the list of known hosts. Permission denied (publickey). 対処方法 1. known_hostsの整理 .sshの中に、known_hostsが自動的に作成されています
GitHubでプルリクエスト用ブランチを保守するメモ - なんたらノート第三期ベータ
GitHubにリポジトリを置いてる人はみんなプルリクエストを待っています。けどプルリクエスト用にフォークした自分のリポジトリを保守する方法が途中でわからなくなって...という人が案外多いんじゃないかなと思ったり。なので、ちょっとメモ置いときます。って、人のためみたいな言い方ですが、まあ自分用のメモです。 まずこうしたほうがいいという原則。masterブランチはフォーク元から変更せず、かならず自分用のブランチを作る。これは、masterを作業の同期用に置いておくためです。 自分のブランチでコミットしたあと、フォーク元のmasterが進んでないかのチェックは必ずすること。 もし進んでいたら自分のmasterに元作者のコミットを取り込んで自分のGitHubでのフォークが最新と同期してる状態にしましょう。で、元作者のコミットログを確認して何が起こったのかを理解しましょう。 $ git checko
Pull Request が Merge された後でしたこと - るびー めも
前回、github のとあるリポジトリに Pull Request したことを綴りました。 githubでPull Request送られてきたら。 人生初めての Pull Request が Merge されて、 その後に何する必要があるの？ってところを メモにします。 自分のローカルリポジトリにある、master ブランチが古くなってるはずなので 以下で Pull しましょう。 $ git checkout master Switched to branch 'master' $ git branch RouletteClass * master $ git remote add upstream https://github.com/whitech0c0/LabRoulette.git #fork元 $ git pull upstream master remote: Counting
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
GitHubで初めてpull requestしてみたので、手順をメモしておきます。 内容はこちらを参考にさせて頂きました。 GitHubへpull requestする際のベストプラクティス http://d.hatena.ne.jp/hnw/20110528 Forkして、ソースの取得とブランチの作成、修正 まずForkしないと話が始まりません。 GitHubにログインした状態で、ソースを修正してpull requestしたいページを表示。 「Fork」ボタンをクリックします。 Forkすると自分のリポジトリにForkしたリポジトリのコピーが表示されます。 自分にコピーされてきたリポジトリにブランチを作成し、修正を行なっていきます。 gitコマンドでソースをForkしたソースを取得します。 ※URLはForkして自分のリポジトリにあるソースのURL
Gitの忘れがちだけど絶対に使うであろうコマンド達 | Basicinc Enjoy Hacking!
ベーシックでは、Gitを使ったバージョン管理システムを導入しています。一部のプロジェクトでは先行して導入していたものの、全社的にはまだまだ…といったわけで、よくGitコマンドについて質問されるので、ここで軽くまとめておきたいと思います。 普段は git add / commit / push / pull しかしてない…っていう人向けです。 addしたファイルを取り消す $git reset HEAD ファイル名 更新内容自体は取り消さず、addしてインデックスに登録するのを取り消します。 更新したファイルの更新内容を取り消す $git checkout ファイル名 commitする前限定です。 他ブランチの特定のコミットだけマージしたい $git cherry-pick コミットID とても便利なコマンドですが、cherry-pickを多用するような運用スタイルになっていたら問題なので、
SmartGit での日本語の文字化け対処 - モノラルログ
Windows XP 環境での git クライアントとして SmartGit を試してみてたのですが、結構よさげなんだけど日本語が文字化けしちゃうのがなー…という感じでした。UTF-8ソースの diff 画面の日本語が化け化けなのです。 どうやら文字コードが Shift-JIS固定みたいで、設定画面でも文字コードに関する項目は見つけられず… しかしググったら、こんな情報が！ @nashimoto: [SmartGitでUTF-8メモ] 初回起動前であれば smartgit.vmoptions に -Dfile.encoding=UTF-8 を書く。既に設定ファイルが出来てたら projects.xml の encoding を全て UTF-8 に書き換える。 2010-03-03 13:07:10 via Silver Bird ビバTwitter!!! 感謝感謝!!! ということで C:
こわくない Git
8. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) 例: 受け取ったパッチを取り込んだ人 ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー（説明は省略） 1つ前のコミットのリビジョン 例: 4717e3cf182610e9e82940ac45abb0d422a76d77 9. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Co
Git svnではじめる忍者のごとく潜むgit
2. * なぜgitか？なぜgit-svnか？ * Gitのインストール * git svn clone、trunkとmasterの関係 * コミット、そしてプッシュ * ブランチ（切る。作業する。リベース） * ブランチしたらプッシュの前に * その他のtips * まとめ * 4. *Gitにはローカルレポジトリ＝自由がある！ * ひとりひとりが専用のレポジトリ * バージョン管理の便利さを気兼ねなく * コミット済みのコードを変更できる * あのコミットを無かった事に * Rev(21)とRev(25)をまとめたかった・・・ * 機能追加にまじってバグ修正かよ・・・ * つまり履歴が奇麗に！ *
【Git】ローカルで利用する場合1 | 雪の天秤
初回コミット とりあえず、適当なファイルを作成します。 $ echo "test" > testfile この状態で下記のコマンド実行すると $ git status # On branch master # # Initial commit # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # testfile こんな感じで、「Untracked files」に作成した「testfile」が入っています。 ここで、 $ git add . で、カレントディレクトリ配下のファイルをすべてインデックスに記録します。 このインデックスに記録する事を「ステージする」または「ステージング」と言います。 この状態で $ git status # On branch maste
github 超入門 - glasses factory
ここ1年くらい、僕はソースコードなどを github で公開しています。 つい先日まで書いていた連載記事 GAE for Flasher のサンプルソースコードや、 東京てら子で発表したデモ、今まで作ったライブラリや便利クラスなど なんでもかんでも github で公開しています。 しかし、プログラムに慣れた人ならともかく、これから AS3 をガシガシ勉強していこう！ といった方や、AS3 自体はガシガシかけても基本的に SVN 等バージョン管理システムを 使わない方にとっては github 自体がやはり少し敷居が高いイメージがあるという話を聞きました。 GAE for Flasher の記事自体、ある程度 AS3 に関する知識のある人を想定していたとはいえ 流石に当たり前のように使い過ぎたかなと反省の意を込めて github 超入門( for Flasher ) を書く
gitでpushしたりpullしたり | 半年前の私への教科書
なんかおかしいと思いつつも、決定的な情報がなかったために間違ったやり方をしていたのですが、ひょんなことから正しい情報をゲットしたので、私はこうやって使っていますという話を。 （もしかしたらまだまだ非効率なやりかたをしていると思うので是非ご指摘ください） バージョン管理システム自体を知らなかった自分にも理解できるよう、かみ砕いた説明をしたいと思います。 基本的にgitは、sshが使えれば、導入をためらうことはありません。 サーバー間のやりとりはsshを使って行えますので、gitを導入するにあたって余計なポートをあけたりする必要はないです。 gitでは、今いるレポジトリ（ソースを入れてるディレクトリ）を特に「ローカルレポジトリ」と呼び、やりとりする相手方を「リモートレポジトリ」と呼びます。 普段開発している社内のPCを開発サーバー（開発環境）と呼び、Webサイトを公開しているサーバーにはテ
[デザイナー向けGit解説] みんなで開発できるGitのカタチ | uniq-style
私のまわりには「バージョン管理が未体験」なデザイナーさん多いです。 デザイナーでも、プログラマーと一緒に仕事すると、Gitやsvnを使うことになると思うんですが、Gitとかsvnはまず「その仕組みとかカタチとか」が、デザイナーにとっては分かりにくいと思います。 そんなわけで（元）デザイナーの私が、理解してる範囲のことを分かりやすい言葉で解説してみます。 例の図を描いてみました。 だいたいこんな感じなのですが。。。 解説すると みんなの場所 プログラマーの人がremote（りもーと）とかorigin（おりじん）とか言ってる場所です みんなのファイル共有置き場です branch（ぶらんち）というものがあります。branchはプロジェクトやリリース毎や機能ごとに作られます。 図では「デイリーランキング機能追加用のdaily-rankingというbranch」「検索ページリニューアル用のse
ローカルでプライベートに使用する為のgit入門 - かせいさんとこ
これは何? subversion使いが、gitを知るための第一歩をメモ gitの特徴って何? subversion使いにもやさしく教えて 分散型バージョン管理システムが特徴 ステージング コミットログの操作が簡単 元々linuxのカーネル開発用なので、大規模向け ブランチやマージが速い 分散型バージョン管理システムって何? 中央リポジトリと別に、各開発環境に、ローカルリポジトリを持つ ローカルにリポジトリがあるので、中央にリリースする前の一時作業の履歴管理ができる 最悪、まるっと捨てることも簡単 ローカルにリポジトリをcloneできるので、オレオレブランチが簡単に作れる ステージングって何? 作業ディレクトリと、ローカルリポジトリの間に、index という領域があって ローカルリポジトリにcommitする前に、一度 index にファイルを置くことをステージングと言うっぽい こんな感じ 作
英語なんてわかんねーよ！！ってな人へ贈るGithub入門 for MacOS - Seasons.NET
Gitという分散リポジトリシステムを使い始めました。 これ自体は、MacだとMacPorts使えば楽に入ってくるのですが、 まぁローカルで管理していてもあんまりうまみがない。 せっかくならば、外にソースを公開して、みんなでいじくりまくれる リポジトリを構築したほうが良い。 そこで便利なのが、githubというサービスです。 簡単に言えば、gitのリポジトリを作成＆管理する為のサービスです。 自分でサーバーたてて管理するコストが減る為かなり楽です。 Free版だと、１００ＭＢまでという制限がありますが、まぁ普通に使う分には、 問題ない容量でしょう。登録してある言語は、Rubyが多く、ＬＬな人達からの 人気の高さが伺えます。 まずは、アカウントを作っておきます。 これは、github.comに行き、好きなアカウントを作成してください。 特にアバターの設定は、ちとはまるので、私のこのエントリーを
http://ja.hgtip.com/tips/beginner/2009-11-30-reverting-dirty-files/
See related links to what you are looking for.
Git+Redmineな人におすすめのフックスクリプト集 - みずぴー日記
id:bleis-tiftによるgitのフックスクリプト集がマジ便利。 gitとredmineを使ってる人はぜひ使うべき 機能 チケット番号付加 id/12というブランチで作業してるときは、コミットメッセージの末尾にrefs 12を自動でつけてくれます Redmineのチケットごとにブランチを切るようにすると、マジ便利 masterブランチへのコミット拒否 masterブランチへのコミットを拒否する 必ずトピックブランチを切るようになる pushされたときにチケットIDのないコミットの拒否 チケットIDのないコミットのpushを拒否します ダウンロード・インストール方法 https://github.com/bleis-tift/Git-Hooks に書いてある通りにすれば簡単にインストールできます
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IDEA * IDEA
