今さら聞けないGit　

【超わかる！】100MB以上のファイルをGithubにPushする方法

# 状況
アセット追加でGitにあげれんくなった！！

(その他、容量の大きいデータでも応用できます。)
黒い壁に呪文入力するのが苦手な人にもオススメ！！！！！！(俺)

# 実行環境
開発: Unity 2022.3.22f1
ツール: Github Desktop、Git LFS

# 結論。Git LFSを使って仮想的に実現させる。

### 仕組み 【従来】

Git hub <100MB超えてるから受け取れないよ！！ ↑ ↑ 100MB File ↑ Client < 送るよ～ ## アップロード時【Git LFS】 Git hub < 軽いから受け取れる！！(データそのものは持っていないが存在自体は在る) ↑ ↑ 存在を証明するバイナリファイルを送る ↑ Git LFS < 預かるよ！！【バイナリファイルに変換】 ↑ ↑ 100MB File ↑ Client < 送るよ～ ## データ受け取り時【Git LFS】 Git hub ↓ ↓ ↓ 他Client <普段のデータは受け取れるけど、例のファイルは受け取れない！ Git Hubには存在しているのに、直でRawでダ

Git LFSのリポジトリへの導入手順

# はじめに
GitHubのリポジトリの上限である5GB（推奨は1GB以下）を超える原因になりうるようなファイルを出力することになったので，Git LFSを利用することにしました．
ところが，想定外にエラー対処に時間が掛かったのと，遭遇したエラーの対処法を記述した記事が見当たらなかったので，その際の対処法を備忘録的にまとめたいと思います．

# TL; DR
– エラー内容
– `git lfs track `で指定したが`git lfs ls-files`で確認できない
– 対処法
– `git rm –cached `

# Git LFSとは
Gitはその時点でのスナップショットによって履歴を保存するため，大きなファイル（GitHubでは500MB以上）を扱うには不向きです．

そこで登場するのがGit LFSで，Git LFSは大きなファイル本体をGitリポジトリに保存せず，代わりのGit LFS専用のリモートサーバに保存します．Gitリポジトリは，そのファイルのポインタ情報のみを管理することで，リポ

【UE5】チーム開発におけるGitの運用例

# はじめに
弊社ではソースコントロールツールにPerforceを使用していました。
Perforceでソースを管理しながら、1つのプロジェクトのversion1.0.0をリリースするまでやってきましたが、リリースしたタイミングでGitへの移行を開始しました。
Perforceをやめた理由としては、
* ドキュメントが少ない
* 無料枠の範囲で使用していたが、規模が拡大した時のコストが許容できない
* Depotがただのプロジェクトバックアップのような使い方になっていた
* ワークフローを最適にすることができなかった（これは完全に自分のせいですが、ドキュメントの少なさ、コミュニティの規模も関係しているかと思います）

以上が移行するきっかけになった大きな理由です。
弊社にはインターンシップのメンバーもいるのですが、教育の一環として「キャリア形成的にもGitの使い方を知っておいた方がいいのでは」という思いが頭の片隅にあったことも要因です。

チームでGitを使い始めて3ヶ月ほど経ちましたが、Gitのコミュニティの大きさ、ロジカルなワークフローに基づいた堅牢な開発環境に触れることで、改めて

GitHub 返信テンプレート を設定して、レビュー意図を明確に伝えよう！


## 概要

レビューコメントを残す際にラベルやアラートを付けるどのような指摘なのかがより明確に伝わり、対応するべきか、そのままでいいのか判断しやすくなります。

## Gitシリーズ記事まとめ

https://qiita.com/ucan-lab/items/33c63a402f533aa92f3e

## 各種機能紹介

### Saved replies

https://docs.github.com/ja/get-started/writing-on-github/working-with-saved-replies/using-saved-replies

公式で用意されている、IssueやPull Requestを書く際に使用できる返信テンプレートを管理できます。

### Ale

GitでCloneしたらearly EOF

## 再現手順
Reactのデザインテンプレートである[AdminLTE](https://adminlte.io/)を
自分のGitにforkし、ローカルにcloneしようとしたところ以下のエラーが出た。

“`
% git clone {リモートリポジトリURL}
Cloning into ‘{リポジトリ名}’…
remote: Enumerating objects: 2889, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (3/3), done.
Receiving objects: 47% (1360/2889), 9.61 MiB | 121.00 KiB/s

error: RPC failed; curl 92 HTTP/2 stream 5 was not closed cleanly: CANCEL (err 8)
error: 7152 bytes of body are still expected
fetch-pack: une

Gitのリモートリポジトリをローカル環境に作成，後からpush先をSSH先(Github, Devops等)に変更

# 経緯
– 個人開発の場合はcommitだけで正直事足りるが，いつもと同様のルールでバージョン管理したい
– どうしても生まれる裏作業内容や秘匿性の高いソースコードを個人でバージョン管理したい
– アジャイル開発に必須だと思うGitの勉強(時間がない時修正箇所にconflictができて迷惑をかけた経験)

# Gitでリモートリポジトリをローカル環境に作成
基本は以下(リモートを先に立てて，git clone)を参考したが，
今回は既にローカルが存在することを前提としたい．
`remote add`する形でリモートリポジトリを作成する．

https://qiita.com/masatomix/items/19f4604c939567929ee8

以下のローカルリポジトリが既に存在するとする．


空のリモートリポジトリを任意のディレクトリに

【2024年度】新入社員が入れておきたい開発ツールまとめ

## 新年度がはじまって
新年度が始まって新入社員が入ってくる季節だと思います。

今回は開発者として入れておいてもらいたいツールをまとめました。
これらのツールは使い方はネット上にいくらでもあるので、自分で使い方を覚えておきましょう。

## ツールリスト
– VSCode（IDE）
– DBeaver（DBクライアント）
– Docker DeskTop（コンテナ仮想化）
– Notion（メモツール）
– Postman（APIツール）
– Git（バージョン管理）
– ChatGPT/Claude（生成AI）

## VSCode
定番のIDE。JavaであればIntelliJ、RubyであればRubyMineを使ったりするかもしれませんが、とりあえず入れておいて損はない高機能なIDEです。

https://code.visualstudio.com/

※VSCodeで入れておくべきプラグインは以下を参照してください。

https://qiita.com/pike3/items/6c25cb8460e6eb34963b

## DBeaver
データベースを操作するための

.gitignore 使ってみた

# はじめに

`.gitignore`をちゃんと触ったことがなく、
「gitによってやり取りされないためのもの」くらいのイメージしかありませんでした。

`.gitignore`に特化して使ってみたところ、勘違いしていた点があったので記事にします。

# Githubからローカルへ`clone`してみる


このレポジトリから、`test2.txt`だけ`.gitignore`に記述し、ローカルに`clone`してみます。

予想では、`test.txt`だけがローカルに`clone`されると思いましたが・・・

![スクリーンショット 2024-04-06 15.11.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.c

CodeCommit デフォルトプロファイルではないプロファイルでのHTTPS(GRC)でのリポジトリクローン

# プロファイル情報の一覧
“`
aws configure list-profiles
“`

# CodeCommitリポジトリ一覧
“`
aws codecommit –region {リージョン名} list-repositories –profile {プロファイル名}
“`

# CodeCommit HTTPS(GRC)でのリポジトリクローン
“`
git clone codecommit://{プロファイル名}@{リポジトリ名} {クローン先ディレクトリパス}
eg) git clone codecommit://hogehoge@fugafuga (クローン先ディレクトリパスは省略可能、カレントディレクトリにクローン)
“`

Github Actionsで簡単なワークフローを試す。

# Github Actions　使ってますか？
※本記事ではGithubについての説明は割愛します。
Github Actiosとは、GithubによるCI/CDパイプライン構築のためのワークフローです。
CI/CDとはContinuous Integration/Continuous Delivery & Deploymentの略。継続的インテグレーション・継続的デリバリーのことで、要するにコードに変更を加えてマージし（インテグレーション）、本番環境に反映させる（デプロイメント）漸進的に改良を加え続け、より良い価値を届けるためのプラットフォームを築き続けるということです。

しかし、開発における継続的なコードのインテグレーション（統合）・デプロイメントは人の手で行おうとすると少なくない工数と手間がかかり、「継続性」の担保が難しい状況に陥る可能性があります。その為、リモートリポジトリへの変更のプッシュ等のイベントにフックして（フックはぶら下がるという意味の英単語です。ここにおいては作業開始の合図みたいなものだとお考えください。）ワークフローを自動実行します。
変更を引き金にしてビルド

チケットを切ることで感じた恩恵

１、ブランチ一覧が見やすい
チケットを切っていないとどのような背景があり、何を実現したいのか把握するのに
時間がかかってしまい非効率です。

しかし、チケットで管理しているとそれを一目見て理解できる。

２、自分が何をしたいか整理しやすい
シーケンス図やユースケース図があるともっとコードを書きやすい

– まずチケットを切る
– ブランチを切る
例：チケット番号-prefix-機能
110-add-login-function

– プルリクを出す
チケット番号：タイトル
これはマストではないですが、個人的に導入してみて良かったと思う方法です。

３、後からドキュメントを作成しやすい
ドキュメントの際にチケットに書かれている内容を使いまわせるので
容易にドキュメントを作成できる。

4、　タスクが属人化しづらい
タスクの属人化は永遠のテーマだと思いますが、詳細に書かれていると
レビュー側もレビューしやすいですし、属人化も避けられる。

ディレクトリ丸ごと差分を確認したい時に俺がやってること

## はじめに
ディレクトリAとディレクトリBの差分を丸ごと確認したいってこと、あると思います。
ファイルの差分であればvscodeの機能で確認することができるのですが（ctrl + shift + P → “compare”で差分チェックできる。）ディレクトリ丸ごととなるとこの方法は使えません。

また、「Compare Folders」という拡張機能で差分を確認することはできるのですが、ひとつひとつディレクトリを開かないといけなかったり、ぱっと見では数がわからなかったりでうーんといった感じでした。

https://marketplace.visualstudio.com/items?itemName=moshfeu.compare-folders

（↑このように差分があるファイルはわかるが

【Git】Git rebaseについて

今回は「git rebase」について投稿します。
gitで悪戦苦闘することの1つに、git rebaseがあると思います。
そんなrebaseについて振り返ってみました。

# 1: git rebaseとは？
– 今までコミットしてきた”複数のブランチ”を「一直線の道筋にして、整える」コマンドです。

“`git:gitコマンド
git rebase
“`
■例
例えばmainブランチと、featureブランチの2つがありました。
– mainブランチには、「コミット履歴が3つ」あります。
– featureブランチには、「コミット履歴が2つ」あります。

2つのブランチがあることにより、ブランチは枝分かれしていますね。

**枝分かれで進めている最中に、「mainブランチに、featureブランチを取り込んで履歴を一直線に綺麗にしたい。」と思いました。**

そこで使うのが「git rebaseコマンド」です。
“`git:featureブランチにいる状態で、下記を入力。
git rebase main
“`

■結果
「mainブランチに、featureブランチ」が統合

VS CodeでGitに再入門してみる （ローカルリポジトリのみの作業）

## はじめに
就活中です。前職はGitLabに関係のある仕事をしてずっとGitLabを使っていました。
とはいえ多く使われているのはGitHub。GitHubも使えるようにならないと、と思って触り始めたのですが、いまさら気づきました。
**IT系の経験はインフラ構築がメインで、コードを書いたことがほとんどないため、そもそも、Gitを使い慣れていない…**

実はインフラ系の後、長くWeb制作・更新代行をやっていまして、その時はgitで管理していました。一度コンテンツを誤って消してしまった時はgitで助けられました。
でも、一人で仕事をしていたので、GitHubも使わず、pushもpullもプルリクもコンフリクトも未経験。
まー触っているうちに思い出してなんとかなるでしょ、と練習しはじめたけど、全然思ったように操作できません。
## Git&GitHub入門！
そこで、初心に帰って勉強することに。 **「わかばちゃんと学ぶ Git使い方入門」** を買いました！

https://amzn.asia/d/5arvdtC

わかばちゃん、よろしくね！
この本の内容を参考にしつつ、ほんっと

Git操作コマンド集

よく忘れるコマンドを自分用に整理。都度更新します。

# Remote repo関連
– 登録されているリモートリポジトリを確認
“`bash
git remote -v
“`
– originのURLを変更
“`bash
git remote set-url origin {New git repository url}
“`
– originにリポジトリURLを追加
“`bash
git remote set-url –add origin {New git repository url}
“`

# Commit関連
– 直前のコミットを取り消し
– `–soft`: ワークディレクトリの内容はそのままでコミットだけを取り消したい場合に使用
– `–hard`: コミット取り消した上でワークディレクトリの内容も書き換えたい場合に使用
– `HEAD^`: 直前のコミットのこと
– `HEAD~{n}`: n個前のコミットを意味する
“`bash
git reset –soft HEAD^
“`
– 直前のコミットメッセージ変

EUC-JP環境下のGitで日本語を扱う

# 背景
UTF-8でないシステムでGitを使おうとすると、日本語が化ける。
不便なので解決したい。

:::note info
EUC-JPなシステムでの記述です。適宜文字コードを読み替えてください。
Linux環境、git version 2.34.1 で動作確認済み。
:::

# 結論
“`
git config core.pager “LESSCHARSET=iso8859 less” # diffとかlogとか（ページャ）
git config core.quotepath false # 日本語ファイル名
git config i18n.commitEncoding iso8859 # コミットメッセージ
“`

# diffとかlogとか（ページャ）
## 現象
“`
$ git diff
diff –git a/readme b/readme
index 4472dd6..82a7901 100644
— a/readme
+++ b/readme
@@ -1,2 +1 @

【Git】間違えたpushを取り消したい

Gitでpushを取り消したい時の手法になります。
※個人開発では問題ないと思いますが、チームで開発しているときは注意が必要です。

## 直前のpushを取り消す

間違えたpushをしたブランチにて実行

“`bash
$ git reset –hard HEAD^
“`

強制pushをして、リセットをリモートリのブランチに反映させます。

“`bash
$ git push -f origin 間違えてpushしたブランチ名
“`

## 過去のpushを取り消す

過去の取り消しにはコミットのハッシュ値が必要になります。
`git log`にてハッシュ値を取得します。

“`bash
$ git log

// git logだと情報量が多いと思うのでオプションをつけると見やすくなると思います。
$ git log –oneline -5
“`

取得したコミットのハッシュ値を指定してリセット、強制pushをして反映します。

“`bash
$ git reset –hard コミットのハッシュ値
$ git push -f origin 間違えてpush

Git 登録　Github連携 ubuntu 用　

git登録とgithub連携を行う手順

参考にした記事:
Ubuntu git ~ github連携まで

# ユーザー設定:
これはローカルのgitを登録するための設定です。
“`
$ git config –global user.name [名前]
$ git config –global user.email [メールアドレス]
“`
# Github連携:
既存のGithubのアカウントと連携します。

## ssh-keyの作成:
Githubを連携させるには公開鍵が必要ですので、以下のコマンドで作成します。

“`
ssh-keygen -t rsa -C “メールアドレス”
“`
このコマンドを実行すると、~/.ssh/id_rsa というファイルが作成されます。

## Githubに公開鍵を設定:
作成した公開鍵をGithubに登録します。

まず、公開鍵をクリップボードにコピーします。xclip はUbuntuで使用するコマンドです。
“`
$ cat ~/.ssh/id_rsa.pub | xclip -selection clipboard
`

Github複数アカウントでssh接続設定を切り替える

いつも設定やり方を忘れてしまうため自分用に手順書作成しました。
[こちら](https://qiita.com/yampy/items/24638156abd383e08758)の記事を参考にしています。(いつもお世話になってます)
Business, Privateで使い分ける際に使用してます。

# 1. ssh key作成
– ローカル環境で作成する
– オプション整理
– -t: 作成する鍵の暗号化形式。`rsa`(default), `dsa`, `ecdsa`, `ed25519`から指定
– -C: コメントを指定。「ユーザ名@ホスト名（default）」以外にするとき使用
– -f: ファイル名(厳密には保存先)
“`bash
cd ~/.ssh
ssh-keygen -t rsa -C {Github mail address} -f {key-name}
# 実行後以下が聞かれる。基本的にはEnter押すだけでOK
# Enter passphrase (empty for no passphrase):
# Enter same pass

Git LFSは無制限のクラウドか？

# はじめに

gitを用いて開発を行うときに、画像、動画、音声、巨大なバイナリファイル等をgithubに上げたくなる場合があります。

しかし実は、githubに上げられるデータには制限が設けられています

https://docs.github.com/ja/repositories/working-with-files/managing-large-files/about-large-files-on-github

具体的には、

・100MBを超えるfileはpush出来ない
・レポジトリあたり5GBまでのデータしかpush出来ない

という制約があります。

しかし、画像、動画、音声、バイナリファイルで100MBを超えるデータは多く、このようなデータをgithubに上げられないのはとても不便です。

そこで、Git LFSという拡張機能を利用することによってこのような問題を解決することができます。

# Git LFSとは

Git LFSとはGit Large File Storage (LFS)のことで、巨大なファイルをGitのポインターファイルに変更する機能です。