Atomの便利なパッケージ管理方法 – GitHubやスターを利用して他の開発環境でも使えるようにしておく
Atomと言えばGitHub製の開発者向けエディタで、今まさにホットなツールのひとつとして盛り上がってきています。私も御多分に洩れず、先日長年使ってきたSublime TextからAtomに乗り換え、『Atom（GitHub製エディタ）に乗り換えて最初にやっておきたいこと』といった記事を書きました。今回も引き続き最初にやっておきたいこととして、Atomのパッケージや設定ファイルを管理する便利な方法を紹介したいと思います。 Atomの設定が完了したら、同じ設定下のAtomを他の環境でも使いたくなるはずです。他の環境で使うたびに、設定ファイルをいじって、パッケージを検索して、インストールしてなどを繰り返していたら日が暮れてしまします。そこで、やっておきたいのがパッケージや設定ファイルの管理となります。方法はいくつかあり、GitHubを利用する方法とAtomのスターを利用する方法が主流となるでし
Gitを実践的に使うために参考にすべき記事20選
チームで開発を行うときにGitのスキルは必要不可欠なものとなってきています。以前、Git初心者向けにスライドをまとめたものを紹介しましたが、今回はGit（GitHub）をさらに活用するために参考にしたい記事を紹介します。 この記事は以下のような方におすすめです！ ・ブランチをどのように運用すれば良いのかわからない。 ・コミットメッセージの書き方にいつも悩んでしまう。 ・issueやPull Requestをもっとうまく活用したい。 ・Git�やGitHubに関する便利なテクニックを知りたい。 ・間違ってコミットしてしまったけど対処法がわからない。 今回は、運用編、コミットメッセージ編、issue編、Pull Request編、テクニック編、問題解決編と５つの内容で分類してみました。実践的な読み応えのある記事ばかりなので、ぜひ参考にしてみてください。 運用編 中の人に聞いたGitHub fl
git branch の結果を時間順にソート: git branch --sort=-authordate - Islands in the byte stream
id:kazuho さんと「gitのbranchを消すべきか否か」という話をしていて、ぼくの「ローカルにせよリモートにせよbranchが増えすぎると目的のブランチを見つけられない」という意見に対して次のエントリを教えてもらったのでした。 git branch の結果を時間順にソート - kazuhoのメモ置き場 一理あるかもしれないと思ってこれをgitに組み込むためにgitのソースコードを眺めていたら、実はもうできるということを知りました。それがこれ: # 新しいのが下 git branch --sort=authordate # 新しいのが上 git branch --sort=-authordate このソートに使えるフィールドは、 git branch --help を引くと "The keys supported are the same as those in git for-e
iOSアプリ開発の現場で訊いてみた！ユビレジ編 - Qiita
自分が他社のiOSアプリ開発者と話す時にいつも同じことを聞いていたのでそれをQiitaにまとめていましたが、実際に他社の開発の現場でインタビューをしてくるというシリーズになりました。 記念すべき1社目はユビレジ社！ ユビレジとはなにか 私の分かる範囲でユビレジというものについてすごく平たく説明すると、iPadを利用したお店のレジとそれを管理するウェブ上のシステムみたいな感じだと思います。そもそもお店のレジスターっていうものは単純な売上の計算のためだけのものと、商品や顧客情報をひもづけるPOSレジ（POSはPoint of sale)と呼ばれるものがあって、このPOSレジをiPadとウェブで実現するぜ！ということでしょう。 訊いてきたこと ユビレジ社ではiOSアプリ開発をしている人で知らない人はいないという@kishikawakatsumiさんと、インターネットで有名な@laisoさんを中心
direnvを使って複数のgitコミッタ名を切り替える - MANA-DOT
例えば会社のPCでこっそり個人的なリポジトリで作業してgithubにpushする場合、 うっかり会社用のgitコミッタ名(本名@会社名.co.jp みたいなアドレスとか)で commit/pushしてしまい、紐付けるつもりのなかったネットの人格と本名/会社名が紐付いてしまう というのは皆が恐れるところであると思います。 そこで、direnv を利用するといい感じに切り替えられることができたので、共有いたします。 direnv zimbatm/direnv あるディレクトリに .envrc というファイルを置いておくと、そのディレクトリ以下に cd した時に .envrc の内容の環境変数が読み込まれるという代物です。 例えば、 - home ├ .envrc // export SOME_ENV=hogehoge ├ c └ a ├ .envrc // export SOME_ENV=fu
Git/GitHub 社内勉強会コンテンツ (最小限の手順まとめ) Git-it SourceTree - Qiita
概要 Git/GitHub 社内勉強会コンテンツ (最小限の手順まとめ)。 本記事は、Git-it で学習を進める際の、副資料。 はじめに Git-it という、Git/GitHub学習のための素晴らしいアプリがある。 Git-it (Git/Github 勉強アプリ) https://github.com/jlord/git-it-electron/releases/tag/3.1.0 それを使った、社内勉強会用コンテンツ。 しかしながら、Git-it では、プルリク - レビュー - マージ の開発の流れが理解しづらいので、その部分を、あとから追加で実施する。 ブランチの状態を可視化する目的もあり、Git管理アプリ SourceTree を併用しながら学習を進める。 SourceTree https://ja.atlassian.com/software/sourcetree GitH
作業中ブランチのプルリクエストをブラウザで開く - Qiita
WIPとかプルリクエスト出した後にゴチャゴチャ作業してる状態の時にちょくちょくgithubの画面開きたいのでコマンドにした。 propen() { local current_branch_name=$(git symbolic-ref --short HEAD | xargs perl -MURI::Escape -e 'print uri_escape($ARGV[0]);') git config --get remote.origin.url | sed -e "s/^.*[:\/]\(.*\/.*\).git$/https:\/\/github.com\/\1\//" | sed -e "s/$/pull\/${current_branch_name}/" | xargs open } propen() { local current_branch_name=$(git symb
iOS開発でGitを利用する際のTips
Oct 27, 2012 ちょっと今更な感じもありますが、iOS開発でGitを使うときのTipsを紹介します。 Gitそのものの使い方は理解している前提のもとで書きます。 バージョン管理する対象 Xcodeのプロジェクトにはバージョン管理する上で結構余計なものが入っています。 Gitで管理すべきでないもの Xcodeの作業データ Xcodeのプロジェクトは.xcodeprojですが、こいつ自身はディレクトリになっていて project.pbxproj project.xcworkspace xcuserdata というファイルが入っています。このうち、Gitで管理するべきものはproject.pbxprojです。 その他のものはXcodeの状態(グループを開いてるかなど)を管理しているものなので、 プロジェクトのバージョン管理対象としては適切ではありません。 ビルドデータ xcodebui
レビューしやすいコミット履歴でバグ削減 - Money Forward Developers Blog
こんにちは。 アグリゲーション開発担当の中川です。 今回は、みんなが大好きな構成管理ツール「Git」について話したいと思います。 私は Git を使い始めてから、バグの発生数が激減しました。 Git を使ったとある手法によってレビューが充実し、バグの少ないコードを書くようになったと考えています。 では、今回はその手法について紹介したいと思います。 ※ 本稿は Git 以外の第三世代構成管理ツール（Hg、Bzr など）にも適用するかと思いますが、Git の用語とコマンドを使って紹介していくため Git の基本知識が必要となります。ご了承ください。 レビューしやすいコミット履歴と、開発の流れで自然にできるコミット履歴の乖離 以下のようなコミット履歴があるとします。 1. wip: 仕様変更○○を行い始めた 2. wip: 仕様変更○○の続き 3. wip: ちょっと設計を変更、それと過去のバグ
$ command line ruby cheat sheets
Setup ----- git clone <repo> clone the repository specified by <repo>; this is similar to "checkout" in some other version control systems such as Subversion and CVS Add colors to your ~/.gitconfig file: [color] ui = auto [color "branch"] current = yellow reverse local = yellow remote = green [color "diff"] meta = yellow bold frag = magenta bold old = red bold new = green bold [color "status"] add
チーム開発に必要なGitコマンドを神速で習得しよう！
すみません、タイトルは釣りです。書籍『入門git 』と『もっと早く知りたかった！ Gitが鬼のようにわかるスライド厳選7選』、『Gitがこわくて触れられなかったけど、このスライドで理解出来るようになったよGitサイトまとめ』紹介のスライドを読んで、理解したことをまとめるためにこの記事を書きました。今までは個人でしかGitを使っていなかったので、チーム開発に必要なGitコマンドを少しでも理解できるように頑張ります！ (05/13 08:45) githelpを追加 🐡 Gitの基本的な開発スタイルについて From イラストでわかる！git入門の入門 Gitの基本的な開発スタイルは次のとおりです。 (1) gitの開発ではローカルで使う個人リポジトリとチームで使う共有リポジトリを用いる (2) 共有リポジトリに push すると個人リポジトリのこれまでのコミット内容を送れる (3) pul
【翻訳】あなたの知らないGit Tips
Mislav Marohnićさんの "A few git tips you didn't know about" を翻訳しました。 元記事はこちら： http://mislav.uniqpath.com/2010/07/git-tips/ （翻訳の公開は本人より許諾済みです） 翻訳の間違い等があれば遠慮なくご指摘ください。 あなたの知らないGit Tips注意：いくつかのコマンドやオプションは Git の version 1.7.2 以降が必要です。 OS Xでは、 Homebrew で簡単にアップグレードできます： brew install git git log でブランチとタグも見る$ git log --oneline --decorate 7466000 (HEAD, mislav/master, mislav) fix test that fails if current d
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
gitで最後に行ったコミットを修正する | Webシステム開発／教育ソリューションのタイムインターメディア
$ git status # On branch master # Untracked files: # (use "git add <file>..." to include in what will be committed) # # lib/x.c # lib/x.h nothing added to commit but untracked files present (use "git add" to track) 上記の通り新たにバージョン管理下に置くべきファイルを追加し忘れているというありさまです。 この場合、ミスを修正するコミットを行って git rebase -i で1つにまとめてしまってもよいのですが、 さすがにこの程度のことで git rebase -i を使うのは面倒臭いです。 どうすればよいでしょうか。 解決方法 git commit --amend を使います。
git-flowとgit-issueを使ったTiDD環境について | Technology-Gym
以前書いた、TiDDとgit-flowを合わせた開発手法について | Technology-GymのRedmineとgit-flowを使ったチケットドリブンな開発手法は相変わらず続けていますが、少し使ってるツールが変わりました。 まずはgit-flow自体はそのまま使い続けています。 後述しますが、git-flowのhooksが正式に実装されれば、TiDDな開発はもっとスムーズに進むような気がします。 コマンドラインからredmineを操作するツールを以前は複数使っていましたが、 現在はgit-issueに統一してあります。 この記事で使用してるバージョンはgit-issue 0.8.0です git-issue : CLIでRedmine/Github-issuesのticketをbrows/editできるgitサブコマンド – ゆろよろ日記 git-issueはチケットの作成(git i
Git
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.
git flow でのチーム開発ワークショップ資料 - Yamashiro0217の日記
この記事は会社内の別チームの方に、 僕の今のチームで git をどう運用してるかを ワークショップ形式で説明するための資料である。 事前準備 git と git-flow を入れておくこと 参考資料(Macでgitとgit-flowインストール) - xcode cli toolインストール -- https://daw.apple.com/cgi-bin/WebObjects/DSAuthWeb.woa/wa/login?appIdKey=d4f7d769c2abecc664d0dadfed6a67f943442b5e9c87524d4587a95773750cea&path=%2F%2Fdownloads%2Findex.action - homebrew のインストール -- https://github.com/mxcl/homebrew/wiki/installation - b
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Open GitHub URL for current directory/repo...
Gitコマンドリファレンス - No Programming, No Life
