今さら聞けないGit　2022年08月17日

git push で403 error が出た時の対処法

git push で403 error が出た時の対処法

git push で403 error が出た時の対処法

トークン？
https://zenn.dev/kazuma_soon/articles/b2568723ae4bc0

【初心者向け】SSHでgithubと通信できるようにする

## はじめに
　gitのローカルリポジトリをSSHを用いてリモートリポジトリにpushできる方法を調べたので記載します。
SSHを用いることでパスワード入力の手間を省き楽にリモートリポジトリにプッシュできるようになります。

## git、githubとは　
簡単に言うと、ソースコードを管理できるツール。
複数人での開発時にとても便利。
詳しくは以下の記事を参考。
[【超入門】初心者のためのGitとGitHubの使い方](https://tech-blog.rakus.co.jp/entry/20200529/git)

## ローカルリポジトリで通信方法にSSHを指定する
以下の記事を参考
[gitでパスワードを毎回聞かれる問題の解決方法](https://qiita.com/rorensu2236/items/df7d4c2cf621eeddd468)

## 鍵を生成してgithubに公開鍵を設定する
以下の記事を参考
[GitHubにssh接続するまでの手順](https://zenn.dev/schnell/articles/0e1c2e9db5c08d)
[GitやGi

忙しいレビュアーにも読んでもらえるような優しいコミットコメントをつけよう

# 概要
レビュアーは得てして忙しいことが多いと思うので、読んでもらえるような優しいコミットコメントをつけようというお話

# 結論
## 1コミットで1つの対応「のみ」を行う
シンプルにこれだけ。
Simple is best.

# 利点と欠点
## 利点
レビュアーの負荷軽減。
大量のコミット、大量の変更、かつコメントと修正内容の不一致を起こしていると、レビュアーが疲弊してしまう。
コミット単位の意味が単純かつ明確であると、背景を読む必要がなくなり負荷が減る。
また、コミットが複数ある場合でも、「このコミットまで確認した」という区切りがつけやすい。
複数の意図が混ざったコミットコメントだと、作業中断から再開したときに、スイッチングコストがかかってしまう。

## 欠点
レビュイーの手間が少し増える。
ただし、これを意識できると、忙しいレビュアーから後回しにされるようなことは減ると思う。

# 具体例
## NG
・コミットコメントで記載されている以外のことしている
「バグ修正のコミットコメントに対して、コード差分としてはリファクタリングをも実施している」場合などが該当。
意図が

レンタルサーバーを借りてオンラインゲームのWikiサイトを作ってみる #3

## 前回の記事
https://qiita.com/Unirenkon/items/bb58b8b4228fcf845e6f

## 今回の作業
プロジェクトをGitHubにpushする

## 事前準備
前回の記事で書いたFTPソフトを使ってxserverからプロジェクトディレクトリをlocalにダウンロードしておく

## GitHubにレポジトリ作成


左上のコードを押してレポジトリのアドレスをコピー

Teamのためのより良いPull Requestタイトル作成について調べてみた

# 目的
coventional commit仕様に沿ったPull Requestタイトルを作成するため

## Introduction
明示的なmerge commitを作るためにPRのtitleを当該ルールに基づいて作成

## Usage
PRタイトルは “type“(“option“): “description“で作成

### PR title
– “type“ – Typeのうち一つ[オプション範囲]-追加情報
– “description“ – PRについての説明

### Type

– “build“ – ビルドシステムまたは外部従属性に影響を及ぼす変更事項(従属性アップデート)
– “ci“ – CI構成ファイルおよびスクリプト変更(基本的に.github/ワークフローディレクトリ)
– “docs“ – ドキュメントのみ変更される時
– “feat“ – 新しい機能
– “fix“ -バグ修正時
– “chore“ – コードに触れない変更事項(例:リリースノートの手動アップデート)
– “refactor“

VS CodeのGit関連の拡張機能が使えなくなったときに試したこと

# 記事の概要
VS Codeの拡張機能「Git Graph」が突然`No Git repositories were found in the current workspace when it was last scanned by Git Graph.`というエラーを吐いて表示されなくなってしまったときにやったことの備忘録。
※とき同じくして、「GitLens」という拡張機能も使えなくなった

# 環境
* Windows11

# やったこと
該当のファイル・ディレクトリを、`safe.directory`に追加する。たったそれだけ。

““
git config –global –add safe.directory 該当のファイルパス
““
Git Lensに関しては、上述の処理後、再インストールをすることで、再び履歴などを追いかけられるようになりました。

しかしリモートリポジトリ設定で`add.safedirectory`したはずなのになぁ……。

WIndowsのSourcetreeでSSHのURLでリポジトリのクローンができない

私はMacユーザーですが、Windowsだと少し違うんだということを知ったので。

## 手順
1.Gitをインストール
2.SSHキーを生成
3.Gitlabに公開鍵を登録
4.Gitコマンドでお試しリポジトリにブランチ作成、ダミーデータをコミット、プッシュ

## 問題発生の経緯
ここから、私はよくSourceTreeを使うので、インストールし、
お試しリポジトリのクローンをSSHのURLから作成して、問題なくコミットプッシュまでできました。

ただ、Windowsユーザの人がSourceTreeをインストールして、
同じようにSSHのURLからリポジトリをクローンしようとしたら、
なにやらSSH鍵に関するエラーがでてきて、クローンを作れなかった。

## 調べてみた
そんなことがあるのか、と調べてみると、SSH鍵って種類があるんですね。
MacだとデフォルトでOpenSSHという種類のものが入っていて、
GitもデフォルトOpenSSHなので、特に意識することなく使用できていたのですが、
WindowsだとデフォルトでOpenSSHがない（？設定がされていない？）。

Windo

Gitオブジェクトってなにもの？

Gitってsvnと比べると、同じリモートリポジトリで比較しても、かなり速いですよね。
まだまだGitには知らないことも多くあるので、この際調べてみると、Gitってスナップショットで管理していることを知りました。svnのように差分を積み上げる必要がない分、Gitは速いんだと思います。

とすると、スナップショットで保持するのに、なぜGitリポジトリは肥大化しないのか？という疑問が沸いてきましたが、Gitオブジェクトの構造で工夫しているんだろうと分かったので、自分の整理のために記事にしました。

# Gitオブジェクトの種類
– 4種類のオブジェクトが存在する
– SHA-1ハッシュによる識別

|種類|内容|
|-|-|
|blobオブジェクト|ファイルに相当
|treeオブジェクト|ディレクトリに相当
|commitオブジェクト|コミットのスナップショット
|tagオブジェクト|タグ。今回は対象外

# blobオブジェクト
– ファイルに相当するオブジェクトで、ファイルの中身がzlibで圧縮されている。ファイル名は管理外。
– ファイルの中身に`blob <ファイルサイズ>\0`を

Amazon Linux2での環境構築メモ（Git、Node.js、MySQL）

## はじめに
よくわからなくなってググるので超個人的備忘録として書き記しておきます。

### 動作環境
OS：Amazon Linux2

## gitのインストール
コマンドラインで以下のコマンドを入力
“`bash
sudo yum install git
“`

インストール確認。
“`bash
git –version
“`

これでgitのインストールは完了。
あとは任意のリポジトリを`git clone`してやればOK

## Node.jsのインストール
まずはnvm（Node.jsのバージョン管理ツール）をインストールします。
[公式サイトの手順](https://github.com/nvm-sh/nvm/tree/v0.37.2#installing-and-updating)に従うだけで大丈夫。コピペで簡単。
“`bash
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.37.2/install.sh | bash
“`

bashを開き直すよう言われるので開き直してからインストー

【Git】git commit 後に commit message を変更したい

# やりたいこと
`git commit`で間違って設定してしまったコミットメッセージを変更したい！

# どうやってやるか
`git commit –amend` を使えば、コミットメッセージを後から変更可能です。

# ユースケース
## 直前のCommitメッセージの変更
「GitHubのテンプレート作ったからコミットしよーっと :smiley: 」
“`zsh
git commit -m ‘GitHubのテンプレートwo追加’
“`
「うお！コメントミスってしまった！」
「落ち着け。。。コミットメッセージは –amend で変更出来る。変更しよう。」
“`zsh
git commit –amend -m ‘GitHubのテンプレートを追加’
“`
「`–amend`を使って、まともなCommitメッセージに出来てよかった :sweat_smile: 」

# 参考
– https://www.granfairs.com/blog/staff/git-commit-fix

【Git】現在のブランチ名を取得する方法

以下のコマンドで現在のブランチ名を取得できます。

## `git rev-parse`
“`:ターミナル
$ git rev-parse –abbrev-ref HEAD
main

$ git rev-parse –abbrev-ref @
main
“`

## `git symbolic-ref`
“`:ターミナル
$ git symbolic-ref –short HEAD
main
“`

## `git branch`
“`:ターミナル
$ git branch –show-current
main
“`

## `git name-rev`
“`:ターミナル
$ git name-rev –name-only HEAD
main

$ git name-rev –name-only @
main
“`

【Git】ブランチを削除する方法

## ローカルブランチを削除する
削除したいブランチ以外のブランチに移動します。
“`:ターミナル
$ git checkrout main
“`

以下のコマンドを実行してローカルブランチを削除します。

“`:ターミナル
$ git branch -d 削除するブランチ名
“`

## リモートブランチを削除する
以下のコマンドでリモートブランチを削除できます。
“`:ターミナル
$ git push リモート名 –delete 削除するブランチ名
“`

ディレクトリをgitの管理下に置いてブランチを作成するまでの流れ

　Gitで管理していないディレクトリを`git init`でGitの管理下に置く場合、最初にコミットをしておかないとブランチが作成できない。ただコミットする中身はまだないので、空のコミットを行う。空のコミットというのは、ステージに何も変更がないのにコミットをするということ。そのような状態では通常コミットは出来ないけど、`–allow-empty`をつければ出来る。

“` bash
# ディレクトリを作成
$ mkdir git-practice

# 作成したディレクトリに移動
$ cd git-practice/

# まだ.gitはない
$ ls -a
./ ../

# ディレクトリをGitの管理下に置く
$ git init
Initialized empty Git repository in hoge/git-practice/.git/

# .gitが出来ている
$ ls -a
./ ../ .git/

# 何も表示されない
$ git branch

# ブランチの作成に失敗してしまう
$ git branch sample
fatal: Not a v

huskyでGitでcommit前にeslintコマンドを自動実行したい

## 目次

– [目次](#目次)
– [概要](#概要)
– [準備](#準備)
– [React雛形作成](#react雛形作成)
– [起動確認](#起動確認)
– [リンターの導入](#リンターの導入)
– [リンターの動作確認](#リンターの動作確認)
– [huskyの導入](#huskyの導入)
– [huskyのインストール](#huskyのインストール)
– [コミット前のhooks作成](#コミット前のhooks作成)
– [検証](#検証)
– [git addしてコミットしてみる](#git-addしてコミットしてみる)
– [参考](#参考)

## 概要

開発でリンターを入れている人はいるかと思いますが、eslintコマンドを実行し忘れてPRで指摘されるケースがたまにあります。

それをなくすために、commit前にeslintコマンドを自動実行する方法についてまとめてみました。

## 準備

### React雛形作成
“`bash
npx create-react-app react-app
“`

### 起動確

gitlabへのpush時に”you don’t have permission”で失敗した問題の解決

# 概要
– 内輪用に立てたGitLabサービスでprivate設定のリポジトリにpushする際に失敗した
– リポジトリが見つからないとのことで、remoteの送り先にアカウント名を含むように修正した。

# 前提
– git: git version 2.37.1.windows.1
– gitリポジトリのProject visibility: Private
– 使用したプロトコル: https

# 背景
– 普段はPublicなリポジトリを操作する事が多かった
– しかし、家族にプログラム講座をやるためにプライベートな例を含めたリポジトリが欲しくなりPrivateなプロジェクトを作成した
– clone時は接続後に認証処理をしたが、push時はそもそもパーミッション的に見られないとのエラーが出た
– remoteのURLをアカウント名を含むように修正し、解決した。

# 現象
– 自分で立てたGitLabサービスに作ったPrivateなプロジェクトにpushしようとしたら以下のエラーが出た。
“`
PS Microsoft.PowerShell.Core\FileSyste

DjangoとDocker練習O17o2o0 gitでソースをクローンしよう！

Git を使ってソースをデプロイする方法を説明する

# はじめに

この記事は Lesson 1. から順に全部やってこないと ソースが足りず実行できないので注意されたい。
連載の目次: ? [DjangoとDockerでゲーム対局サーバーを作ろう！](https://qiita.com/muzudho1/items/eb0df0ea604e1fd9cdae)

# 用語解説

* `レポジトリ` – ソースを置いているディレクトリー

# 本題に入る前に

Git Hub にレポジトリを作っておいてほしい

# git をインストールする

? [1.5 使い始める – Gitのインストール](https://git-scm.com/book/ja/v2/%E4%BD%BF%E3%81%84%E5%A7%8B%E3%82%81%E3%82%8B-Git%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB)

git は Dockerコンテナの外側のOSにインストールしたい

? Ubu

公開鍵暗号方式をかじった

(追記：かじった自分用メモです！正確な情報は他の方をご参照ください！)

GitHubの鍵作ったりしてて、秘密鍵ってなんで必要なの？なんで教えちゃいけないの？って思っていたので調べた　なるほど〜！

読んだサイト：「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典

https://wa3.i-3-i.info/word1830.html


WSLで作成したgitリポジトリをWin側で開くと生じる所有権問題の解決

# 概要
– Windows11でWSL2上で開発する際、VScodeはWin11側で起動している。
– このとき、WSL2側でgit initやgit cloneしたgitリポジトリをWin11側で起動したVScodeで開いてもVScodeのgit機能で管理できなかった。
– powershellでgit logすると「リポジトリの所有権が疑わしい」とのこと。
– メッセージに従い、git configでsafe.directoryに当該パスを追加し、解決した。

# 前提
– OS: Windows 11 Pro(バージョン:21H2/OSビルド22000.856)
– 仮想マシンOS: CentOS Stream release 8
– 仮想マシン動作環境: WSL2
– 前提ソフトウェア: VScode, Windows Terminal

# 背景
– WSL2のお陰でWindowsマシンのみでも手軽にLinux環境向けの開発もできるようになった。
– また、開発物はgitで管理したい。
– さらに、上記環境でVScodeで開発したい場合、WSL2上のファイル、リポジトリをW

2022/08/10 頃に買ったM1 MacBookAirにgitをhomebrewでインストールするまで。

# homebrewのインストール
https://brew.sh/index_ja
のサイトにあるコマンドをターミナルに貼る。
パスワードを聞かれてエンターを押したらインストールが開始される。
インストールが終わったら↓を実行する。
“`:ターミナル
brew –version
“`
バージョンが表示されればOK。
表示されなければ続きます。

実はインストールのときにhomebrewから次のコマンドを入力してね　と言われている。
下記がその一部。
“`:ターミナル
==> Next steps:
– Run these two commands in your terminal to add Homebrew to your PATH:
echo ‘eval “$(/opt/homebrew/bin/brew shellenv)”‘ >> /Users/あなたの名前/.zprofile
eval “$(/opt/homebrew/bin/brew shellenv)”
– Run brew help to get started
– Further docu

【Git】ブランチを保護する方法【GitHub】

## 設定方法
対象のリモートリポジトリにアクセスし､`Settings`の`Branches`を選択します。

`Add rule`をクリックします。

`Branch name pattern`に対象ブランチの名前を入力し`Protect matching branches`および`Rules applied to everyone including administrators`から適用するルール