上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

Vanです。
2月9日の勉強会では、3Dオブジェクト作成ソフトblenderについて共有しました。


blenderブログ用


blenderは、S丼曰く、最も使いやすい3Dソフトとのこと。

視覚的に利用しやすいのが利点ということです。

今回は、blenderの基本動作を学ぶものとして、他サイト様に載っていたサイコロ的なものを作るチュートリアルを実践しました。

上図のようなサイコロのオブジェクトを作ることができました。

自分(Van)はblender初心者なのですが、面取りなどが簡単に実行でき、blenderの便利さが実感できました。

用いるべきキー操作は多いですが、さすがにこれは覚えきれないので、毎回調べる形にしようと思います。

自分が3Dオブジェクト担当に新任しているので、これからこれを使っていろいろ作っていきたいですね。


ではでは!また次回お会いしましょう(←?)

スポンサーサイト
こんにちは。Cincです。

今更ですが、1/16に行った勉強会のまとめです。

目的


今回の勉強会の目的はそれぞれの担当分野について調べ、学んだことをアウトプットしつつ他メンバーに知ってもらうことが目的で、僕とLuiが発表しました。

発表内容


Cinc

今回の勉強会ではメンバーにUnityの基礎知識を知ってもらうことも兼ねて、Unityのゲームオブジェクトとプレハブについて発表しました。

発表資料はこちらです。プレハブはUnityを使う上で必要不可なものなので、メンバーににも是非覚えてもらいたいです。
説明だけではわかりづらいので、花火のようなものを打ち上げているように見えるプログラムを実演で作成しました。

せっかくなのでWebGL向けにコンパイルしたものを置いておきます。
最近のChrome、Firefox、Edgeなどのブラウザならリンク先でそのまま再生されます。


クリックした場所に花火のようなものが現れます。それだけです。

Lui

発表内容は音楽作成ソフトについてです。
Cubaseというソフトを使っているようで、実際に簡単な曲の作成を実演してくれ、Luiの音楽センスの高さが垣間見れました。
これはLightningGraviryの曲にも期待できますね(ハードル上げ)

最後に


簡単なまとめになりましたが、以上になります。
次回の第4回勉強会は1/30です。……というか今日です。
第4回勉強会のまとめについては、第4回勉強会ブログのアップロード役であるS丼が行う予定です。

Vanです。

引き続き勉強会で学んだことを紹介します。

今回はLuiさんの調べたGitの主要コマンドです。


コマンド

解説・詳細

git config --global user.name "<ユーザ名>"

git config --global user.email "<メールアドレス>"

設定

git config --global color.ui auto

git config --global alias.co checkout

gitの出力をカラーリング

エイリアス設定(checkoutをcoに)

git branch <NAME>

git checkout -b <新ブランチ名>

git branch -d <ブランチ名>

ブランチ作成

ブランチの作成とチェックアウトをまとめて行う

ブランチ削除

git remote add <NAME> <URL>

リモート化・・・インデックス(ファイルの変更点などのリスト?)をGitHubに作成

リモートリポジトリのアドレスを名前付け(普通は<NAME>はorigin)

git status : 確認

git add -A : 追加削除情報をインデックス登録

git commit -m "add event" : コメント

git push -u <リポジトリ名> <ブランチ名> : 反映

git status : 確認

git add -A : 追加削除情報をインデックス登録

git commit -m "add event" : コメント

git push -u <リポジトリ名:origin> <ブランチ名> : 反映

クローンしたリポジトリでは、pushのパラメータのorigin masterは省略可

プッシュやプルは実行時にリモートリポジトリ名を省略すると、originという名前のリモートリポジトリを使用

git log

git log --graph --oneline

git log --decorate

リポジトリの変更履歴を表示

可視化

タグ情報も見れる

stash

まだコミットしてないファイルがインデックスやワークツリーに残したまま他ブランチへチェックアウトすると、その変更内容は元のブランチから移動先のブランチに対して移動する。

移動先のブランチで同じファイルが既に変更されている場合チェックアウトに失敗。

このような場合は、変更内容を一度コミットするかstashで一時的に変更内容を退避させてからチェックアウトしなければならない

退避させた変更は後から取り出して、元のブランチや別のブランチに反映可

rebase

merge : 変更内容の履歴はそのまま残るが、履歴が複雑になる

rebase : 履歴は単純になるが、元のコミットから変更内容が変更される(元のコミットを動かない状態にしてしまうことがある)

rebaseしただけだとmasterの先頭の位置はそのままなので、masterブランチからNEWブランチをマージして、NEWの先頭まで移動

(例:統合ブランチにトピックブランチを取り込む場合は、まずrebaseしてからmerge)

rebaseにiオプションを指定すると、コミットの書き換え、入れ替え、削除、統合を行うことができる

→ pushする前にコミットコメントをきれいに書きなおす、意味的に同じ内容のコミットをわかりやすいように一つにまとめる、コミット漏れしたファイルを後から追加する

git fetch

pullを実行するとリモートリポジトリの内容のマージが自動的に行われる。(pull = fetch + merge)

単にリモートリポジトリの内容を確認したい場合はfetch

取得したコミットは名前の無いブランチとして取り込まれ、FETCH_HEADという名前でチェックアウト

git tag <tagname>

git tag -am "注釈" <tagname>

git tag -d <tagname>

タグ名を指定してcheckoutしたり「コミットの書き換え」で説明するresetをすることで、簡単に過去の特定の状態に戻せる

-aで注釈つきタグ、-mでコメント

タグ削除

git commit --amend

指定してコミットを行うと、同じブランチの直前のコミットに対して内容を追加やコメントの修正

git revert HEAD

指定したコミットの内容を打ち消すコミットを作り出す。rebase -iやresetによるコミット削除は、そのコミットが既に公開済みだと削除できない。

reset

要らなくなったコミットを捨てる

モード名

soft ・・・ HEAD位置変更する + インデックス変更しない + ワークツリー変更しない → コミットだけを無かったことにする

mixed ・・・ HEAD位置変更する + インデックス変更する + ワークツリー変更しない → 変更したインデックスの状態を元に戻す

hard ・・・ HEAD位置変更する + インデックス変更する + ワークツリー変更する → 最近のコミットを完全に無かったことにする

cherry-pick

cherry-pickでは、別のブランチから指定したコミットをコピーして、現在のブランチに取り込む

(ブランチを間違えて追加したコミットを正しい場所に移す、別ブランチのコミットを現在のブランチにも追加する)

squash

このオプションを指定してブランチをマージすると、そのブランチのコミット全てをまとめたコミットが追加される

rm -rf ディレクトリ名

gitディレクトリごと削除

git pull origin develop

developブランチのものを取ってくる(pull = fetch + merge)

git add -A

1.Xと2.Xの違い

(1.X)

git add . と git add -u を足したもの(削除と追加ファイル全部反映)

git add . ・・・ ワーキングツリーに新規作成、あるいは変更されたファイル対象(削除されたファイルはaddされない)

git add -u ・・・ 一つ前と最新のステージを比較して、変更があった部分のみをadd(新しく作られたファイルはaddされない)


(2.X)

git add -A : ツリー全体を対象とする

git add . : カレントディレクトリ以下のツリーを対象とする


Git 1.x では対象に削除されたファイルを含むかが違い、Git 2.0からはその違いはない。

git checkout master

git merge(rebase) develop

git add myfile.txt(競合修正後)

git rebase --continue

まず取り込み先の別のブランチに移動

developブランチの内容を持ってくる(競合しなければdevelopにブランチ切り替わって統合)

rebaseの場合、競合箇所を修正した後はコミットではなくrebaseコマンドに --continue オプションを指定実行。もしrebase自体を取り消す場合は --abort オプションを指定

最後にgit push origin master

git checkout .

git reset --hard HEAD~

変更を打ち消す

マージを取り消し



今回は初心者の自分にもわかりやすい内容ですね。

今回の勉強会で学んだことの紹介は以上です。

また次回の勉強会をお楽しみに(?)

Vanです。

前回に引き続いて勉強会で学んだことを紹介していきます。

今回はS丼さんの調べたGit diffについてです。

ブログの使い方がつかめないのですが、コピーしたものが黒字になってしまう・・・書式スタイルのクリア押してもなんで変わらないんだろう?

というわけで我慢して見てください(ぁ



“git diff”の基本動作

⇨ワーキングツリーに行われた変更の表示


[インデックス] → [ワーキングツリー] の差分を見る場合

$ git diff



引数に「比較元」を指定できるので、引数を変更することにより、比較対象を変更できる。


// [最新コミット] → [ワーキングツリー] の差分を見る場合

// HEADは現在のブランチの先頭のコミットへの参照

$ git diff HEAD



指定したコミットとの差分を見たい場合


// <commit> → [ワーキングツリー] の差分を見る

git diff <commit>


——————

[参考]commitの識別子


$git log

commit 0162e65afed22b9fbd4ef915d77f9f67a223f7ec

Author: naoyashiga

Date: Sun Jun 2 18:57:30 2013 +0900

change README.md

commit 57228b29d976075bdf47eb9ea7ead44c8b867632

Author: naoyashiga

Date: Sun Jun 2 18:55:15 2013 +0900

change README.md

——————



他の差分についても見てみる


「--cached」オプションを利用することで、インデックスを変更を見ることができるようになる。


//インデックスとHEADの差分を確認したい場合

$ git diff --cached HEAD

$ git diff --cached             //こっちでもok



特定のコミット間を比較したい場合はこちら


// コミット同士を比較する

git diff [比較元のコミット] [比較先のコミット]


*コミットの指定は、コミットのID、ブランチ名、HEADのどれでもOK



こういうこともできるらしい。比較対象を限定したい場合


// パスやファイル同士を比較する

git diff <コミット名>:<ファイル名> <コミット名>:<ファイル名>





ん?いつ使うべきなのか書いてる自分がわからないぞ?(あーあ

次回はGitの主要コマンドについてです。

Vanです。


luftelliメンバー内で勉強会を行ったので、今回はその内容についてまとめたいと思います。
実は自分であるVanは忘年会の影響で今回の勉強会に参加できなかったので、書いてる自分自身で分かっていない部分だらけですが・・・・・。

今回はCincさんが調査したGitでよく起こる問題と解決方法についてです。


  1. リポジトリのクローンに時間がかかる

    Shallow Cloneにより最新のファイルのみをクローンする
    git clone --depth 1 [URL]
  2. 作業する前にブランチを切り替え忘れた

    1. まだコミットはしてない
      stashコマンドを使う

      1. git stash #現在されている変更を退避する

      2. git checkout [目的のブランチ名]

      3. git stash pop #退避していた変更を元に戻す

    2. コミットしてしまった

      1. git reset --soft HEAD^ #直前のコミットを取り消す

      2. まだコミットしていない場合と同じ手順

  3. 他の人がすでにpushしていた/作業前にpullし忘れた状態でローカルに変更を行ってしまい、pushできない
    pullを行い、必要なら競合の解決をしてから改めてpushする

    1. git pull origin [現在のブランチ名]

    2. 競合が起きたら競合の解決

    3. git push -u origin [現在のブランチ名]

  4. 競合が起きてしまった

    1. 競合が起き得る状況
      同じファイルを変更していても可能な場合は自動でマージしてくれるが、自動マージが不可能な場合は競合部分にマークがつけられるので、自分で解決しなければならない

      1. ローカルとリモート上がともに変更されているときにpullする

      2. 同じファイルが変更されているブランチをマージする

    2. 競合の解決
      競合を解決する場合は、競合が起きたファイルに変更を加えた人とも相談するのがいいと思う

      1. どちらか片方のブランチのファイルを優先する

        1. 現在いるブランチを優先させる場合
          git checkout --ours [ファイル名]
          ファイル名に”.”を指定することで、全てのファイルに対して適用できる

        2. マージ相手やリモートブランチを優先させる場合
          git checkout --theirs [ファイル名]
          ファイル名に”.”を指定することで、全てのファイルに対して適用できる

      2. ファイルを直接編集する
        競合の起きている部分にはマークがつけられている。その部分を自分で修正する。VisualStudioやVIsualStudioCodeではファイルの競合が起きている部分を強調表示してくれたり、どちらを残すか選択すれば自動で書き換えてくれる機能がついている

      3. 編集が終わったら、コミットして作業を再開

  5. なんか色々試したらpushもpullもできなくなってしまった
    下に行くほどめんどくさい方法。-fオプションによる強制pushはリポジトリを壊すことになりかねないのでやめよう

    1. 新しい派生ブランチを作り、そこでpullとpushを試してみる

    2. 変更したファイルをリポジトリ外にコピーして正常なブランチに移動、そこから新しいブランチを作ってコピーしたファイルを元に戻し、pushする

    3. 諦める



むむ?このブログの箇条書きの使い方がつかめず見づらくなってるぞ?

よくわからなかったらコメント欄で質問してください(そもそもこのブログを見ている人などいないとか言ってはいけない)

次回の記事ではGit diffについて紹介します。

プロフィール

Luftelli

Author:Luftelli
ゲーム開発を行なっている4人のチームLuftelliです。
今はデジゲー博2018に向けて、対戦型シューティングゲーム「LightningGravity」を制作しています。

チーム連絡先: Twitter, メール

メンバー
・Cinc: リーダー、プログラム担当
 個人連絡先: Twitter, メール
・S丼: デザイン・素材管理、GUI・2Dグラフィック担当
・Lui: 広報、音楽・BGM担当
・Van: エフェクト・3Dモデル担当

最新記事
最新コメント
月別アーカイブ
カテゴリ
FC2カウンター
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。