20201215のGitに関する記事は5件です。

投稿日：2020-12-15T23:36:14+09:00

Gitと連携するツールとしてのVim

はじめに

Vimといえば、みなさんご存じテキストエディタですが、テキストエディタである以前に一つのCLIコマンドでもあります。そんなCLIコマンドの利点一つにThe UNIX philosophyの定理として提唱されている『7. Use shell scripts to increase leverage and portability. (シェルスクリプトによって梃子(てこ)の効果と移植性を高める)』というものがあります。

今回は私も普段の仕事で利用しているVimの梃子としての側面をご紹介できればと思います。

GitコマンドとVim

今回Vimと組み合わせるのはシステム開発で避けては通れぬバージョン管理システムGitです。私は普段Gitを使用するときにはSourcetreeやGitKrakenなどのGUIクライアントを利用せずにCLIで操作をしています。
皆さんこう思われるかもしれません。「またCLI狂信者か。あんな簡素なインタフェースで、Gitなんて複雑なものを素早く操作できる訳無いだろう。おとなしくGUIクライアントを使えばいいじゃないか。」
ちょっとまってください。私もなにも素のGitコマンドだけですべてを操作することが効率が良いという気はないのです。CLIコマンドだからこそ簡単に他のツールと連携できることこそが魅力だと言いたいのです。

コミットメッセージをVimで入力する

まずは基本のキ、コミットメッセージの入力です。Git管理ファイルを変更し、差分をaddしてstagedにします。そしたらさあコミットの時間です。
皆さんは普段GitのCLIコマンドでコミットするときにどうされるでしょうか？私はそのまま単純にgit commitと入力します。オプションなしで実行するとそのままデフォルトのエディタ(環境変数$EDITORに設定されたコマンド)でGitのメッセージ入力用の一時ファイルを開き、ファイルを閉じたときにファイル入力内容を読み取ってコミットします。

補足すると、このとき最優先で開くエディタは.gitconfigファイルに設定されているコマンドなので、明示的に指定したいときは以下のコマンドで指定すると良いでしょう。
git config --global core.editor ${editor}
ここからが面白いところです。素のVimを立ち上げただけだとそれなりに便利ではありますが少し物足りません。そこでいくつかの機能を追加してあげましょう。まずスペルチェックをGitのメッセージ編集時のみ有効にしてあげましょう。
augroup GitSpellCheck
    autocmd!
    autocmd FileType gitcommit setlocal spell
augroup END
スペルチェックだけだと、タイポはわかっても正しいスペルがわからないってときもありますよね。そんなときは辞書を引けばいいのです。deoplete.nvimとneco-lookを導入すれば、英単語が自動補完されるので、つまらないタイポとはオサラバです。
Plug 'Shougo/deoplete.nvim'
Plug 'ujihisa/neco-look'
let g:deoplete#enable_at_startup = 1
call deoplete#custom#option('sources', {
\ 'gitcommit': ['look'],
\})
更にcommittia.vimというプラグインを導入することで、変更したファイル内容などのコミットに付属する各種情報を一目で確認することができます。Vimでコミットメッセージをいじるなら是非入れたいプラグインです。
Plug 'rhysd/committia.vim'
function! g:committia_hooks.edit_open(info)
    " Additional settings
    setlocal spell
    setlocal spelllang+=cjk

    " If no commit message, start with insert mode
    if a:info.vcs ==# 'git' && getline(1) ==# ''
        startinsert
    end

    " Scroll the diff window from insert mode
    " Map <C-n> and <C-p>
    imap <buffer><C-n> <Plug>(committia-scroll-diff-down-half)
    imap <buffer><C-p> <Plug>(committia-scroll-diff-up-half)
endfunction
いかがでしょうか？Gitのコミット時に英単語のスペルチェックと自動補完と各種差分情報を見れてVimキーバインドでテキスト編集できる環境というのはなかなかないと思います。コミットメッセージを書くというVimが最も得意な行為をVimに任せる。それだけでGitコマンド単体と比べ格段に便利になるのです。

Gitの差分をVimで見る

Gitで差分の確認もよくやる作業です。Gitコマンドで差分を見るなら以下のような流れですね。
# 差分を確認するハッシュをログから確認
git log
# 該当のハッシュの差分を見る
git diff ${hash}
上記を実行すると、だいたいの環境ではlessコマンドなどのページャが起動してスクロールすると思います。少量ならばこれでもいいですが、多量のdiffを確認するには心もとありません。そこで登場するのがVimです。皆さんVimのことをただのエディタだと思ってますよね？実はVimは差分比較ツールとしても優秀なのです。もし使ったことがないのならば一度でいいからdiffのかわりにvimdiffを使ってみて欲しいです。

Gitは先程のコミットメッセージのように、差分についても別コマンドに連携することができるのです。例えばWindowsで有名な差分ツールのWinMergeでGitの差分を表示したり。なんてこともできます。

このような外部ツールをGitコマンドから起動するときはdiffではなくdifftoolを利用するのですが、このとき起動する外部ツールをeditorの変更をしたとき同様に設定で変更できます。
git config --global diff.tool vimdiff
設定を変更したらあとはコマンドを実行するだけです。
git difftool ${hash}
いかがでしょうか。とても見やすくなったのではないでしょうか？
差分以外の部分は折り畳まれてたりと、いい感じに気を利かせてくれていますね。

なお上記のGIF動画ではファイルごとに確認のプロンプトが表示されていますが、こちらについては設定で有無を選択できます。
git config --global difftool.prompt false
さて差分を確認できるとなると、少し欲が出てきますね。この見やすい差分の画面で、コンフリクト解消ができたらとっても便利なのに。そう思いませんか？

できます！！！！以下の記事に自分が以前参考にした内容が記載されているので見てみてください。

Gitのmergetoolでvimdiffを指定してVimでマージコンフリクトを解決してみた

またvimdiffというのは本家Vim側が用意しているコマンドであって、NeoVimのコマンドではありません。そのため、NeoVimで同じことをやろうとするとまた別の設定が必要になります。こちらについては以下の参照ください。

GitのdifftoolとmergetoolコマンドがNeovimを使うように設定してみた

さてここまでくるとだいぶGitとVimの組み合わせのパワーを感じてきたのではないでしょうか？

TigとVim組み合わせてインタラクティブにGit操作しよう

最後に組み合わせの要素をもう一つ追加します。それがTigです。俗に言うインタラクティブなGitコマンドです。
類似のコマンドにGolang製のLazyGitやRust製のGitUIなんかがあります。これらのほうがパフォーマンス面で優れていたりしているのですが、コマンドを形作る思想やカスタマイズ性が自分にマッチしすぎていて、tigを手放す気にはなりません。
tig単体でもかなり強力なツールなのですが、tigとVimを組み合わせることでもっと強力になります。

今回基本的な使い方については解説しないのでマニュアルをご参照ください。

Tigでみた差分からVimを開く

私が多様するのがこれで、TigのDiff Viewからeを押すことで、カーソル位置のファイルをgit editorで開くというものです。シンプルが故にいくらでも応用が効きます。開いた後は普通にエディタとして操作が可能です。私はこれをプロジェクト編集の起点にしたりします。

Tigで差分を見てからrebaseしよう

皆さんチームメンバーに「このコミットとこのコミット粒度が小さすぎるからsquashしておいて、git rebase -iでできるから。」と言われて、ナンノコッチャと調べて悪銭苦闘し、一時間ぐらいかけて２つのコミットをsquashしたことはありませんか？私はあります。
git logで該当のハッシュと差分を調べつつ、恐る恐るgit rebase -iを実行する。そして次回やる頃にはどうやるかを忘れている。そしてrebaseなんかもう二度とやらないと思う。そんなことありませんか？私はあります。

そんな私はTigとたった一行の.tigrc(Tigの設定ファイル)でこの悩みから開放されました。それがこの$HOME/.tigrcです。
bind main R !git rebase -i %(commit)
やってることは単純でTigのmain view閲覧時のRでカーソル配下のcommitを起点にrebase -iを実行するだけです。

なお豆知識なんですが、このrebase -iで起動したファイル上だとcommit hashをカーソル下においてKを押すとdiffが見れます。これはVimにビルドインされているプラグインの機能です。

Tigの差分をVimで見る

自分で紹介しといてなんですがGitの差分をVimで見るを更に便利にしたものをご紹介しましょう。.tigrcに以下を追加することで、その機能を利用できます。なおgit difftoolの設定ができていることを前提とします。
bind main D !sh -c "git difftool %(commit)~ %(commit)"
これはTigでカーソル配下のcommitとその前のcommitの差分をvimdiffで表示できます。Gitコマンドでやっていたことをインタラクティブにできるようにしたと考えれば良いでしょう。

これはmain viewだけではなくref view(ブランチの一覧)でも使えるため、ブランチの差分なんかを確認するのにも使えます。
bind refs D !sh -c "git difftool %(branch)"
最後に

Vimというコマンドの中だけでも面白いですが、Vimとて一つのCLIコマンドです。その特色を活かして、他のコマンドからVimへ、Vimから他のコマンドへの組み合わせることで、相乗効果が生まれるということが少しでもわかっていただけたなら幸いです。
もし皆さんのオススメの組み合わせなどあれば、ぜひ私に教えてください。

　 Tweet
Qiitaで続きを読む

投稿日：2020-12-15T20:45:18+09:00

EC-CUBEのバージョンアップを見据えたカスタマイズ方法2020年度版

この記事はGit を使って EC-CUBE を簡単アップデートの2020年度版です。

EC-CUBE はバージョンアップが大変なことで有名?でしたが、 4系になって EC-CUBEアップデートプラグイン が用意されるなど、徐々に改善されてきています。

しかし、本体のコードをカスタマイズしてしまうと、バージョンアップ時に上書きすることもできず、アップデートプラグインでもエラーが表示され、バージョンアップの難易度が格段に上ってしまいます。
「プラグインや Customize ディレクトリでカスタマイズしろよ」ってことでしょうが、何でもかんでもプラグインや Customize ディレクトリで頑張ろうとすると、開発・保守コストも上がってしまいます。
高度なプログラミングスキルも求められるため、なかなか簡単にはいきません。

EC-CUBE4系の場合、カスタマイズ方法は大きく分けて3種類あります。

Customize ディレクトリでカスタマイズ

プラグインでカスタマイズ

本体のファイルを上書き

この中で、1 の Customize ディレクトリは EC-CUBE4系から用意された方法です。
2系や3系では 2 or 3 の2択となります。

ここで、本当にプラグインにする必要があるのか？ Customize ディレクトリを使う必要があるのか？今一度考えてみましょう。

別の案件などで再利用したい。オーナーズストアで販売したい

アンインストール機能が必要

Git でソースコードのバージョン管理ができない

ec-cube.co を使っている

クラウド版である ec-cube.co は、カスタマイズ可能な箇所が限られているため、必然的にプラグインでカスタマイズすることになります。

バージョンアップ楽になるからプラグインで... と、よく言われるのですが それは大きな間違いです。

プラグインを使ってカスタマイズしても、本体がバージョンアップした時に、処理が干渉すれば影響を受けます。
干渉しているかどうかは、テストで動かすまでわかりません。
干渉しているかどうか、差分を取るのも苦労します。

プラグインや Customize ディレクトリは実装が複雑化しやすく、脆弱性を生みやすい懸念もあります。
実装上の依存関係がわかりづらいため、引き継ぎをした場合に後任者が大変な思いをすることも。。。

また、すべてのカスタマイズを Customize ディレクトリやプラグインでできるわけではありません。
規模が大きくなると必然的に本体のカスタマイズも必要になってきます。

Git でしっかりバージョン管理しつつ、本体ファイルを上書きするのがカスタマイズの開発効率も、バージョンアップも楽で開発効率のバランスが取れています。(当社比)

開発工数自体は本体をカスタマイズした方が圧倒的に少ないです。
また、バージョンアップも Git を使用した方が安全・確実です。

影響のあるところはコンフリクトするので、バージョンアップ時のテストも楽です。 git diff で差分の一発でわかります。
hub コマンドを使えば、脆弱性パッチもコマンド一つで当てられます。
# Pull Request #4575 を取り込む
hub merge https://github.com/EC-CUBE/ec-cube/pull/4575
3系、4系でデザイン管理画面からテンプレートを編集すると app/template 以下にファイルがコピーされます。アップデートプラグインを使用していても、手動で差分を確認する必要が出てきます。このため、テンプレートを Git で管理することが難しくなりますので注意しましょう

それでも本体はさわりたくないという人は否定しませんが、 Git でバージョンアップする手順を見ていきましょう。

この方法は 2系、3系でも利用可能です。
ただし、すべての状況において万能なアップデート方法ではありませんので、自己責任でお願い致します。

また、汎用的にするため、すべてコマンドラインで記載していますが、 SourceTree などの GUI ツールを使っても大丈夫です。

1. github から EC-CUBE のソースコードを clone します

<eccube version> には、使用したい EC-CUBE のバージョン(例: 4.0.4)

<folder name> には、宛先のフォルダ名を入力してください
EC-CUBE4.x
git clone https://github.com/EC-CUBE/ec-cube.git -b <eccube version> <folder name>
EC-CUBE3.x
git clone https://github.com/EC-CUBE/ec-cube3.git -b <eccube version> <folder name>
EC-CUBE2.x
git clone https://github.com/EC-CUBE/eccube2.git -b <eccube version> <folder name>
# 2系の場合はバージョンの前に eccube- を付与してください
# 例) eccube-2.4.4
2. 管理用のブランチを作成

<new-branch-name> には、ソースコードを管理するためのブランチ名(例: production) を入力します
cd <folder name>
git checkout -b <new-branch-name>
これで、カスタマイズしたソースコードを管理するための準備が整いました。
本番環境などからソースコードを取得し、 <folder name> に上書きしてください。

3. 差分の確認

カスタマイズしたソースコードと、 EC-CUBE 本体のソースコードに差分が発生しているかを git status コマンドで確認します。
git status

On branch production
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:   src/Eccube/Repository/OrderRepository.php

no changes added to commit (use "git add" and/or "git commit -a")
src/Eccube/Repository/OrderRepository.php に修正が入っていることがわかります。

どのような内容の修正か、 git diff コマンドで見てみましょう。
git diff

diff --git a/src/Eccube/Repository/OrderRepository.php b/src/Eccube/Repository/OrderRepository.php
index f80ee50e8d..d41217427c 100644
--- a/src/Eccube/Repository/OrderRepository.php
+++ b/src/Eccube/Repository/OrderRepository.php
@@ -113,7 +113,7 @@ class OrderRepository extends AbstractRepository
             $qb
                 ->andWhere('o.id = :multi OR o.name01 LIKE :likemulti OR o.name02 LIKE :likemulti OR '.
                             'o.kana01 LIKE :likemulti OR o.kana02 LIKE :likemulti OR o.company_name LIKE :likemulti OR '.
-                            'o.order_no LIKE :likemulti OR o.email LIKE :likemulti OR o.phone_number LIKE :likemulti')
+                            'o.order_no LIKE :likemulti OR o.email LIKE :likemulti OR o.phone_number LIKE :likemulti OR o.message LIKE :likemulti')
                 ->setParameter('multi', $multi)
                 ->setParameter('likemulti', '%'.$searchData['multi'].'%');
         }
受注管理画面の検索条件に、お問い合わせ内容が追加されています。

4. 修正内容の保存

この修正内容を、 git add と git commit コマンドで保存しておきましょう。
git add .
git commit -m 'save production'

[production 37fb0e7] save production
 1 file changed, 1 insertion(+), 1 deletion(-)
git add . では、最後に「.(ドット)」を入れるのを忘れないようにしてください。
git commit の -m には、任意のコミットログを記録できます。どんな修正なのか書いておくと、後々役立ちます。

こうして日々の修正をコミットしておくと、差分の確認ができたり、万が一修正ミスが発生した時でも、安心して元に戻すことができます。

5. バージョンアップ

EC-CUBE の新バージョンがリリースされましたので、バージョンアップしましょう。

git fetch origin <eccube version> コマンドで、最新のソースを取得できます。
ここでは 4.0.5 のソースを取得します。バージョン番号は適宜読み替えてください。
git fetch origin 4.0.5

From https://github.com/EC-CUBE/ec-cube
 * tag               4.0.5      -> FETCH_HEAD
この時、 git pull は使用しないのがコツです。 git pull を使用すると、予期せぬ更新が反映されてしまう場合があります。

取得した差分を適用(merge)しましょう。
git merge 4.0.5

Updating 8710496..2d2b958
Fast-forward
 .gitignore                                         |    2 +-
 .gitmodules                                        |    2 +-
 .travis.yml                                        |    9 +-
 README.md                                          |   19 +-
 app/console                                        |    1 -
 appveyor.yml                                       |   11 +-
 composer.json                                      |    7 +-
 composer.lock                                      |  912 +++++++++++-------
 docs
...snip
大量にログが出力されますが、落ち着きましょう。
もう一度、 git status で正常に適用されたか確認しましょう。
改修した本体のソースコードが上書きされていないことも確認しましょう。
git status

On branch production
nothing to commit, working directory clean
nothing to commit, working directory clean と出ていれば、大丈夫です。

composer.json や composer.lock が変更されていた場合は、以下のコマンドで vender を更新しましょう。
curl -sS https://getcomposer.org/installer | php
php ./composer.phar selfupdate --1
php ./composer.phar install --dev --no-interaction
この後、ソースコードをサーバーへアップロードすればアップグレード完了です。

データベースに変更が入っていた場合は、以下のコマンドでマイグレーションを実行しましょう
## データベースの更新を確認
bin/console doctrine:schema:update --dump-sql

## 更新がある場合はマイグレーションを実行
bin/console doctrine:schema:update --dump-sql --force
番外) 競合(コンフリクト)してしまった時は？

git merge の時に、ソースコードの修正が被ってしまい、バージョンアップの適用に失敗する場合があります。
git merge 4.0.5

Auto-merging src/Eccube/Repository/OrderRepository.php
CONFLICT (content): Merge conflict in src/Eccube/Repository/OrderRepository.php
Removing src/Eccube/Form/Type/ShoppingType.php
Removing src/Eccube/DependencyInjection/Compiler/TemplateListenerPass.php
Removing repos/.gitkeep
Removing html/user_data/.gitkeep
Removing html/template/default/assets/css/maps/style.css.map
Removing html/template/admin/assets/css/maps/bootstrap.css.map
Removing html/template/admin/assets/css/maps/app.css.map
Removing .github/workflows/action.yml
Removing .github/actions/setup-chromedriver/tsconfig.json
Removing .github/actions/setup-chromedriver/src/setup-codeception.ts
Removing .github/actions/setup-chromedriver/package.json
Removing .github/actions/setup-chromedriver/package-lock.json
Removing .github/actions/setup-chromedriver/lib/setup-codeception.sh
Removing .github/actions/setup-chromedriver/lib/setup-codeception.js
Removing .github/actions/setup-chromedriver/jest.config.js
Removing .github/actions/setup-chromedriver/docs/contributors.md
Removing .github/actions/setup-chromedriver/action.yml
Removing .github/actions/setup-chromedriver/__tests__/run.test.ts
Removing .github/actions/setup-chromedriver/README.md
Automatic merge failed; fix conflicts and then commit the result.
最後に Automatic merge failed; fix conflicts and then commit the result. という行が出たら修正が競合しています。

上記の例では、 src/Eccube/Repository/OrderRepository.php が CONFILICT となっています。

git status コマンドでも確認できます。
git status

On branch production
You have unmerged paths.
  (fix conflicts and run "git commit")

Changes to be committed:

    new file:   .devcontainer/devcontainer.json
    modified:   .dockerignore
    new file:   .editorconfig
    modified:   .env.dist
    modified:   .env.install
    new file:   .github/.htaccess

...snip

Unmerged paths:
  (use "git add <file>..." to mark resolution)

    both modified:   src/Eccube/Repository/OrderRepository.php
最後に Unmerged paths: と出ているのが、競合してしまったファイル一覧です。

src/Eccube/Repository/OrderRepository.php を開くと、競合した箇所を確認できます。
<<<<<<< で検索するとすぐに見つかります。
            $qb
<<<<<<< HEAD
                ->andWhere('o.id = :multi OR o.name01 LIKE :likemulti OR o.name02 LIKE :likemulti OR '.
                            'o.kana01 LIKE :likemulti OR o.kana02 LIKE :likemulti OR o.company_name LIKE :likemulti OR '.
                            'o.order_no LIKE :likemulti OR o.email LIKE :likemulti OR o.phone_number LIKE :likemulti OR o.message LIKE :likemulti')
=======
                ->andWhere('o.id = :multi OR CONCAT(o.name01, o.name02) LIKE :likemulti OR '.
                            'CONCAT(o.kana01, o.kana02) LIKE :likemulti OR o.company_name LIKE :company_name OR '.
                            'o.order_no LIKE :likemulti OR o.email LIKE :likemulti OR o.phone_number LIKE :likemulti')
>>>>>>> 4.0.5
                ->setParameter('multi', $multi)
                ->setParameter('likemulti', '%'.$clean_key_multi.'%')
======= より上が、アップグレード前のソースコード、下がアップグレード後のソースコードです。
この場合は、上の方を残したいので、下の方を削除して正しいソースコードに修正します。
                ->andWhere('o.id = :multi OR o.name01 LIKE :likemulti OR o.name02 LIKE :likemulti OR '.
                            'o.kana01 LIKE :likemulti OR o.kana02 LIKE :likemulti OR o.company_name LIKE :likemulti OR '.
                            'o.order_no LIKE :likemulti OR o.email LIKE :likemulti OR o.phone_number LIKE :likemulti OR o.message LIKE :likemulti')
修正ができたら、コミットしておきましょう。
git add .
git commit -m 'save production'
[production b6da7e2] save production
小々長くなってしまいましたが、こうすることで、本体のソースコードに手を入れても、比較的簡単にアップデートすることができます。
プラグインを使っていても、本体の修正と競合する問題を完全に防ぐことは難しいです。
Git をうまく活用して、開発効率と安定性を両立させましょう。

　 Tweet
Qiitaで続きを読む

投稿日：2020-12-15T18:31:10+09:00

Git Hubのチーム開発での使い方〜ブランチを切る、プルリクをあげる、マージする〜

Git Hub使い方まとめ　

Git HubのIssueに対応する作業ブランチをmasterブランチから作成　
feature
feature/add-name_column
　のように　feature/XXX　でブランチを切って作業。　

git statusで変更したファイル一覧を見て、git diffで差分確認。　

問題なければ、git add -Aして、git commit -m “MESSAGE”して　git push origin HEAD して　

GitHubのリモートブランチにpushする。　git push origin HEADというコマンドは

ブランチ名を指定しなくてもカレントブランチをリモートにpushすることが出来る。　

Pushしたブランチからプルリクエストを作成。
qiita.rb
puts 'The best way to log and share programmers knowledge.'
プルリク画面でマージを実行して完了。

git checkout master, git pull origin master,コマンドの実行。

masterブランチを更新して次のタスクに備える。

コンフリクトに遭遇することもチーム開発の醍醐味。

ボタンを押すだけでコミットできるような
ツールもあるそうですが、しっかりコマンドラインを覚えて
コマンドで作業できるようにしておいたほうが
良いと思います。

　 Tweet
Qiitaで続きを読む

投稿日：2020-12-15T13:58:43+09:00

GitHubにpushせよ

はじめに

本当にいつもいつも忘れるので戒めのメモです。

結論

いろんなやり方があると思うのですが、ぼくはこれが基本です。
作業中のブランチ名は｀master-cron｀とします。
#作業中のブランチを確認
git branch
* master-cron
  master

#ステータスを確認
git status

#addする
git add ｀*｀とか｀意図したファイル名｀

#ステータスを確認してaddされているか確認する
git status

#commitする
git commit -m "modify ファイル名"

#ステータスを確認してcommitされたことを確認する
git status

#作業中のブランチを改めて確認
git branch
* master-cron
  master

#pushする
git push origin master-cron
コンフリクトとかしたら調べて都度対応する感じですね。
もう忘れるんじゃないぞ。。

簡単ですが以上です。

　 Tweet
Qiitaで続きを読む

投稿日：2020-12-15T12:19:16+09:00

UdemyのGit講座で概念を仕組みを学んで自分用の「gitコマンド辞書」としてまとめてみた

はじめに

この記事はUdemyのGit/Githubの講座を受けて、自分用の「gitコマンド辞書」としてまとめたものです。

流れや裏側の仕組みをもっと知りたいと思う方は下の講座を受けてみてください。

『Git：はじめてのGitとGitHub』は無料ですので気軽に覗いてみることもおすすめです。

Git：もう怖くないGit！チーム開発で必要なGitを完全マスター
https://www.udemy.com/share/101WYWAEcZdF5UR3kB/

Git：はじめてのGitとGitHub
https://www.udemy.com/share/101vBkAEcZdF5UR3kB/

gitのインストール/バージョン確認(version)
git version
gitのインストール方法

Macにはデフォルトで入っているが、入ってない場合は下のURLを参考に
https://www.atlassian.com/ja/git/tutorials/install-git

gitの初期設定(config)
git config --global user.name "githubで登録したユーザーネーム"
git config --global user.email githubで登録したメールアドレス
//atomエディターの場合
git config --global core.editor "atom --wait"

//VSCodeエディターの場合
git config --global core.editor "code --wait"
git初期設定の確認(config)
git config user.name
git config user.email
git config core.editor
//いっぺんに確認したい場合
git config --list
コマンドにエイリアスをつけて短縮する(config)
//commitコマンドをciで呼び出せる
git config --global ailas.ci commit

//statusコマンドをstで呼び出せる
git config --global ailas.st status

//brachコマンドをbrで呼び出せる
git config --global ailas.br branch

//checkoutコマンドをchで呼び出せる
git config --global ailas.ch checkout
git configは設定を変えるようなコマンド

ローカルリポジトリーの新規作成(init)
git init
initializeの略。初期化。
.gitディレクトリが作成される

gitリポジトリーのコピーを作成する(clone)
git clone <リポジトリー名>
変更をステージに追加する(add)
git add <ファイル名>
git add <フォルダー名>
git add .
変更を記録する(commit)
git commit -m "<メッセージ>"

//コミットの変更内容をみることができる
git commit -v
メッセージの例 "initial commit"

現在の変更状況を確認(status)
git status
変更差分の確認(diff)
git diff
git diff <ファイル名>

//git addしたあとの変更分
git diff --staged
qコマンドで終了

変更履歴の確認(log)
git log

//１行で表示
git log --oneline

//表示するコミット数を制限する
git log -n <コミット数>
コマンドを終了するときにはqコマンド

ファイルの削除(rm)
git rm <ファイル名>
git rm -r<フォルダー名>

//gitからは消したいけどファイルを残したいとき
git rm --canched <ファイル名>
リモートリポジトリーへ送信(push)
git push origin <ブランチ名>
ファイルへの変更を取り消す(checkout)
git checkout -- <ファイル名>

git checkout -- <ディレクトリ名>

//全変更を取り消す
git checkout --.
git addした変更を取り消す(reset)
git reset HEAD <ファイル名>
git reset HEAD <ディレクトリ名>

//全変更を取り消す
git reset HEAD .
直前のコミットをやり直したいとき(--amend) ※pushしたコミットはできない
git commit --amend
リモートリポジトリを表示(remote)
git remote

//URLを表示
git remote -v
リモートリポジトリーを新規追加する(remote add)
git remote add origin <githubのリポジトリーのURL>
リモートの詳細を表示(show)
git remote show origin
リモート名の変更(rename)
git remote rename <旧リモート名> <新リモート名>
リモートの削除(rm)
git remote rm <リモート名>
リモートリポジトリから情報を取得する(fetch)
git fetch <リモート名>
リモートのコピーちょうだいって言う

ローカルとの差分を見つつ、リモートリポジトリが変更や新規ブランチをリモート追跡ブランチに渡す

リモート追跡ブランチが更新される ※リモート追跡ブランチはあくまでもリモートのブランチの状態を示すもので、ユーザー自身がブランチの内容を変更することはできない

リモートから情報を取得してマージする(pull)
git pull <リモート名> <ブランチ名>
ブランチの新規追加(branch)
git branch <ブランチ名>
ブランチの表示
git branch
ブランチの切り替え(checkout)
git checkout <既存ブランチ名>

//ブランチを新規作成して切り替える
git checkout -b <新ブランチ名>
変更履歴をマージする(merge)
git merge <ブランチ名>
mainのブランチにいるときに行う

ブランチの変更
git branch -m <ブランチ名>
ブランチの削除
git branch -d <ブランチ名>

//強制削除
git branch -D <ブランチ名>
リベースで履歴を整えた形で変更を統合する(rebase)
git rebase <ブランチ名>

//fetch + rebase
git pull --rebase
githubにプッシュしたコミットをリベースするのはダメ

タグの一覧を表示する(tag)
git tag
タグはリリースポイントに付けておくと後から変更があったときに便利

タグを作成する(tag)
git tag -a <タグ名> -m "<メッセージ>"

//軽量版
git tag <タグ名>
タグのデータを表示する(show)
git show <タグ名>
タグをリモートポジトリに送信する
git push <リモート名> <タグ名>

//タグを一斉に送信する
git push origin --tags
作業を一次避難する(stash)
git stash save
避難した作業の確認/一覧(stash list)
git stash list
避難した作業を復元(stash apply)
//最新の作業を復元する
git stash apply

//ステージの状況を復元
git stash apply --index

//特定の作業を復元
git stash apply <スタッシュ名>
避難した作業を削除(stash drop)
//最新の作業を削除する
git stash drop

//特定の作業を削除する
git stash drop <スタッシュ名>

//全作業を削除する
git stash clear
プルリクエストの手順
//mainブランチを最新の状態に更新
git pull origin main

//ブランチを作成
git checkout -b <ブランチ名>

//確認
git branch

//ファイルの変更
code .

//確認
git status

//ステージに追加
git add .

//変更をコミット
git commit -m "<コミットメッセージ>"

//GitHubへプッシュ
git push origin <ブランチ名>

//ブランチに移動
git checkout main

//確認
git status


GitHub上でプルリクエストを送る
　　　　　　↓
　　　　コードレビュー
　　　　　　↓
　　プルリクエストをマージ
　　　　　　↓
　　　ブランチを削除

//最新の情報に更新
git pull origin main

//ローカルのブランチを削除
git branch -d <ブランチ名>

//確認
git branch
もう少し、、ってときに

gitのチュートリアル
https://www.atlassian.com/ja/git/tutorials

GitHub Docs
https://docs.github.com/ja

　 Tweet
Qiitaで続きを読む

20201215のGitに関する記事は5件です。

Gitと連携するツールとしてのVim

はじめに

GitコマンドとVim

コミットメッセージをVimで入力する

Gitの差分をVimで見る

TigとVim組み合わせてインタラクティブにGit操作しよう

Tigでみた差分からVimを開く

Tigで差分を見てからrebaseしよう

Tigの差分をVimで見る

最後に

EC-CUBEのバージョンアップを見据えたカスタマイズ方法2020年度版

1. github から EC-CUBE のソースコードを clone します

2. 管理用のブランチを作成

3. 差分の確認

4. 修正内容の保存

5. バージョンアップ

番外) 競合(コンフリクト)してしまった時は？

Git Hubのチーム開発での使い方〜ブランチを切る、プルリクをあげる、マージする〜

GitHubにpushせよ

はじめに

結論

UdemyのGit講座で概念を仕組みを学んで自分用の「gitコマンド辞書」としてまとめてみた

はじめに

gitのインストール/バージョン確認(version)

gitのインストール方法

gitの初期設定(config)

git初期設定の確認(config)

コマンドにエイリアスをつけて短縮する(config)

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

gitリポジトリーのコピーを作成する(clone)

変更をステージに追加する(add)

変更を記録する(commit)

現在の変更状況を確認(status)

変更差分の確認(diff)

変更履歴の確認(log)

ファイルの削除(rm)

リモートリポジトリーへ送信(push)

ファイルへの変更を取り消す(checkout)

git addした変更を取り消す(reset)

直前のコミットをやり直したいとき(--amend) ※pushしたコミットはできない

リモートリポジトリを表示(remote)

リモートリポジトリーを新規追加する(remote add)

リモートの詳細を表示(show)

リモート名の変更(rename)

リモートの削除(rm)

リモートリポジトリから情報を取得する(fetch)

リモートから情報を取得してマージする(pull)

ブランチの新規追加(branch)

ブランチの表示

ブランチの切り替え(checkout)

変更履歴をマージする(merge)

ブランチの変更

ブランチの削除

リベースで履歴を整えた形で変更を統合する(rebase)

タグの一覧を表示する(tag)

タグを作成する(tag)

タグのデータを表示する(show)

タグをリモートポジトリに送信する

作業を一次避難する(stash)

避難した作業の確認/一覧(stash list)

避難した作業を復元(stash apply)

避難した作業を削除(stash drop)

プルリクエストの手順

もう少し、、ってときに

日付別

タグ一覧