`git blame`と`git rebase`の使用例

# はじめに

https://qiita.com/kohki_takatama/items/58c8063c1f6bb7303bfa

↑ の記事で `git blame`便利そ～ `git rebase`使い道わからん～hoge~ってやってたんですが、
ありがたいコメントを契機に、一気に理解できたので記事にさせていただきます。
# いただいたコメント

> 私の場合、`git rebase` で コミット整理する際に よく使います。
> ちょっとした間違いを修正するときとか
> (`git commit –amend` の、ずっと前のコミットでも直せる版)。
>
> `git rebase`する前に、修正対象コミット を見つけるために、`git blame`するんです。
>
> やり方としては：
> 直したい行をコミットしちゃったコミットを、
> `git blame` で特定しておきます。
>
> 見つけたコミットに対して、修正コミットを、
> `git commit –fixup COM

はじめてのGit

## Gitを使ったプロジェクト管理の手順

**1**. 自身のPCにGitで管理するディレクトリを用意する

– [こちらのリンク](https://prog-8.com/docs/git-env-win) を参考に設定する.
– ディレクトリの状態変化をローカルリポジトリに登録し, リモートリポジトリと同期する.
– リポジトリは, ファイルやフォルダのデータとその変更履歴を収納しておく場所である.ローカルリポジトリとリモートリポジトリの同期によって, 複数人でコードと変更履歴を共有できる.

**2**. リモートリポジトリのクローンを作成する

– GitHubページから `git@~` を取得する.
– コマンドプロンプトで操作し, クローンを作成したい場所に移動する.

“`zsh
cd 作成したいディレクトリへのパス
“`

– クローンを作成する.

“`zsh
git clone git@github.com:ユーザ名/リモートリポジトリ名.git
“`

**3**. 変更内容をローカルリポジトリにコミットする

– ファイルやフォルダの変更をローカル

GitHubとGitとSSHと

# 趣旨
GitHubの初期設定のやり方を毎度忘れて毎度検索してるのでそれに終止符を打ちます。

間違えてる部分があったらご指摘をお願いします。

# GitHubとGitとSSH接続の設定

GitHubでプロジェクトを始める際の手順と、それに伴うGitおよびSSH接続の設定について解説します。プロジェクトを新しく始める場合と、既にローカルでコードを書き始めている場合の2つのシナリオに分けて説明します。

## まっさらな状態から始める場合

### GitHubでリポジトリを作成する

1. **GitHubにログイン**します。
2. 右上の**「New repository」**ボタンをクリックします。
3. リポジトリ名を入力し、**「Initialize this repository with a README」** のチェックボックスをオフにしてリポジトリを作成します。これにより、空のリポジトリが作成されます。

### ローカルにリポジトリをPullする

1. **Git Bash**や**ターミナル**を開きます。
2. `git clone [リポジトリのURL

GitHubCLIを用いてリモートリポジトリーをコマンドで作成してみた

## はじめに
技術記事を書いている際にサンプルコードを載せたいときがあります。その際に、プラウザ上でGitHubに毎回リモートリポジトリーを作成することにめんどくささを感じたので、コマンドで作成しました。実施方法について記しておきます。

公式ドキュメント

https://docs.github.com/ja/github-cli/github-cli/about-github-cli

## 内容

コマンドラインから作業しているときは、GitHub CLI を使用して時間を節約することができます。

GitHub CLI には、次のような GitHub 機能が含まれています。

– リポジトリの表示、作成、複製、フォーク
– Issue と pull request の作成、クローズ、編集、一覧表示
– プルリクエストのレビュー、diff、マージ
– ワークフローの実行、表示、一覧表示
– リリースの作成、一覧表示、表示、削除
– gist の作成、編集、一覧表示、表示、削除
– codespace の一覧表示、作成、削除、接続
– GitHub API から情報を取得します

はじめてGitを使いたい非エンジニアの個人ゲーム開発者向けの覚え書き（Gitのツール選定）

お友達のあきらさんに、GitHubを使うべきかSourceTreeを使うべきか聞かれたのでまとめました。

# 対象
本職エンジニアではなく、Gitも（ほぼ）触ったことないけど、個人でゲーム作ったりしてる人

# 要約
– Gitというシステムがあるよ
– GitHubはWebのソフトウェア開発プラットフォーム、SourceTreeはGitのGUIツール（ソフトウェア）だよ

ファイルはローカルに置いておきたい + 一人での開発 -> SourceTree（ソフトウェア）を使うのがおすすめ！

ファイルはリモートに置いておきたい + 共同開発(みんなで別々のファイルを同時にいじりたい) -> Github+GitHub Desktopがおすすめ！

＊あくまでもおすすめで、使い方次第でどうとでもできます。

# 解説

### Gitっていうシステムがあるよ

まず、Git（ギット）という技術があります。
分散型バージョン管理システムというやつです。

すごくざっくりいうと、作業のセーブポイントをいくつも作ってけるような、便利な仕組みです。
（もう少しちゃんと言うと、ファイルをどう変更

IntelliJ IDEA で 複数のローカルブランチを まとめて削除する方法

1. IDE の Git タブ > Git ログの表示 を選択する
1. IDEのどこか(デフォルトなら下部)に、Git ログ画面が表示される
1. 左側にローカルブランチ（とリモートブランチ）の一覧が出る
1. Shift+クリックなどで複数選択をして、右クリック→削除 でOK

[感想]
これまで右下のブランチのところからポチポチやっていたわ…

git コマンド

## 1.git の初期化　リポジトリの作成
`git init`
## 2.名前メールアドレスの設定
`git config –local user.name “名前”`
`git config –local user.email “mail”`

確認は
`git config –local user.email`
などと打つとみることができる。
## ３．gitの場所(1branchのどこにいるか確認する）
`git status`
## 4.ステージに追加
`git add ファイル名`
commitする準備をする作業
## 5.変更内容を記録するコミットする
`git commit -m “メッセージ”`
gitをコミットするときにどのような変更内容を行うかを表すもの。
## 6.記録された内容を確認
`git log`
著者やidなどがみれる
## 7.過去のブランチにさかのぼる
`git switch –detach コミットid`
detach というのは新たな時系列をつくる切り離すという意味合いがある。前のブランチに戻ることができる。しかしこのブランチには新た

git リモートリポジトリにソースコードをpush

“`git
$cd フォルダが置かれている場所（desktop)など)/フォルダの名前

$ git init

$ git add .

$ git commit -m “好きなコメント”

$ git remote add origin git@github.com:jibunNO/jibunNoRepositoryName.git

$ git push origin main
“`

git push origin masterにするとエラーがでる

GitHubのデフォルトブランチ名を取得する

# やりたいこと・背景

“`sh
$ git remote show origin
* remote origin
Fetch URL: git@github.com:vividmuimui/foo.git
Push URL: git@github.com:vividmuimui/foo.git
HEAD branch: main
Remote branches:
bar_branch tracked
“`

“`sh
$ git branch -r
origin/HEAD -> origin/main
origin/bar_branch
origin/main
“`

上記などのコマンドで表示される `HEAD branch: main` や `origin/HEAD -> origin/main` の `main` の部分を取得したい。

理由としては、リモートリポジトリの設定によって、`master` だったり `main` だったりする。
これをコマンド一発で取れるようにしたい。

# コマンド

“`sh

git で特定のコミットの差異が発生したファイルの一覧を出力する

# bashなどで以下を実行
~~~
git show コミット番号（７桁？） –stat –name-status > d:\\aaa.txt

初めてのタスクアサイン〜プルリクエスト！

# 初めてのタスクアサイン〜プルリクエストの手順

この記事は、新米エンジニアの僕が初めて業務をアサインされてプルリクエストをするまでに行った手順をまとめたものになります。
僕のようにチーム開発の経験がなく、初めてプルリクエストをする！という方の参考になればいいなと思います。

### 用語＆前提
・ローカルリポジトリ　→　自分のPCに入っているgitのリポジトリのこと
・リモートリポジトリ　→ github上に存在するチームで共有しているリポジトリのこと
・ローカルリポジトリには、リモートリポジトリの内容が`git clone`でコピーされている状態
・ローカルリポジトリもリモートリポジトリもどちらも`master`ブランチがメインのブランチ

### ①ローカルリポジトリに作業ブランチを生やす
まず、上司の方から業務をアサインされたら初めに行うことは、ローカルブランチで作業ブランチを生やすことです。
この作業ブランチというのは、自分の業務用のブランチのことを指します。つまり、自分が業務のためにコーディングや修正を行うブランチのことです。
ターミナルを開き、該当のフォルダに移動します

Git Progateメモ

Git Progate

・gitはターミナルで操作する
・git init:initiatelize=初期化
・共同開発の流れは①コードを変更する→②共有する準備をする→③共有する. で行う
・git add ファイル名:共有したいファイルとして選択する。
・git commit -m “コミットメッセージ”:選択したファイルをメッセージ付きで記録し共有する準備をする。(共有準備完了)
・リモートリポジトリはURL。名前はoriginが一般的。
・git remote add origin URL:リモートリポジトリの登録
・git push リモートリポジトリ名(例えばorigin) master:リモートレポジトリにファイルをアップするコマンド。プッシュという。
・git pull origin master:リモートリポジトリからファイルをダウンロードする。プルという。
・git status:自分が変更したファイルのファイル名を表示できる。addされたファイル(緑色)とされていないファイル(赤色)も区別できる。
・git diff:コードの変更内容を緑色で表示する。変更前コー

最低限のGit・Github

# はじめに
大学のグループ課題などで、Gitを使ったほうが楽だけど、他の人があまりGitを知らないということが周りでよくありました。
そこで、必要最低限の知識を短時間で身につけることを目的に記事を書こうと思いました。

急にGitを使うことになった方や、Gitを全く触ったことがない人を対象としています。

## Git とは
バージョン管理システムのひとつ。

このように更新するごとにファイルが増えていくとする。
– ドキュメント.txt
– ドキュメント_20240218更新.txt
– ドキュメント_20240219更新.txt
– ドキュメント_20240220更新.txt

Gitを用いるとファイル名を変えること無く差分や、更新履歴を保存していくので、いつ更新したかを指定してその時の状態に戻すことも可能である。

– ドキュメント.txt
更新履歴
20240218更新 by aさん ← 20240220の状態から、いつでもここに戻すことが出来る
20240219更新 by bさん
20240219更新 by aさん
20240220更新 by aさん

また、複数人で作業

チーム開発に向けたgitコマンド

環境

• WSL2

目的

チーム開発のためにgitコマンドを習得する。

注意

• 今回はメインブランチが「main」ではなく、「master」になっています。
• https通信ではなく、ssh通信を使っています。

事前準備

Githubにssh接続できるようにしておく

作業ディレクトリはどこでもいいです。

下記のコマンドで公開鍵と秘密鍵のペアを生成する。生成するディレクトリなどが聞かれるが、何も入力せずに全部Enterを押す。

“`shell
> ssh-keygen -t rsa
“`

下記の場所に秘密鍵(id_rsa)と公開鍵(id_rsa.pub)が生成されているはず。

“`shell
> ls -l ~/.ssh
…id_rsa
…id_rsa.pub
“`

下記のコマンドで公開鍵(id_rsa.pub)の中身を

git – 特定ファイルだけを1個前の状態に戻す

# コマンド例

`git checkout HEAD^ <ファイルパス>`

# gitconfig のエイリアスに設定する例

“`
[alias]
rollback = “!f() { git checkout HEAD^ \”$1\”; }; f”
“`

コマンド実行

“`
git rollback <ファイルパス>
“`

# チャットメンバー募集

何か質問、悩み事、相談などあればLINEオープンチャットもご利用ください。

https://line.me/ti/g2/eEPltQ6Tzh3pYAZV8JXKZqc7PJ6L0rpm573dcQ

# プロフィール・経歴

https://github.com/YumaInaura/YumaInaura

Git002:Gitのブランチ運用法

#### おすすめのBranch管理　考え方
人やチームによって、Branchの管理は異なります。
あくまで私の経験上で良いと思ったBranch管理は下記の通りです。

①機能毎にBranchを作ってSoft変更する。
②MainのBranchでSoft変更を行わない。
　他の機能毎のBranchをMergeするだけとする。
　
キーポイントは機能毎にSourceを管理する事だと思います。
複数の機能の変更を合体して１つのブランチでCommitしてしまうと、どの変更がどの機能か分からなくなります。
各機能を実現するにはどの様な記述が必要かをブランチ毎にまとめる事が重要です。

そうなっていたら、Mainブランチは結合するだけのはずです。

#### Commitの注意点
Gitではたまに変更したSourceが消えてしまう、注意すべき挙動が有ります。

多くのGit HistoryのViewerはBranchの履歴情報だけを追って表示します。
つまり、「Branchに所属しないで変更したコミット内容は、別のBranchにCheck Outすると見えなくなる事が有る。」のです。

＜2種類

若手エンジニアのコードレビュー 〜斜め上のPRを見て学ぼう！〜

# はじめに

「コードレビューは自分にはハードルが高いなー🙁」、「知識ないから、先輩のPRにコメントするの恐れ多い😨」などと思っていませんか？

自分は普通に思っていました〜
特に、自分の書くコードにすら自信がないのに、突然レビューしようとしても、難しいですよね💦💦💦

自分は、プログラミング初めてまだ1年半であるため、先輩エンジニアやチームメンバーのコードをレビューするのは恐れ多く、ワンステップ先だと思っていました。🤔
最近は、全く完璧ではなく、なんちゃってですが、積極的に行なっているつもり、、、

ですが、『どこを見たらいいんだろう？🤔』、『これレビューできているんだろうか？😟』と思うことが多くあります。

そんなコードレビューについて、先輩エンジニアやCTOから多くのアドバイスをいただいたので、記事にしたいと思います！

※記事では、プルリクエストのことをPRと書いてます！

## 対象読者

– 自分の書くコードに自信がない若手エンジニア
– レビューが苦手なエンジニア
– 初めてレビューをするエンジニア

# 💪 コードレビューの目的は？

[良いソフトウェアとコードレビュ

【Git,GitHub】リモートリポジトリを複製する方法

# はじめに
みなさんこんにちは！
まずは本記事を読んでいただきありがとうございます。

今回はコミット履歴も含め、リモートリポジトリを別のリモートリポジトリに複製するときの手順を説明したいと思います。

# この記事の対象者
リポジトリのミラーをフォークすることなく自身のリポジトリに取り込む方法がわからない人
イメージ図:
上記の画像のようにforkを行うと、forked from とfork元が表示された上で複製されています。

今回は、この外部のリポジトリをforked from と表示させずにリポジトリを複製することを目標とします！

# 手順
例として、

＜コピー元＞
laravel-app-original

＜コピー先＞
laravel-app

としてリポジトリをコピーします。

１. 新しいリポジトリをGitHubで作成
l

【Git】LF will be replaced by CRLF the next time Git touches it 警告の解消方法

# 背景
新しく使い始めたPCのgit、vscodeの環境を構築し開発環境を整えていた。
vscodeのターミナルで`git add .`を実行した際に下記の警告が表示された。

# 警告
`git add .`を実行時に下記のwarningがターミナルに表示。
“`
warning: in the working copy of ‘src/App.tsx’, LF will be replaced by CRLF the next time Git touches it
“`

# 原因
以下、DeepLで日本語に翻訳してみた内容です。
“`
警告：作業コピーの’src/App.tsx’では、次にGitが触ったときにLFがCRLFに置き換えられます。
“`

Gitが改行コードをLFからCRLFに変更しようとしいてるみたい。

# 解決策
次のコマンドを実行し、`git add`コマンド実行時に警告が表示されなくなった事を確認できた。
“`
git config –global core.autoCRLF false
“`

Git で覚えていきたいコマンド

# はじめに

`git スキル` リファクタリングの時間です！！

最近`git`コマンドに慣れてきたので、新しいコマンドを覚えていきたい所存

“`
「すぐ使えるもの」：RUNTEQ カリキュラムで使えるもの

「すぐ使えないけど絶対使うもの」：備忘録

「まだ重要度のわからないもの」：初心者（私）からするとわからないもの。
“`

という形で書いていきます！

（↓ こちらの記事に触発されました。ありがとうございます🙇‍♂️🙇‍♂️）

https://qiita.com/uhooi/items/c26c7c1beb5b36e7418e
# すぐ使えるもの

今取り組んでいる RUNTEQ カリキュラム上、すぐに使って覚えていけそうなものです。

## git commit –amend

> 直前のコミットメッセージは `git commit –amend` で変更できます。
> テキストエディタが開くので、コミットメッセージを変更して保存します。

まさに今日やりたかったことですね～便利。
## git branch

> | コマンド | 説明 |
> |–