What's New Qiita

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

  • 投稿日：2020-06-04T19:38:07+09:00

GitHubでCloneでもForkでもなくレポジトリの複製が欲しい

GitHubでCloneでもForkでもなくレポジトリの複製が欲しい。
そんな時の方法。

1. GitHub上で新規レポジトリを作成

普通に New Repository から作っちゃってOK。
仮にこれを user/new-repository とする。

2. ベアレポジトリの作成

ターミナルでコピー元のレポジトリ（仮に user/old-repository とする）をベアクローンする。
（ベアとは作業ディレクトリを持たないレポジトリのこと）

git clone --bare https://github.com/user/old-repository.git

（SSH使ってる方は https://github.com を git@github.com: に変えてください）

3. 新しいレポジトリにミラープッシュする

cd old-repository.git
git push --mirror https://github.com/user/new-repository.git

4. 確認&ベアレポジトリの削除

GitHubで新しいレポジトリにファイルが複製されているのを確認したら、ベアレポジトリを削除する。

cd ../
rm -rf old-repository.git

以上。

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

【Git】『ブランチ間の差分ファイルのみ』をZIPファイルにまとめて取得する。

メモとして残します。

■やり方

 git archive ブランチ名 --format=zip -o ./diff-files.zip  `git diff --name-only --diff-filter=d コミット1Rev コミット2Rev`

注意！

ブランチ名はあくまで未来の方のブランチを指定すること。
masterとdevelopでの比較の場合は、基本的にはdevelopが未来のリリースのため、欲しいのは未来のリソースになります。
git archive master...にすると、masterブランチ基準の差分になるため、古いリソースでの差分ファイルが取得されてしまいます。

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

Git リモートブランチの一覧を表示する

目的

  • 毎回若干忘れるのでこの機会にまとめる

実施環境

  • ハードウェア環境
項目 情報
OS macOS Catalina(10.15.5)
ハードウェア MacBook Pro (13-inch, 2020, Four Thunderbolt 3 ports)
プロセッサ 2 GHz クアッドコアIntel Core i5
メモリ 32 GB 3733 MHz LPDDR4
グラフィックス Intel Iris Plus Graphics 1536 MB
  • ソフトウェア環境
項目 情報 備考
Git バージョン 2.26.2 Homebrewにて導入実施方法はこちら→Mac ネイティブのGitからHomebrewでインストールしたGitに切り替えた話

コマンド例

  • リモートブランチのブランチ名を出力するコマンドを下記に記載する。

    $ git branch -r

  • リモート、ローカル問わず全てのブランチ名を出力するコマンドを下記に記載する。

    $ git branch -a
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-06-04T15:20:50+09:00

【Git】修正したファイル差分の一覧を取得する。

メモとして残します。

■やり方

git diff --name-status コミット1revision コミット2revision

削除したファイルを除きたい場合は--diff-filter=dオプションを付ければOK。
　

■おまけというより、追記

日本語というより、全角文字はエスケープされた状態で表示されるため、下記のコマンドを実行して、gitの設定を変更しましょう。

git config --global core.quotepath false
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-06-04T14:42:46+09:00

git github gitlab 入門

git github gitlab 入門

本記事について

  • git自体というより、いわゆるソース管理としてgitを使うor使っていますという開発現場で手を動かせる（お話ができる）ための調査まとめ
  • なので、gitのコマンド詳細が知りたいとかいう方はそっ閉じしてください。
  • 以下のような人向け
    • git未経験者
    • gitの流れは何となく知ってるけど具体的にどういうツールを使ってどういう操作を行うのか知りたい
    • gilab？github？git？何が違うの？っていう人
    • svnとの違いがわからない（メリット）
  • 自身について
    • SE8年目。最近はもっぱら上流寄り。
    • バージョン管理はSVNのみ使用経験あり
    • gitに関しては実務では経験なし

前提条件

  • リポジトリサービスとしてはgithubもしくはgitlabを使用
    • gitlabの場合はオンプレに自前でgitlabをたててもgitlab.comの無料サービスを使用してもよい
  • クライアント端末はWindows10端末
  • gitクライアントとしてsourcetreeをインストール（なんでもよい）

事前準備（前提）

  1. github（gitlab）にアカウントを作成する
    1. お試し用のアカウントやリポジトリが既存でない場合はgithubアカウントを複数（最低２個）作っておくとチームプレイを体感しやすい
  2. リモートリポジトリを作成する（ソースorファイルのアップロード）
  3. githubでリモートリポジトリへのアクセス権のあるユーザを作成する（管理者に権限を付与してもらう）
  4. ローカルPCにsourcetree（などのクライアントGUIツール）をインストールする

全体図（流れ）

  1. （user1）クライアントPCでリモートリポジトリをクローンする（アクセス権のあるgithubユーザで実施すること）
  2. （user1）自分用の作業ブランチを作成する
  3. （user1）追加修正が完了したら作業ブランチにコミットする
  4. （user1）リモートリポジトリに反映したいタイミングで作業ブランチをリモートリポジトリにプッシュする
  5. （user1）github上で作業ブランチ→masterブランチへのプルリクエスト（プルリク）を作成する
  6. （admin）：プルリクを確認し、masterブランチへのマージを行う

2020-06-04_14h07_01.png

sourcetreeの使い方、githubの使い方にいて

  • 以下参考URLを参照

※その他後日追記予定

参考URL

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

git github gitlab 入門（フロー理解編）

git github gitlab 入門

本記事について

  • git自体というより、いわゆるソース管理としてgitを使うor使っていますという開発現場で手を動かせる（お話ができる）ための調査まとめ
  • なので、gitのコマンド詳細が知りたいとかいう方はそっ閉じしてください。
  • 以下のような人向け
    • git未経験者
    • gitの流れは何となく知ってるけど具体的にどういうツールを使ってどういう操作を行うのか知りたい
    • gilab？github？git？何が違うの？っていう人
    • svnとの違いがわからない（メリット）
  • 自身について
    • SE8年目。最近はもっぱら上流寄り。
    • バージョン管理はSVNのみ使用経験あり
    • gitに関しては実務では経験なし

前提条件

  • リポジトリサービスとしてはgithubもしくはgitlabを使用
    • gitlabの場合はオンプレに自前でgitlabをたててもgitlab.comの無料サービスを使用してもよい
  • クライアント端末はWindows10端末
  • gitクライアントとしてsourcetreeをインストール（なんでもよい）

事前準備（前提）

  1. github（gitlab）にアカウントを作成する
    1. お試し用のアカウントやリポジトリが既存でない場合はgithubアカウントを複数（最低２個）作っておくとチームプレイを体感しやすい
  2. リモートリポジトリを作成する（ソースorファイルのアップロード）
  3. githubでリモートリポジトリへのアクセス権のあるユーザを作成する（管理者に権限を付与してもらう）
  4. ローカルPCにsourcetree（などのクライアントGUIツール）をインストールする

全体図（流れ）

  1. （user1）クライアントPCでリモートリポジトリをクローンする（アクセス権のあるgithubユーザで実施すること）
  2. （user1）自分用の作業ブランチを作成する
  3. （user1）追加修正が完了したら作業ブランチにコミットする
  4. （user1）リモートリポジトリに反映したいタイミングで作業ブランチをリモートリポジトリにプッシュする
  5. （user1）github上で作業ブランチ→masterブランチへのプルリクエスト（プルリク）を作成する
  6. （admin）：プルリクを確認し、masterブランチへのマージを行う

2020-06-04_14h07_01.png

sourcetreeの使い方、githubの使い方にいて

  • 以下参考URLを参照

※その他後日追記予定

参考URL

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

Git操作:タグとブランチ

研究室ではタグとブランチを使ったルールがあるのでその概要を示す．

タグ

Gitではcommitする毎にその時々のファイルの状態を保存している(snapshot機能)．タグはそれに名前を付ける機能である．
例えば前の状態に戻すときにタグ名をもとにもとに戻したりできる．

タグについて詳しくはここを見るがよい．

コマンド

git tag -a [tag名] -m "comment"
  • 最新のcommitしたものにtag名を付与．
git tag [option]
  • タグを表示
  • option
    • なし
      • 既存のタグ一覧を表示．
    • -l "検索文字列"
      • 検索文字列に指定したタグの検索・表示．
git show [タグ名]
  • 指定したタグ名の詳細を表示．

ブランチ

Gitにてファイルのバージョン管理を行っていると「安定版」と「機能どんど追加していく版」に分けたくなったりする．バージョンの流れを必要に応じていくつか作り，何か変になったら安定版の流れにすぐ戻せたりできると楽である．このようなバージョンの流れをブランチ(branch)という．

Gitではプロジェクトを最初に作った時にmasterという名前のブランチが作成され，masterブランチ上でバージョン管理が開始される．そして任意の時点で新しいブランチを作ることができ(名前は自由)，また統合できる．統合とは，二つのブランチを一つにすることで，それぞれのブランチで行った作業の結果を一つにまとめることである．もちろん全く異なる進化をとげて内容が全く違うブランチを統合することは困難を極める．しかし一つのプロジェクトから始まっているので基本的には同じ目的のものを作っているので，一般に多少の手間で統合するメリットを大きく得られる．

branch.png

コマンド

注意: branchのコマンド操作をする場合には，commitを行ったうえでbranchのコマンドを実行すること．

git branch [option]
  • ブランチを見る，作成する．
  • option
    • なし
      • ブランチ一覧を表示．
    • ブランチ名
      • 指定したブランチ名で新しいブランチを作成．
    • -d ブランチ名
      • 指定したブランチを削除．commitしていなかったらエラー．
    • -D ブランチ名
      • 指定したブランチを削除．commitしてなくても強制的に削除．
git checkout [option] [branch name]
  • ブランチを切り替える．
  • option
    • なし
      • 作業するブランチをbranch nameに変更．
    • -b
      • 指定したbranch nameで新しいブランチを作成し，そのブランチに変更．git branch [branch name] && git checkout [branch name]と同等．
git merge [branch name]
  • 複数のブランチを統合する．現在のブランチが統合する側で，branch nameが統合される側となる．
  • 例: develブランチの内容をmasterブランチに取り込む場合
    • git checkout master # masterブランチにしておく
    • git merge devel
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-06-04T09:14:41+09:00

fatal: 'origin/hoge_branch' is not a commit and a branch 'hoge_branch' cannot be created from it

特定のリモートブランチをcheckoutしたくてこれをやるとこのエラーになる。

git checkout -b hoge_branch origin/hoge_branch
fatal: 'origin/hoge_branch' is not a commit and a branch 'hoge_branch' cannot be created from it

# しばし悩んで、ローカルはリモートブランチ名を知らないことに気づく
git fetch

git branch -a
* master
  remotes/origin/hoge_branch

# これでチェックアウトできる
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-06-04T01:21:19+09:00

単刀直入にgit rebaseのsquash

備忘録です。

git rebase -i for squash

  1. git rebase -i HEAD~N or git rebase -i [commitHash]
    指定した数字によってHEADコミットから古い順で選ばれたコミットの数が決まります。直にコミットのハッシュを指定することも可能です。指定した一番古いコミットが選ばれたコミットに含まれます。

  2. そうしたらこのようなまとめたコミットのVIMのファイルが出てくる。

    pick d94e78 Prepare the workbench for feature Z     --- older commit
pick 4e9baa Cool implementation 
pick afb581 Fix this and that  
pick 643d0e Code cleanup
pick 87871a I'm ready! 
pick 0c3317 Whoops, not yet... 
pick 871adf OK, feature Z is fully implemented      --- newer commit

  3. そこで一番古いコミットを選択し（PICK）、他のコミットをその一番古いコミットにまとめるわけです。

    pick d94e78 Prepare the workbench for feature Z     --- older commit
squash 4e9baa Cool implementation 
squash afb581 Fix this and that  
squash 643d0e Code cleanup
squash 87871a I'm ready! 
squash 0c3317 Whoops, not yet... 
squash 871adf OK, feature Z is fully implemented      --- newer commit

  4. 次に出てくるテキストファイルでコミットのメッセージを編集することができます。（僕の場合一番新しいコミットのメッセージを残すだけ）

  5. 成功するためには必ずコミット履歴を書き換える必要になってくるのでここでgit push --forceを使います。（originに）

  6. 以上です。

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

【備忘録】GitとGithubの基本知識

本記事は上から読んでいくだけで、GitとGithubの基本知識が学べるようになっています！
少しでもお役に立てれば幸いです！

また本記事ではGitとGithubを使用するので、「Gitのインストール」と「Githubのアカウント作成」を事前にしていただく必要があります。是非以下の記事も参考にしてみてください！
https://qiita.com/moonbass630/items/2084edb250feef88f15f

1.ひとりで開発編！

まずはGithubでリモートリポジトリを作成しましょう！
今回は「git-test」という名前で作成したいと思います。
image.png

ちなみに「リモートリポジトリはGithubで管理」、「ローカルリポジトリはGitで管理」というイメージです。
image.png

保存したら以下のようにリモートリポジトリのURLをコピーしましょう。
image.png

ではまず、以下のコマンドを実行し、リモートリポジトリをコピーしてローカルに同じリポジトリを作成してみましょう。「git clone」の後ろには先ほどコピーしたリモートリポジトリのURLを貼り付けてください。
（今回はデスクトップ上にフォルダを作成したいので、デスクトップまで移動してからコマンドを実行します。）

$ git clone https://github.com/moonbass630/git-test.git

image.png

以下のように「git-test」というフォルダが作成されていればOKです！
image.png

次にcloneしたフォルダ内で「file1.txt」、「file2.txt」を作成します。
今回はVSCodeを使用していきます。
image.png

保存した後に以下のコマンドを実行してみましょう。
こちらはGitの状態を見るためのコマンドです。

$ git status

赤字のファイル名が見えますが、
これは作成したファイルがまだGitに管理されていない状態を表しています。
要はローカルリポジトリに保存されていない状態です。
image.png

そんな時はまず以下のコマンドを実行します。

$ git add ファイル名

以下のコマンドを実行することで、作成した「file1.txt」がGitの管理下に移ります。
これをステージングと言います！
image.png

実際にステージングされたファイルは緑色で表示されます。
image.png

またカレントディレクトリの全てのファイルをGitの管理対象にするのが以下のコマンドになります。
便利なので覚えておきましょう。

$ git add .

実行すると「file2.txt」もステージングされたのが分かると思います。
image.png

いよいよファイルをリポジトリに保存したいと思います。
以下のコミットコマンドを実行すると保存できます。「メッセージ」にはメモ感覚で、コミットの内容をメモすることができます。今回は「初めてのコミット」としておきます。

$ git commit -m "メッセージ"

image.png

以下のようなメッセージが出ればOKです！
「git status」で確認してみてもファイル名が表示されていないことが分かるかと思います。
image.png

では次に「file1.txt」を修正し、「git status」で確認してみましょう。
image.png

「file1.txt」が修正されていることをgitが検知していることが分かると思います。
これはgitが以前にコミットしたファイルの履歴をコミットしたタイミングで保存しているからです。
image.png

では続けてステージングとコミットを実施します。
image.png

ちなみに以下のコマンドでgitの履歴を確認することができます。

$ git log

image.png

では次に「リモートリポジトリ」にローカルリポジトリでコミットした内容をアップロードしましょう。
image.png

ご覧のようにgithubを確認しても、まだ何も起きておりません。
空のリモートリポジトリ「git-test」があるだけでです。
image.png

アップロードするコマンドは以下になります。
「origin」はリモートサーバーを意味します。

$ git push origin

以下のようなメッセージが出ればOKです！
image.png

ではgithubを確認してみましょう！
image.png

「2commits」をクリックするとコミットの履歴が見れます。
色々自分で確認してみてください！
image.png

ちなみに今、こういう状態になっています。
image.png

2.共同開発編！

では次に以下のように他のデベロッパー「B子」も作業するために、「git clone」を実行しましょう。
image.png

今回はパソコンが２台ないので、同じパソコンにB子のローカルリポジトリを作成します。
ローカルリポジトリの名前は変更も可能なので、分かりやすいように「git-b」にしようと思います。
コマンドは以下のようになります。

$ git clone https://github.com/moonbass630/git-test.git git-b

image.png

以下のように「git-b」のフォルダができていればOK!
image.png

ちなみに今、こういう状態になっています。
image.png

ではB子で「git log」を実行してみましょう。
（※「git-b」フォルダに移動して、gitコマンドを実行してください。）
以下のようにB子からでもA太郎のコミット履歴を見ることができます。
image.png

次にB子から「file1.txt」を編集してコミットしてみましょう。
image.png

「file1.txt」には「３回目の編集です。」と追記して保存しておきます。
image.png

「git add」と「git commit」を実行します。
image.png

「git push」もしてあげましょう。
image.png

コマンドはこんな感じです。

$ git add .
$ git commit -m "３回目のコミット"
$ git push origin

では次にA太郎もリモートリポジトリにある最新のファイルを手に入れましょう。
前回はローカルリポジトリを作成する際に「git clone」を使用しましたが、
こちらは新規にリポジトリを作成する場合に使用します。
今回は既に「git-test」リポジトリはあるので、別のコマンドになります。

$ git pull origin

image.png

「git pull」実行前
image.png

「git pull」実行後
image.png

試しに「git log」で確認してみたいと思います。
B子の３回目のコミットが確認できるかと思います。
image.png

3.共同開発編！（応用）

ここからはケーススタディ形式を少し取り入れて考えていきましょう！

A太郎は「システムG」を運用している。ある日「システムG」の修正が必要になり、
B子に依頼したとしましょう！
image.png

しかしこれまでのようにB子が本番環境で使われるソースファイルを「git clone」して修正し、「git push」してしまうとA太郎が確認できないまま本番環境で使われるソースファイルが書き変わってしまいます。もしB子の修正に誤りがあるとかなり危険です。
image.png

そこで「ブランチ」という機能を使用します！
ブランチの説明ですが、まずこれまでにリモートリポジトリへ「git push」した時のコミット履歴を見てみましょう。
image.png

「初めてのコミット」から「３回目のコミット」まで枝のように繋がっていますね！
そうこれがブランチなんです！そして左上にある「master」と記載されいるのがブランチ名となります。
「ブランチ」を一言で表現すると、「コミットの履歴を管理しているもの」って感じでしょうか。

以上を踏まえた上で、以下の流れに沿ってB子には作業を進めてもらいましょう。
image.png

①まず本番環境で使われるソースファイルが入っているリモートリポジトリをmasterブランチから「git clone」コマンドを実行し、ローカルリポジトリを作成しましょう。
②次にローカルリポジトリ内で「git checkout」というコマンドを実行し、
図のように新しく「develop」と言うブランチを開発用として作成します。
③これによりB子は修正、コミットを繰り返しても「master」ブランチの中身は書き変わらず、
「develop」の中で修正とコミット履歴を管理することができます。
④修正した「develop」ブランチにあるソースファイルを「git push」します。
⑤するとリモートリポジトリには「develop」ブランチと修正したファイルが保存されます。

では①「git clone」はもう実行したとして、②の「git checkout」からやっていきましょう！
image.png

まず以下のコマンドで自分が今どのブランチで作業しているか確認しましょう。

$ git branch

「master」ブランチにいることが確認できたと思います。
image.png

次に以下のコマンドでブランチ「develop」ブランチの作成と、作業する場所を「develop」ブランチに変更しましょう。

これは「git checkout -b」で「develop」というブランチ名で「master」ブランチからブランチを切るという意味になります。

$ git checkout -b develop master

「git branch」で確認し、以下のようになっていればOKです！
image.png

また「master」ブランチに作業場所を変えたい場合は、以下のコマンドで戻れます。

$ git checkout master

以下のようになればOKです！
では「git checkout develop」を実行し「develop」ブランチに戻っておきましょう。
image.png

次に③「修正」、「コミット」と④「git push」を実施してみましょう！
image.png

「file1.txt」に修正を加えます。
image.png

次に「ステージング」と「コミット」をしましょう。

$ git add .
$ git commit -m "５回目のコミット"

image.png

そして次に以下の「git push」コマンドでローカルリポジトリにある「develop」ブランチをリモートリポジトリにアップロードしてあげましょう。

$ git push origin develop

このようなメッセージが出ればOKです！
image.png

これで以下のように、現在リモートリポジトリもローカルリポジトリのような状態になっているはずです。
ではGithubから⑤リモートリポジトリを確認してみましょう！
image.png

「develop」が作成されていることが確認できます！
image.png

以下のようにB子の修正「４回目のコミット」が確認できます！
image.png

では次にA太郎の作業を確認していきましょう！

image.png

①A太郎はB子が修正したソースファイルを確認しなければならない、言わばViewer（ビューワー）なので、「git pull」でローカルリポジトリに「develop」ブランチをダウンロードします。
②もし修正に問題がなければ、ローカルリポジトリ内で「master」と「develop」を統合します。これをmerge（マージ）すると言います。
③最後にmergeした「master」を「git push」でリモートリポジトリにアップロードして、このプロジェクトは完了になります！

ではまず①「git pull」を実行しローカルリポジトリに「develop」ブランチをダウンロードしましょう。
その後に「git log」で中身を確認したいので「git checkout」で「develop」ブランチに移動しましょう。
image.png

$ git pull origin
$ git checkout develop

以下のように最終的に「develop」ブランチに移動できればOKです！
（※実は「git pull」した時はまだローカルリポジトリには「develop」ブランチはできていません。今回は深く説明はしないので、「追跡ブランチ」で調べてみてください！）
image.png

「git log」で確認すると、B子さんの修正「４回目のコミット」が確認できます。
image.png

いよいよ、②「git merge」の作業に移ります。
image.png

マージする時は、マージ先（master）のブランチに移動しないいけないので、「git checkout」で移動しておきましょう。
image.png

そして以下の「git merge」コマンドを実行してください。

$ git merge develop

これでマージ完了です！
image.png

念のために「git log」で確認してみましょう。
「master」ブランチも４回目のコミットができていることが確認できます。
image.png

補足ですが、以下赤枠のブランチは「４回目のコミット」までの履歴があることを意味しています。
HEAD -> master　：　「master」ブランチ（HEADは今いるブランチを示している）
origin/develop　：　リモートでポジトリの「develop」ブランチ
develop　：　「develop」ブランチ

そして青枠のリモートリポジトリの「master」ブランチのみまだ「３回目のコミット」で履歴が止まっています。

なのでローカルの最新の「master」ブランチをリモートリポジトリの「master」ブランチへ③「git push」してあげましょう！
image.png

$ git push origin master

image.png

Githubで確認してみましょう！
image.png

これで一連の流れは終わりです！！
お疲れ様でした！！

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

日付別

タグ一覧