Unity開発者が複数人で開発を進める上で覚えておくと幸せになる９つの事 - テラシュールブログ
ゲームジャムが近いので、複数人開発で注意すべきことをまとめる。この内容は自分の開発経験やヒアリングを元に考えたものだ。※この方法が正しいとは限らない。とにかく意見がほしい 今回は管理システムにはGitでSource Tree、Unityのバージョンは4.5を想定。 ややこしい…、やるべき事だけ教えろ！って人のため、簡易版を用意した。 この取り敢えずこのルールを守っていればOKなハズだ。 Unityで複数人で開発する際に注意すべき事（簡易版） - テラシュールブログ バージョン管理システムを覚える コミット リセット プッシュ プル マージ（解決) プロジェクト設定で注目すべきポイント .metaファイルが更新されるケース Unity Project以外からファイルを移動・リネームする metaファイルが無い metaファイルの元ファイルが無い 機能の追加フロー（Unity 5.2、Unit
コンフリクトが発生しなくても壊れる場合 - ぐるぐる～
push したら誰かが先に push していたので失敗した。 なので pull したが、コンフリクト (競合) は発生しなかったので何も確認せずにそのまま push した。 何も問題なさそうですね。 ・・・本当ですか？ 例えばこんな状況を考えてみましょう。 最初の状態 A さんと B さんと C さんが登場します。 作っているのは Web ページで、コードはこんな感じ。 <html> <head> <title>hoge</title> <style> .menus { overflow: auto; } ul { margin: 0; padding: 0; list-style-type: none; } .button { float: left; width: 100px; margin: 0; padding: 10px 0; text-align: center; backgr
Linusが2週間でgitを作った話。 - 未来のいつか/hyoshiokの日記
Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記という日記がとんでもなく読まれていてビビる。ブックマークもいっぱいついた。はてなブックマーク - Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記 Linusがgitを２週間で作ったという話はわりと知られていなかったようなので、その話である。 gitっていつから作られているのだろうか。ということで、本家のリポジトリから引っ張ってくる。 $ git clone https://github.com/git/git わたしのしょぼいネット環境でも2分はかからない。 最初の10個のコミットは次のようになる。 $ git log --oneline|tail 9426167 Add "-lz" to link line to get in zlib. 7660a18 Add new fsck
コミットメッセージの先頭に絵文字いれるのが流行ってんだろうか | そんなこと覚えてない
Atom Editor の Contributringをみてみると、「コミットメッセージの先頭に関係ある絵文字をいれろ」的なことが書いてある。 Git Commit Message - contributing - Atom :lipstick: when improving the format/structure of the code :racehorse: when improving performance :non-potable_water: when plugging memory leaks :memo: when writing docs :penguin: when fixing something on Linux :apple: when fixing something on Mac OS :checkered_flag: when fixing somethi
YappoLogs: xlsx ファイルを git diff しやすくする為の天才的な wrapper script を書いた
皆さんはプロジェクトのリソースとしてエクセルの xlsx ファイルを使う事があると思います。 何てったって事務職の人ですら楽々使えるスーパー優れた UI なので、 web の管理画面とかを作り込むよりもエクセルでシート作ってもらってしまった方が早いケースも多いんです。現実の世界では。 で、普通の人は TSV にするだの CSV にしてもらうだのすると思うんですが、一方的にデータ貰うだけなら良いんだけど、相手とやり取りする時にはどうしても xlsx ファイル経由とかにしないと相手がこまる！やっぱりエンジニアのエは優しさのエだから相手に優しくしないとだめです。 で、 xslx ファイルでエンジニア以外の人とデータやり取りするとやっぱり、バージョン管理したくなるのが人情です。 でも xslx ファイルはバイナリファイルなので git diff とかが残念です。。。 って事で作っちゃいました。 h
提言: コミットメッセージの一行目には要求仕様を書け - Qiita
これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情
Gitonomy – PHP製のGit管理サーバ
おお、これは企業で使えそうですよ！ 企業によっては外部にソースコードを預けられないため、自社でGitサーバを構えているところも多いでしょう。しかしそうなると管理画面が欲しくなります。GitHubの管理画面は優秀で、ああいったWebブラウザ上でリポジトリの情報を見たいと思うはずです。 そこで使ってみて欲しいのがGitonomyです。デザインの格好いい、Gitリポジトリマネージャです。 Gitonomyの使い方 GitonomyはPHP + Symfonyの組み合わせで作られていて、Webブラウザ上でGitリポジトリの操作が一通りできるようになっています。ユーザはプロジェクト単位にグループに入り、そこで権限管理される仕組みです。 ソーシャル機能はありませんが、企業ユースであれば十分ではないでしょうか。社内でGitサーバを立てている場合はぜひ導入を検討してみてください。 GitonomyはPHP
Gitコンフリクト解消ガイド（git mergetoolの使い方） - Qiita
ファイル編集がコンフリクトした場合 下記はよくある（忌々しい）コンフリクト画面ですね。 皆さんはコンフリクトのmergeはどんな方法でやっていますでしょうか？ vimやemacsで直接編集している方が多いイメージですが、実際開いてみると、下記のように差分が表示されていると思います。 この画面を見ただけではどのようにmergeすればよいのかわかりません。（Objective-CのARC/MRC双方の開発経験がある人は目をつぶってください・・） gitにはこのようなコンフリクトのmergeを支援するgit mergetoolコマンドが搭載されています。 このままEnterキーを押すと下記のような画面が立ち上がります。 画面幅の都合でフォントが小さいのですが、ここで「mergeしたい差分が作られる直前の状態」と「mergeしたい差分」に注目してみます。 この2つを見比べると、@propertyの
ソースコード管理ツールをSubversionからGitへ変更して感じたこと - torutkのブログ
少人数チームでのソフトウェア開発でソースコードを管理するリポジトリにGitを適用して1,2ヶ月ほど経過しました。Gitを開発に使用するのは今回が始めてで、みなSubversionを使っていたメンバーです。 開発環境 OS Linux、たまにWindows 開発言語 Java プログラミングツール NetBeans 7.4 Gitクライアント NetBeans標準搭載のGit機能、たまにコマンドライン、WindowsではたまにTortoiseGit Gitサーバー apacheでgit-http-backend、Redmineと認証統合 現在の使用状況 Gitの共有リポジトリを、開発サーバー上にapache（HTTP）でホストしています。 共有リポジトリはmasterブランチ一本で、各メンバーはローカルにcloneしたあとローカルのmasterで変更作業を実施し、適宜共有リポジトリのmast
Gitブランチを使いこなすgit-flow／GitHub Flow入門（終）：プルリクエスト／レビューを取り込んだ、よりシンプルなGitHub Flowの運用を図解する (1/2) - ＠IT
プルリクエスト／レビューを取り込んだ、よりシンプルなGitHub Flowの運用を図解する：Gitブランチを使いこなすgit-flow／GitHub Flow入門（終）（1/2 ページ） 数回にわたってgit-flowとGitHub Flowを使ったGitの活用テクニックを紹介します。最終回は、GitHubが採用している、git-flowよりシンプルな構成のブランチ管理フローについてです。5つの運用ルールや開発の流れを図を交えて解説します。 本連載「Gitブランチを使いこなすgit-flow／GitHub Flow入門」では、これまでgit-flowについて解説してきました。git-flowはプロダクトを厳格にリリースすることを念頭にフローが考えられていますが、プロジェクトによっては、冗長過ぎると感じることもあるかもしれません。本連載の最終回となる今回は、git-flowに比べシンプルなブ
ぐにゅぐにゅ動く直感的なGitクライアント ungit｜TechRacho by BPS株式会社
ungitはnode.jsで動くグラフィカルなgitクライアントです Learn Git Branchingみたいな直感的なGUIで操作できるので とても分かりやすいです インストール 今回はnvmを使用してnode.jsを入れます $ git clone git://github.com/creationix/nvm.git ~/.nvm $ source ~/.nvm/nvm.sh $ nvm install v0.10.22 $ npm install -g ungit $ nvm use v0.10.22 ログイン時も有効にしたい場合は.bashrcに以下のように書いておきます if [ -d $HOME/.nvm/ ] then source ~/.nvm/nvm.sh nvm use v0.10.22 > /dev/null fi 起動 以下のコマンドで
glide.so - Domain Name For Sale | Dan.com
Buyer Protection Program When you buy a domain name at Dan.com, you’re automatically covered by our unique Buyer Protection Program. Read more about how we keep you safe on our Trust and Security page. Next to our secure domain ownership transfer process, we strictly monitor all transactions. If anything looks weird, we take immediate action. And if the seller doesn't deliver on their part of the
Git にパッチを送って取り込まれた話
Git の挙動に変なところを見つけたので、パッチを作って Git のメーリングリストに投げてみたところ、何度かのレビューを経て、無事に取り込まれた。 Git に貢献したい人とか、オープンソース開発の流れに興味がある人もいるだろうから、作業の流れを書いておくことにする。 1. バグを発見する 何はともあれ、修正したいところを見つけるところから。 先日、git difftool --dir-diff が便利すぎて泣きそうです という記事を書いたが、difftool --dir-diff の挙動を調べているうちに、一時ファイル書き戻し条件が変なことに気づいた。 手元のバージョンが古いのかとも思ったが、master ブランチでも再現したので、ちょっくら深入りしてみた。git difftool は Perl スクリプトだったので、ソースコードに print を追加しつつ挙動を探っていった。しばらく調
もしWordPressユーザーがGitを使ったら 〜WordPressテーマを共同編集しよう〜
WordPressでサイトを制作するとき、2人以上のチームで取り組むことも多いと思います。例えば「構築担当者」と「デザイン担当者」で1つのサイトを構築するような場合です。 同じ会社内で一緒に作業するときと違って、ノマドワーカーのようにそれぞれが別の場所で作業する場合は、直接ファイルを手渡しするようなことはできません。 そんなとき、メールにファイルを添付してやりとりしていますか? Webサーバーに直接アップロードして更新していますか? どちらにせよファイルの管理と意思疎通をしっかりやらないと、せっかく更新したファイルがまた元に戻っちゃいますよね。 そんなコラボレーションワークでのファイル管理に、Git(ギット)を使ってみましょう。ファイル管理の煩わしさから開放され開発がスムーズにできます。 WordPressの構築を経験したことあるけど、Gitはまだ使ったことがない、という方向けにGitの使
危なくないgitこと、うちのチームのgit戦略草案(ver. 2)
履歴 恥を忍んで記事を公開させていただいたおかげで、いろいろフィードバックいただきました。フィードバックを取り込んで更新を行なっています。 2012/11/16: cherry-pickしやすいように、というくだりのところは論理通ってないので削除しました。 1 pull req. 1 commitの原則をやめました。言いたいことであった「試行錯誤の過程を入れないで」を丸パクリしました！ > id:kazuho その他表記修正、クリアコードさんの記事に説明丸投げなど。 まえがき gitでトラブった！という話を何度か聞いたことがあります。なんでトラブッてるんだろう…と話を聞いたところ、同一のリモートブランチに対して複数人・複数環境から操作が行われているようです。極端な例を挙げると、masterブランチしか存在しておらず、コミットログをキレイにするためと称してgit pull –rebaseを常
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
docker.sh - a really cool domain parked on Park.io
Git log output log file
GitBook – Knowledge management for technical teams
layer8.sh