20210116のGitに関する記事は13件です。

投稿日：2021-01-16T23:14:55+09:00

[Android/Kotlin]Gitに保存しないデータを扱う

なんでそんなことするの？

github等でgitを共有する時に、データベース接続用パスワード等は公開したくない

説明

.gitignoreファイルに記載されているファイルはgitに保存されなくなる
AndroidStudioでプロジェクトを作成すると、自動的に.gitignoreとlocal.propertiesが作成され、
.gitignoreの中にlocal.propertiesも入っているのでそれをそのまま使用する

結論

github
この中にlocal.propertiesは入っていない

コード

.gitignore

local.propertiesが入っていることを確認
.gitignore
/local.properties
local.properties
build.gradle(:app)

ここのやり方はわからなかったらbuildConfigFieldでググってください
build.gradle(app)
android {
    defaultConfig {
        // local.propertiesファイルを指定
        def properties = new Properties()
        properties.load(project.rootProject.file('local.properties').newDataInputStream())

        // buildConfigFieldで値を保存
        def LOCAL_PROPERTIES_SAMPLE = properties.getProperty("LOCAL_PROPERTIES_SAMPLE")
        buildConfigField("String", "LOCAL_PROPERTIES_SAMPLE", "\"${LOCAL_PROPERTIES_SAMPLE}\"")
    }
}
local.properties

ここに隠したい値を入れる
文字列でもクォーテーションは要らない
半角スペースを使用できない
local.properties
LOCAL_PROPERTIES_SAMPLE=SAMPLE
値を受け取る

今回はtext_viewでlocal.propertiesで指定した値を表示してみる
activity_main.xml
<TextView
    android:id="@+id/text_view" />
BuildConfigやその中の値は最初存在せず、赤くなってるけど、初回ビルド時にBuildConfig.javaが生成・更新され、使えるようになる
MainActivity.kt
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // BuildConfig.javaは初回ビルド時に生成される
        text_view.text = BuildConfig.LOCAL_PROPERTIES_SAMPLE
    }
}

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-16T22:54:57+09:00

gitリポジトリのオブジェクトデータベースをさくっとリストしてみる

オブジェクトデータベースとは？

いいかげんgitのことをちゃんと知りたいというあなたへ（内部構造編）をご参照ください

.git/objectsの中身をさくっとみたい

.git/objectsにあるgitオブジェクトの
種類、サイズ、内容を表示します。
gitリポジトリに置いて実行してみてください

ls-git-obj.sh

#!/bin/sh

GITOBJ_DIR="./.git/objects"

for path in ${GITOBJ_DIR}/*; do
    dir=`basename ${path}`
    # ディレクトリ名が2文字のものの内容を表示
    if [ ${#dir} -eq 2 ]; then
      obj_name=`find ${GITOBJ_DIR}/${dir} -type f | xargs basename`
      echo '------------------------'
      echo ${dir}${obj_name}
      echo '- type:'
      git cat-file -t ${dir}${obj_name}
      echo '- size:'
      git cat-file -s ${dir}${obj_name}
      echo '- contents:'
      git cat-file -p ${dir}${obj_name}
    fi
done

実行結果はこちら

$ ./ls-git-obj.sh
------------------------
20c8a040010b6ca65a4c9d75873da6b86aff7447
- type:
commit
- size:
178
- contents:
tree a760aa994bbdd615f7ecb442be6bab636e11eba6
author: atchy <atchy@example.com> 1610805112 +0900
committer atchy <atchy@example.com> 1610805112 1610805112 +0900

add aaa.txt
------------------------
72943a16fb2c8f38f9dde202b7a70ccc19c52f34
- type:
blob
- size:
4
- contents:
aaa
------------------------
a760aa994bbdd615f7ecb442be6bab636e11eba6
- type:
tree
- size:
35
- contents:
100644 blob 72943a16fb2c8f38f9dde202b7a70ccc19c52f34    aaa.txt

もうちょっときれいに表示できんもんかなあ

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-16T22:34:57+09:00

指定したリポジトリに貢献してる人全員のメアドで勝手にコミットするワンライナー

メアドを変えるだけで偽装ができる

Gitの偽装はとても簡単なので、GPGでしっかりと署名をしましょう。

怖さを表す

Repo1に貢献してる人全員のメアドを取得して空コミットを行います。
git -C /path/to/Repo1 log | grep Author | sort | uniq | grep "@" | cut -d '<' -f 2 | sed "s|>$||g" | xargs -I%s bash -c "git config user.email %s; git commit --allow-empty -m 'Fake commit'"

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-16T21:58:29+09:00

Gitのユーザー名とメールアドレスを設定する方法

はじめに

現在会社ではGitLab、個人開発ではGitHubを使用しています。それぞれユーザー名やメールアドレスが異なるため、プロジェクト毎に設定する方法を記載します。

Gitのユーザー名とメールアドレスを設定する方法

全体(global)の設定を行う

コンピュータ内のGit全体のユーザー名/メールアドレスの設定です。
最も使用頻度の高いものをこちらで設定しておきます。

ユーザー名を設定
git config --global [user.name](http://user.name/) "ユーザー名"
メールアドレスを設定
git config --global user.email メールアドレス
プロジェクト毎に設定を行う

まずcdコマンドを使用して設定したいプロジェクトのディレクトリに移動しておきます。
その後、下記コマンドで設定します。

ユーザー名を設定
git config --local user.name "ユーザー名"
メールアドレスを設定
git config --local user.email メールアドレス
最後に

以上、Gitのユーザー名とメールアドレスを設定する方法でした。見ていただきありがとうございました。

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-16T19:28:00+09:00

いいかげんgitのことをちゃんと知りたいあなたへ（内部構造編）

いつまでたってもgitさんのことががよく分からなくつらい

恥ずかしながら自分、ほぼ毎日なんらかのかたちでgitに触れているのにもかかわらず、いまだによく分かってないです、gitさんのこと・・・
origin/master?あー、リモートリポジトリってやつ？Githubに置かれてるやつ?
インデックス?あー、ステージングとか、あの辺りのやつ?（Sourcetreeさんに頼ってばかりですんません）
ベアリポジトリ?あー、あの、くまーってやつね（なにが

gitさんとちゃんとお付き合いさせていただきたい

きみのとこがちゃんと知りたい！
なのでpro git(日本語版)を読んでみた。

磁器コマンドと配管コマンドとゆうのがある

日々なんとなく使ってるのによく分かってない自分からすると、Gitnの内側あたりをちゃんと理解するべきだと思いました。そのなかで出てくるコマンドの種類がふたつあります。

磁器（Porcelain）コマンド
$ git clone
$ git add
$ git commit
お馴染みですよね。たぶん、磁器のようにどっしりとしてるからそう呼ぶ、と理解。
配管コマンドの集まりが磁器コマンド、というイメージです。

配管（Plumbing）コマンド
$ git hash-object
$ git update-index
$ git write-tree
何やら見慣れぬコマンド・・・
ざっくり言うと、パイプ処理で繋げたりして使用する比較的低水準なコマンドのことを指すもよう。

たとえば、磁器コマンドを使用して
### 1.ファイル作って
$ echo 'aaa' > aaa.txt

### 2~3.インデックスに追加して
$ git add test.txt

### 4~6.コミットする
$ git commit -m 'add aaa.txt'
と同じことを、配管コマンドでしようとすると、以下となります。
コメントの番号は両コマンドが行う処理の内容に対応しています。
### 1.ファイル作って
$ echo 'aaa' > aaa.txt

### 2.blobとして登録して
$ git hash-object -w aaa.txt
72943a16fb2c8f38f9dde202b7a70ccc19c52f34

### 3.インデックスに追加して
$ git update-index --add --cacheinfo 100644 72943a16fb2c8f38f9dde202b7a70ccc19c52f34 aaa.txt 

### 4.treeを作って
$ git write-tree
a760aa994bbdd615f7ecb442be6bab636e11eba6

### 5.commitする
$ git commit-tree -m "add aaa.txt" a760aa994bbdd615f7ecb442be6bab636e11eba6
1e87843b08cdcd96216ab42ce56d6e0109c53427

### 6.でもってmasterブランチの参照を更新する
git update-ref refs/heads/master 1e87843b08cdcd96216ab42ce56d6e0109c53427
初見では「???」ですが、gitの内部構造を少し理解すれば「ははーん」となります。
順をおって説明してきますが、まずはgitの内部構造に軽く触れてみます。

gitオブジェクトとオブジェクトデータベース

gitは管理対象のファイルやディレクトリ、それにコミット情報なんかをgitオブジェクト化して扱います。化というのがポイントで、gitはファイルをそのまま登録するわけではありません（後ほど説明します）
また、それらgitオブジェクトを登録する場所をオブジェクトデータベースといいます。

gitオブジェクト

gitが扱うモノのことをgitオブジェクトといいます。
gitオブジェクトは以下の4つです。

blob（big large object）

ファイルです。
ソースコート、画像ファイル、バイナリファイルなど、あらゆるファイルをgitはblobとして扱います。

tree

ディレクトリです。
ただ、ディレクトリを指すのみでなく、コミットするときの単位でもあります。

commit

コミットです。
コミットするtree、作成者、コミット者、コミットメッセージを保持します

tag

タグです。
今回は触れません。

オブジェクトデータベース

オブジェクトデータベースとはgitオブジェクトのデータベースです（そのまま）
具体的にいうと、git initしたあとに作成される.gitディレクトリ内のobjectsディレクトリがオブジェクトデータベースです。

では先ほどつらつらとあげた、配管コマンドを使ってファイルをコミットする様子をを見ていきましょう。

配管コマンドを使ってコミットしてみる
$ mkdir /git-test && cd /git-test
### ローカルリポジトリを作成
$ git init
Initialized empty Git repository in /git-test/.git/
### .git/objects内のファイルを検索
$ find .git/objects -type f
適当な場所に実験用のローカルリポジトリを作成しておいてください。
リポジトリ作成直後なのでひとつもファイルが登録されていませんね。

ファイルをオブジェクトデータベースに登録する
### 1.ファイル作って
$ echo 'aaa' > aaa.txt

### 2.blobとして登録して
$ git hash-object -w aaa.txt
72943a16fb2c8f38f9dde202b7a70ccc19c52f34
git hash-object はgitオブジェクトのオブジェクトIDを返します。
オブジェクトIDとは、gitオブジェクトのSHA1ハッシュ値です。gitが扱うリビジョン番号とかと同じノリです。
オプションに-wを指定すると、対象ファイルをgitオブジェクト化したのち、オブジェクトデータベースに登録します。
このコマンドにより、gitはファイルをgitオブジェクト化します。
gitオブジェクトは、gitオブジェクトの種類（ファイルの場合はblob）とファイルサイズからなるヘッダと、ファイルの内容を連結したもので、そのSHA1ハッシュ値がgitオブジェクトIDです。また、実際にオブジェクトデータベースに登録されるときは圧縮されます。
.git/objectsの内容をリスト表示してみるにはこちらをお試しください。
また、このあたりの詳細についてはオブジェクトストレージが詳しいです。

それでは、現時点でオブジェクトデータベースの中身を覗いてみましょう。
$ find .git/objects -type f
.git/objects/72/943a16fb2c8f38f9dde202b7a70ccc19c52f34
ファイルがひとつ作られていますね。
gitはgitオブジェクトIDの先頭2文字をディレクトリ名として、残りの38文字をファイル名として、git/objects以下に配置します。
今の状態はファイルをオブジェクトデータベースに登録しただけです。

インデックスに登録する
### 3.インデックスに追加して
$ git update-index --add --cacheinfo 100644 72943a16fb2c8f38f9dde202b7a70ccc19c52f34 aaa.txt 
さっきgitオブジェクト化したときに返ったSHA1ハッシュ値をパラメータとして、リポジトリのインデックスに登録します。
新規にインデックスに登録するだけならgit update-index --add aaa.txtでもいいようです。
インデックスを確認してみましょう。
$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
    new file:   aaa.txt
ステージングされてますね。

コミットする
### 4.treeを作って
$ git write-tree
a760aa994bbdd615f7ecb442be6bab636e11eba6

### 5.commitする
$ git commit-tree -m "add aaa.txt" a760aa994bbdd615f7ecb442be6bab636e11eba6
1e87843b08cdcd96216ab42ce56d6e0109c53427

### 6.でもってmasterブランチの参照を更新する
git update-ref refs/heads/master 1e87843b08cdcd96216ab42ce56d6e0109c53427
まずはgit write-treeで、現在のインデックスをtree化します。
返るのはtreeのオブジェクトIDです。
オブジェクトデータベースの中身を覗いてみます。
$ find .git/objects -type f
.git/objects/72/943a16fb2c8f38f9dde202b7a70ccc19c52f34
.git/objects/a7/60aa994bbdd615f7ecb442be6bab636e11eba6
さっきの追加したファイルに加え、生成されたtreeが登録されていますね。
さて、それではいよいよ、git commit-treeコマンドで、このtreeをコミットします。
このコマンドにはコミットメッセージとtreeのオブジェクトIDをパラメータとして渡します。
返る値はコミットオブジェクトのオブジェクトIDです。
コミットオブジェクトはタイムスタンプを含むので、生成したタイミングによりオブジェクトIDが異なります。
最後に、git update-refコマンドにより、このコミットオブジェクトのオブジェクトIDをmasterブランチとして登録します。
今回は最初のコミットなので指定しませんでしたが、コミットオブジェクトには親であるオブジェクトを指定することができます。これにより、コミットの歴史が表現されるわけですね。
たとえば、このリポジトリにbbb.txtを追加してそのコミットオブジェクトを追加するときのことを考えてみます。
$ echo 'bbb' > bbb.txt
$ git hash-object -w bbb.txt
f761ec192d9f0dca3329044b96ebdb12839dbff6
$ git update-index --add --cacheinfo 100644 f761ec192d9f0dca3329044b96ebdb12839dbff6 bbb.txt
$ git write-tree
75d27669a0c4e9dd702c71c6ac3307d533493ba5
### 親となるコミットオブジェクトIDを指定してコミットする
$ git commit-tree -m "add bbb.txt" -p 1e87843b08cdcd96216ab42ce56d6e0109c53427 75d27669a0c4e9dd702c71c6ac3307d533493ba5
de5c2b4cf1ce3519102b9cc5a606c3089af02dcc
### 参照を更新
git update-ref refs/heads/master de5c2b4cf1ce3519102b9cc5a606c3089af02dcc  
git commit-treeコマンドの-pオプションで親コミットオブジェクトIDを指定します。
git logで今の状況を確認してみましょう。
commit de5c2b4cf1ce3519102b9cc5a606c3089af02dcc (HEAD -> master)
Author: atchy <atchy@example.com>
Date:   Sat Jan 16 19:07:21 2021 +0900

    add bbb.txt

commit 1e87843b08cdcd96216ab42ce56d6e0109c53427
Author: atchy <atchy@example.com>
Date:   Sat Jan 16 18:59:56 2021 +0900

    add aaa.txt
ちゃんと歴史が刻まれていますね！

もっとくわしく知りたいあなたへ

pro gitをじっくり読むのもいいですが、
こちらを利用すると、目からウロコがボトボト落ちます。ジョークソフトと表現されていますが、体感で理解できるという意味では冗談抜きかと思いますｗ

次回予告

今回はgitがどのようにファイルを扱い、コミットの歴史を積み上げていくか、にフォーカスしてみました。
次回はリモートリポジトリまわりについて、お伝えできればと考えています！

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-16T19:28:00+09:00

いいかげんgitのことをちゃんと知りたいというあなたへ（その1）

いつまでたってもgitさんのことががよく分からなくつらい

恥ずかしながら自分、ほぼ毎日なんらかのかたちでgitに触れているのにもかかわらず、いまだによく分かってないです、gitさんのこと・・・
origin/master?あー、リモートリポジトリってやつ？Githubに置かれてるやつ?
インデックス?あー、ステージングとか、あの辺りのやつ?（Sourcetreeさんに頼ってばかりですんません）
ベアリポジトリ?あー、あの、くまーってやつね（なにが

gitさんとちゃんとお付き合いさせていただきたい

きみのとこがちゃんと知りたい！
なのでpro git(日本語版)を読んでみた。

磁器コマンドと配管コマンド

日々なんとなく使ってるのによく分かってない自分からすると、Gitnの内側あたりをちゃんと理解するべきだと思いました。そのなかで出てくるコマンドの種類がふたつあります。

磁器（Porcelain）コマンド
$ git clone
$ git add
$ git commit
お馴染みですよね。たぶん、磁器のようにどっしりとしてるからそう呼ぶ、と理解。
配管コマンドの集まりが磁器コマンド、というイメージです。

配管（Plumbing）コマンド
$ git hash-object
$ git update-index
$ git write-tree
何やら見慣れぬコマンド・・・
ざっくり言うと、パイプ処理で繋げたりして使用する比較的低水準なコマンドのことを指すもよう。

たとえば、磁器コマンドを使用して
### 1.ファイル作って
$ echo 'aaa' > aaa.txt

### 2~3.インデックスに追加して
$ git add test.txt

### 4~6.コミットする
$ git commit -m 'add aaa.txt'
と同じことを、配管コマンドでしようとすると、以下となります。
コメントの番号は両コマンドが行う処理の内容に対応しています。
### 1.ファイル作って
$ echo 'aaa' > aaa.txt

### 2.blobとして登録して
$ git hash-object -w aaa.txt
72943a16fb2c8f38f9dde202b7a70ccc19c52f34

### 3.インデックスに追加して
$ git update-index --add --cacheinfo 100644 72943a16fb2c8f38f9dde202b7a70ccc19c52f34 aaa.txt 

### 4.treeを作って
$ git write-tree
a760aa994bbdd615f7ecb442be6bab636e11eba6

### 5.commitする
$ git commit-tree -m "add aaa.txt" a760aa994bbdd615f7ecb442be6bab636e11eba6
1e87843b08cdcd96216ab42ce56d6e0109c53427

### 6.でもってmasterブランチの参照を更新する
git update-ref refs/heads/master 1e87843b08cdcd96216ab42ce56d6e0109c53427
初見では「???」ですが、gitの内部構造を少し理解すれば「ははーん」となります。
順をおって説明してきますが、まずはgitの内部構造に軽く触れてみます。

gitオブジェクトとオブジェクトデータベース

gitは管理対象のファイルやディレクトリ、それにコミット情報なんかをgitオブジェクト化して扱います。化というのがポイントで、gitはファイルをそのまま登録するわけではありません後ほど説明します
また、それらgitオブジェクトを登録する場所をオブジェクトデータベースといいます。

gitオブジェクト

gitが扱うモノのことをgitオブジェクトといいます。
gitオブジェクトは以下の4つです。

blob（big large object）

ファイルです。
ソースコート、画像ファイル、バイナリファイルなど、あらゆるファイルをgitはblobとして扱います。

tree

ディレクトリです。
ただ、ディレクトリを指すのみでなく、コミットするときの単位でもあります。

commit

コミットです。
コミットするtree、作成者、コミット者、コミットメッセージを保持します

tag

タグです。
今回は触れません・・・

オブジェクトデータベース

オブジェクトデータベースとはgitオブジェクトのデータベースです（そのまま）
具体的にいうと、git initしたあとに作成される.gitディレクトリ内のobjectsディレクトリがオブジェクトデータベースです

では先ほどつらつらとあげた、配管コマンドを使ってファイルをコミットする様子をを見ていきましょう。

配管コマンドを使ってコミットする
$ mkdir /git-test && cd /git-test
### ローカルリポジトリを作成
$ git init
Initialized empty Git repository in /git-test/.git/
### .git/objects内のファイルを検索
$ find .git/objects -type f
適当な場所に実験用のローカルリポジトリを作成しておいてください
リポジトリ作成直後なのでひとつもファイルが登録されていませんね。

ファイルをオブジェクトデータベースに登録する
### 1.ファイル作って
$ echo 'aaa' > aaa.txt

### 2.blobとして登録して
$ git hash-object -w aaa.txt
72943a16fb2c8f38f9dde202b7a70ccc19c52f34
git hash-object はgitオブジェクトのオブジェクトIDを返します。
オブジェクトIDとは、gitオブジェクトのSHA1ハッシュ値です。gitが扱うリビジョン番号とかと同じノリです。
オプション-wは、対象のファイルをgitオブジェクト化したのち、「オブジェクトデータベース」に登録します。
このコマンドにより、gitはファイルをgitオブジェクト化します。
gitオブジェクトは、gitオブジェクトの種類（ファイルの場合はblob）とファイルサイズからなるヘッダと、ファイルの内容を連結したもので、そのSHA1ハッシュ値がgitオブジェクトIDです。また、実際にオブジェクトデータベースに登録されるときは圧縮されます。
このあたりについてはオブジェクトストレージが詳しいです。

それでは、現時点でオブジェクトデータベースの中身を覗いてみましょう。
$ find .git/objects -type f
.git/objects/72/943a16fb2c8f38f9dde202b7a70ccc19c52f34
ファイルがひとつ作られていますね。
gitはgitオブジェクトIDの先頭2文字をディレクトリ名として、残りの38文字をファイル名として、git/objects以下に配置します。
今の状態はファイルをオブジェクトデータベースに登録しただけです。

インデックスに登録する
### 3.インデックスに追加して
$ git update-index --add --cacheinfo 100644 72943a16fb2c8f38f9dde202b7a70ccc19c52f34 aaa.txt 
さっきgitオブジェクト化したときに返ったSHA1ハッシュ値をパラメータとして、リポジトリのインデックスに登録します。
新規にインデックスに登録するだけならgit update-index --add aaa.txtでもいいようです。
インデックスを確認してみましょう。
$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
    new file:   aaa.txt
ステージングされてますね。

コミットする
### 4.treeを作って
$ git write-tree
a760aa994bbdd615f7ecb442be6bab636e11eba6

### 5.commitする
$ git commit-tree -m "add aaa.txt" a760aa994bbdd615f7ecb442be6bab636e11eba6
1e87843b08cdcd96216ab42ce56d6e0109c53427

### 6.でもってmasterブランチの参照を更新する
git update-ref refs/heads/master 1e87843b08cdcd96216ab42ce56d6e0109c53427
まずはgit write-treeで、現在のインデックスをtree化します。
返るのはtreeのオブジェクトIDです。
オブジェクトデータベースの中身を覗いてみます。
$ find .git/objects -type f
.git/objects/72/943a16fb2c8f38f9dde202b7a70ccc19c52f34
.git/objects/a7/60aa994bbdd615f7ecb442be6bab636e11eba6
さっきの追加したファイルに加え、生成されたtreeが登録されていますね。
さて、それではいよいよ、git commit-treeコマンドで、このtreeをコミットします。
このコマンドにはコミットメッセージとtreeのオブジェクトIDをパラメータとして渡します。
返る値はコミットオブジェクトのオブジェクトIDです。
コミットオブジェクトはタイムスタンプを含むので、生成したタイミングによりオブジェクトIDが異なります。
最後に、git update-refコマンドにより、このコミットオブジェクトのオブジェクトIDをmasterブランチとして登録します。
今回は最初のコミットなので指定しませんでしたが、コミットオブジェクトには親であるオブジェクトを指定することができます。これにより、コミットの歴史が表現されるわけですね。
たとえば、このリポジトリにbbb.txtを追加してそのコミットオブジェクトを追加するときのことを考えてみます。
$ echo 'bbb' > bbb.txt
$ git hash-object -w bbb.txt
f761ec192d9f0dca3329044b96ebdb12839dbff6
$ git update-index --add --cacheinfo 100644 f761ec192d9f0dca3329044b96ebdb12839dbff6 bbb.txt
$ git write-tree
75d27669a0c4e9dd702c71c6ac3307d533493ba5
### 親となるコミットオブジェクトIDを指定してコミットする
$ git commit-tree -m "add bbb.txt" -p 1e87843b08cdcd96216ab42ce56d6e0109c53427 75d27669a0c4e9dd702c71c6ac3307d533493ba5
de5c2b4cf1ce3519102b9cc5a606c3089af02dcc
### 参照を更新
git update-ref refs/heads/master de5c2b4cf1ce3519102b9cc5a606c3089af02dcc  
git commit-treeコマンドの-pオプションで親コミットオブジェクトIDを指定します。
git logで今の状況を確認してみましょう。
commit de5c2b4cf1ce3519102b9cc5a606c3089af02dcc (HEAD -> master)
Author: atchy <atchy@exmple.com>
Date:   Sat Jan 16 19:07:21 2021 +0900

    add bbb.txt

commit 1e87843b08cdcd96216ab42ce56d6e0109c53427
Author: atchy <atchy@exmple.com>
Date:   Sat Jan 16 18:59:56 2021 +0900

    add aaa.txt
ちゃんと歴史が刻まれていますね！

もっとくわしく知りたいあなたへ

pro gitをじっくり読むのもいいですが、
こちらを利用すると、目からウロコがボトボト落ちます。ジョークソフトと表現されていますが、体感で理解できるという意味では冗談抜きかと思いますｗ

次回予告

今回はgitがどのようにファイルを扱い、コミットの歴史を積み上げていくか、にフォーカスしてみました。
次回はリモートリポジトリまわりについて、お伝えできればと考えています！

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-16T19:28:00+09:00

いいかげんgitのことをちゃんと知りたいというあなたへ（内部構造編）

いつまでたってもgitさんのことががよく分からなくつらい

恥ずかしながら自分、ほぼ毎日なんらかのかたちでgitに触れているのにもかかわらず、いまだによく分かってないです、gitさんのこと・・・
origin/master?あー、リモートリポジトリってやつ？Githubに置かれてるやつ?
インデックス?あー、ステージングとか、あの辺りのやつ?（Sourcetreeさんに頼ってばかりですんません）
ベアリポジトリ?あー、あの、くまーってやつね（なにが

gitさんとちゃんとお付き合いさせていただきたい

きみのとこがちゃんと知りたい！
なのでpro git(日本語版)を読んでみた。

磁器コマンドと配管コマンドとゆうのがある

日々なんとなく使ってるのによく分かってない自分からすると、Gitnの内側あたりをちゃんと理解するべきだと思いました。そのなかで出てくるコマンドの種類がふたつあります。

磁器（Porcelain）コマンド
$ git clone
$ git add
$ git commit
お馴染みですよね。たぶん、磁器のようにどっしりとしてるからそう呼ぶ、と理解。
配管コマンドの集まりが磁器コマンド、というイメージです。

配管（Plumbing）コマンド
$ git hash-object
$ git update-index
$ git write-tree
何やら見慣れぬコマンド・・・
ざっくり言うと、パイプ処理で繋げたりして使用する比較的低水準なコマンドのことを指すもよう。

たとえば、磁器コマンドを使用して
### 1.ファイル作って
$ echo 'aaa' > aaa.txt

### 2~3.インデックスに追加して
$ git add test.txt

### 4~6.コミットする
$ git commit -m 'add aaa.txt'
と同じことを、配管コマンドでしようとすると、以下となります。
コメントの番号は両コマンドが行う処理の内容に対応しています。
### 1.ファイル作って
$ echo 'aaa' > aaa.txt

### 2.blobとして登録して
$ git hash-object -w aaa.txt
72943a16fb2c8f38f9dde202b7a70ccc19c52f34

### 3.インデックスに追加して
$ git update-index --add --cacheinfo 100644 72943a16fb2c8f38f9dde202b7a70ccc19c52f34 aaa.txt 

### 4.treeを作って
$ git write-tree
a760aa994bbdd615f7ecb442be6bab636e11eba6

### 5.commitする
$ git commit-tree -m "add aaa.txt" a760aa994bbdd615f7ecb442be6bab636e11eba6
1e87843b08cdcd96216ab42ce56d6e0109c53427

### 6.でもってmasterブランチの参照を更新する
git update-ref refs/heads/master 1e87843b08cdcd96216ab42ce56d6e0109c53427
初見では「???」ですが、gitの内部構造を少し理解すれば「ははーん」となります。
順をおって説明してきますが、まずはgitの内部構造に軽く触れてみます。

gitオブジェクトとオブジェクトデータベース

gitは管理対象のファイルやディレクトリ、それにコミット情報なんかをgitオブジェクト化して扱います。化というのがポイントで、gitはファイルをそのまま登録するわけではありません（後ほど説明します）
また、それらgitオブジェクトを登録する場所をオブジェクトデータベースといいます。

gitオブジェクト

gitが扱うモノのことをgitオブジェクトといいます。
gitオブジェクトは以下の4つです。

blob（big large object）

ファイルです。
ソースコート、画像ファイル、バイナリファイルなど、あらゆるファイルをgitはblobとして扱います。

tree

ディレクトリです。
ただ、ディレクトリを指すのみでなく、コミットするときの単位でもあります。

commit

コミットです。
コミットするtree、作成者、コミット者、コミットメッセージを保持します

tag

タグです。
今回は触れません。

オブジェクトデータベース

オブジェクトデータベースとはgitオブジェクトのデータベースです（そのまま）
具体的にいうと、git initしたあとに作成される.gitディレクトリ内のobjectsディレクトリがオブジェクトデータベースです。

では先ほどつらつらとあげた、配管コマンドを使ってファイルをコミットする様子をを見ていきましょう。

配管コマンドを使ってコミットしてみる
$ mkdir /git-test && cd /git-test
### ローカルリポジトリを作成
$ git init
Initialized empty Git repository in /git-test/.git/
### .git/objects内のファイルを検索
$ find .git/objects -type f
適当な場所に実験用のローカルリポジトリを作成しておいてください。
リポジトリ作成直後なのでひとつもファイルが登録されていませんね。

ファイルをオブジェクトデータベースに登録する
### 1.ファイル作って
$ echo 'aaa' > aaa.txt

### 2.blobとして登録して
$ git hash-object -w aaa.txt
72943a16fb2c8f38f9dde202b7a70ccc19c52f34
git hash-object はgitオブジェクトのオブジェクトIDを返します。
オブジェクトIDとは、gitオブジェクトのSHA1ハッシュ値です。gitが扱うリビジョン番号とかと同じノリです。
オプションに-wを指定すると、対象ファイルをgitオブジェクト化したのち、オブジェクトデータベースに登録します。
このコマンドにより、gitはファイルをgitオブジェクト化します。
gitオブジェクトは、gitオブジェクトの種類（ファイルの場合はblob）とファイルサイズからなるヘッダと、ファイルの内容を連結したもので、そのSHA1ハッシュ値がgitオブジェクトIDです。また、実際にオブジェクトデータベースに登録されるときは圧縮されます。
このあたりについてはオブジェクトストレージが詳しいです。

それでは、現時点でオブジェクトデータベースの中身を覗いてみましょう。
$ find .git/objects -type f
.git/objects/72/943a16fb2c8f38f9dde202b7a70ccc19c52f34
ファイルがひとつ作られていますね。
gitはgitオブジェクトIDの先頭2文字をディレクトリ名として、残りの38文字をファイル名として、git/objects以下に配置します。
今の状態はファイルをオブジェクトデータベースに登録しただけです。

インデックスに登録する
### 3.インデックスに追加して
$ git update-index --add --cacheinfo 100644 72943a16fb2c8f38f9dde202b7a70ccc19c52f34 aaa.txt 
さっきgitオブジェクト化したときに返ったSHA1ハッシュ値をパラメータとして、リポジトリのインデックスに登録します。
新規にインデックスに登録するだけならgit update-index --add aaa.txtでもいいようです。
インデックスを確認してみましょう。
$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
    new file:   aaa.txt
ステージングされてますね。

コミットする
### 4.treeを作って
$ git write-tree
a760aa994bbdd615f7ecb442be6bab636e11eba6

### 5.commitする
$ git commit-tree -m "add aaa.txt" a760aa994bbdd615f7ecb442be6bab636e11eba6
1e87843b08cdcd96216ab42ce56d6e0109c53427

### 6.でもってmasterブランチの参照を更新する
git update-ref refs/heads/master 1e87843b08cdcd96216ab42ce56d6e0109c53427
まずはgit write-treeで、現在のインデックスをtree化します。
返るのはtreeのオブジェクトIDです。
オブジェクトデータベースの中身を覗いてみます。
$ find .git/objects -type f
.git/objects/72/943a16fb2c8f38f9dde202b7a70ccc19c52f34
.git/objects/a7/60aa994bbdd615f7ecb442be6bab636e11eba6
さっきの追加したファイルに加え、生成されたtreeが登録されていますね。
さて、それではいよいよ、git commit-treeコマンドで、このtreeをコミットします。
このコマンドにはコミットメッセージとtreeのオブジェクトIDをパラメータとして渡します。
返る値はコミットオブジェクトのオブジェクトIDです。
コミットオブジェクトはタイムスタンプを含むので、生成したタイミングによりオブジェクトIDが異なります。
最後に、git update-refコマンドにより、このコミットオブジェクトのオブジェクトIDをmasterブランチとして登録します。
今回は最初のコミットなので指定しませんでしたが、コミットオブジェクトには親であるオブジェクトを指定することができます。これにより、コミットの歴史が表現されるわけですね。
たとえば、このリポジトリにbbb.txtを追加してそのコミットオブジェクトを追加するときのことを考えてみます。
$ echo 'bbb' > bbb.txt
$ git hash-object -w bbb.txt
f761ec192d9f0dca3329044b96ebdb12839dbff6
$ git update-index --add --cacheinfo 100644 f761ec192d9f0dca3329044b96ebdb12839dbff6 bbb.txt
$ git write-tree
75d27669a0c4e9dd702c71c6ac3307d533493ba5
### 親となるコミットオブジェクトIDを指定してコミットする
$ git commit-tree -m "add bbb.txt" -p 1e87843b08cdcd96216ab42ce56d6e0109c53427 75d27669a0c4e9dd702c71c6ac3307d533493ba5
de5c2b4cf1ce3519102b9cc5a606c3089af02dcc
### 参照を更新
git update-ref refs/heads/master de5c2b4cf1ce3519102b9cc5a606c3089af02dcc  
git commit-treeコマンドの-pオプションで親コミットオブジェクトIDを指定します。
git logで今の状況を確認してみましょう。
commit de5c2b4cf1ce3519102b9cc5a606c3089af02dcc (HEAD -> master)
Author: atchy <atchy@exmple.com>
Date:   Sat Jan 16 19:07:21 2021 +0900

    add bbb.txt

commit 1e87843b08cdcd96216ab42ce56d6e0109c53427
Author: atchy <atchy@exmple.com>
Date:   Sat Jan 16 18:59:56 2021 +0900

    add aaa.txt
ちゃんと歴史が刻まれていますね！

もっとくわしく知りたいあなたへ

pro gitをじっくり読むのもいいですが、
こちらを利用すると、目からウロコがボトボト落ちます。ジョークソフトと表現されていますが、体感で理解できるという意味では冗談抜きかと思いますｗ

次回予告

今回はgitがどのようにファイルを扱い、コミットの歴史を積み上げていくか、にフォーカスしてみました。
次回はリモートリポジトリまわりについて、お伝えできればと考えています！

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-16T18:49:00+09:00

gitのブランチ削除コマンド

ブランチの削除

ローカルブランチの削除
$ git branch -d ブランチ名
リモートブランチの削除
$ git push --delete origin ブランチ名
最後に

スクールでチーム開発をしたことはあったのですが、時間が経つと忘れることも多くまとめてみました。
ブランチを切ったり、プルすることもなくなってしまったので今後のためにも、一人擬似チーム開発をしながら学習していこうと思います。

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-16T18:34:54+09:00

【GitHubまとめ第3回】プルリクエスト

はじめに

必須スキルとなっているgit・gitHubの基礎についてまとめました。今回は「プルリクエスト」について記述しています。初学者向けの内容です。コマンドはコピペしやすいように、$をあえてつけていません。

全3回に渡って、下記の計画で進めています。
【計画】
第1回目 git基礎コマンド (https://qiita.com/tatsuya_1995/items/b0747759630b6c230684)
第2回目ブランチ・マージ・リベース・コンフリクト（https://qiita.com/tatsuya_1995/items/04148896a7f23a1f2090）
第3回目プルリクエスト（今回）

プルリクエスト

自分の変更したコードをリポジトリに取り込んでもらえるよう依頼する機能。
A.バグを未然に防止する。
B.ソースコードの変更点を明らかにする。
C.ソースコードに関するコミュニケーションをとる。
などを目的にしており、結果として開発者が品質の高いコードを書くことに繋がる。

参考：https://backlog.com/ja/git-tutorial/pull-request/01/

プルリクエストの手順

masterブランチを最新に更新

ブランチを作成

ファイルを変更

変更をコミット

GitHubへプッシュ

プルリクエストを送る

コードレビュー

プルリクエストをマージ

2.で作成したブランチを削除

1. masterブランチを最新に更新
git pull origin master
origin:リモートリポジトリのアクセス先に対してGitがデフォルトでつける名前。

2. ブランチを作成
git branch -b <ブランチ名>
-bオプションがついているため、新規ブランチ作成後、そのブランチに移動する。

3. ファイルを変更

お任せ!!

4. 変更をコミット

ステージへ追加
git add <ファイル名>  
ローカルリポジトリへコミット
git commit 
5. GitHubへプッシュ
git push origin <ブランチ名>
6. プルリクエストを送る

I.GitHub→リポジトリ名→Pull requests(下図番号①)→New pull request(下図番号②)を選択。
II.Create pull requestボタンを押す。
III.タイトルとコメントを記述。

統合するブランチ(下図赤枠)と統合元のブランチ(下図青枠)の名前を選択し、New Pull Requestを押す。

7. コードレビュー

Reviewersボタンからレビューしてもらう人を選択。通知が行くのでレビューしてもらう。レビューの動作については割愛。~~（その立場になるのは少し先なので…）~~

8. プルリクエストをマージ

Merge Pull request→Confirm mergeでマージする。コンフリクトが発生した場合は、先に修正。

9. 2.で作成したブランチを削除

マージされた後に、Delete branchボタンが表示される。これを押すとGitHub上で、ブランチが削除される。

最後にターミナルのコマンドでローカルで切ったブランチを削除しておく。
git branch -d <ブランチ名>
最後に

今回はgitのプルリクエストについてまとめました。gitは想像以上に覚えておくべきことが沢山ありますね。少しなめていました…。精進します。
（もしこの記事に誤りがありましたらご教授いただけると幸いです。）

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-16T13:32:00+09:00

【GitHubまとめ第2回】ブランチ・マージ・リベース・コンフリクト

必須スキルとなっているgit・gitHubの基礎についてまとめました。今回は「ブランチ」・「マージ」・「リベース」・「コンフリクト」を記述しています。初学者向けの内容です。コマンドはコピペしやすいように、$をあえてつけていません。

全3回に渡って、下記の計画で進めています。
【計画】
第1回目 git基礎コマンド (https://qiita.com/tatsuya_1995/items/b0747759630b6c230684)
第2回目ブランチ・マージ・リベース・コンフリクト（今回）
第3回目プルリクエスト (https://qiita.com/tatsuya_1995/items/6d48b7ba8487fe38bbf8)

※沢山出回っている記事ですので、あくまでも自分用メモです。

ブランチ

分岐することで、並行して複数機能を開発するときに使う仕組み。
コミットを指し示したポインタのこと。

ブランチを新規追加
git branch <ブランチ名>
ブランチの一覧を表示する
git branch
git branch -a //全てのブランチを表示する
-aをオプションでつけると追跡ブランチも表示される。

ブランチを切り替える

HEADが指し示すブランチ名を切り替える。
git checkout <既存ブランチ名>
git checkout -b <新規ブランチ名>  //ブランチを新規作成して切り替える
HEAD:
今作業しているブランチを指し示したポインタのこと。

ブランチ名を変更

今自分が作業しているブランチの名前を変更することができる。
git branch -m <ブランチ名>
ブランチを削除

注意：現在自分がいるブランチ（カレント）は削除できないため、git checkout <他のブランチ名>で移動してから削除。

該当ブランチの変更分がmasterブランチへmergeされていないときは削除されない。
git branch -d <ブランチ名>
該当ブランチの変更分がmasterにmergeされていなくても強制削除する。
git branch -D <ブランチ名>
ブランチの命名規則

Gitにはブランチモデルという運用方法のガイドラインがあり、名前の付け方、いつ作成し、いつマージするか等に標準指針がある。有名なブランチモデルのうちのgit-flowでは下記のようになる。

中央リポジトリ(GitHubなど)

master　

現在の製品のメインブランチ。originに常に存在。git-flowではmasterブランチに直接コミットすることはなく、マージを行うだけのブランチになる。

develop　

次回リリースの開発用。originに常に存在。リリース時にmasterへマージする。

開発者リポジトリ

feature　

新機能開発中に使う開発者用のブランチ。Issueの作業をするときに、developから分岐して、Issueの作業が完了したらdevelopへマージしたら削除する。例：feature/123 (123はIssue番号)

release

次回リリースが近くなったら、developから分岐して、developとmasterへマージする。リリース担当者用のブランチ、リリースしたら削除する。例：release/1.2

hotfix

現在の製品バージョンのバグフィックス用。masterから分岐して、masterとdevelopへマージする。マージしたら削除する。例：hotfix/123 (123はIssue番号)

git-flowの詳細：
https://tracpath.com/bootcamp/learning_git_git_flow.html
https://www.atmarkit.co.jp/ait/articles/1311/18/news017.html

ブランチの種類

①ローカルブランチ
②追跡ブランチ(リモートトラッキングブランチ)
③リモートブランチ

①ローカルブランチ

ローカルリポジトリにあるブランチのこと。git branchコマンドをオプションなしで実行した時に表示されるもので、一番初めは「master」という名前のローカルブランチしか存在しない。git checkout <リポジトリ名>を実行すると<リポジトリ名>のローカルリポジトリを作成し、移動することができる。

②追跡ブランチ（リモートトラッキングブランチ）

git banch -aというコマンドを打った時に「remotes/origin/master」というブランチ名が表示される。これが追跡ブランチの名前であり、リモートブランチではない。
追跡ブランチはローカルリポジトリにあるブランチ。
追跡ブランチはリモートリポジトリのリモートブランチを追跡している。
また。図では追跡ブランチ「origin/master」をローカルリポジトリの「master」が追跡している。「origin/master」ブランチはローカルの「master」ブランチの上流ブランチという。

③リモートブランチ

リモートリポジトリにあるブランチ。このブランチだけは自分のローカルPCにはない。

ブランチの統合

①マージ(merge)
②リベース(rebase)
の大分類があり、どちらを使うかで統合後のブランチの履歴が異なる。

①マージ(merge)する
git merge <ブランチ名>
fast-forward(早送り)マージ

下図のようにmasterブランチからfeatureブランチが分岐していた場合。featureブランチを修正後、masterブランチにマージする時、masterブランチの状態が以前から変更されていなければ、簡単にマージを行うことができる。これをfast-forward(早送り)マージと呼ぶ。

featureブランチの履歴はmasterブランチの履歴を全て含んでいるため、masterブランチは単純に移動するだけで、featureブランチの内容を取り込むことができる。

Non-fast-forward(早送りでない)マージ

masterブランチの履歴がfeatureブランチを分岐させた時より、進んでいた場合。この場合はmasterブランチの変更内容とfeatureブランチの変更内容を一つに統合する必要がある。そのため、両方の変更を取り込んだマージコミットが作成される。masterブランチの先頭はそのコミットに移動する。

マージの実行時に、fast-forwardとNon-fast-forwardをオプションで指示することもできる。
fast-forwardでマージすると履歴が残らないため、基本的にはNon-fastforwardでマージする方が望ましい。らしいです。

fast-forwardでマージ
git merge --no-ff <マージするブランチ>
Non-fast-forwardでマージ
git merge ーーff <マージするブランチ>
参考：マージの挙動
https://backlog.com/ja/git-tutorial/stepup/04/
https://qiita.com/tkek321/items/8134467a7ae606199554

②リベース(rebase)する

別々のブランチで開発していたコミットを繋げ直す
git rebase <つなぐ元にするブランチ名>
作業が完了したブランチを分岐元のブランチに統合する。更新履歴が一直線になり、履歴を追う時に見やすい。

複数のコミットを１コミットにまとめる

注意：リモートに一度pushしたものをまとめると、他の作業者が迷子になる可能性があるため、このコマンドを実行するのはローカルのみが望ましい。
git rebase -i <ひとまとめにするする地点の一つ前のコミットID>
コミットIDはgit logコマンドで確認可能。
参考：https://qiita.com/tatsuya_1995/items/b0747759630b6c230684#%E5%A4%89%E6%9B%B4%E3%81%AE%E5%B1%A5%E6%AD%B4%E3%82%92%E7%A2%BA%E8%AA%8D

コンフリクトとは

複数人で同じファイルの
同じ箇所を別々に変更して統合した際に、どれを優先すべきか判断できなくなること。

↓git mergeしようとしたらコンフリクトが発生して、マージできなかった例

git statusで確認したときboth modifiedと表示される。両方が変更されたの意味。→コンフリクトした。

コンフリクト解消方法

①コンフリクトするとテキストエディタにこのような表示がされるため、必要な箇所だけ残して、不要な箇所は削除する。

②テキストエディタで編集しただけではstatusに変化はない。ここからステージに追加、コミットする。

最後に

今回はgitのブランチ・マージ・リベース・コンフリクトについてまとめました。次回はプルリクエスト等についてまとめます。
（もしこの記事に誤りがありましたらご教授いただけると幸いです。）

(追記：2021/1/17)大変分かりやすい説明資料を見つけたので貼っておきます。
https://www.slideshare.net/kotas/git-15276118

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-16T13:04:08+09:00

Gitを理解したい！！！（初心者の叫び）

Git操作の理解の仕方

自分自身、Git(SourceTree)を使い始めて理解しかけなので、初心者ホヤホヤだからこそ、これからGitを学ぼうとしている人にとって心に寄り添った記事が書けるかなと思いました。

理解するために必要な事

1.なんかで作業している

やっぱり、ここがないときついですね。

自分は、過去にGitもGitHubもSourceTreeも使ってないのにGit入門みたいなyoutubeの動画を見て、それだけで満足！みたいなことがありました。

はっきり言って、それで理解できる人は宇宙人だなと思います。
同じ失敗をしないように是非とも何かで作業している状態が手元にあるといいです。

2基本構造を理解してから…

サルでも分かるなどありますが、
https://backlog.com/ja/git-tutorial/reference/branch/#section1

やっぱり、初心者の心持としてはそれでも分からないものは、分からないのですよ。
初心者は、何が知りたいのかというと全体像が分かるといいのですよね。
常に、構造がやんわりと意識出来ていて、そのうえで細かい作業を使いながら覚えていく。

初心者が知りたい全体像はこれ。（ざっくりですよ！！）

作業場で作ったのを、自分用の奴（笑）に保存して、みんなの奴に保存して共有できるようになる。
みんなのコードを、みんな見ることができれば、みんなハッピー！って感じ（？）

これを把握してないで、コミットとか、プッシュとか……、

もう白旗上げるしかない。

ちなみに、自分のパソコンをステージと呼びます。
ググると、当たり前のようにステージとか呼ばれているので、ここで心構えしておこう。

3 基本操作をかじる（必要最小限）

さっきの基本構造を把握したうえで、基本的な操作を図式に加えるとこんな感じ。

プッシュとか、コミットとかって何をしているのかというと、「反映」です。

自分のパソコンの作業状況を、自分の奴（保存先）に「反映」させるのが、コミット。
自分の奴（保存したもの）をみんなの奴（保存先）に「反映」させるのが、プッシュ。

4 後は、ググりながら、使いながら覚える。

ここは、色んなサイトや動画で言われている通りですね。激しく同意。

終わりに

本当にふざけた、記事だったかと思いましたが、ご覧いただきありがとうございました。

今回は、ブランチには全く触れませんでした。

というのも、Gitとは？でググると、基本的に我々初心者でも、バージョンを管理するツールであることは容易に理解・納得できるからです。

「なるほど。確かに、コードを編集してどんどん上書きした時に、上書き前を見れなかったり、どこを書き換えたのか見れないのは、なんとなく不便であるなぁ」

と、言った具合です。

自分自身まだまだ、理解が浅いのでつよつよの方々！
お叱りの程よろしくお願いいたします。

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-16T00:59:14+09:00

未経験からエンジニア転職後、1年半の間に実務で使ったGitコマンド

はじめに

他業種、他業界へのエンジニア転職をした後、1年半が経ちました。
その間に使用したGitコマンドをご紹介します。
Gitは転職前に自分でプログラミングの学習に使っていましたが、一人でmasterブランチを使うだけだったので、ほぼ使ったことがない状態でした。
それから実務で使うようになり、以下ののコマンドの組み合わせで特に困らずにやっていけています。
今後、エンジニアを目指される方は覚えておいていただくと役に立つのではないかと思います。
開発の順に沿って説明しているので、こんな順で使っていくんだなということも理解できるようにと心がけています。

Git初心者へメッセージ

プッシュさえしなければ、周りに迷惑が拡大することはありません。
手元の環境でコンフリクトしようが、プログラムが消えようが大丈夫です。何とかなります。
もし、自分が作った部分がなくなっても、もう一度作ればいいんですから。
それよりも、プッシュする前に一息ついて、本当にプッシュしても大丈夫か確認するようにしましょう。
プッシュしてしまうとどこまで影響するかわかりません。
Gitには様々なオプションがあります。その中でも「-f」は最強のオプションです。
慣れないうちは使うのをやめましょう。初心者にとってはバルスみたいなもんです。
必ず周りの人に相談してください。
相談すれば、そんなオプションを使わなくても回避できることが多いはずです。
初めはとても怖いです。いろいろ使っていくうちに意外と慣れていくものです。

各コマンドの重要度

個人的な感覚で重要度を星の数で表していますので、優先順位の参考にしてください。

★★★・・・必ず覚えよう
★★☆・・・覚えておくと便利
★☆☆・・・必要になったときに覚えよう

コマンド紹介

プロジェクト開始！

まずはリポジトリの操作から

リモートリポジトリからリポジトリを複製する　★★★
$ git clone {リモートリポジトリ} {ローカル開発環境ディレクトリ}
例）
$ git clone https://github.com/username/projectname.git test/projectname
この例だと、カレントディレクトリに対して、test/projectnameのディレクトリ内にリポジトリを複製するということ。自分のパソコン内のリポジトリをローカルリポジトリといいます。
ディレクトリ部分の記述をしなければ、カレントディレクトリに複製する。

現在のリモートリポジトリを確認する　★☆☆
$ git remote -v
通常は、クローンしたリポジトリを「origin」と省略して呼んでいます。

別のリポジトリを追加する　★☆☆

別のリポジトリも一緒に操作したい時が出てきますので、別のリモートリポジトリを接続することができます。
$ git remote add {追加したいリモートリポジトリ} {リポジトリの略称}
例）
$ git remote add https://github.com/username/projectname2.git project2 
これで、originとproject2というリポジトリを追加することができました。
git remote -vで確認してみてください。

ブランチ操作

現在のブランチを確認する　★★★
$ git branch
リモートリポジトリのブランチ情報を見るために以下のオプションをよく使います。　★★☆
$ git branch -a　または　$ git branch -avv
ブランチを新規作成　★★★
$ git branch 作りたいブランチ名
ブランチを移動　★★★
$ git checkout ブランチ名
これでブランチを作って移動することができました。
ただ、コマンドが2つになり面倒なので、以下のコマンドをよく使います。

ブランチを作りながらブランチを移動　★★★
$ git checkout -b ブランチ名
これで、ブランチを作ってそのブランチに移動。
簡単にまとめると以下のような感じ。

ブランチ名を変える　★★☆

タイプミスや実は作業内容とブランチ名が全然違って気持ち悪いというときによく使います。
$ git branch -m 新しいブランチ名
ブランチを削除　★★☆
$ git branch -d ブランチ名
ただし、対象のブランチがどのブランチにも取り込まれていないときは、実行しても拒否される。
どうしても消したいときは、以下。　★☆☆
$ git branch -D ブランチ名
dを大文字にしただけですね。

リモートリポジトリのブランチを削除　★☆☆
$ git push origin :ブランチ名
プログラムの変更が完了したら

変更したファイルを確認する　★★★
$ git status
変更があったファイルは赤い文字でカレントディレクトリからのファイルパスが示されます。

どのような変更を行ったか確認する　★★★
$ git diff
ファイルを指定することができます。
$ git diff ファイル名１　ファイル名２　ファイル名３
ステージに乗せた（後述）ファイルを確認するにはオプションが必要です。同じようにファイル名を指定できます。
$ git diff --staged
変更プログラムをステージに乗せる　★★★

プログラムをgit上で保存するにはまず、どのファイルを保存するかを指定します。
変更ファイルをすべてステージに乗せる。
$ git add .
ステージに乗せられたファイルはgit statusとすると、緑色の文字で示されます。
ファイルを指定してステージに乗せる。以下のように複数のファイルを同時に指定することができます。
$ git add ファイル名１　ファイル名２　ファイル名３
ステージに乗せたファイルをステージに乗せていない状態にする。間違えて指定してしまったときに使います。
$ git reset ファイル名１　ファイル名２
変更をキャンセルしたい　★★★
$ git checkout ファイル名
これで、ファイルの変更が即座にキャンセルされます。

変更を記録する

変更を記録する　★★★
$ git commit -m '変更内容がわかるコメント'
git statusで緑色に示されたファイルをまとめて変更が記録されます。

コメントを間違えたので修正したい　★☆☆
$ git commit --amend -m '新しいコメント'
変更を直前のコミットに含めたい　★☆☆

変更後、ステージにファイルがある状態でコメントを変更するコマンドでOK。
$ git commit --amend -m 'コメント'
コミットされたか確認する。　★★★
$ git log
これで、ログがざざっとでてきます。
上にいくほど新しく、新しいものから表示され、下にスクロールしていくと古い情報をさかのぼることができます。
よく使うオプションは、以下です。変更したファイル名も一緒に出てきます。
$ git log --name-status
ツリー状に表示したり、変更内容を確認したり、対象を絞ったりといろいろなことができます。
ログの詳細な確認はSourceTreeを使っています。
https://www.sourcetreeapp.com

リモートリポジトリに反映させる

ここからが長いんです。。。
でもここは、複数の人が関わるからこそ重要なコマンドです。ぜひ、覚えましょう。

基本的な手順

１．変更したプログラムを取り込みたいブランチに移動
２．移動先のブランチを最新の状態にする。（リモートリポジトリにプログラムが反映されている場合、取り込む）
３．変更したプログラムを取り込む。
４．変更が重複したら修正する。
５．プログラムをリモートリポジトリに反映させる。

では、行きましょう。

何はともあれ、ブランチ移動ですね。繰り返しになりますが。。
$ git branch 移動先のブランチ名
プログラムを最新の状態にする　★★★
$ git pull
$ git fetch origin 
$ git merge origin/ブランチA
後者はトラッキングブランチを最新の状態にしてからマージします。　　　　　え？？
origin/ブランチAはトラッキングブランチと言い、リモートリポジトリにアクセスしてリモートリポジトリのブランチAの内容をローカルリポジトリに取得したもので、これは開発中のブランチとは別です。
git fetch originで、リモートリポジトリの情報を引っ張ってきます。
そのあと、git merge origin/ブランチAで今のブランチに最新のブランチAの情報を取り込みます。
originとブランチAの間にある「/」はスペースではありません。
参考記事

作成したプログラムを取り込む　★★★
$ git merge 作業したブランチ
現在のブランチがmainという名前のブランチとします。

では、いよいよほかのメンバーが参照できる状態にしていきます。
以下のコマンドを実行する前に一息おきましょう。

リモートリポジトリに反映する　★★★
$ git push origin main
プッシュしてしまったら変更などがとてもしにくくなります。
他の人が取り込んでしまっている可能性があるからです。

作業ブランチをリモートリポジトリに反映させる　★★☆
$ git push origin feature
リモートリポジトリに同名のブランチがなければ作ってくれます。
あれば、同名のブランチに反映します。

ややイレギュラーな操作

以下でコミットハッシュを使ったコマンドが出てきます。
コミットハッシュとはgit logで表示されるときにcommit:の隣に出てくるなが～い数字とアルファベットの文字列のことです。

コミットしたけど、コミットする前の状態に戻したい（プッシュした後は不可）　★★☆
$ git reset --soft HEAD^
手元のプログラムを指定のコミットの位置に戻したい。　★★☆
$ git reset --hard コミットハッシュ
指定のコミットの内容だけを取り込みたい。　★★☆
$ git cherry-pick コミットハッシュ
指定のコミットの情報と全く逆の追加を行い、打ち消す。　★☆☆
$ git revert コミットハッシュ
リモートリポジトリの特定のブランチの情報を落としてきたい。　★★☆
$ git fetch origin ブランチ名:ブランチ名
編集内容を一時的によけておきたい　★★☆
$ git stash save
戻すときは以下。
$ git stash pop
stashはlistやapplyなどがあります。

現職ではgit flowという開発手法を採用していますが、これは複数のコマンドを一つのコマンドでまとめたようなもので、各作業者によって全然違うブランチ管理をすると不都合が起こりやすくなるので、操作方法を統一するためのものだと理解しています。
それぞれのコマンドの意味が分かっていることが大切です。

終わりに

Gitのコマンドはたくさんありますが、ぼくが実務で使っているコマンドはそれほど多くありません。
forkとかrebaseとかなんだかありますが、今のところ使わなくて困ったことはありません。
必要になったら覚えることができます。
上記のコマンドを繰り返し使っていくうちに何をしているかだんだんわかってくるので、使ったことのないコマンドは調べたら動作がわかると思います。
まずは、自信をもって使えるコマンドを一つずつ増やしていくことが大切です。
以上、ここまでお読みいただきありがとうございました。

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-16T00:59:14+09:00

未経験からエンジニア転職後、1年半の間に実務で使ったGitコマンド【初心者向け】

はじめに

他業種、他業界からのエンジニア転職をした後、1年半が経ちました。
その間に使用したGitコマンドをご紹介します。
Gitは転職前に自分でプログラミングの学習に使っていましたが、一人でmasterブランチを使うだけだったので、ほぼ使ったことがないシロート状態でした。
それから実務で使うようになり、以下ののコマンドの組み合わせで今は特に困らずにやっていけています。
今後、エンジニアを目指される方は覚えておいていただくと役に立つのではないかと思います。
開発の順に沿って説明しているので、こんな順で使っていくんだなということも理解できるようにと心がけています。

Git初心者へメッセージ

プッシュさえしなければ、周りに迷惑が拡大することはありません。
手元の環境でコンフリクトしようが、プログラムが消えようが大丈夫です。何とかなります。
もし、自分が作った部分がなくなっても、もう一度作ればいいんですから。
それよりも、プッシュする前に一息ついて、本当にプッシュしても大丈夫か確認するようにしましょう。
プッシュしてしまうとどこまで影響するかわかりません。
Gitには様々なオプションがあります。その中でも「-f」は最強のオプションです。
慣れないうちは使うのをやめましょう。初心者にとってはバルスみたいなもんです。
必ず周りの人に相談してください。
相談すれば、そんなオプションを使わなくても回避できることが多いはずです。
初めはとても怖いです。いろいろ使っていくうちに意外と慣れていくものです。

各コマンドの重要度

個人的な感覚で重要度を星の数で表していますので、優先順位の参考にしてください。

★★★・・・必ず覚えよう
★★☆・・・覚えておくと便利
★☆☆・・・必要になったときに覚えよう

コマンド紹介

プロジェクト開始！

まずはリポジトリの操作から

リモートリポジトリからリポジトリを複製する　★★★
$ git clone {リモートリポジトリ} {ローカル開発環境ディレクトリ}
例）
$ git clone https://github.com/username/projectname.git test/projectname
この例だと、カレントディレクトリに対して、test/projectnameのディレクトリ内にリポジトリを複製するということ。自分のパソコン内のリポジトリをローカルリポジトリといいます。
ディレクトリ部分の記述をしなければ、カレントディレクトリに複製する。

現在のリモートリポジトリを確認する　★☆☆
$ git remote -v
通常は、クローンしたリポジトリを「origin」と省略して呼んでいます。

別のリポジトリを追加する　★☆☆

別のリポジトリも一緒に操作したい時が出てきますので、別のリモートリポジトリを接続することができます。
$ git remote add {追加したいリモートリポジトリ} {リポジトリの略称}
例）
$ git remote add https://github.com/username/projectname2.git project2 
これで、originとproject2というリポジトリを追加することができました。
git remote -vで確認してみてください。

ブランチ操作

現在のブランチを確認する　★★★
$ git branch
リモートリポジトリのブランチ情報を見るために以下のオプションをよく使います。　★★☆
$ git branch -a　または　$ git branch -avv
ブランチを新規作成　★★★
$ git branch 作りたいブランチ名
ブランチを移動　★★★
$ git checkout ブランチ名
これでブランチを作って移動することができました。
ただ、コマンドが2つになり面倒なので、以下のコマンドをよく使います。

ブランチを作りながらブランチを移動　★★★
$ git checkout -b ブランチ名
これで、ブランチを作ってそのブランチに移動。
簡単にまとめると以下のような感じ。

ブランチ名を変える　★★☆

タイプミスや実は作業内容とブランチ名が全然違って気持ち悪いというときによく使います。
$ git branch -m 新しいブランチ名
ブランチを削除　★★☆
$ git branch -d ブランチ名
ただし、対象のブランチがどのブランチにも取り込まれていないときは、実行しても拒否される。
どうしても消したいときは、以下。　★☆☆
$ git branch -D ブランチ名
dを大文字にしただけですね。

リモートリポジトリのブランチを削除　★☆☆
$ git push origin :ブランチ名
プログラムの変更が完了したら

変更したファイルを確認する　★★★
$ git status
変更があったファイルは赤い文字でカレントディレクトリからのファイルパスが示されます。

どのような変更を行ったか確認する　★★★
$ git diff
ファイルを指定することができます。
$ git diff ファイル名１　ファイル名２　ファイル名３
ステージに乗せた（後述）ファイルを確認するにはオプションが必要です。同じようにファイル名を指定できます。
$ git diff --staged
変更プログラムをステージに乗せる　★★★

プログラムをgit上で保存するにはまず、どのファイルを保存するかを指定します。
変更ファイルをすべてステージに乗せる。
$ git add .
ステージに乗せられたファイルはgit statusとすると、緑色の文字で示されます。
ファイルを指定してステージに乗せる。以下のように複数のファイルを同時に指定することができます。
$ git add ファイル名１　ファイル名２　ファイル名３
ステージに乗せたファイルをステージに乗せていない状態にする。間違えて指定してしまったときに使います。
$ git reset ファイル名１　ファイル名２
変更をキャンセルしたい　★★★
$ git checkout ファイル名
これで、ファイルの変更が即座にキャンセルされます。

変更を記録する

変更を記録する　★★★
$ git commit -m '変更内容がわかるコメント'
git statusで緑色に示されたファイルをまとめて変更が記録されます。

コメントを間違えたので修正したい　★☆☆
$ git commit --amend -m '新しいコメント'
変更を直前のコミットに含めたい　★☆☆

変更後、ステージにファイルがある状態でコメントを変更するコマンドでOK。
$ git commit --amend -m 'コメント'
コミットされたか確認する。　★★★
$ git log
これで、ログがざざっとでてきます。
上にいくほど新しく、新しいものから表示され、下にスクロールしていくと古い情報をさかのぼることができます。
よく使うオプションは、以下です。変更したファイル名も一緒に出てきます。
$ git log --name-status
ツリー状に表示したり、変更内容を確認したり、対象を絞ったりといろいろなことができます。
ログの詳細な確認はSourceTreeを使っています。
https://www.sourcetreeapp.com

リモートリポジトリに反映させる

ここからが長いんです。。。
でもここは、複数の人が関わるからこそ重要なコマンドです。ぜひ、覚えましょう。

基本的な手順

１．変更したプログラムを取り込みたいブランチに移動
２．移動先のブランチを最新の状態にする。（リモートリポジトリにプログラムが反映されている場合、取り込む）
３．変更したプログラムを取り込む。
４．変更が重複したら修正する。
５．プログラムをリモートリポジトリに反映させる。

では、行きましょう。

何はともあれ、ブランチ移動ですね。繰り返しになりますが。。
$ git branch 移動先のブランチ名
プログラムを最新の状態にする　★★★
$ git pull
$ git fetch origin 
$ git merge origin/ブランチA
後者はトラッキングブランチを最新の状態にしてからマージします。　　　　　え？？
origin/ブランチAはトラッキングブランチと言い、リモートリポジトリにアクセスしてリモートリポジトリのブランチAの内容をローカルリポジトリに取得したもので、これは開発中のブランチとは別です。
git fetch originで、リモートリポジトリの情報を引っ張ってきます。
そのあと、git merge origin/ブランチAで今のブランチに最新のブランチAの情報を取り込みます。
originとブランチAの間にある「/」はスペースではありません。
参考記事

作成したプログラムを取り込む　★★★
$ git merge 作業したブランチ
現在のブランチがmainという名前のブランチとします。

では、いよいよほかのメンバーが参照できる状態にしていきます。
以下のコマンドを実行する前に一息おきましょう。

リモートリポジトリに反映する　★★★
$ git push origin main
プッシュしてしまったら変更などがとてもしにくくなります。
他の人が取り込んでしまっている可能性があるからです。

作業ブランチをリモートリポジトリに反映させる　★★☆
$ git push origin feature
リモートリポジトリに同名のブランチがなければ作ってくれます。
あれば、同名のブランチに反映します。

ややイレギュラーな操作

以下でコミットハッシュを使ったコマンドが出てきます。
コミットハッシュとはgit logで表示されるときにcommit:の隣に出てくるなが～い数字とアルファベットの文字列のことです。

コミットしたけど、コミットする前の状態に戻したい（プッシュした後は不可）　★★☆
$ git reset --soft HEAD^
手元のプログラムを指定のコミットの位置に戻したい。　★★☆
$ git reset --hard コミットハッシュ
指定のコミットの内容だけを取り込みたい。　★★☆
$ git cherry-pick コミットハッシュ
指定のコミットの情報と全く逆の追加を行い、打ち消す。　★☆☆
$ git revert コミットハッシュ
リモートリポジトリの特定のブランチの情報を落としてきたい。　★★☆
$ git fetch origin ブランチ名:ブランチ名
編集内容を一時的によけておきたい　★★☆
$ git stash save
戻すときは以下。
$ git stash pop
stashはlistやapplyなどがあります。

現職ではgit flowという開発手法を採用していますが、これは複数のコマンドを一つのコマンドでまとめたようなもので、各作業者によって全然違うブランチ管理をすると不都合が起こりやすくなるので、操作方法を統一するためのものだと理解しています。
それぞれのコマンドの意味が分かっていることが大切です。

終わりに

Gitのコマンドはたくさんありますが、ぼくが実務で使っているコマンドはそれほど多くありません。
forkとかrebaseとかなんだかありますが、今のところ使わなくて困ったことはありません。
必要になったら覚えることができます。
上記のコマンドを繰り返し使っていくうちに何をしているかだんだんわかってくるので、使ったことのないコマンドは調べたら動作がわかると思います。
まずは、自信をもって使えるコマンドを一つずつ増やしていくことが大切です。
以上、ここまでお読みいただきありがとうございました。

　 Tweet
Qiitaで続きを読む