タグ

開発とGitに関するFluss_kawaのブックマーク (7)

  • これがXcodeでのバージョニングの決定版になるかも • Yuta Tokoro

    概要 この記事でできるようになること 安定してInfo.plistの内容(ここではBuild番号)を変更できる ふつうにRun Scriptで編集するとタイミングによってすぐにアプリに反映されないことがあったりしたがそれが解消される Info.plistに差分がでないのでcommitのときに邪魔にならない なお、この方法を教えてくれた熊谷さんがこの方法に行き着いた経緯や所感がこちらに詳しくまとめられています。詳細や考え方などをきちんと知りたいかたは是非、熊谷さんの記事をご一読ください! 必要な設定 Preprocess Info.plist file でInfo.plistをビルド前に確定させる Run Scriptで${TEMP_DIR}/Preprocessed-Info.plistを編集する 以下、具体的な話をします。 経緯 これまで、 デバッグ用やArchive用のアプリのバージョ

    これがXcodeでのバージョニングの決定版になるかも • Yuta Tokoro
  • 2014年、春のGit事情 - fujimuradaisuke's blog

    なんとなく最近どんな感じでGitを使っているか、適当にリストアップしてみた。 よく使うやつ git status git status --branch --short にしている。変更されたファイルが出る。とりあえず何をしたかざっくり把握する用。sにエイリアスしている。一日100回くらい実行しているのではないか。 git diff 特にオプションは指定していない。何をしたかしっかり把握する用。dにエイリアスしている。一日50回くらい実行しているのではないか。 git grep バージョン管理しているファイルから渡した単語を含む行を検索、表示。関数の検索などあらゆる場面で超便利。オプションは --line-number --show-function --color --heading --break がオススメ。 git ls-files バージョン管理しているファイルのファイルパスを表

    2014年、春のGit事情 - fujimuradaisuke's blog
  • Git を学ぶ - チュートリアル、ワークフローおよびコマンド | Atlassian

    Git は、元々 Linus Torvalds によって 2005 年に作られた、無料でオープンソースのバージョン管理システムです。他の SVN や CVS といった中央バージョン管理システムと違って、Git は分散型で、すべての開発者がローカル環境で彼らのコードのリポジトリの完全な履歴を持っています。これは、最初のリポジトリのクローン作成に時間がかかりますが、commitblame、diff、merge、log といったこれに続く作業を劇的にスピードアップします。 Git は多くの革新的で強力なワークフローやツールにつながる、リポジトリ履歴のブランチ、マージ、および書き換えに非常に役立ちます。プル リクエストは、チームが Gitランチでコラボレーションを行い、他のコードを効果的に見直すことができる、非常に人気のツールです。Git は現在世界で最も広く使用されているバージョン コント

  • GitHub上の大事な中央ブランチをgit push --forceの恐怖から守るgit hookスクリプト - Qiita

    つい先日、GitHubで管理していたテスト用中央ブランチに、チームメンバーが誤ってgit push --forceしてしまい、 一部の歴史が消失するという事件が起きました。 ぎゃあああ!なんばしよっとね!うっかりでしたじゃ済まんばい! とか思っていたらJenkinsの開発者みたいなスゴい人でもやらかしちゃうみたいです。 Jenkinsの開発者、間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまう http://cpplover.blogspot.jp/2013/11/jenkinsgit-push-force.html スゴい人でもやらかすんだから、平民の我々もそのうちやらかすに違いない。 緊急バグ修正などで慌てていたら尚更ですね。(というか自分が一番やりかねない) というわけで、何とか仕組みの上で防くことができればと思って仕掛けることにしました。 以下のスクリ

    GitHub上の大事な中央ブランチをgit push --forceの恐怖から守るgit hookスクリプト - Qiita
  • ボードゲーム界隈での興味深い4つの試み - One For Owl

    今回は最近ボードゲーム界隈で見られたいくつかの興味深い挑戦について紹介したい。 「GitHubでアナログゲームを開発する」 「クラウドファンディングでアナログゲームの資金集め」 「アナログゲームの制作ハッカソン」 「アナログゲームのダウンロード頒布」 「GitHubでアナログゲームを開発する」 『Githubでアナログゲームを開発する | Open Design Games』 GitHubというのはバージョン管理システムの一種だ。複数のファイルを管理して「いつ」「誰が」「何を」編集したか記録しておき、ある時点まで状態を戻したり出来る。一般にはソフトウェアを複数人で開発する際に使うが、これをアナログゲームの開発に利用してみようというのが@fullkawa氏の試みである。 @fullkawa氏が行ったのは自身が制作するdqz(a.k.a Xan)というアナログゲームのルールやカードをファイルと

    ボードゲーム界隈での興味深い4つの試み - One For Owl
  • Web制作者のための実践Git | 第1回 適切な履歴の作り方

    上記の例の場合、変更した箇所が近いため同じhunk(変更の塊)として表示されています。ですので、hunkをさらに分割する必要があります。そのためにはsを選択します。そうすると次のような表示になります。 Split into 2 hunks. @@ -1,5 +1,5 @@ <ul> <li><a href="/">Home</a></li> - <li><a href="/about.html">About</a> + <li><a href="/about.html">About</a></li> <li><a href="/help.html">Help</a></li> </ul> Stage this hunk [y,n,q,a,d,/,j,J,g,e,?]? 変更が分割されて閉じタグ忘れだけの変更が表示されています。ここでyを押してこの変更をステージングします。すると次は以下の表

    Web制作者のための実践Git | 第1回 適切な履歴の作り方
  • git による分散作業パターン | GREE Engineering

    分散バージョン管理を華麗に扱いたい堀口です。 GREE Advent calendar 2013 の 14 日目として参加させていただきます。 お二人に続き Haskell の話をしようかと思ったのですが、急遽無難な開発の話に変更しました :o JavaC++ には OOP の概念が必要であったように、分散作業の認識が薄いまま git や Mercurial を使うことは長期的に不幸をもたらします。 とあるプロジェクトにて、その一部を副産物のミドルウェアとして抽出すべく、アプリケーションと分離したい 不具合があったので原因を探りたいが、依存関係が複雑すぎるのでコードを読む量を減らしたい テストやレビュー、提案、リファクタの運用を強化したい よそのプロジェクトに迷惑を掛けないように、そこのツールを改良して使いたい。 いままで何気なく「こんなもんだろう」と思って手間をかけていませんでした

    git による分散作業パターン | GREE Engineering
  • 1