What's New Qiita

20200917のGitに関する記事は10件です。

  • 投稿日：2020-09-17T23:27:37+09:00

[win10] Gitのalias設定時に、記述ミスで追跡ファイル全解除された.. 時の対処

定時後にgit bashでalias整理してたんですが、若干焦ったので書きます〜
まあこんなパターンないかも。。

経緯から

Gitのaliasを整理しようと下記コマンドを打ちました。

$ git config --global --edit

エディタでaliasを追加しました。
例ですがこんな感じでアンダーバーを使用しました。↓

[alias]
    ss_l = stash list

ローカル内のGit追跡対象だったファイルが、全て追跡解除..

になってました。いつもの開発ファイルのあるディレクトリに移動してもgitコマンドが使えず。

「もっかい編集して直したろ！」

と思い、もう一度初めに記載したコマンドを打ったのですが.. そう、gitコマンドが使えないw

なんとなく思い当たったのは、alias名にアンダーバーを使ったこと。
（エディタで書いてた時、周りとテキストの色が違った気がする..）

aliasを設定しているファイル(.gitconfig)が見つかったので、そいつを再編集

// 僕の場合は下記にありました。(みんなそう？)
$ cd /c/Users/{ユーザー名}
$ ls -a1
~
~
.gitconfig

// もっかい編集してアンダーバーを取り除き保存。
$ vi .gitconfig

ほんで無事、元の追跡状態に戻すことができました。

以上ですー。

追記

本記事投稿後に似たようなことをmacOSでやらかしました。

macではこちらに.gitconfigファイルがありました。↓

$ ~/.gitconfig

参考：http://www.curict.com/item/fe/fe45741.html

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-17T23:26:06+09:00

新人エンジニアが見返すべきGitコマンド　【随時更新】

いま自分がどこのブランチにいるか確認

$ git branch

これでブランチを作成&移動までできる。

$ git checkout -b [ブランチ名]

いま自分がいないブランチを削除することができる。

$ git branch -D [ブランチ名]

これで他のリポジトリのデータを取得する。リモートのデータを取得したければ、通常は[origin]でいける。

$ git fetch [リポジトリ]

だれかのブランチで作業したい・・・

$ git checkout [誰かが作業していたブランチ名]

これで直前のコミットを削除することができる。間違ってmasterにpushしてしまったときに使える。

$ git reset --hard HEAD^

PUSH。originはリモートリポジトリのこと。ブランチ名は作業しているブランチ名を入力すればいい。→このあとGIthubやGitlabでプルリクエストを作成する。

$ git push origin [ブランチ名]

変更したファイルをステージングさせる。という認識ではいるけど、奥が深そう。

$ git add -A

コミットするときに簡単にメッセージを入力できるやつ。

$ git commit -m “[コミットメッセージを書く]"

作業ツリーのファイルすべてをステージする

$ git add .

Git 管理対象のファイルの変更、削除をすべてステージする。（新規ファイルは無視。）

$ git add -u
$ git add --update

および作業ツリーのファイルをすべてステージする。引数なしで、すべての作業ツリーのファイルを反映。

$ git add --all
$ git add -A

これで、bookmark.rbだけをステージングエリアに追加できる。

$ git add api/app/models/bookmark.rb

git addに関しての参考記事
https://www-creators.com/archives/4939

直前のコミットを取り消したいとき。 —hardとすることにより、変更した内容も取り消される。

この—hardの部分を —softにすると変更はそのままで、コミットだけ取り消される。

$ git reset --hard HEAD^

ローカルに最新のリーモートのmasterを取り込む

$ git pull origin master

★常にmasterブランチを新しい状態で作業をすることが大事、、、

そのあとにcheckoutで作業ブランチに移動する。そして

$ git merge origin master

をすると最新のmasterブランチの変更を取り込むことができる。
するとコンフリクトが起こる→コマンド＋クリックでコンフリクトしているファイルを開ける。
どの変更を残すか、それとも両方の変更を適用するかを決めることができる。

随時更新していきます。
間違っている点などあればご指摘お願いします。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-17T21:43:42+09:00

vscodeで表示されるアルファベットと数字は何を意味しているのか？

vscodeで表示されるアルファベットのフラグの意味

vscodeを使っているときにファイルの右側に表示されるアルファベットの意味について。

下図のA、C、M、Uとかのこと。

image.png

それぞれの意味

Gitにおけるファイルの状態を表している。

アルファベット 単語 意味
A added 新規追加
M modified 変更あり
U untracked gitが未追跡(新規作成、add前)
D deleted 削除済み
C conflict コンフリクト発生中
R renamed ファイル名変更済み
S submodule サブモジュール

git status -sで表示される内容とは一部異なる。
git status -sのアルファベットの意味一覧



git commitして、git statusで何も表示されない状態になれば、アルファベットは消える。

$ git status
On branch master
nothing to commit, working tree clean

image.png


数字の表す意味

アルファベットの左側に表示される数字（アルファベットがない場合は数字のみ）は、そのファイルで発生している問題箇所の数を表している。

例えばHTMLファルであれば、タグが間違ってたり、終端タグのみ書かれているなど、

jsファイルであれば、functoinの中身にエラーがある場合など。

image.png


  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-17T21:18:13+09:00

git status -sで表示されるアルファベットの意味。それぞれの状態一覧

git status -sで表示されるアルファベットの意味

git statusに短縮形表示オプションの「-s」(--short)をつけた時に表示されるフラグの意味について。

vscodeで表示されるアルファベットのフラグにも通じるところがある。（※gitと一部同じ意味だが、vscode固有のものも存在する）

どれのこと？

下記のようにgit status -sを実行すると表示される、カラフルな大文字のアルファベットのこと。

image.png

各ファイル毎に表示され、ファイルの状態が一目でわかるようになっている。

何を表しているのか？

状態は二文字（XY）で表される構造になっている。

基本的には
・右側（Y）がステージ前（git add前）の状態、
・左側（X）がステージ後、コミット前の状態
を表している。

ローカルレポジトリ 
    ↑ commit
ステージ（インデックス）【←左側】
    ↑ add
ワークツリー 【←右側】

ぱっと見で分かりやすいように色分けされている。
・赤色：add前（ステージ前）
・緑色：add済み（コミット前）


アルファベットの意味

各アルファベット毎に意味を持っている。
頻出するのは、A、M、D、？の４つ。

Uはコンフリクトが発生したときに表示される。

アルファベット 単語 意味
A added 新規ファイル。gitが新規に追跡したファイル
M modified 変更があったファイル
D deleted 削除されたファイル
R renamed 名前変更
C copied コピー
U unmerged マージしていない
? untracked 未追跡。gitが認識していない。
! ignored 無視


状態一覧

X Y 意味
? ? gitが認識していない。新規作成し、git add前のファイル。
M 変更したが、git addしてないファイル
A 新規作成し、git addされたファイル。コミット前
M M 変更しgit addした後に、また変更したファイル（add前）。
D git認識済みのファイルが削除された。（add前）
D ステージのファイルが削除された(add後、commit前）
A D ステージに追加したファイル(A)が消され、addしてない状態。
U U コンフリクト。それぞれのブランチで変更されている
A A コンフリクト。それぞれのブランチで新たに追加されている

他にもある。詳細はgit公式のgit stateコマンドページ参照。

image.png


  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-17T20:04:47+09:00

Gitサブモジュールとは？git submoduleの使い方。

Gitサブモジュールとは？git submoduleの使い方。

大きめのプロジェクトで使用されることのある便利なサブモジュールについて。

サブモジュールを使うことで、他のリモートレポジトリの内容を丸ごと追加することができる。

目次

  1. サブモジュールとは？
  2. サブモジュールを追加する方法
  3. サブモジュール追加内容の確認
  4. サブモジュールの更新
  5. サブモジュールのあるレポジトリのクローン


サブモジュールとは？

Gitには、大元となるレポジトリに他のレポジトリを追加できる機能がある。

この後から追加したレポジトリをサブモジュールと呼ぶ。

完全に別のPJなので、現在のプロジェクトの中身やログをきれいに保てる。管理が楽ということも大きなメリット。



▼githubのサブモジュールの例

サブモジュールは青字で表示される。
下図だと、calculator, modal, textCounterがサブモジュール。

image.png


サブモジュールを追加する方法

現在推進中のPJにサブモジュールを追加するのは簡単。
追加したいレポジトリのURLを指定して、「git submodule add」を実行する。

git submodule add <URL>

  • リモートレポジトリのURLを指定
  • レポジトリ名のディレクトリが作成される
  • .gitmoduleというファイルも作成される
  • git addされた状態になる（commitの手前）


▼実例

リモートレポジトリ（slideshow）を追加する

submoduleの追加
$ git submodule add https://github.com/xxx/slideshow.git

Cloning into '/Users/projects/test2/slideshow'...
remote: Enumerating objects: 82, done.
remote: Counting objects: 100% (82/82), done.
remote: Compressing objects: 100% (56/56), done.
remote: Total 82 (delta 27), reused 78 (delta 23), pack-reused 0
Unpacking objects: 100% (82/82), done.

ステージの状態になっているので、コミットすれば完了。簡単。


サブモジュール追加内容の確認

▼submodule add後（コミット前）の状態確認

状態の確認
$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    modified:   .gitmodules
    new file:   slideshow

git statusで確認すると、新規ファイル（ディレクトリ）slideshowと.gitmodulesがステージに追加されていることがわかる。

.gitmodules
[submodule "slideshow"]
    path = slideshow
    url = https://github.com/xxx/slideshow.git

.gitmodulesにはサブモジュールのパスとURL情報が保存されている。



▼追加内容をdiffで確認する
上記ではgit statusと実際のファイルで確認したが、git diffで変更点だけをさくっと確認してみる。

ステージにあるファイルと比較するため、--cachedをつける。

加えて、サブモジュールの変化点だけを見るため--submoduleもつける。

git diff --cached --submodule

$ git diff --cached --submodule
diff --git a/.gitmodules b/.gitmodules
index e94e555..714291b 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -1,3 +1,3 @@
+[submodule "slideshow"]
+       path = slideshow
+       url = https://github.com/xxx/slideshow.git
Submodule slideshow 0000000...885fd4b (new submodule)

.gitmodulesにレポジトリが追加されていることがわかる。


サブモジュールの更新

リモートのサブモジュールで更新する場合は、--remoteをつけてsubmoudle updateコマンドを実行する。

git submodule update --remote

サブモジュールを指定しない場合、PJ内のすべてのサブモジュールが更新される。



▼特定のサブモジュールのみ更新

特定のサブモジュールのみ更新したい場合は、末尾でサブモジュールを指定する。

git submodule update --remote <サブモジュール名>



▼補足
「git submodule update --remote <サブモジュール>」の内容は以下手順を実行したのと同じ。

  1. サブモジュールのディレクトリに移動
  2. git fetch
  3. git merge origin/master


サブモジュールのあるレポジトリのクローン

サブモジュールのあるレポジトリをクローンする場合は--recrusiveをつける。

これがないと、サブモジュールのフォルダは作成されるが、中身が空の状態となってしまう。

・git clone --recursive <URL>

recrusiveは再起的の意味。このオプションをつけることで、大元のレポジトリのみではなく、その配下のサブモジュールの中身も取ってくる指示になる。


--recrusiveなしでクローンした場合

通常のcloneでフォルダの中身がコピーされなかった場合は以下手順で後から修正可能。

(1)ローカルのsubmodule設定ファイルを初期化。(2)プロジェクトからデータを取得。(3)コミット。

  1. git submodule init
  2. git submodule update
  3. git commit -m "コメント"

以上で、サブモジュールの中身が入る。


  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-17T16:11:23+09:00

自分用メモ　gitについて

はじめに

gitとは

ソースコードのバージョン管理するツール。
システム開発では複数の開発者によってソースコードがどんどん書き変わっていく。そのためいつどこで？最新バージョンはどれか？などを管理することができるツール

gitは分散方バージョン管理システムの一つで、元々Linuxのソースコードを効果的に管理するために開発された。
gitでは、ファイルの状態を好きな時に更新履歴として保存しておくことでできるため、一度編集したファイルを過去の状態に戻したり、編集箇所の違いだけを表示したりすることができる。
また古いファイルを元に編集したファイルで、他人の編集した最新ファイルを上書きしようとすると、サーバにアップロードした時に警告が出るようになる。そのため他人の編集内容を上書きするようなことはない。

github
gitとgithubの関係は,
gitはソースコード管理するためのツール
githubはgitを利用した開発者を支援するwebサービスになる。

注意）githubに関してはサービス名なのでgithub以外にも存在する。しかしエンジニアの業界ではデフォルトと言えるほど、githubが使われている。

リポジトリ

ファイルやディレクトリに状態を記録する場所。保存された状態は、内容の変更履歴として格納されている。
変更履歴を管理したいディレクトリをリポジトリの管理下に置くことで、そのディレクトリ内部のファイルやディレクトリの変更履歴を記録することができる。

リモートとローカルリポジトリ

gitのリポジトリは２種類ある。

リモートリポジトリ
複数人で共有するためのリポジトリ。

ローカルリポジトリ
ユーザー１人が利用するためのリポジトリ。

リポジトリをリモートとローカルに分けることで、自分自身での変更、更新が大元のリモートリポジトリに影響されなくなる。
作業をローカルリポジトリで行い、変更、編集が完了したら、リモートリポジトリにアップロードすることができる。

コミット

ファイルやディレクトリの追加・変更をリポジトリに記録するにはコミットという操作を行う。
コミットを実行すると、リポジトリに中では、前回コミットしたときの状態から現在に状態までの差分を記録したコミットと呼ばれるものが作成される。

上記のような時系列で内容を知ることができる。
これらのコミットにはそれぞれ計算された重複されることのない英数字40桁の名前がつけられている。この名前をしてすることでリポジトリの中からコミット指定できる。

コミット時にはメッセージ記入が必須となっている。
その中に変更内容や履歴などを記入しておく。後から見てわかるようにしておく。

ワークツリーとインデックス

ワークツリーは作業しているディレクトリのこと
インデックスはリポジトリにコミットする準備をするための場所

gitではコミットを実行した時にワークツリーから直接リポジトリ内に状態を記録するのではなく、その間に設けられているインデックスの設定された状態を記録するようになっている。そのためコミットでファイルの状態を記録するためには、まずインデックスにファイルを登録する必要がある。
インデックスを挟むことで、ワークツリーの必要ないファイルを含まずにコミットを行ったり、ファイルの一部の変更だけをインデックスに登録してコミットすることができる。

Push

リモートリポジトリで自分の手元のローカルリポジトリの変更履歴を共有する。

Clone

リモートリポジトリに内容を丸々ダウンロードしてきて、別のマシンにローカルリポジトリとして作成できる。

Pull

リモートリポジトリから最新の変更履歴をダウンロードしてきて、自分のローカルリポジトリにその内容を取り込む。

注意）自分がpullしてきた後で他の人がpushをしてリモートリポジトリを更新してしまっていた場合には、自分のpushが拒否されてしまう。
この場合はマージという作業を行なって、他の履歴での変更を取り込むまで自分のpushは拒否するようにする。
これはこのままマージを行わず、pushしてしまうと他の人がpushした変更内容が失われてしまうため。

マージでは、Gitが変更箇所を自動的に統合する
同じ箇所を変更したいた場合は、統合できない。

ブランチ

ブランチとは、履歴の流れを分岐して記録していくためのもの。
分岐したブランチは他のブランチの影響を受けないため、同じリポジトリの中で複数の変更を同時に進めていくことができる。
また分岐したブランチは他のブランチとマージすることで１つにまとめ直すことができる。

image.png

他のメンバーの作業の影響を受けないように通常は、メインのブランチから自分の作業用ブランチを作成してそこで作業を行う。
その作業を完了したら、メインのブランチに自分の作業用ブランチから変更を取り込んでいく。
この作業にはきちんと履歴を残していくことで、問題が発生した場合に原因となる変更箇所の調査や対策を行うことが容易になる。

image.png

注意）リポジトリに最初のコミットを行うと、Gitはmasterという名前のブランチを作成する。

統合ブランチ

いつでもリリース版が作成可能なようにしておくためのブランチ。また、下記のトピックブランチの分岐元として使用する。
そのため安定した状態に保っておく必要がある。
変更を行う時はトピックブランチを作成して作業を行うことが多い。
通常masterブランチを統合ブランチとして使用する。

トピックブランチ

機能追加やバグ修正といったある課題に関する作業行うために作成するブランチ。複数の課題に関する作業を同時行う場合は、その数だけトピックブランチが必要。作業が完了したら、統合ブランチに取り込む。

ブランチに切り替え

作業するブランチを切り替えるには、チェックアウトという操作を行う。
行うと移動先のブランチ内の最後のコミットの内容がワークツリー展開される。
チェックアウトを行ったコミットは、移動後のブランチに対して追加されるようになる。

HEAD
現在使用しているブランチのこと
デフォルトではmasterブランチ

注意）ここでのブランチの切り替え失敗やそれに対しての対策方法などもあるがここでは幾分、まだまだ理解不足のため省かせていただきます。

ブランチの統合

トピックブランチから統合ブランチに統合する方法がmergeとrebaseを使うに種類がある

merge

複数の履歴の流れを合流させることができる。

トピックブランチを作っておからmasterブランチの内容が変更されていなければmaterブランチをそのトピックブランチに移動すればいいだけになる。

しかしトピックブランチを作ってからmasterブランチの内容が変更されていればmasterブランチとそのトピックブランチの変更内容を一つにまとめる必要がある。(merge)

image.png

マージの実行時に、non fast-forwardマージというオプションを指定することで、fast-forwardマージが可能な場合でも新しくマージコミットを作成してコミットさせることもできる。
履歴の参照、作業の特定が容易になる。
※fast-forwardはmasterブランチがトピックブランチ作成時から変更されていなかった時、

rebase

rebaseとするとそのトピックブランチがmasterブランチの後ろにつけられる。一本化される。
rebaseしただけだとmasterの先頭の位置はそのまま。そのためmasterからk地ピックブランチをマージして、トピックブランチまで移動する。

違い

merge
変更内容の履歴はそのまま残るが、履歴が複雑になる。
rebase
履歴は単純になるが、元のコミットから変更される。そのため、元のコミットが動かない状態にしてしまうことがある。

image.png

image.png

最後に

以上で終わりになりますが、幾分素人故数多く至らない点などあると思いますが、その際はアドバイスしていただけると幸いです。
このgitに関しての知識は必ず必要になってくると思うのでしっかりと支えこなせるようにしておきたいと思います。

参照

Gitを使ったバージョン管理

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-17T15:49:07+09:00

【Git】リモートレポジトリからデータを取得する。clone, fetch, pullの違い

【Git】リモートレポジトリからデータを取得する。clone, fetch, pullの違い

リモートレポジトリからデータを取得するコマンド、clone, fetch, pullのそれぞれの違いを理解する。

一番大きく異なるのは取ってきたデータの保存先。

  • cloneは新たに専用のディレクトリを作成
  • fetchは現在のフォルダ内に新たにブランチを作成
  • pullは現在のブランチに追加する。

また、fetch, pullで必須となるリモート追跡ブランチと、頻出する上流ブランチの理解も必要。


目次

  1. git clone
    1. git cloneの使い方
    2. 実行内容の確認
    3. ローカルレポジトリのクローンも可能
  2. git fetch
    1. git fetchの使い方
    2. リモートレポジトリ名の確認
    3. ブランチの確認
    4. リモート追跡ブランチとは？
    5. ローカルのブランチ名を指定してfetch
  3. git pull
    1. git pullの使い方
    2. 引数の省略
    3. 上流ブランチとは？
    4. 上流ブランチの設定方法（pull --set-upstream）
    5. 上流ブランチの確認（branch -vv）
    6. git pullの裏側の処理内容
  4. 上流ブランチの設定方法
    1. --set-upstream
    2. -u
    3. .git/configファイルに追記
  5. 上流ブランチを活用するコマンド


git clone

指定したリモートレポジトリをローカルに丸ごとコピーするコマンド。

既存のプロジェクトを使って、新たにプロジェクトを立ち上げる場合に使う。

  • どこのブランチで実行するかは関係ない
  • 新たに専用のディレクトリを作成
    • デフォルトのディレクトリ名はリモートのレポジトリ名
    • ディレクトリを指定することも可能
  • リモートレポジトリのショートカット名にoriginを自動設定
  • masterブランチを自動作成


git cloneの使い方

・git clone URL
・git clone URL ディレクトリパス

ディレクトリ名を指定してクローン
$ git clone git@github.com:xxx/git-test.git clone-test

Cloning into 'clone-test'...
remote: Enumerating objects: 89, done.
remote: Counting objects: 100% (89/89), done.
remote: Compressing objects: 100% (40/40), done.
remote: Total 89 (delta 46), reused 80 (delta 38), pack-reused 0
Receiving objects: 100% (89/89), 8.39 KiB | 2.80 MiB/s, done.
Resolving deltas: 100% (46/46), done.



既にディレクトリが存在する場合はエラーになる。

既にフォルダがある場合はエラー
$ git clone git@github.com:xxx/git-test.git
fatal: destination path 'git-test' already exists and is not an empty directory.

この場合は下記で対応する。
- コマンドを実行するディレクトリを変更
- ディレクトリ名を指定してコマンドを実行


実行内容の確認

・masterブランチの自動生成
・originの自動設定
・ファイルの確認
・ログの確認

ブランチの確認
$ git branch
* master
リモートレポジトリの確認
$ git remote -vv
origin  git@github.com:xxx/git-test.git (fetch)
origin  git@github.com:xxx/git-test.git (push)
ファイルの確認
$ ls
README.md           style.css
index.html          test.txt
script.js
ログの確認
$ git log --oneline --graph
*   7f02744 (HEAD -> master, origin/master, origin/HEAD) Merge branch 'ft2'
|\
| * d6eb207 add h3 again
* | 07ea837 add h4
|/
* 788f5b1 remove all marks
*


ローカルレポジトリのクローンも可能

URLの代わりに、ディレクトリパスを指定すればローカルのレポジトリも複製できる。

$ git clone ../git-test
Cloning into 'git-test'...
done.

単純にディレクトリをコピーしただけなので以下と同じ。

cp -r  ../git-test git-test


git fetch

取ってくるを意味するfetch。

gitでは、リモートレポジトリのブランチのデータを丸ごと取ってくるコマンド。

リモートレポジトリのブランチの状態をそのまま再現できる。

cloneはブランチを区別しない
pullは取ってきたブランチを強制的にマージしてしまう

  • リモート名で取得（URLは使えない）
  • 取得するブランチの指定も可能
  • ディレクトリはgitレポジトリである必要がある
  • ブランチは、remotes/リモート名/ブランチ名でコピーされる


git fetchの使い方

gitレポジトリで実行する（git init済みの親ディレクトリ）

・git fetch <リモート名>
・git fetch <リモート名> <ブランチ名>

第２引数でブランチを指定しない場合は、リモートレポジトリの全てのブランチをとってくる。


リモートレポジトリ名の確認

リモート名の確認
#リモートレポジトリが設定されているか確認
$ git remote -v


#ない場合は登録
$ git remote add <リモート名> URL



▼fetchの実行例
リモート名originのデータをとってくる場合。

fetch
$ git fetch origin

remote: Enumerating objects: 89, done.
remote: Counting objects: 100% (89/89), done.
remote: Compressing objects: 100% (40/40), done.
remote: Total 89 (delta 46), reused 80 (delta 38), pack-reused 0
Unpacking objects: 100% (89/89), done.
From github.com:xxx/git-test
 * [new branch]      ft1        -> origin/ft1
 * [new branch]      master     -> origin/master
 * [new branch]      test       -> origin/test

リモートレポジトリのブランチに対応するブランチとして、ローカルにorigin/ft1、origin/master、origin/testが作成された。

ブランチの確認

git branch -a
　┗ -a(-all)でリモート追跡ブランチも表示する

ブランチの確認
$ git branch -a
  remotes/origin/ft1
  remotes/origin/master
  remotes/origin/test

リモート追跡ブランチは赤字で表示される。

リモート追跡ブランチとは？

git branch -aで表示される冒頭にremotesがついたブランチたち。

remotes/<リモートレポジトリ名>/<ブランチ名>の形でローカルに保存されている。

つまり、特定のリモートレポジトリのブランチを同期したローカルのブランチという意味。

英語ではremote-tracking branchesと表記される。



■リモート追跡ブランチでできること

  • git fetchしたときに、対応するレポジトリ名のブランチに自動で上書きする。

  • ローカルにコピーした時点でのリモートブランチのデータが確認できる。


ローカルのブランチ名を指定してfetch

デフォルトのfetchではリモート追跡ブランチを作成するのみだったが、とってきたブランチで新たなローカルブランチを作成することも可能。

git fetch <リモート名> <リモートブランチ名>:<ローカルブランチ名>

ローカルに指定したリモートの追跡ブランチが存在する場合は、指定したローカルブランチのみ作成。

どちらもない場合は、(1)追跡ブランチと(2)指定したローカルブランチの２つを作成。

$ git fetch origin master:l-master

remote: Enumerating objects: 70, done.
remote: Counting objects: 100% (70/70), done.
remote: Compressing objects: 100% (31/31), done.
remote: Total 70 (delta 41), reused 62 (delta 34), pack-reused 0
Unpacking objects: 100% (70/70), done.
From github.com:xxx/git-test
 * [new branch]      master     -> l-master
 * [new branch]      master     -> origin/master

ローカルブランチl-masterと、リモートブランチorigin/masterを作成。


ブランチの確認
$ git branch -a
  l-master
  remotes/origin/master

fetchしたブランチが作成されている。


git pull

fetch後によく行われる処理(merge)をセットにした便利コマンド。

つまり、リモートレポジトリ更新内容をローカルに取ってきて(fetch)し、現在のブランチに統合(merge)する。

  • どこのブランチで実行するかが重要
  • リモートレポジトリ名とブランチ名を指定
  • リモート追跡ブランチを作成/更新（fetch）
  • リモート追跡ブランチを現在のブランチにマージ（merge）
  • 上流ブランチを設定することで引数の省略が可能

mergeまで行うので、cloneやfetchと異なりコンフリクトが発生する可能性がある。


git pullの使い方

git pull <リモート名>　<ブランチ名>

▼実例
リモートレポジトリ（名前:origin）のmasterのデータを現在のブランチにマージする。

pullの実行
$ git pull origin master

From github.com:xxx/git-test
 * branch            master     -> FETCH_HEAD
 * [new branch]      master     -> origin/master

・ローカルにリモート追跡ブランチがない場合は新規作成
origin/master

・作成したリモート追跡ブランチにFETCH＿HEADのポインタを移動
　┗ mergeするときに参照するため

ブランチの確認
$ git branch -a
* master
  remotes/origin/master
ログの確認
$ git log --oneline --graph
*   7f02744 (HEAD -> master, origin/master) Merge branch 'ft2'
|\
| * d6eb207 add h3 again
* | 07ea837 add h4
|/
* 788f5b1 remove all marks

リモートレポジトリのデータが追加されている。


引数の省略

現在のローカルブランチに上流ブランチを設定すると、引数を省略して実行することができる。

git pull

上流ブランチとは？

上流ブランチとは、ローカルブランチ設定したリモート追跡ブランチのこと。

▼上流ブランチとリモート追跡ブランチのイメージ

リモート
　┗　リモート名(origin)：ブランチ(master) 
　　　　　　　　　↑
ローカル　　　　　↑ 
　┗　リモート追跡ブランチ(origin/master) 
     　　　　　　↑　上流ブランチ
　┗　現在のブランチ(master)

・リモートレポジトリを追跡するのがリモート追跡ブランチ。通常、ローカルブランチから独立している。（git branchで表示されない）

・リモート追跡ブランチとローカルブランチは紐づけることができる。

・紐付けた場合、リモート追跡ブランチが上流ブランチとなる。

・上流ブランチは各ローカルブランチ毎に設定可能。


上流ブランチの設定方法（pull --set-upstream）

git pullのオプション「--set-upstream」で指定したリモートのブランチに対応する、リモート追跡ブランチを上流ブランチとして設定できる。

git pull --set-upstream <リモート名> <リモートブランチ名>

　┗ git pullの初回で引数を省略することはできない。

上流ブランチの設定
$ git push --set-upstream origin master

Branch 'master' set up to track remote branch 'master' from 'origin'.


上流ブランチの確認（branch -vv）

git branch -vvコマンドで上流ブランチを確認することができる。（vは２つ必要）

上流ブランチの確認
$ git branch -vv
* master 7f02744 [origin/master] 
  topic  7f02744

ローカルブランチに上流ブランチが設定されている場合は、カッコ[ ]内に、対象のリモート追跡ブランチが表示される。


git-pullを試す
$ git pull

remote: Enumerating objects: 20, done.
remote: Counting objects: 100% (20/20), done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 20 (delta 4), reused 20 (delta 4), pack-reused 0
Unpacking objects: 100% (20/20), done.
From github.com:xxx/git-test
 * [new branch]      ft1        -> origin/ft1
 * [new branch]      master    -> origin/master

引数なしでgit pullが実行できた。
リモートに実行中以外のブランチがある場合、すべてのリモート追跡ブランチが作成される。

ただし、mergeはせずfetchのみ。新たにブランチが自動作成されることもない。



▼（参考）エラー：上流ブランチが設定されていない場合

追跡情報（上流ブランチ）が設定されていない場合
$ git pull

There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

    git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

    git branch --set-upstream-to=<remote>/<branch> master

・git pull <remote> <branch>
通常通り、リモート名とブランチ名を指定するか、または

・git branch --set-upstream-to=<remote>/<branch> masterで上流ブランチをセットしろとの示唆。


git pullの裏側の処理内容

git pullは下記コマンドと同じことをしている。

git pull <リモート名> <リモートブランチ名>
  1. git fetch <リモート名> <リモートブランチ名>
  2. git merge FETCH_HEAD


git pull --rebase

git pullのオプションで「--rebase」をつけると、mergeをrebaseに書き換えることができる。

git pull --rebase <リモート名> <リモートブランチ名>
  1. git fetch <リモート名> <リモートブランチ名>
  2. git checkout <FETCH_HEAD>
  3. git rebase <pullを実行したローカルブランチ>


上流ブランチの設定方法

git pullで上流ブランチの作成方法を述べたが、fetchとpushでも同様の方法で上流ブランチが設定できる。

コマンドオプション以外にも、configファイルに追記・書き換えする方法もある。

オプションで指定

--set-upstream

pull, fetch, pushのいずれでも使用可能。

・git pull --set-upstream <リモート名> <リモートブランチ名>

・git fetch --set-upstream <リモート名> <リモートブランチ名>

・git push --set-upstream <リモート名> <リモートブランチ名>


-u

git pullのみショートオプションの「-u」が使える。

・git push -u <リモート名> <リモートブランチ名>


.git/configファイルに追記

configファイルに追記する場合は、対象のリモートブランチの(1)remote、(2)mergeの２つの値を設定する必要がある。

(1) $ git config branch.<ローカルブランチ名>.remote <リモートブランチ名>

(2)$ git config branch.<ローカルブランチ名>.merge refs/heads/<リモートブランチ名>

実例
$ git config branch.topic.remote origin
$ git config branch.topic.merge refs/heads/master

configファイルの確認

#エディタで開く
vim .git/config
.git/config
[branch "topic"]
    remote = origin
    merge = refs/heads/master

configファイルのtopicブランチに、remoteとmergeがそれぞれ追加されている。

今回はコマンドで追記したが、エディタで直接編集してもOK。


上流ブランチを活用するコマンド

現在のローカルブランチに上流ブランチの設定ができれば、git pull, fetch, push時に引数を省略して実行することができる。

・git pull
・git fetch
・git push

使うときは、どのブランチでコマンドを実行しているかに注意が必要。


  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-17T15:49:07+09:00

【Git】リモートレポジトリからデータを取得する。「clone, fetch, pullの違い」と「リモート追跡ブランチと上流ブランチとは？」

【Git】リモートレポジトリからデータを取得する。「clone, fetch, pullの違い」と「リモート追跡ブランチと上流ブランチとは？」

リモートレポジトリからデータを取得するコマンド、clone, fetch, pullのそれぞれの違いを理解する。

一番大きく異なるのは取ってきたデータの保存先。

  • cloneは新たに専用のディレクトリを作成
  • fetchは現在のフォルダ内に新たにブランチを作成
  • pullは現在のブランチに追加する。

また、fetch, pullで必須となるリモート追跡ブランチと、頻出する上流ブランチの理解も必要。


目次

  1. git clone
    1. git cloneの使い方
    2. 実行内容の確認
    3. ローカルレポジトリのクローンも可能
  2. git fetch
    1. git fetchの使い方
    2. リモートレポジトリ名の確認
    3. ブランチの確認
    4. リモート追跡ブランチとは？
    5. ローカルのブランチ名を指定してfetch
  3. git pull
    1. git pullの使い方
    2. 引数の省略
    3. 上流ブランチとは？
    4. 上流ブランチの設定方法（pull --set-upstream）
    5. 上流ブランチの確認（branch -vv）
    6. git pullの裏側の処理内容
  4. 上流ブランチの設定方法
    1. --set-upstream
    2. -u
    3. .git/configファイルに追記
  5. 上流ブランチを活用するコマンド


git clone

指定したリモートレポジトリをローカルに丸ごとコピーするコマンド。

既存のプロジェクトを使って、新たにプロジェクトを立ち上げる場合に使う。

  • どこのブランチで実行するかは関係ない
  • 新たに専用のディレクトリを作成
    • デフォルトのディレクトリ名はリモートのレポジトリ名
    • ディレクトリを指定することも可能
  • リモートレポジトリのショートカット名にoriginを自動設定
  • masterブランチを自動作成


git cloneの使い方

・git clone URL
・git clone URL ディレクトリパス

ディレクトリ名を指定してクローン
$ git clone git@github.com:xxx/git-test.git clone-test

Cloning into 'clone-test'...
remote: Enumerating objects: 89, done.
remote: Counting objects: 100% (89/89), done.
remote: Compressing objects: 100% (40/40), done.
remote: Total 89 (delta 46), reused 80 (delta 38), pack-reused 0
Receiving objects: 100% (89/89), 8.39 KiB | 2.80 MiB/s, done.
Resolving deltas: 100% (46/46), done.



既にディレクトリが存在する場合はエラーになる。

既にフォルダがある場合はエラー
$ git clone git@github.com:xxx/git-test.git
fatal: destination path 'git-test' already exists and is not an empty directory.

この場合は下記で対応する。
- コマンドを実行するディレクトリを変更
- ディレクトリ名を指定してコマンドを実行


実行内容の確認

・masterブランチの自動生成
・originの自動設定
・ファイルの確認
・ログの確認

ブランチの確認
$ git branch
* master
リモートレポジトリの確認
$ git remote -vv
origin  git@github.com:xxx/git-test.git (fetch)
origin  git@github.com:xxx/git-test.git (push)
ファイルの確認
$ ls
README.md           style.css
index.html          test.txt
script.js
ログの確認
$ git log --oneline --graph
*   7f02744 (HEAD -> master, origin/master, origin/HEAD) Merge branch 'ft2'
|\
| * d6eb207 add h3 again
* | 07ea837 add h4
|/
* 788f5b1 remove all marks
*


ローカルレポジトリのクローンも可能

URLの代わりに、ディレクトリパスを指定すればローカルのレポジトリも複製できる。

$ git clone ../git-test
Cloning into 'git-test'...
done.

単純にディレクトリをコピーしただけなので以下と同じ。

cp -r  ../git-test git-test


git fetch

取ってくるを意味するfetch。

gitでは、リモートレポジトリのブランチのデータを丸ごと取ってくるコマンド。

リモートレポジトリのブランチの状態をそのまま再現できる。

cloneはブランチを区別しない
pullは取ってきたブランチを強制的にマージしてしまう

  • どこのブランチで実行するかは基本関係ない
  • リモート名を使う（事前設定必要。URLは使えない）
  • 取得するブランチの指定も可能
  • ディレクトリはgitレポジトリである必要がある
  • ブランチは、remotes/リモート名/ブランチ名でコピーされる
  • コピー先のローカルブランチを指定することもできる


git fetchの使い方

gitレポジトリで実行する（git init済みの親ディレクトリ）

・git fetch <リモート名>
・git fetch <リモート名> <ブランチ名>

第２引数でブランチを指定しない場合は、リモートレポジトリの全てのブランチをとってくる。


リモートレポジトリ名の確認

リモート名の確認
#リモートレポジトリが設定されているか確認
$ git remote -v


#ない場合は登録
$ git remote add <リモート名> URL



▼fetchの実行例
リモート名originのデータをとってくる場合。

fetch
$ git fetch origin

remote: Enumerating objects: 89, done.
remote: Counting objects: 100% (89/89), done.
remote: Compressing objects: 100% (40/40), done.
remote: Total 89 (delta 46), reused 80 (delta 38), pack-reused 0
Unpacking objects: 100% (89/89), done.
From github.com:xxx/git-test
 * [new branch]      ft1        -> origin/ft1
 * [new branch]      master     -> origin/master
 * [new branch]      test       -> origin/test

リモートレポジトリのブランチに対応するブランチとして、ローカルにorigin/ft1、origin/master、origin/testが作成された。

ブランチの確認

git branch -a
　┗ -a(-all)でリモート追跡ブランチも表示する

ブランチの確認
$ git branch -a
  remotes/origin/ft1
  remotes/origin/master
  remotes/origin/test

リモート追跡ブランチは赤字で表示される。

リモート追跡ブランチとは？

git branch -aで表示される冒頭にremotesがついたブランチたち。

remotes/<リモートレポジトリ名>/<ブランチ名>の形でローカルに保存されている。

つまり、特定のリモートレポジトリのブランチを同期したローカルのブランチという意味。

英語ではremote-tracking branchesと表記される。



■リモート追跡ブランチでできること

  • git fetchしたときに、対応するレポジトリ名のブランチに自動で上書きする。

  • ローカルにコピーした時点でのリモートブランチのデータが確認できる。


ローカルのブランチ名を指定してfetch

デフォルトのfetchではリモート追跡ブランチを作成するのみだったが、とってきたブランチで新たなローカルブランチを作成することも可能。

git fetch <リモート名> <リモートブランチ名>:<ローカルブランチ名>

ローカルに指定したリモートの追跡ブランチが存在する場合は、指定したローカルブランチのみ作成。

どちらもない場合は、(1)追跡ブランチと(2)指定したローカルブランチの２つを作成。

$ git fetch origin master:l-master

remote: Enumerating objects: 70, done.
remote: Counting objects: 100% (70/70), done.
remote: Compressing objects: 100% (31/31), done.
remote: Total 70 (delta 41), reused 62 (delta 34), pack-reused 0
Unpacking objects: 100% (70/70), done.
From github.com:xxx/git-test
 * [new branch]      master     -> l-master
 * [new branch]      master     -> origin/master

ローカルブランチl-masterと、リモートブランチorigin/masterを作成。


ブランチの確認
$ git branch -a
  l-master
  remotes/origin/master

fetchしたブランチが作成されている。


git pull

fetch後によく行われる処理(merge)をセットにした便利コマンド。

つまり、リモートレポジトリ更新内容をローカルに取ってきて(fetch)し、現在のブランチに統合(merge)する。

  • どこのブランチで実行するかが重要
  • リモートレポジトリ名とブランチ名を指定
  • リモート追跡ブランチを作成/更新（fetch）
  • リモート追跡ブランチを現在のブランチにマージ（merge）
  • 上流ブランチを設定することで引数の省略が可能

mergeまで行うので、cloneやfetchと異なりコンフリクトが発生する可能性がある。


git pullの使い方

git pull <リモート名>　<ブランチ名>

▼実例
リモートレポジトリ（名前:origin）のmasterのデータを現在のブランチにマージする。

pullの実行
$ git pull origin master

From github.com:xxx/git-test
 * branch            master     -> FETCH_HEAD
 * [new branch]      master     -> origin/master

・ローカルにリモート追跡ブランチがない場合は新規作成
origin/master

・作成したリモート追跡ブランチにFETCH＿HEADのポインタを移動
　┗ mergeするときに参照するため

ブランチの確認
$ git branch -a
* master
  remotes/origin/master
ログの確認
$ git log --oneline --graph
*   7f02744 (HEAD -> master, origin/master) Merge branch 'ft2'
|\
| * d6eb207 add h3 again
* | 07ea837 add h4
|/
* 788f5b1 remove all marks

リモートレポジトリのデータが追加されている。


引数の省略

現在のローカルブランチに上流ブランチを設定すると、引数を省略して実行することができる。

git pull

上流ブランチとは？

上流ブランチとは、ローカルブランチ設定したリモート追跡ブランチのこと。

▼上流ブランチとリモート追跡ブランチのイメージ

リモート
　┗　リモート名(origin)：ブランチ(master) 
　　　　　　　　　↑
ローカル　　　　　↑ 
　┗　リモート追跡ブランチ(origin/master) 
     　　　　　　↑　上流ブランチ
　┗　現在のブランチ(master)

・リモートレポジトリを追跡するのがリモート追跡ブランチ。通常、ローカルブランチから独立している。（git branchで表示されない）

・リモート追跡ブランチとローカルブランチは紐づけることができる。

・紐付けた場合、リモート追跡ブランチが上流ブランチとなる。

・上流ブランチは各ローカルブランチ毎に設定可能。


上流ブランチの設定方法（pull --set-upstream）

git pullのオプション「--set-upstream」で指定したリモートのブランチに対応する、リモート追跡ブランチを上流ブランチとして設定できる。

git pull --set-upstream <リモート名> <リモートブランチ名>

　┗ git pullの初回で引数を省略することはできない。

上流ブランチの設定
$ git push --set-upstream origin master

Branch 'master' set up to track remote branch 'master' from 'origin'.


上流ブランチの確認（branch -vv）

git branch -vvコマンドで上流ブランチを確認することができる。（vは２つ必要）

上流ブランチの確認
$ git branch -vv
* master 7f02744 [origin/master] 
  topic  7f02744

ローカルブランチに上流ブランチが設定されている場合は、カッコ[ ]内に、対象のリモート追跡ブランチが表示される。


git-pullを試す
$ git pull

remote: Enumerating objects: 20, done.
remote: Counting objects: 100% (20/20), done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 20 (delta 4), reused 20 (delta 4), pack-reused 0
Unpacking objects: 100% (20/20), done.
From github.com:xxx/git-test
 * [new branch]      ft1        -> origin/ft1
 * [new branch]      master    -> origin/master

引数なしでgit pullが実行できた。
リモートに実行中以外のブランチがある場合、すべてのリモート追跡ブランチが作成される。

ただし、mergeはせずfetchのみ。新たにブランチが自動作成されることもない。



▼（参考）エラー：上流ブランチが設定されていない場合

追跡情報（上流ブランチ）が設定されていない場合
$ git pull

There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

    git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

    git branch --set-upstream-to=<remote>/<branch> master

・git pull <remote> <branch>
通常通り、リモート名とブランチ名を指定するか、または

・git branch --set-upstream-to=<remote>/<branch> masterで上流ブランチをセットしろとの示唆。


git pullの裏側の処理内容

git pullは下記コマンドと同じことをしている。

git pull <リモート名> <リモートブランチ名>
  1. git fetch <リモート名> <リモートブランチ名>
  2. git merge FETCH_HEAD


git pull --rebase

git pullのオプションで「--rebase」をつけると、mergeをrebaseに書き換えることができる。

git pull --rebase <リモート名> <リモートブランチ名>
  1. git fetch <リモート名> <リモートブランチ名>
  2. git checkout <FETCH_HEAD>
  3. git rebase <pullを実行したローカルブランチ>


上流ブランチの設定方法

git pullで上流ブランチの作成方法を述べたが、fetchとpushでも同様の方法で上流ブランチが設定できる。

コマンドオプション以外にも、configファイルに追記・書き換えする方法もある。

オプションで指定

--set-upstream

pull, fetch, pushのいずれでも使用可能。

・git pull --set-upstream <リモート名> <リモートブランチ名>

・git fetch --set-upstream <リモート名> <リモートブランチ名>

・git push --set-upstream <リモート名> <リモートブランチ名>


-u

git pullのみショートオプションの「-u」が使える。

・git push -u <リモート名> <リモートブランチ名>


.git/configファイルに追記

configファイルに追記する場合は、対象のリモートブランチの(1)remote、(2)mergeの２つの値を設定する必要がある。

(1) $ git config branch.<ローカルブランチ名>.remote <リモートブランチ名>

(2)$ git config branch.<ローカルブランチ名>.merge refs/heads/<リモートブランチ名>

実例
$ git config branch.topic.remote origin
$ git config branch.topic.merge refs/heads/master

configファイルの確認

#エディタで開く
vim .git/config
.git/config
[branch "topic"]
    remote = origin
    merge = refs/heads/master

configファイルのtopicブランチに、remoteとmergeがそれぞれ追加されている。

今回はコマンドで追記したが、エディタで直接編集してもOK。


上流ブランチを活用するコマンド

現在のローカルブランチに上流ブランチの設定ができれば、git pull, fetch, push時に引数を省略して実行することができる。

・git pull
・git fetch
・git push

使うときは、どのブランチでコマンドを実行しているかに注意が必要。


  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-17T12:44:29+09:00

GitHubのリポジトリを移行

すぐに浮かんだ方法

$ rm -rf .git
$ git init
# GitHubでリポジトリを作ってから
$ git remote add origin https://github.com/ユーザーID/リポジトリ名.git
$ git push origin master

この方法でも移行できますが、それまでの編集履歴は全て消えてしまいます。

ちゃんと調べた

以下の2つの記事に書いてある内容を組み合わせればいけそう。

手順

  • 移行元のリポジトリにアクセスしSettingsページを開く
  • ページ下部の「DangerZone」内Transferをクリック
  • 移行先のuser名 or organition名、現在のリポジトリ名を入力
  • 必要に応じてorganization内のユーザーのアクセス権を設定
  • ローカルのgit remoteを差し替え
$ git remote set-url origin https://github.com/user_name_or_organization_name/project_name.git

注意点

  • 移譲元と移譲先、両方のリポジトリの管理者でないといけない
  • リポジトリのURLが変わってしまうので、デプロイ用ツール等の設定変更が必要な場合がある
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-17T12:17:30+09:00

SourceTreeのターミナルから作業ツリー内の変更を全破棄、未追跡を全削除、メモ

Unityをアップデートしたら差分が山ほど出た

全部を破棄しようとして作業ツリー内をたくさん選択すると
SourceTreeが固まるのでコマンドラインからクリーンする。
同じく未追跡のファイルを全部削除しようとして全選択してから削除しようとすると固まるので
コマンドラインからクリーンする。

こちらの記事を参考にしました。
https://awesome-linus.com/2019/05/13/git-clean-untracked-files-delete/

■ターミナルを開く
　SourceTreeを開く→メニューの右上のターミナルアイコンがあるのでクリック

■コマンドラインから破棄対象ファイルを全削除

git checkout .

■コマンドラインから未使用ファイルを全削除

git clean -df
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧