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
提言: コミットメッセージの一行目には要求仕様を書け - 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 の挙動に変なところを見つけたので、パッチを作って 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（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
続・イラストでわかるgit入門の入門：ブランチを切る
こんにちは！志田です。 最近ドラクエモンスターズを購入しました。 だいあくまの書・シュプリンガー・メッサーラのパーティでがんがんいってます。 配合を繰り返していると、「この組み合わせ、AにもBにもなるのに！どっちが強くなるんだろう？」ということがたびたび起こります。 そんなときに使えたらいいのが、今回ご説明するブランチです。 前回のあらすじ 前回の記事では、バージョン管理と基本的な動作について、ご説明しました。 ・バージョン管理にgitを使おう！ ・コミットを繰り返し、キリのいいところでプッシュする ・コミットを重ねることでバージョン管理ができる こんな経験ありませんか みなさん、これまでの経験で、こんな経験ってありませんか？ ・直すことによる影響範囲が広いため、もしきちんと改修できて、テストもできたら安定バージョンに含めたい 今まで何度もコミット・プッシュを重ねてきたプロジェクト。現在は
GitHub for Windows
ProductGitHub for WindowsThis article hasn't been updated in a while. For the most current information, please refer to the official Help documentation and the Desktop website. Ever wish there was an easy… This article hasn’t been updated in a while. For the most current information, please refer to the official Help documentation and the Desktop website. Ever wish there was an easy way to get up
Redmine, git, Jenkinsの状態を横断的かつリアルタイムに表示する『Dashbozu』をリリースしました。 - みずぴー日記
Redmine, git, Jenkins などプロジェクト管理ツールの状態を横断的かつリアルタイムに表示するWebアプリ『Dashbozu』を作りました。 これを使えば、一つの画面でプロジェクトの”今”の状態を把握できます。 WebSocketを用いているので、ただ開いているだけで、次々と情報を得ることができます。 iPadで開きっぱなしにして、机の上に置いておくような使い方を想定しています。 なぜこれを作ったか 一般的なソフトウェア開発現場では Redmineでチケットを作成する gitでコミットを繰り返し、中央レポジトリにpushする JenkinsによるCIが実行される 結果を確認し、Redmineのチケットを閉じる という流れで作業が進んでいきます。 これらの作業の中で、開発者は「適切な」タイミングでチェックとフィードバックをすることを求められます。 例えば、チェックのタイミング
git-助けてというすごく便利なエイリアスを作った - 鳩舎
こんばんは！暑い！ ということで今日はgitのすごく便利なエイリアスを作りました。 Git-助けて https://github.com/rosylilly/git-tasukete という、超便利コマンド集です。 使い方はホームディレクトリあたりにクローンしてきて、パスを通しておくだけです。 するとあら不思議、ターミナルに $ git 助けて と打つだけで、助かりたい時の場合がリストで出てきます。 後はそのうち、目的の状況のモノをターミナルにコピペするだけです。ほらね $ git mergeを取り消したい はい、マージが取り消せました。よかったよかったー！ こんな困った場合にも対応してください！というのはGitHubのissueか、コメント欄にて受け付けてます！
PHP source now available on GitHub
Last fall the PHP core team voted to pick a distributed version control system and git won handily. David Soria Parra, the release manager of PHP 5.4, has put together a workflow for core committers merging GitHub pull requests into PHP. Using github was one of the most important reasons to switch to git in the first place. The php-src repository is 13 years old and includes over 80k commits. Mayb
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
docker.sh - a really cool domain parked on Park.io
Git log output log file
layer8.sh