SkypeからSlackにした理由

プログラマの西川です。

今回の記事では、チャットツールのSlackについてお話します。最近各所で使いはじめたよーというお話がチラホラと出てきていますが、弊社でも大体4ヶ月ほど便利に使っています。

僕が入社した頃、弊社ではSkypeを社内チャットツールとして使っていました。僕は何年か前から、会社など管理が必要な組織でSkypeの利用は適さないと思っており、これは改善しなければと思いました。そこでSlackを利用できる状態を先に作り、社内メンバーに多少強引に使いはじめてもらい、便利さを実感してもらってそのまま社内のチャットツールとして定着させました。
とても便利なので、基本機能、連携機能等を紹介し、他社等でもより便利なコミュニケーションのためのきっかけになれば良いなと思います。

Continue reading

「カード」は2次元?3次元?

blogtitle_card

こんにちは、マークアップエンヅニアのゆーじろ(仮称)です。

今回は皆さんが今まさしく使っているWEBサイトについて書きます。
といっても全てを書くと膨大になってしまうので、テーマを「WEBサイトの奥行き」に絞ってお話します。
WEBの世界はその歴史も相まって不可思議なものです。

本題に入る前に…

WEBサイトの見栄えはHTMLというもので殆どが出来ています。
HTMLはタグと呼ばれるもので構成されていて、テキストの意味をコンピュータに伝える為の役割をしています。
これがあるおかげで、例えばニュースの更新をチェックするWEBサービスだとか、そういった情報の特定をすることやリッチなデザインを表示することが出来ています。
私の仕事であるマークアップはデザインと情報を切り分けて、WEB上に「再現」させるものです。

ここでタイトルの話をしましょう。
皆さんはカードを3次元だと思いますか?2次元だと思いますか?

Continue reading

PHP初心者向けのコードの最適化

php_code_image

こんにちは。GeNERACEのみきあらいです。
今回はPHP初心者の方に向けて、コードの最適化について書かせて頂きました。初めにコードを書くにあたって意識したことをまとめ、その後に実際にどのようなコードを書いたのか、サンプルコードをご紹介します。

Continue reading

オブジェクト指向CSS(OOCSS)とSassとUIデザインのベストな関係

こんにちは、マークアップエンヅニアのゆーじろーです。
今回は掲題の通り、オブジェクト指向CSSという概念について書きます。

ちなみに恥ずかしながら私はつい最近までこのOOCSSという概念を知りませんでした。
ただ、私が普段CSSコーディングする際に行っている行為がどうやらこれらしい。というのと、
いくつかドキュメントを探してみたら、概念を誤解しているようなものも散見されたので改めて纏めました。

Continue reading

エンジニアもロジカルに企画・デザインできる!ハイパーエンジニアデザイナーへの道」

iQONさんの画像
こんにちは。GeNERACEのエンジニアのみきあらいです。

今日はiQONさん主催のイベント「人気ファッションアプリiQON★クリエイティブワークショップ ~女子をつかむUIの作り方&デザインワークショップ~」に参加したときのお話をします。

すでにご存知の方もいるかもしれませんがiQONとはどういうアプリかというと、女性向けのファッションを取り上げたアプリで、ユーザーは自分で考えたコーディネートをアプリ上にアップできたり、他のユーザーがアップしたコーディネートで欲しいものがあったら買えるというものです。

百聞は一見に如かずということでアプリの詳細については以下をご覧ください。facebook×amazonといった感じで面白いです。

http://www.iqon.jp/

イベントに参加してどういうことをしたかというと、iQONの方々のお話を聞いたあとは参加者同士でグループワークをしました。グループワークのテーマは「アプリの登録情報入力画面とログイン画面をデザインする」です。

以下、イベントとグループワークを通して聞いた話とそれに対する気付きを紹介してきます。

  • 「面倒なこと」「つまんないこと」が斬新なデザインを生む!

イベントで聞いた話の概要(以下、イベント):「名前とか住所とか入力するのめんどくせーなあ」→「やっぱ登録するのやめるわー」

といったように登録する直前でアプリから離れてしまうユーザーは少なくないようです。そういったユーザーの動きを止めよう!という傾向があります。
例えば対話型や穴埋め式のログインフォームにするといったような工夫が必要です。アメリカですでにそんな画期的なログインフォームがあります(例:私の名前は「    」です。)

気付き:ネガティブ要素を潰すことが新しいデザインやコンテンツを生むようです。
例えばソーシャルゲームで遊んでいて「挨拶機能とか面倒だな」と思ったら、挨拶機能をなくして別の機能でユーザーに特典をあげる、などというアイディアを企画チームにも話して、その仕様で実装するということができそうです。

  • データ至上主義

イベント:「なんとなーくこれがやりたい」「なんか良さげ」で企画やデザインを決めないし決めさせない!
「LINEの新しいスタンプを売る」という企画があるとします。スタンプを売るということで例えばディズニーのスタンプを売ろうという意見があり、それを採用するとします。
もしこの「ディズニーのスタンプを売りたい」ということを実現するためには、大抵の場合「なぜディズニーのスタンプを売るのか」「売り方・宣伝の方法はどうするのか」ということを考える、つまり「1. 売りたいものを考える → 2. 売り方を考える」という流れになると思います。

まず、ターゲットをすでにスタンプを高頻度で使ってるユーザーに絞ります。これによって、スタンプを買わないユーザーではなく、スタンプを買うユーザーに絞ります。
次に、スタンプを使っているユーザーが別のスタンプを買い換えるタイミングを調査します。
調査の結果、ユーザーがスタンプを買い替えるタイミングがわかったら、「新しいスタンプができました」というメッセージをターゲットであるユーザーに一斉送信します。
そのあと、スタンプをよく使うユーザーが実際にどういうスタンプを買っているのかを調査します。
調査してどのようなスタンプがよく売れているのかがわかれば、そのスタンプと似たようなスタンプを新しいスタンプとして売ります。

このように、イベントで聞いた話によると、「1. 売り方を考える → 2. 売るものを考える」といったように、はじめに書いた「1. 売りたいものを考える → 2. 売り方を考える」という順番とは異なります。
なぜ順番が異なるのかというと、「1. 売りたいものを考える → 2. 売り方を考える」という順番では、データ分析の前に「ディズニースタンプを売る」と決めているのに対し、後者の「1. 売り方を考える → 2. 売るものを考える」という順番では、データ分析に基づいて売る方法を考えた上でそれのあとに何を売るのか決めているからです。

「やりたいことがあるならデータ分析に裏付けされていないと企画としてみなさない」ということもこの例え話と同時にイベントで聞きましたが、この考えが売れるコンテンツを生み出す秘訣なようです。

気付き:正直デザイナーの方々は感性とかを何より大事にされるだろうという認識があったので、(会場にはデザイナーとディレクターの方々がいたわけですが)どちらかというと感性がものを言うことより、論理的なデータ分析の話をたくさん聞けたのがとても新鮮でした。

—————————————————————————–

☆その他気づいたこと、聞いたこと

  • 足を使って情報を稼ぐ!

「プログラマー=超絶運動不足」と思われがちですが、とにかく足を使って色んなイベントに参加してみると、他の会社の方々と情報交換して自分たちの仕事に活かせられます。(「skypeでいいじゃん」という意見もありそうですが、直接会場に出向くのが一番だと思います。また、ただイベントやセミナーの話を聞くだけでなく、実際にイベントの会場でグループワークをしてみたり、その場にいる人と情報交換をするなど、イベントに参加するときは受け身にならないという心意気も大切だと改めて思いました。)

今まではどちらかというと、企画チームに受身的に仕様を聞いて実装していたのですが、仕様やデザイン案をただ聞くだけではなく、自分から提案していく姿勢が大切なのかなと思いました。

最後までお読みいただきましてありがとうございました。

効率が良いペアプログラミング

こんにちは。エンジニアのみきあらいです。今回はペアプログラミングについて書きます。

「ペアプログラミング」「ペアプロ」などといった単語でgoogle検索すると様々な記事が紹介されますが、今回は初めてのペアプログラミングを行ったときのやり方と気づいたメリットをまとめていきます。

    ☆ペアプログラミングしたときの状況

  • ペアを組んでもらった人:自分よりも経験があり技術力もある(コードを書くのが速い、知識が豊富なため問題解決が速い)人
  • Gitでソースコードを管理しました。コードを書くときは各自のPCを使用しました。
    ☆メリット
    実は効率が良い:「二人で一つのコードを書くので効率が悪い」と思われがちですが、以下のメリットがあります。

  • 良い実装方法を共有しやすい:自分よりも経験があり技術力がある人に見てもらってペアプログラミングをすることにより、一人でコードを書くよりも良い実装ができます。
    さらに技術力がある人がコードを書くのを見てるとコーディングの勉強になる上に、開発を行う際にもどのように実装されたかをリアルタイムで見ているので情報共有がしやすいです。

  • 手戻りが少なくなる:一人がコードを書いてもう一人がそのコードを同時に見ているので、問題点があればその場で指摘でき、解決もその場でできます。
  • ソースコードを確認する時間が短縮できる:例えばGitでソースコードを管理しているときにもメリットがあります。GitでPull Requestを送って第三者にマージしてもらう場合、その第三者がリクエストした人とペアプログラミングをしていれば、リクエストされたコードを読むのに時間をかけなくてもどういう実装がされているのかがわかるので、すぐにマージをすることができます。
  • コーディングとコードレビューをほぼ同時に行うことができる:一人がコードを書き、もう一人がそのコードをほぼリアルタイムでレビューすることができるので、実は効率が良いです。
  • コードに責任を持てる:チーム開発ではつい自分の書いたコードに集中し、他の人が書いたコードに注意が向かなくなりかねないこともなきにしもあらずですが、それを回避するためにも「二人以上の人が書いて確認する」ことにより、そのコードに対して責任を持ちやすくなります。従って万が一障害などが起こった場合も、責任を持っているコードならより対処がしやすくなります。
    ☆今回のペアプログラミングのやり方とポイント

  • コードを書く人と書いてるのを見る人の2人で行います。30分交代でコードを書きます。
    その際は時間配分を計算して「どの処理まで書いたら交代」ということをあらかじめ決めておきます。
    具体的には、今回ペアプログラミングでやる実装の範囲を決めて、その中で行う実装をわけて作業をするとスムーズです。
  • コードを書くときはそれぞれのPCを使います。交代の段階でGitにコミットし、相手に引き継ぎます。
  • コードを書くときは「今どういう処理を書くのか」「何のためにこの条件分岐を行うのか」などを発言しながら書きます。
    実際にコードを読めばどういうことをしているのかわかるといえば確かにそうなのですが、ペアプログラミングで重要なのは「常に認識合わせを行うこと」なので、常に会話をしてコードを書くようにします。
    認識が少しでも合わなくなると二人でコードを書いている意味がなくなってしまいます。ただ会話すればいいという訳ではなく、コードを書く人も見る人も互いに認識確認をすることが大切です。
  • デバッグをこまめに行います。これはペアプログラミングに限った話ではないですが、バグを未然に防ぐためにもこまめに行います。
    ペアプログラミングならデバッグも一人ではなく事実上二人で行うため、より確実にデバッグを行うことができます。
  • コードを見る人は、書いてる人のモニターに張り付く勢いで30分間見ることに集中します。
    (当たり前のことのようですが、本当に30分間なら30分間集中しないとペアプログラミングではなく単独でコードを書くことになってしまうためです。)
  • コードを書いてる人のミスを発見したときは、「なぜそのような実装をしたのか」を見ている人が質問します。
    質問に答えることによって、コードを書いている側も「自分が本来やりたかった実装」と「今自分が書いてる実装」の違いに気付き、ミスの解決が速くなります。
    また、不要なメソッドの有無、変数名の付け方、インスタンスの生成の場所などに関しても指摘事項があればすぐにそれを共有します。
  • 書いてる人は見てる人の言う通りにコードを書くのではなく、見てる人にアドバイスをもらいつつも主体的にコードを書きます。
    これも当たり前のことのようですが、見てる人の方が書いてる人より経験がある場合、書いてる人はつい見てる人の指示通りにコードを書いてしまうようなこともありえます。が、それだと結局二人ではなく、見てる人が一人で書いているのとほぼ同じになってしまうため、ペアプログラミングの意味がなくなってしまいます。
  • コードを書くことからは少し外れますが、コードを書いてる人が自分よりも技術力がある人の場合、その人が調査してるときのやり方も見るべきポイントとなります。自分が一人でコードを書いていて調査するときの参考になります。

まとめました。

  • コードを書く人と見る人は交代制
  • 常に認識合わせをすること
  • 「一人」ではなく「二人」でコードを書くという認識を忘れずに!
  • 今回のペアプログラミングに関するメリットとポイントについては以上です。今回は具体的なコードの公開などは割愛させていただきました。
    最後まで読んでいただきまして、ありがとうございます。

    デザイナーの為のSass/Compassのすゝめ

    三月とはいえすっかりもう桜が咲き、杉花粉で目と鼻を塞がれ
    これで耳と口も塞がったらさながら『ライ麦畑でつかまえて』の主人公だななどと思っています。ゆーじろーです。

    今回はSass/CompassについてのHowtoを書かせていただきます。

    SASS
    compass

    Continue reading

    LinuxのシェルコマンドでFuelPHP開発環境を構築

    こんにちは。金髪エンジニアのみきあらいです。今日でGeNERACEに入って2ヶ月めになります。
    今回はLinuxのシェルコマンドを使ってFuelPHPの開発環境を構築する方法について書きます。

    個人で開発環境を設定するのなら一人でコマンドを叩けばいいのですが、複数人で同じことをする場合、
    各人がそれぞれコマンドを叩くのはあまり効率的とは言えません。
    そこで、「これさえあれば一瞬で開発環境が作れる!」というシェルスクリプトを書きました。

    ☆下準備

    • GitのリポジトリにFuel PHPをフォークする。
    • DNSにサブドメインを設定する。
    • Apacheが入っているLinuxサーバーを準備する。
    • PHP5.3がApacheで起動していることを確認する。
    • サーバー用のssh鍵を作成する。(Git使用時に必要)
    • configファイル、xxx_setupを書いてサーバー上に置く。(注意:本物のconfigファイルではなく、あくまで別のconfigファイルを作成するためのものなので、拡張子を.confにしないこと!)

    xxx_setupの中身

    <VirtualHost *:80>
            ServerName 任意の名前(例:xxx)
            DocumentRoot 任意のドキュメントパス(例:/home/xxx/www/public)
            DirectoryIndex 任意のファイル(今回はindex.phpとindex.htmlを設置)
    </VirtualHost>
    

    ServerNameに記載した名前でブラウザから参照することができます。

    ☆今回やりたいこと

    • 作成したconfigファイル、xxx_setupの中身をコピー。
    • コピーしたファイルをもとに”各ユーザー名.conf”を作る。
    • コピー元ファイルでユーザーごとにあわせて置換したい部分を置換。(上記の例だとサーバー名やルートパス内の”xxx”を各ユーザー名に置換)
    • Gitに置いたFuelPHPをサーバーにgit cloneする。
    • Apacheを再起動する。

    シェルスクリプトを書きます。
    今回は”shelltest.sh”というシェルスクリプトを作成します。

    vi shelltest.sh
    

    “shelltest.sh”の編集を行います。
    まず、シェルスクリプトを/bin/shで実行させます。

    #!/bin/sh
    

    echoの後ろに変数や文字列を指定します。今回はコメントを文字列として表示します。
    すでに”ユーザー名.conf”がある場合も考慮し、スーパーユーザー権限で事前に削除します。-rfをつけてエラーなしで削除します。

    echo "setting for httpd"
    sudo rm -rf /etc/httpd/conf.d/${USER}.conf
    

    事前に作成したxxx_setupを、”ユーザー名.conf”としてコピーします。

    sudo cp -rf /etc/httpd/conf.d/xxx_setup /etc/httpd/conf.d/${USER}.conf
    

    コピー元のxxx_setupの中には”xxx”という文字列があり、それを各ユーザー名に変えたいので、置換するためのコマンドを書きます。

    sudo sed -i "s/xxx_setup/"${USER}"/g" /etc/httpd/conf.d/${USER}.conf
    

    変数として${USER}と書くと、そのまま${USER}という文字列として置換されてしまうので、${USER}以外をダブルクオーテーションで囲みます。

    次に、confで作成したDocumentRootにFuelPHPを配置します。今回は/home/ユーザー名/www以下にFuelPHPを置きます。
    /home/ユーザー名/wwwが既にあることを想定して一度エラーなしで削除し、新たにディレクトリを作り直します。

    echo "delete old folder"
    rm -rf /home/${USER}/www
    echo "settings"
    mkdir /home/${USER}/www
    

    /home/${USER}/wwwに移動し、Gitに置いたFuelPHPをサーバーにクローンします。
    git@github.com:の後ろにはGithubの各人のユーザー名を書くので、変数として$1を引き渡します。

    echo "clone git@github.com:"$1"/fuel.git "
    cd /home/${USER}/www/
    git clone git@github.com:$1/fuel.git
    

    今回はクローンするだけとしましたが、中央リポジトリのリモートリポジトリを作成したい場合は以下のコマンドを書きます。
    (例:fuel.gitのクローン元があるGithubのユーザー名=”UserXXX”、リモートリポジトリ名=”upstream”)

    git remote add upstream git@github.com:UserXXX/fuel.git
    

    例として”dev”というブランチを作成し、devブランチに切り替えてpullとpushを行います。

    git checkout dev
    git pull upstream dev
    git push origin dev
    

    最後に作成したconfファイルを反映させるためにApacheを再起動させます。
    restartだとエラーが起きたときにApache自体が落ちてしまうので、それを避けるためにgracefulコマンドを使います。

    echo "graceful httpd"
    sudo /etc/rc.d/init.d/httpd graceful
    

    “shelltest.sh”の編集モードを終了します。これで”shelltest.sh”の完成です。

    ☆”shelltest.sh”の実行!
    早速作成した”shelltest.sh”を実行しましょう。引数$1としてLinuxに渡すGitHubの各人のユーザー名を実行時に入力します。

    cd shelltest.shが格納されている場所
    sh shelltest.sh GitHubの各人のユーザー名
    

    これでシェルスクリプトを叩くだけで、FuelPHPの開発環境ができるようになります!
    シェルスクリプト全体はこちらのgistを参照してください。

    今回はここまでです。ご覧いただきましてありがとうございます。

    参考記事一覧

    Andengineで使うスプライトアニメーション素材作成

    皆様はじめまして、今月からGeNERACEに参画してます。マークアップエンジニアのユージローです。

    さて、いくつか前のポストでも紹介されてる通り、弊社ではAndengineを使用して開発を行っています。

    Andengine = java

    マークアップエンジニア = html,css,javascript,etc

    仕事が無い!(待て

    そんなこんなで慣れないjavaを少し触りつつ、僕は現在キャラクターなどの画面素材を担当しています。

    Andengineはjavaですので、アニメーションの実装方法もcssアニメーションなどではなく、javaを用いてのアニメーションが主になりますが、スプライトアニメーションは昔ながらのフィルムビデオと同じ形式です。

    全てのコマを一枚の画像として書き出さなければなりません。

    スプライトシートは縦横に繰り返すものもありますが、単純なものであれば
    縦もしくは横のみの繰り返しで済みます。

    このスプライトシートですがアナログな作業でやるのは効率的ではないのでツールを使います。
    作成ツールも下記のように幾つかあるのですが、Flash Pro CS6からFlashでもスプライトシートの作成が可能になりました。

    インストールタイプのツール:http://www.codeandweb.com/texturepacker
    ブラウザアプリ:http://draeton.github.com/stitches/

    ということで今回はFlash Pro CS6を使用した場合のスプライトシート作成手順です。

    ステップ1:Flashアニメの書き出し

    Flashアニメの作成方法は端折るとして、ここでは作成したFlashアニメをpng画像に書き出します。キャプチャのようにメニューの『ファイル』➡『書き出し』➡『ムービーの書き出し』を選択します。

    ss2013-02-22-12.40.08

    フォーマットは今回背景有の為jpegでもgifでも良いのですが、変更で透過させる可能性も考えてpngシーケンスを選択しました。ss2013-02-22-12.58.30

    保存するとタイムラインに沿った画像が全て吐き出されこのようになります。
    無事に書き出せました。

    スクリーンショット-2013-02-22-13.07.54

    ステップ2:ライブラリへの取り込み

    ここでまたFlash Proで新規ファイルを作成します。
    新規ファイルを作成したら、メニューの『ファイル』➡『読み込み』➡『ライブラリに読み込み』を選択し、先ほど書き出したpng画像を全て読み込みます。
    スクリーンショット-2013-02-22-13.22.39

    ステップ3:スプライトシートの生成

    読み込みが完了したら、今度はライブラリウインドウから全ての素材を選択して右クリック➡『スプライトシートを生成』を選択します。

    スクリーンショット-2013-02-22-13.55.21

    最後です。
    スプライトシートの出力と書かれている部分でシートの幅と高さや、素材間の距離、背景色などの調整を行い書き出して完了です。
    スクリーンショット-2013-02-22-14.01.50

    シートの大きさなどは実際の実装にも影響する為、事前に認識のずれが無いかなどの確認が必要です。

    また今回は新規ファイルを作成しましたが、Flashアニメーションの任意のキーフレームシンボルからスプライトを生成することも可能になっています。

    ご覧いただきありがとうございました。

    GitとGitHubを使いこなすためのメモ

    こんにちは。2月から入った新人のあらいみきです。今日から「爆速」で開発できるエンジニアになるために頻繁にメモを書き残します。
    第一弾のテーマはGitです!

    macでGitを使いこなすための簡単なメモ。

    1. 下準備

    ☆用意するもの

    • Xcodeがインストールされていて、Command Line Toolsが入っているmacbook

    ☆インストールするもの

    • Tower

    ☆GitHubの設定をする。

    • GitHub https://github.com/

    ☆Git coreをmac portでダウンロード

    $ sudo port install git-core
    

    ☆Gitのバージョンを確認

    $ git version
    

    2. Gitを使う

    ☆登場人物

    • 中央リポジトリ…メインユーザーが持つプロジェクトのリポジトリ。
    • リモートリポジトリ…各人が中央リポジトリからforkしたリポジトリ。メインユーザーではなく各人のリポジトリとなる。
    • ローカルリポジトリ…リモートリポジトリからローカルへクローンして作るリポジトリ。

    ☆Gitのおさらい

    • fork…自分のGitのリポジトリに任意のGitのリポジトリをコピーする。
    • pull…任意のリモートリポジトリの変更を自分のところに反映させる。
    • push…自分のリモートリポジトリに、自分のローカルでの変更を反映させる。commitとセットで行うとわかりやすい。
    • commit…自分がローカルで行った変更を確定させる。commitしただけだと変更が自分のリモートリポジトリ反映されないことに注意!(svnとは違う)
    • pull request…自分のリモートリポジトリの変更を中央リポジトリに反映させたい場合は、中央リポジトリに対してpull requestを送る。
    • master…リポジトリの大本命。ここを簡単に変えられないように枝分かれのリポジトリ(=branch)を作る。
    • 中央リポジトリの設定について…Git Flowに似た運用をしているので、中央リポジトリの更新用にリモートリポジトリを追加します。

      中央リポジトリの設定について詳細は後述

    ☆ローカルにgitのリポジトリを置くディレクトリを作る。

    $ mkdir Git用ディレクトリ名
    

    ☆GitHubでコピーしたいリポジトリをforkする。

    ☆forkしたリポジトリのクローンをローカルに作る。

    $ cd Git用ディレクトリ名
    $ git clone git@xxx/yyy.git
    $ git checkout -b ブランチ名
    

    ※今回はSSHの鍵認証を使ってるので、HTTPではなくSSHを選択しました。

    ☆中央リポジトリの設定を行う。
    今回は中央リポジトリのリモートブランチとして、”upstream”という名前のリモートブランチを作成しました。

    $ git remote add upstream git@フォークしたリポジトリの元のURL
    

    ☆ローカルで、クローンしたリポジトリ内のどこかに変更を加える。

    ☆自分の変更をまずはコミットさせる。

    • Towerの左側のBRANCHESは常にチェックすること。ターゲットになってるブランチだったら、ブランチ名の横に(HEAD)と書いてある。
    • コミットさせたい変更したファイルを選ぶ方法→Statusタブを開いて、任意のファイルのStagedをチェックする。チェックしたら、上部にあるチェック印の”Commit”ボタンをクリック。

    これで「コミットは完了」!、、だけどローカルの変更は自分のリモートリポジトリに反映されていない。pushをして、ローカルでの変更を自分のリモートリポジトリに反映させる。

    ☆変更をpushする。
    Towerの上部のpushボタンをクリックし、ブランチの場所を要確認してokボタンをクリックする。
    これで自分のリモートリポジトリにも変更した内容が反映させる。
    今回はTowerでpushしましたが、ターミナルを使う場合は以下のコマンドを打ちます。

    $ git push origin ブランチ名/プロジェクト名
    

    ※引数なしのpushをすると、カレントブランチに関わらずローカルブランチと同名のブランチがリモート上にある場合はそれらを一気にpushします。

    ☆中央リポジトリの最新版を取り込む。

    $ git pull upstream ブランチ名
    

    ☆pull requestを送る。
    GitHub上で自分がフォークしたリポジトリのページに遷移し、Commitsというタブを選択し、自分のpush内容が反映されていることを確認し、pull requestボタンをクリックする。

    • pull(変更を)する側…master
    • pullするもの…pull requestを送る側が変更した箇所

    これで中央リポジトリの管理者にpull requestが送信される。

    ※pull requestを押した後、Tower上で空pushをする。これで自分が行った変更+中央リポジトリの変更を自分のリモートリポジトリに反映することができる。

    ☆mergeしたいときは?

    自分がpull requestを送ったと同時にほかの誰かもpull requestを送ったとき、エラーや競合が起きない範囲で変更を反映させたいところです。

    そこでGitHub上でmerge pull requestボタンを押すと、簡単にmergeを行うことができます。さらにmergeされた箇所に対してコメントを書くこともできます。これでソースレビューとマージが同時にできます!

    ※自分が行った変更と他の人が行った変更がコンフリクトした場合。
    例えば他の人と同じファイルを変更していて、pullした際にeclipse上などでファイルを確認したときにエラーが起こっている場合は、自分でeclipe上で変更分を手動でマージする必要があります。その後改めて変更分をpushし、pull requestを送る必要があります。

    今回はここまでです。ご覧いただきましてありがとうございます。

    参考記事一覧