投稿日：2021-01-12T19:20:05+09:00

【GitHubまとめ第1回】基礎コマンド

はじめに

必須スキルとなっているgit・gitHubの基礎についてまとめました。今回は「ローカルからリモートリポジトリにpushするまでの流れ」・「変更を取り消す方法」・「クローンの生成方法」を記述しています。初学者向けの内容ですが、ローカルの構造が分かっていない方には少し不親切な説明になっているかもしれません。
コマンドはコピペしやすいように、$をあえてつけていません。

全3回に渡って、下記の計画で進めます。
【計画】
第1回目 git基礎コマンド
第2回目ブランチやマージ
第3回目プルリクエストとその他

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

gitのローカル基本構造

ローカルは3つのエリアに分かれる
1. ワークツリー(ファイルを変更する作業場所)
2. ステージ（コミットする変更を準備）
3. ローカルリポジトリ（スナップショットを記録）

ローカルリポジトリの新規作成

初めに、.gitディレクトリを生成。
git init
Initialized empty Git repository in ○○○○○○と表示されればOK!
.gitディレクトリはリポジトリやインデックスファイル、設定ファイルが作られる。
この中にgit add .やgit commitなどのコマンドで作成されるファイルはこの中に保存される。

リモートリポジトリ(GitHub)へpushする流れ

ワークツリーからステージへ追加
git add .
ステージからローカルリポジトリへコミット
git commit
誰がいつ何の変更したかの記録を残すため重要。
※git commit -m "<メッセージ>"とオプションをつけることでエディタを立ち上げずにコミットできる。

ローカルリポジトリからリモートリポジトリへプッシュ

GitHubでリモートリポジトリを作成

GitHub→Your profile→Repositories→New→Repository nameを入力→Create repositoryの流れ。
そのURLをコピー

リモートリポジトリ(GitHub)を新規追加

originというショートカットでURLのリモートリポジトリを登録
URLはGitHub上で作成したもの。
git remote add origin https://github.com/*****.git
origin:
直訳は「起源、発端、源」。デフォルトのリポジトリの場所(URL)の別名

リモートリポジトリ(GitHub)へプッシュ
git push -u <リモート名> <ブランチ名>
git push　-u origin master
-uオプションをつけておくと、次回以降git pushのみでpushできる。
GitHubのリモートリポジトリを確認すると、リモートリポジトリにpushできていることができる。

現在の状態のファイルの状態を確認
git status
ワークツリ⇄ステージ⇄リポジトリ間で変更されたファイルを、それぞれ確認することができる。
コミットやステージに追加する前にどのファイルが変更されたかを確認する癖を付ける。
→全てのファイルをコミットすると、変更途中の物までコミットしてしまうリスクがある。どれをコミットするのか確認した方が安全。

この図はstageに追加していないindex.htmlがあるという意。
git add .した後、git commitをすると、ローカルリポジトリまで行っているので表示は出なくなる。

変更の履歴を確認
git log
コミットのハッシュ値、変更者、日付、コメントが表示される。

変更履歴のオプション

１行で表示する
git log --oneline
ファイルを指定して変更差分を表示する
git log -p <ファイル名>
表示するコミット数を指示する
git log -n <コミット数>
ファイルの削除方法

ファイルを削除するだけではなく「ファイルを削除する記録を残す」という意。

ファイルごと記録もを削除

リポジトリにコミットした記録が消える

ワークツリーからファイルが消える
git rm <ファイル名>
git rm -r <ディレクトリ名>
ファイルとディレクトリの違い
・ファイル：コンピュータ上で記録・管理される情報の単位
・ディレクトリ：ファイルの目的や種類などに応じて整理するための「入れ物」。ディレクトリはファイルとディレクトリの両方を格納できる。
参考：http://www.cc.kyoto-su.ac.jp/~hirai/text/files.html

ワークツリーにファイルは残して、リポジトリの記録だけ削除
git rm --cashed <ファイル名>
git rmコマンド後、元の状態に戻す
git reset HEAD <ファイル名>
git checkout <ファイル名>
バージョン管理しないファイルの取り扱い

パスワードなどの公開したくないファイルは.gitignoreファイルに指定する

.gitignoreファイルを生成
touch .gitignore
.gitignoreファイルに、公開しないファイル名を記述

.gitignoreファイルに、公開したくないファイル名を記述するとバージョン管理から除外される。（今回はsecret.html)

ワークツリーのファイルを元の状態に戻す

正確には、「指示されたファイルやディレクトリの情報をステージから持ってきて、ワークツリーに反映させる」。

ファイル名やディレクトリ名を指示して元に戻す
git checkout -- <ファイル名>
git checkout -- <ディレクトリ名>
addした全変更を元に戻す
git checkout -- .
※ピリオドは全ファイルの意味

ステージのファイルを元の状態に戻す

正確には、「指示されたファイルやディレクトリの情報をリポジトリから持ってきて、ステージに反映させる」。
→最新のコミットの情報でステージの情報を上書きする。ステージから取り消すだけなので、ワークツリーには影響を与えない。

ファイル名やディレクトリ名を指示して元に戻す
git reset HEAD <ファイル名>
git reset HEAD <ディレクトリ名>
commitした全変更を元に戻す
git reset HEAD .
直前のコミットをやり直す

現在のステージの情報を元に、直前のコミットの情報を上書きする。
git commit --amend
リモートリポジトリにpushしたコミットは修正NG。
リモートリポジトリにpushした内容を修正し、--amendで上書きすると、その間にもし他の人が直前のコミット情報を元に内容を変更し、統合しようとした場合に別のファイルと認識されてしまう。

GitHubからコピー（クローン）を生成する方法
git clone <リポジトリ名>
<リポジトリ名>はGitHub上のリポジトリのCodeタブにあるURL。これをコピーして貼り付ける。

これによって、リモートリポジトリ(GitHub)から以下の2つが行われる。
1. リモートリポジトリのファイルをワークツリーへコピー
2. .gitディレクトリをコピー

最後に

今回はgitの基礎コマンドについてまとめました。次回はブランチやマージについてまとめます。
（もしこの記事に誤りがありましたらご教授いただけると幸いです。）

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-12T18:33:18+09:00

DLしたLaravelの環境構築方法（Linux）

　【前提条件】composerがインストール済み Lamp環境が正常に構築できている。

　　　　githubからDLしたLaravelプロジェクトをとりあえず動かせる
　　　　用にするまでの設定します。　

1、laravelプロジェクトをDLしてみる

ギットハブにアクセスしてとりあえず適当なLaravelのプロジェクトをDLしてみましょう【プロジェクト名testlaravel】

２、composerをインストールする

DLしたtestlaravelプロジェクトのserveを起動しようとするとこのようなエラーが出てきます。
/var/www/html/testlaravel$ php artisan serve
こんなエラーが出てきます↓
PHP Warning:  require(/var/www/html/testlaravel/vendor/autoload.php): failed to open stream: No such file or directory in /var/www/html/testlaravel/artisan on line 18

Warning: require(/var/www/html/testlaravel/vendor/autoload.php): failed to open stream: No such file or directory in /var/www/html/testlaravel/artisan on line 18
PHP Fatal error:  require(): Failed opening required '/var/www/html/testlaravel/vendor/autoload.php' (include_path='.:/usr/share/php') in /var/www/html/testlaravel/artisan on line 18

Fatal error: require(): Failed opening required '/var/www/html/testlaravel/vendor/autoload.php' (include_path='.:/usr/share/php') in /var/www/html/testlaravel/artisan on line 18
Composerが入っていないためLaravelプロジェクトが起動できないのでcomposerをインストールします
/var/www/html/testlaravel# composer install
３、composerのインストールが完了したら

composerのインストールが完了したら早速testlaravelプロジェクトを立ち上げてみましょう
 /var/www/html/testlaravel# php artisan serve
立ち上がることは立ち上がりますが、ここで必ず500サーバーエラーが発生します。

4、.envファイルとAPP_KEYの設定を行う

ここでエラーが発生する要因としてlaravelに.envファイルが作成されていない
APP_keyが作成されていない事が要因でサーバーエラーが発生しています。

まずは.envファイルを作成してみます。コマンドで以下の用に入力します
cp .env.example .env
この段階ではまだenvファイルは作成されてませんのでAPP_KEYの作成をしてみます
php artisan key:generate
vi　.envと入力して無事.envファイルが作成されていれば完成です
↓こんな奴です
APP_NAME=
APP_ENV=
APP_KEY=
APP_DEBUG=
APP_URL=

LOG_CHANNEL=

DB_CONNECTION=
DB_HOST=
DB_PORT=
DB_DATABASE=
DB_USERNAME=
DB_PASSWORD=
（以下略）
改めてtestalaravelプロジェクトを立ち上げてみていつものあのページが出てきたら成功です。

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-12T16:29:02+09:00

Herokuとデプロイについて

はじめに

今のところherokuを使うことが多いので

やり方は他にもあると思いますが、学習したものをまず忘れないように書いていきます。

heroku

クラウド上で開発環境をクラウド上で管理できるサービスとしてのプラットフォーム、「Paas」です。

Herokuとは？

クラウドサービスって・・・

こちらではクラウドサービスとは？
以下のように説明されています。

クラウド（クラウド・コンピューティング）は、コンピューターの利用形態のひとつです。インターネットなどのネットワークに接続されたコンピューター（サーバー）が提供するサービスを、利用者はネットワーク経由で手元のパソコンやスマートフォンで使います。

クラウドの特長のひとつは、利用にあたって、コンピューター（サーバー）の所在地（どこ？）が意識されない点です。たとえるならば、雲（クラウド）の中にあるコンピューターを地上から利用しているようなイメージです。そして、クラウドの形態で提供されるサービスを「クラウドサービス」と言います。

従来のコンピューターの利用形態では、利用者は手元のパソコンの中にあるソフトウェアやデータを利用していました。しかしクラウドサービスでは、ネットワークを経由して、雲（クラウド）の中にあるソフトウェアやデータをサービスの形でつかうのです。

わかりやすい！！

大きく4つに分かれます。

「SaaS」「PaaS」「IaaS」「DaaS」

そのうちの一つが「Paas」です。

「Paas」 (Platform as a Service)

インターネット経由での、仮想化されたアプリケーションやサーバやデータベースなどのアプリケーション実用用のプラットフォーム機能の提供を行うサービス
( AWS、Microsoft Azure、Google App Engine )

「Saas」 (Software as a Service)

電子メール、グループウェア、顧客管理、財務会計などのソフトウェア機能の提供を行うサービス
( Google Apps, Salesforce, サイボウズoffice )

「Iaas」 (Infrastructure as a Service)

主にデベロッパー向けに仮想マシンを提供するもの
( IDCFクラウド, VDC PRO, Dropbox)

「Daas」　(Desktop as a Service)

(Microsoft Virtual Desktop, IBM Smart Business Desktop, Citrix XenDesktop )

...STaaS ..BaaS ..XaaS...

4つと思いきや・・

まだたくさんありますね・・。

詳しくは↓

DigitalMarketingbog: SaaS、PaaS、IaaS、DaaSって何？

ferret: クラウドサービスの「SaaS」「PaaS」「IaaS」「DaaS」の違いとは？

デプロイの流れ

Heroku CLIをインストール（初めのみ）
 % brew tap heroku/brew && brew install heroku
できたかチェックします。
% heroku --version 

(このような表示が出てきます。)
# heroku/7.47.7 darwin-x64 node-v12.16.2
Herokuにログインします。
% heroku login --interactive

(Emailとパスワードを入力します。)
=> Enter your Heroku credentials.
=> Email:　(メールアドレスが最初に自動で表示される場合は何も入力せずにenterを押します。)

=> Password:　
(ログインできるとこのように表示されます。↓)
Logged in as "~"
rails_12factorを導入

gemfileに追記します。

静的アセットファイルやログの保存先をHeroku用に微調整してくれるGemです。
Gemfile
group :production do
  gem 'rails_12factor'
end
インストールします。
% bundle install
Herokuに反映するにはgit上にも反映させる必要があります。
githubでも、直接でも。
こんな感じで。
% git add .

% git commit -m "gem rails_12factorの追加"
これは！前回勉強しましたので、

貼っときましょう。

[Git]基本的なコマンド入門

Heroku上にアプリケーションを作成する

アプリを作っていきます。
使われている名前を入力すると「使ってるよ！」的なことを言われるので注意です。
 % heroku create picapp-30464
                 (↑アプリの名前)決める
出来たか確認してみます。
% git config --list | grep heroku


(このようなものが表示されます。)
remote.heroku.url=https://git.heroku.com/picapp-30464.git
remote.heroku.fetch=+refs/heads/*:refs/remotes/heroku/*
HerokuでMySQLを使用できるようにする

（デフォルトはPostgreSQL）

ClearDBアドオンを使用します。
こちらはMySQLを使用するためのツールです。
% heroku addons:add cleardb
mysql2への変更

ClearDBデータベースのURLを確認
heroku config | grep CLEARDB_DATABASE_URL
設定を変更、
（ClearDBデータベースのURLを変数heroku_cleardbに格納）
% heroku_cleardb=`heroku config:get CLEARDB_DATABASE_URL`
データベースの再設定です。
% heroku config:set DATABASE_URL=mysql2${heroku_cleardb:5}
Heroku上で非公開の値を管理する

credentials.ym.encファイルを利用します。
外部にもたらしたくない情報を扱う際に用いるファイルです。

master.keyがあれば内容を確認できます。
暗号文を複合する鍵の役目を持ったファイルです。
非常に重要なファイルなのでリモートリポジトリで反映されるのが好ましくないので「.gitignore」に記述されています。（Gitで管理されない仕組み）

中身を見てみます。
% EDITOR="vi" bin/rails credentials:edit

(今回は確認だけです。)
(ファイルの抜け方)
escキー
: キー
qキー
enter
Heroku上に環境変数を設定、master.keyを設定

環境変数
OSが提供するデータの一つで、どのディレクトリがファイルからでも参照できる変数です。
例）　heroku config:set 環境変数名="値"
         ↓ （ こう ）
% heroku config:set RAILS_MASTER_KEY=`cat config/master.key`
環境変数の設定を確認します。
「RAILS_MASTER_KEY」があったら成功です。
 % heroku config
アプリケーションをpushする
% git push heroku master
Herokuでマイグレーションをする
% heroku run rails db:migrate
公開情報を確認してみます。
% heroku apps:info
デプロイできました！！ Yes!!

エラーになった場合

エラーログを確認して原因を確認します。

エラーログ
アプリケーションなどのシステム実行時に発生したエラーを記録したものです。
% heroku logs
ログの最後の10行を表示するためのオプションを使用するとこのようになります。
% heroku logs --tail --app picapp-30464
                           (↑アプリケーション名)
デプロイ済みのアプリに変更を加えた場合

Herokuにもまた「push」してデータベースを変更した場合は再度「migrate」をします。

環境変数を設定し忘れた場合

「push」してしまった後に設定し忘れたことに気づいたら、
設定してファイルの変更がない場合は空のコミットを作成し共に「push」してあげるとできます。
% git commit --allow -empty -m "空のコミット"

(その後に)

% git push heroku master
まとめ

リンク切れしてしまうといった困ったこともあるみたいですが簡単にデプロイできるので便利です！！

これを機に近々もう少し深掘りしてみたいと思います。
ちょっと時間かかってしまったので続きは次回にします

参考

Basic認証のやり方も書いてあり忘れたときにも良いです！！

hideo blog：Rails で作った app を Heroku へデプロイする手順

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-12T15:50:29+09:00

【git ssh接続】〜複数のアカウントでgit ssh接続する方法〜

暗号鍵の生成
# sshのセッティングディレクトリに移動
$cd ~/.ssh

# 暗号鍵を生成
$ ssh-keygen -t rsa
# Generating public/private rsa key pair.
# Enter file in which to save the key (/Users/(username)/.ssh/id_rsa): id_git_rsa
# Enter passphrase (empty for no passphrase):
# Enter same passphrase again:
GitHubへの公開鍵のアップロード

以下URLで公開鍵の設定
https://github.com/settings/ssh

「title」に公開鍵名、「key」に公開鍵の中身を入れる

ssh接続の設定
~/.ssh/conifg
Host github
  HostName github.com
  IdentityFile ~/.ssh/main_rsa
  User git
  Port 22
  TCPKeepAlive yes
  IdentitiesOnly yes

Host github-sub
  HostName github.com
  IdentityFile ~/.ssh/sub_rsa
  User git
  Port 22
  TCPKeepAlive yes
  IdentitiesOnly yes
github-subとgithubは任意
IdentityFileのファイル名も任意

githubへのssh接続確認
# ssh接続確認 （<HOST NAME>には「github-sub」などが入る）
$ ssh -T <HOST NAME>
# Hi ******! You've successfully authenticated, but GitHub does not provide shell access.

# git cloneを実行 （ssh用のURLをコピーし、HOST NAMEを書き換える）
$ git clone <HOST NAME>:******/******.git
参考

GitHubでssh接続する手順~公開鍵・秘密鍵の生成から~
https://qiita.com/shizuma/items/2b2f873a0034839e47ce
複数のgitアカウントを使用する場合
https://qiita.com/yamataku29/items/4744c9c70ad793c83b82

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-12T12:26:02+09:00

AWS CodeCommit をスイッチロールで利用する

はじめに

CodeCommitリポジトリをスイッチロール権限でローカルにgit cloneすることを目的とします。
スイッチロールについてや設定方法については本記事では言及しません。

使用環境とバージョン

macOS Catalina

git version 2.24.3 (Apple Git-128)

aws-cli/2.0.28

記事の対象

ある程度AWSとGitの知識がある方

CodeCommitを利用して開発を行いたい方

CodeBuild、CodePipelineを使用したCI/CDに興味がある方

※ CodeCommitとGitの違いについて公式ドキュメントのQ&A
AWS CodeCommit のよくある質問

事前準備

Git 1.7.9 以降がインストールされていること（Macではプリインストールされているはず）

スイッチロールを作成済み。スイッチロール先にCodeCommit操作権限が付与されていること

1. AWS CLIのインストール

以下のコマンドを実行し、AWS CLIをインストールします。
$ brew install awscli  // 更新の場合: brew upgrade awscli
...

$ aws --version
aws-cli/2.0.28 Python/3.8.3 Darwin/19.5.0 botocore/2.0.0dev32
2. IAMユーザのアクセスキーとシークレットキーを発行

AWS CLIを使用するためにはIAMユーザを紐づける必要があります。
事前にAWSコンソールから自身のユーザを選択し、アクセスキーを発行します。

3. configおよびcredentialsを設定

aws configureコマンドを使用して、AWS CLIに事前に取得したアクセスキーとシークレットキーを設定します。
$ aws configure
AWS Access Key ID [None]: [アクセスキー]
AWS Secret Access Key [None]: [シークレットキー]
Default region name [None]: ap-northeast-1
Default output format [None]: json
上記コマンドを実行することで以下の2ファイルに設定が追加されます。
~/.aws/credentials
[default]
aws_access_key_id=AKIAIOSFODNN7EXAMPLE
aws_secret_access_key=xxxxxxxxxxxxxxxxx
~/.aws/config
[default]
region=ap-northeast-1
output=json
4. configにスイッチ先のプロファイル情報を記載

configにスイッチ先のプロファイル情報を追加します。
追加したプロファイルを指定することで自身のIAMユーザに権限がアタッチされていないサービスでもスイッチロール先の権限を利用してサービスを利用できます。
~/.aws/config
[default]
region=ap-northeast-1
output=json

+ [profile switchrole]
+ role_arn = arn:aws:iam::{スイッチ先のAWSアカウントID}:role/{ロール名}
+ source_profile = default
+ region=ap-northeast-1
+ output=json
5. 認証情報ヘルパーを設定

Gitでは認証情報ヘルパーを利用して先ほど追加したプロファイルを指定します。
以下のコマンドで認証情報ヘルパーにプロファイル情報を設定してください。
$ git config --global credential.helper '!aws --profile switchrole codecommit credential-helper $@'
$ git config --global credential.UseHttpPath true

$ git config --global user.name "kazuki.kano"
$ git config --global user.email kano@xxxx
user.nameなどのユーザ情報は適宜設定してください。
設定ルールなどを決めて設定することをお勧めします。

設定内容は以下のようになります。
~/.gitconfig
[credential]
    helper = !aws --profile switchrole codecommit credential-helper $@
    UseHttpPath = true
[user]
    name = kazuki.kano
    email = kano@xxxx
6. CodeCommitからclone

あとはGitリポジトリと同様にcloneすれば完了です。
$ git clone https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/demo-api
しばらくすると以下のようなエラーが発生する場合があります。
fatal: unable to access 'https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/demo-api/': The requested URL returned error: 403
これはAWS公式のドキュメントにもあるように、macOSではKeychain Access ユーティリティによりCodeCommitリポジトリへのアクセスは15分で無効になります。

OS X および macOS でリリースされているデフォルトバージョンの Git では、Keychain Access ユーティリティを使用して、生成された認証情報を保存します。セキュリティ上の理由により、CodeCommit リポジトリにアクセスするために生成されるパスワードは一時パスワードであるため、15 分経過すると、キーチェーンに保存されている認証情報は無効になります。

認証情報ヘルパーと AWS CodeCommit への HTTPS 接続のトラブルシューティング

対処法は以下のようにhelper = osxkeychainをコメントアウトして下さい。
$ git config -l --show-origin | grep credential
file:/Library/Developer/CommandLineTools/usr/share/git-core/gitconfig   credential.helper=osxkeychain
file:/usr/local/etc/gitconfig   credential.helper=osxkeychain
...

$ sudo vi /Library/Developer/CommandLineTools/usr/share/git-core/gitconfig
[credential]
        # helper = osxkeychain  // コメントアウトします
上記だけで認証できない場合は、Keychain Access ユーティリティに認証情報が残っている可能性があるのでこちらはアプリから削除して下さい。

検索ウインドでgitなどで検索すると絞り込めます。

参考記事

AWS CodeCommit のよくある質問

認証情報ヘルパーと AWS CodeCommit への HTTPS 接続のトラブルシューティング

AWS CLI 認証情報ヘルパーを使用して AWS CodeCommit リポジトリへの HTTPS 接続をセットアップする手順

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-12T10:29:48+09:00

Git ローカルリポジトリにあるブランチ間の差分を出力する

目的

Gitのローカルリポジトリ内のブランチ間のソースを比較する方法をメモ的にまとめる

方法
AブランチとBブランチの差分を出力したい場合、ローカルリポジトリ内部で下記コマンドを実行する。
$ git diff Aブランチ Bブランチ
具体例
materブランチとdevブランチの差分を出力したい場合下記コマンドをローカルリポジトリ内部で実行する。
$ git diff master dev

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-12T09:15:47+09:00

【メモ】個人開発で使うgitフロー

個人開発で使うgitフローをメモしておきます。

まず最初にすること

ローカルリポジトリの作成
git init
リモートリポジトリとの紐付け
git remote add origin <リモートリポジトリのURL>
とりあえずプッシュしておく
git add .
git commit -m "first commit"
git push origin master
とりあえずmasterブランチでプッシュしておけば、デフォルトブランチがmasterになるから楽。gitHubで直接操作してもOKだけど、、、

ブランチを作成＆移動
git checkout -b <作成するブランチ名>
ステージング〜コミット
git add .

git commit ([-m "コミットメッセージ"] をつけてもOK。)
リモートリポジトリにプッシュする
git push origin <ブランチ名>
プルリクエスト

gitHub上でプルリクエストを行う。

リモートの内容を取り込む
//mersterブランチに移動
git checkout master

//プルする
git pull origin master
必要のなくなったブランチは削除
git branch -d <削除したいブランチ名>
まとめ

まとめときます。
//最初にすること
git init
git remote add origin <リモートリポジトリのURL>

//それ以降
git add .
git commit
git push origin <ブランチ名（例：develop）>
プルリクエスト
git checkout master
git pull origin master
git branch -d <ブランチ名（例：develop）>

　 Tweet
Qiitaで続きを読む

投稿日：2021-01-12T01:58:17+09:00

【Git】rebaseコマンドの理解

概要

開発現場でGitを利用し、ソースの管理を行なっていました。
その際、「管理者からrebaseしてコミット履歴を綺麗にしてからプルリクエストしてくれ」という指示がありましたが。。。

とりあえずでrebaseコマンドを実施してしまっていたので、
理解したことをメモしておきます。

rebaseとは

rebaseとは。。。
　gitのコマンドの一つであり、分岐したブランチを統合すること
　統合だけでなくコミット履歴も修正することが可能

merge　と　rebase 比較

分岐したブランチを統合した際の違いを確認します。
（master、featureと２つのブランチを作成し、masterブランチへ統合します。）

■mergeの場合
新しいマージコミット履歴を作成し、統合されます。
複数の親コミットを持つというのが特徴です。（今回でいうと②と③）

※時系列としては上記の数字順にコミットしたとします。
コミット履歴としては「①→②→③→④」という時系列順に履歴が作成されます。

■rebaseの場合
親コミットが変更されます。（今回でいうと①から③）
親コミットが変更されるに伴いコミットが一直線になります。

最終的にmasterブランチに最新の情報を反映させるためには、rebaseしたfeatureブランチをmergeする必要があります。
この時のmergeは「Fast-forward」という種類になります。
rebaseしたおかげで履歴が一直線上となり、マージした際も統合ではなく最新のコミットを更新するだけとなります。
（③から②'）

※時系列としては上記の数字順にコミットしたとします。
コミット履歴としては「①→③→②」という時系列順に履歴が作成されます。
時系列に関わらず最新のコミット履歴として統合されます。

実践

実際に分岐したブランチを一つのブランチへ統合してみます。
「merge」「rebase」どちらの場合でも実行し、比較します。

【mergeコマンドで統合】（コミットID等は省略しています）
①masterブランチのみ存在しcommit履歴が一つだけある状態にする。
コンソール
$ git log --oneline
$  master first commit
②featureブランチを作成し、移動する
コンソール
$ git checkout -b feature
③featureブランチにて変更を加えコミットする。
コンソール
$ git add .
$ git commit -m "second commit"
④masterブランチに移動し、変更を加えてコミットする。
コンソール
$ git checkout master
$ git add .
$ git commit -m "third commit"
⑤履歴の確認
　「Atom」の「git-log」プラグインを用いて確認してみます
　Atomを開き「command + shift + p　（Macの場合）」でコマンドパレットを開き
　「Git Log: Show」を入力すると、logを確認することができる。

ブランチが分岐され、それぞれにコミット履歴があることが確認できる。

⑥masterブランチにfeatureブランチでの変更分をmergeコマンドで取り込む
コンソール
$ git merge feature
⑦履歴の確認
コンソール
$ git log --oneline
$ Merge branch 'feature'
$ third commit
$ second commit
$ master first commit
【rebaseコマンドで統合】（コミットID等は省略しています）
mergeで実施した内容⑤まで同様の内容にしておきます。

⑥featureブランチにてrebaseコマンド実行
コンソール
$ git rebase master
⑦履歴の確認

先ほどとは異なり、コミット履歴が一直線になりました。
さらに、変更分がfeatureブランチコミットした内容が最新のコミット履歴として反映されています。

⑧masterブランチに移動し、megeコマンド実行
　⑦ではあくまでfeatureブランチの起点を変更したのに過ぎないため、masterブランチにも反映させます。
コンソール
$ git checkout master
$ git merge feature
⑨履歴の確認
コンソール
$ git log --oneline
$ second commit
$ third commit
$ second commit
$ master first commit
まとめ

コミットに履歴を綺麗にするという意味が以前よりはわかるようになりました。
「自分が作業したコミットを最新の履歴として取り込みたい」、「コミット履歴を綺麗に保ちたい」と行った場合にはrebaseを使うのが良さそうです。

参考文献

https://qiita.com/ganezasan/items/f7ca66f47bc8067988cf
https://qiita.com/KTakata/items/d33185fc0457c08654a5
https://git-scm.com/book/en/v2

　 Tweet
Qiitaで続きを読む

20210112のGitに関する記事は8件です。

【GitHubまとめ第1回】基礎コマンド

はじめに

gitのローカル基本構造

ローカルリポジトリの新規作成

リモートリポジトリ(GitHub)へpushする流れ

ワークツリーからステージへ追加

ステージからローカルリポジトリへコミット

ローカルリポジトリからリモートリポジトリへプッシュ

GitHubでリモートリポジトリを作成

リモートリポジトリ(GitHub)を新規追加

リモートリポジトリ(GitHub)へプッシュ

現在の状態のファイルの状態を確認

変更の履歴を確認

変更履歴のオプション

１行で表示する

ファイルを指定して変更差分を表示する

表示するコミット数を指示する

ファイルの削除方法

ファイルごと記録もを削除

ワークツリーにファイルは残して、リポジトリの記録だけ削除

git rmコマンド後、元の状態に戻す

バージョン管理しないファイルの取り扱い

.gitignoreファイルを生成

.gitignoreファイルに、公開しないファイル名を記述

ワークツリーのファイルを元の状態に戻す

ファイル名やディレクトリ名を指示して元に戻す

addした全変更を元に戻す

ステージのファイルを元の状態に戻す

ファイル名やディレクトリ名を指示して元に戻す

commitした全変更を元に戻す

直前のコミットをやり直す

GitHubからコピー（クローン）を生成する方法

最後に

DLしたLaravelの環境構築方法（Linux）

1、laravelプロジェクトをDLしてみる

２、composerをインストールする

３、composerのインストールが完了したら

4、.envファイルとAPP_KEYの設定を行う

Herokuとデプロイについて

はじめに

heroku

クラウドサービスって・・・

「Paas」 (Platform as a Service)

「Saas」 (Software as a Service)

「Iaas」 (Infrastructure as a Service)

「Daas」 (Desktop as a Service)

デプロイの流れ

Heroku CLIをインストール（初めのみ）

rails_12factorを導入

Heroku上にアプリケーションを作成する

HerokuでMySQLを使用できるようにする

mysql2への変更

Heroku上で非公開の値を管理する

Heroku上に環境変数を設定、master.keyを設定

アプリケーションをpushする

Herokuでマイグレーションをする

エラーになった場合

デプロイ済みのアプリに変更を加えた場合

環境変数を設定し忘れた場合

まとめ

参考

【git ssh接続】〜複数のアカウントでgit ssh接続する方法〜

暗号鍵の生成

GitHubへの公開鍵のアップロード

ssh接続の設定

githubへのssh接続確認

参考

AWS CodeCommit をスイッチロールで利用する

はじめに

使用環境とバージョン

記事の対象

事前準備

1. AWS CLIのインストール

2. IAMユーザのアクセスキーとシークレットキーを発行

3. configおよびcredentialsを設定

4. configにスイッチ先のプロファイル情報を記載

5. 認証情報ヘルパーを設定

6. CodeCommitからclone

参考記事

`git rm`コマンド後、元の状態に戻す

「Daas」　(Desktop as a Service)

merge　と　rebase 比較