fc2ブログ

Gitの主要コマンド

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~

変更を打ち消す

マージを取り消し



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

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

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

スポンサーサイト



git diffについて

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の主要コマンドについてです。

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について紹介します。

初めまして、Vanです。

初めまして、Vanです。

広報担当が変更になりまして、これから自分が務めることになりました。
定期的にブログを更新していこうと思います!

デジゲー博2017が終わりました

Cincです。

デジゲー博2017を目指して6月から4人でゲームを製作してきましたが、時間が経つのは早いものであっという間にデジゲー博2017当日を迎えてしまいました。

とか書いていますが、もうデジゲー博2017が終わってから一ヶ月経ってますけどね。
今更ですが、デジゲー博に限らず展示会の類に参加するのが初めてで戸惑った事もあったので、今回はデジゲー博2017について、準備、設営と当日の流れなどを中心にまとめていこうと思います。


準備


参加するのはいいものの、このようなイベントに参加したことがあるメンバーが誰もいないので、何を準備するのかを決めるのはかなり手探り状態でした。

インターネットで調べると親切にも設営やイベントの様子などを説明してくれている方がいらっしゃり、それらを参考に準備を行うことにしました。参考にしたサイトは以下の通りです。



どのブースも凝っていてすごいです……が、残念ながら僕達にそこまでの余裕はなかったので、説明用のA4ポスターを作るので精一杯でした。単純に準備を始めるのが遅すぎたこともあるので、そこは反省点の一つです。

それはともかく、これらのことを踏まえて用意したものは 

  • ゲーム内容の説明ポスター(A4)2枚
    ゲームルールなどを簡単にまとめたものです。Vanをメインに他メンバーが協力して作ってくれました
  • 本立て&バインダー2セット
    ゲーム内容説明ポスターを立てかけるためのものです。ダイソーで購入しました
  • テーブルクロス2枚
    2スペースの場合、机のサイズは45×180なので一枚では足りず、2枚用意しました。ダイソーで購入しました
  • 滑り止め4枚セット
    マウスを動かした時にテーブルクロスがずれたらやりづらいですからね。効果があったかは分かりませんが。ダイソーで目に入ったので用意しました
  • マウスパッド2枚
    僕たちが用意したゲームはマウスを用いて操作するゲームで、テーブルクロスの上ではマウスの操作がしづらいと考えて用意しました。これもダイソーのものです
  • ノートパソコン4台
    2台はお客さんにやってもらう用、もう2台は裏方用です。残念ながらこれはダイソーで購入したものではありません
  • 有線LANハブ&LANケーブル4本&LAN-USB変換コネクタ
    僕たちが用意したゲームはネットワーク対戦ゲームなので、お客さんPCと裏方PCを有線LAN接続しました。当日は安定性と速度を重視して無線LANではなく有線LANを選択しました
  • タコ足電源タップ
    PC4台に加え、LANハブも電源が必要だったためでです

ダイソー万能ですね。


ブース設営


当日は椅子を一脚500円でレンタルすることができました。はじめは1サークルにつき1つまででしたが、数が余ったようで制限がなくなったため僕たちは2脚借りました。

完成したブースの様子がこちらです。Luftelliの全メンバー四人が写っていますね。

デジゲー博2017ブース 

……あれ、全員写ってるのに誰が撮ったんだ? まあいいか

ところで、なんと当日僕が遅刻するという大失態をおかしてしまったため、これらの設営は他メンバーが済ましてくれました。申し訳ないです。申し訳なさすぎて次の日10時間しか眠れませんでした。


本番


完成が間に合わなかったため、僕たちのブースでは展示のみを行いました。また、事前の宣伝などはほとんど行っていなせんでしたが、端っこのブースだったのにもかかわらずそこそこお客さんがきてくれました。

ブースですが、展示したゲームがネットワーク対戦ゲームなので、はじめはお客さんと裏でプレイするLuftelliのメンバーで対戦してもらうという形式にしていました。
ですが見知らぬ相手と対戦してもなかなか盛り上がらないこと、二人で来ている方が多いことから後半ではお客さん側にパソコンを2台用意し、お客さんどうしでの対戦を体験してもらうことにしました。やはり知り合いどうしで戦った方がやりやすいようで、お客さんどうしで対戦してもらうようにした後半の方が盛り上がっていたように感じます。

イベント自体は11:00から16:00の5時間でしたが、目の前で自分たちの作ったゲームをプレイしてもらって意見をもらえるという貴重な体験ができたと思っています。


終了後


16:00に終了のアナウンスがなりました。それと同時に、会場内に拍手が起こりました。一体感があって良いですね。
この後は17:00まで片付けでしたが、特に時間がかかるようなものもなく30分もしないうちに片付け終わり、会場を出ました。

ちなみにどうでもいいことですが、元々はデジゲー博終了後に打ち上げをやろうかと思っていました。が、全員前日に2時間しか寝ておらず、打ち上げ会場が夢の中になりかねなかったので夕食を食べて解散しました。


最後に


当初の目標はデジゲー博2017でしたが、ゲームはまた完成していないので完成まで作り続けるつもりです。今の所、最終目標はデジゲー博2018あたりを考えています。
近々、おそらく年内にデジゲー博2017の反省記事を書くので詳細はそこで述べます。

プロフィール

Luftelli

Author:Luftelli
ゲーム開発を行なっている4人のチームLuftelliです。
今は2022年後半の公開に向けて、ネットワーク対戦型シューティングゲーム「光影の塔」を制作しています。

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

メンバー
・Cdec: 代表、ゲーム開発全般担当
 個人連絡先: Twitter, メール
・Lui: 各種チェック・レビュー担当
・Van: 広報担当
・Zip: Webページ作成・ゲーム開発担当
・(S丼: 休止)

最新コメント

FC2カウンター