日々淡々と進む日常に一つ足跡を

現役東大生がプログラミングに関して備忘録として記事を残していきます。

英語できるようになりたい

はじめに

これからは、ブログっぽくするためタイトルとか適当な文にしていこうと思います。何か備忘録として残すことがあったら前みたいなタイトルにするかもです。

今日やったこと

  1. Developing iOS 8 Apps with Swift 1. Logistics, iOS 8 Overview復習
  2. Swift公式ページのObjects and Classの前まで

思ったこと

Swift堅ええええええ

Swift勉強その①

Swift勉強その①

今回からSwiftをやっていきます。最終目標は「アプリを作りApp Storeに投稿する」です。

今回やったこと

  1. Developing iOS 8 Apps with Swift 1. Logistics, iOS 8 Overviewを見る
  2. MVC構造を学ぶ
  3. 型指定厳しい

    作ろうとしているアプリ

    人生劇場のような、人生設計ゲームのスマホ版

目標

半年後に公開

ほか今日やったこと

LPIC101の最初の概要

Git　勉強その②

Git勉強その②

programming-it.hatenablog.com

の続きです。

レポジトリの取得

レポジトリとは

その①で簡単に説明しましたが、Gitによるバージョン管理をしているもののまとまりです（ファイル・ディレクトリなどのデータを含む）。

さて、レポジトリの取得ではすでにあるレポジトリ（サーバー・GitHubなど外部サイト）から取得する場合と自分でレポジトリを作る場合があります。

自分でレポジトリを作りGitの管理下に置く

Git Bashなどの端末で

git init

とコマンドを打つとそのディレクトリがGitの管理下に置かれます。

ただこれではまだそのディレクトリの中にあるファイルがコミットされていないので（修正済みの状態）

ステージ済み→コミット済み

この流れをコマンドで打つ必要があります。

git add .    // .は全ファイル・フォルダを指す。git addによってステージ済みになる
git commit -m "commtent" // ステージ済みのものをコミット済みにしている

git commitのところのmがオプションとしてつけられているのが疑問に思った方もいると思います。これはコミットメッセージを次の"“の中の文字列で表す、という意味です。 コミットメッセージは重要です。コミットメッセージによってほかの人がどういったコミットをしたのか把握するからです。

すでにあるレポジトリからローカルにレポジトリをコピーしてGitの管理下に置く

サーバー・Git Hubですでにあるレポジトリを自分のパソコンの中にコピー（クーロン）していきます。

git clone URL

ここでいうURLとはhttp://hogehoge.com/といった見慣れたものよりもID@ドメイン名://パスといったSSHでサーバーを扱うときに使っていく形式が多い気がします。

レポジトリに新規ファイルの追加

上の2つの方法のいづれかでレポジトリができているとします。このレポジトリに新しくファイルを生成する（又は移動して持ってくる）とします。

vim hogehoge.html  // index.htmlを生成する
mv ~/Downloads/hogehoge.css ./  // hogehoge.cssを新しくレポジトリに持ってくる

そのファイルはまだレポジトリに保存されているわけではありません。修正済み・ステージ済み・コミット済みのいづれでもなくて、追跡されていない（untracked）ファイルとして存在しています。なのでこれを追跡されているようにする必要があります。

vim index.html 
mv ~/Downloads/hogehoge.css ./
git add index.html hogehoge.css
git commit -m "new file index.html hogehoge.css"

ファイルの状態確認

git statusでできます。パターンとしては以下のようになっています。((git diffやgit diff --cachedも使えますが省略しました。))

通常時

通常時とはレポジトリに全ファイル・フォルダ保存されていて、コミット済みであることを指しています。

$ git status
On branch master
nothing to commit, working tree clean
コミット済みファイルを変更した時
$ vim index.html

hoge@hoge hoge ~/hoge (master)
$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   index.html

no changes added to commit (use "git add" and/or "git commit -a")

index.htmlが変更された（modified）ということが書かれていますね。

変更済みファイルをステージ済みにした時
$ git add index.html

hoge@hoge hoge ~/hoge (master)
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   index.html

コミットされて（committed）はいないけれどステージ済みになっていることを示しています。

ステージ済みファイルをコミットした時
$ git commit -m "index.html modified meta changes"
[master 8eab8c1] index.html modified meta changes
 1 file changed, 1 deletion(-)

hoge@hoge hoge ~/hoge (master)
$ git status
On branch master
nothing to commit, working tree clean

最初のパターンと同じになりましたね。

新しいファイルを追加した時

追跡されていない状態が生まれるってやりましたね。

$ vim hoge.txt

hoge@hoge hoge ~/hoge (master)
$ git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)

        hoge.txt

nothing added to commit but untracked files present (use "git add" to track)

追跡されていない（Untracked）ファイルがhoge.txtであることが書かれています。 この後git addとgit commitしてあげればコミット済み（しかも追跡されている）ファイルとなります。

Gitの管理下に置きたくないファイル・フォルダがあった時

ディレクトリの中でもGitの管理に置きたくないファイルがあると思います。

例えばlogファイルやGulpなどによって自動的に生成される静的ファイルなどやモジュールなどです。これらを除く方法として.gitignoreというファイルを生成すればいいです。そしてそのファイルの中身に以下のように書くとします。

*.log

これによってlogという拡張子を持つファイルが管理下になるのを防げます。ただし、コミットされているlogファイルに対して.gitignoreでファイル*.logと書いてもすでに 管理下にあるためGitの管理下から外すことはできません。

コミットメッセージ

今まではgit commit -m "comment"とすることでステージ済みのデータをコミットしていました。ここでmオプションをとってみましょう。 すると、エディタが立ち上がります。これはその①でも書いたようにvimがデフォルトですね。ただmオプションつけてやれば基本的にいいと思います。

ステージ済みとかメンドクサイ

git addが面倒だという人もいると思います。その時はgit commitにaオプションを付ければいいです。個人的には好きじゃないです。

ファイル削除

git rmを使いましょう。ただ単にrmだとそのファイルがステージ済みでなくて変更済みとして扱われます。

git rm hoge.txt // これでhoge.txtが削除されたファイルとしてステージ済みになる
git commit -m "hoge.txt deleted"

Git管理下に置きたくないけどファイルは取っておきたい！

.gitignoreを使いましょう。ただ、git initした後ですでにコミット済みであった場合は下のようにします。

git rm --cached hoge.txt
git commit -m "hoge.txt deleted in repo"

ファイル名の変更・ファイルの移動

レポジトリの中でmvコマンドを使いたいときはgit mvを使いましょう。

git mv hoge.txt hogege.txt
git commit -m "hoge.txt renamed"

さて、今回はこれで以上です。公式ドキュメントはやりごたえありますねー。とても面白いです。

Git　勉強その①

Git勉強その①

Git - Book を見ながら勉強していきました。画像などもこちらから引用させていただいています。

Gitが既にインストール済みである状態です。インストール方法などはほかのサイトをあさってみてください。

WindowsにGit Bashを入れています。サーバーはUbuntu 16.04 LTSです。

Gitとは

バージョン管理システム。ただし、管理においては図のようにサーバー側にあるまとまりをローカル側でも持っている(このまとまりをレポジトリという)。

サーバー・ローカルという関係だけでなく、ローカルだけでもファイル・ディレクトリの管理をすることもできる。昔の状態に戻ったりできるということ。

f:id:ijm:20170217183833p:plain

Gitにおけるバージョン管理の仕方　～概念編～

ファイル・ディレクトリが変更したときにその差分(変更点)だけ記録するのではなくその変更を踏まえたGit管理下のファイル・ディレクトリ全部を記録する。

→利点として全部記録しているため、ローカルだけで事をすますことができる(昔の状態に戻ったりなど)。ネットを介してサーバーにアクセスしなくてもこういうのができるのは利点だ。

Gitでのファイル・ディレクトリなどにはハッシュ値(例：24b9da6552252987aa493b52f8696cd6d3b00373)を与えられこれは参照・認証に使われる。

Gitではファイル・ディレクトリ（以下データと言う）に対して3つの状態を与える。ここからはローカルでの話である。

  1. コミット済 →データが完全にレポジトリに保存してある。あるデータに変更を加えた直後はレポジトリに保存されていない（コミット済みでない）。
  2. 修正済み →コミット済みではないが変更を加えたデータ。
  3. ステージ済み →修正済みのデータに関してコミットするための印がつけられたデータ。

つまり、流れとしては

「データの変更→修正済み→ステージ済みにする→ステージ済み→コミット済みにする→コミット済み」

となる。

Git Bashでの作業

概念を理解したところでこっからは作業に行きます。

個人情報登録

まずは個人情報を登録していきます。作業するにあたって、コミットを誰がしたのかとかわかった方がいいですよね。

$ git config --global user.name "ijm"
$ git config --global user.email hogehoge@ijm.com

このようにメールアドレスとユーザー名を登録します。

エディタ

Gitで使う時のデフォルトエディタとしてvimが入っています。 Git Bashでvimがデフォルトで入っているのも、コミットするときに:wqでコミットメッセージを終わらせる（後でやります）のもこのことです。

とりあえず最初の概要としてはこんな感じです。 そういえば、最初の記事なのに自己紹介が遅れていましたね。(笑)

現在東京大学にいる大学生です。プログラミングを趣味や課外活動でやっています。プログラミングの知識っていうのは、実践しないと覚えづらい・だけど先に事前知識をもっていないと何をすべきかもわからないことがある、というものだと思っています。事前知識を得ようとしても中々覚えられない状態を打破しようとブログとして残していくことにしました。つたない文章ですがどうかご付き合いください。