今さら聞けないGit　2022年07月13日

フェッチとプルの違い

# 概要図


# フェッチ

リモートリポジトリからローカルリポジトリに情報を落とすこと(この場合、ワークツリーには反映されない)。
その後、マージをすることでワークツリーに反映をすることができる。

しかし、ローカルリポジトリのmasterブランチではなく、origin/masterブランチに情報が取り込まれるため、マージをしたい場合は、”git merge origin/master”となる。

### コマンド

“`
$ git fetch <リモート名> <ブランチ名> (リモートからローカルへ)
(例: git fetch origin master)

$ git merge orgin/master (ワークツリーに反映)
“`

# プル
リモートリポジトリから情報を取得して、マージま

いかん、git rebase -iでコミットを削除しすぎてしまった。特定のコミットを復活させたいとき

# rebase -iで、一気にdropにして、必要なコミットも削除してしまった

“`
git rebase -i
“`

# そんなときは、
## 編集の覚えがあるファイルを思い出して、reflogから引っ掛ける
reflogを見て、必要なコミットがわかればOK

“`
git reflog –name-status –date=local
“`

## コミットをローカルブランチに適用する

“`
git rebase -i
“`

ステージの内容を見る

# ステージの状態を表示する
## “`git ls-files“`
ステージ内にあるファイルの一覧を表示する。
“`
************@mbp training % git ls-files
.gitattributes
.idea/misc.xml
.idea/modules.xml
.idea/training.iml
.idea/vcs.xml
.idea/workspace.xml
.ruby-version
Gemfile
Gemfile.lock
README.md
Rakefile
app/assets/co
.
.
.
“`
### 気づき
たくさんのファイルをコミットしていないことがわかる。
ステージ上にある。

## “`git ls-files -s“`
-sオプションをつけると詳細な情報も表示される。
“`
************@mbp training % git ls-files -s
100644 ************.gitattributes
100644 ************.idea/misc.xml
10064

git revert

## git revertについて
コミット取り消しを行う際に、気をつけること

### コマンドについて
– 取り消しのコミットを作ること
– デフォルトで自動的に取り消しコミットを作成し、コミットまで行う
　※コミットしたくない場合は、「-n」オプションを書く

### 単純なコミットの取り消し
“`
git revert コミット値
“`

### マージコミットの取り消し
“`
git revert -m 1 コミット値
“`

手順
①logの確認
“`
git log
“`
①マージコミットの内容確認
“`
git show マージコミット値
commit マージコミット値
Merge: ①4f94f12cba2 ②f7dc3f6788d
Author: userName <メールアドレス>
Date: Fri Dec 18 00:0:00 2020 +0000
“`
③マージコミットを戻す
“`
git revert -m 1 マージコミット値
“`
※戻したいブランチ　→　masterにマージしたのを取り消したい場合

エンジニア成長記#1

7月11日(月)
本日の経験

・githubの基礎知識

ワークツリー→インデックス→リポジトリ
(作業環境)　→(準備場所)　→(コミット場所)
clone：github上のリポジトリをローカルに複製する。
add:ワークツリーからインデックスに登録すること
push:ローカルリポジトリの内容をリモートリポジトリにアップロードすること。

インデックスの役割：変更点をいきなりコミットすると更新されてほしくない箇所も更新する恐れがある。色々変更を加えたけど、ファイルAとBを変更したとき、Aだけコミットしたいことがあるとする。インデックスにAだけを登録することで、変更して欲しいファイルだけコミットすることができる。

プルリクエスト：自分のコードを見てもらいレビューしていただくためのリクエスト。
・wslの環境構築
・Dockerの環境構築

・コマンドの利用
make：Linuxにおいてソースファイルをコンパイルするのに必須のコマンド。実際にはコンパイルだけでなくソースファイルの管理など、さまざまな役割を担っている。
git：git操作を行うコマンド
setup：デバイスとファイルシ

Gitコマンド / VSCode上でのブランチ操作

## はじめに
Python学習中のIT初学者が、GitコマンドとVSCode上でのブランチ操作について簡単にまとめてみました。
私自身、ブランチ操作をする際に手間取ったり、Masterブランチ上でブランチを切らなかったせいで余計なファイルを引き継いでしまった経験があるので、同じような失敗をする人が減るように、また、これからGitを使ったバージョン管理を始めたいという方の参考になれば幸いです。

## ブランチとは？
ブランチ(branch)とは、プロジェクト本体から切り離した状態で（プロジェクト本体に影響を与えず）開発を行える機能のこと。
branchは英語で”枝”や”分岐”といった意味があり、例えばPythonのバージョンを枝分かれさせて開発したり、複数人で開発する際にそれぞれが別の機能を担当し、最終的に同じブランチに結合して開発をしたりします。

## 1. PowerShell上でのGitコマンドによるブランチ操作
**・管理しているブランチ一覧表示**
“`
git branch
“`
何もブランチを作成していなければ、masterブランチだけが表示されます。
ブランチ名

gitで秘密鍵を使い分ける

gitで cloneやpushをする際に何故か違う鍵が使われて詰まったので

### configで設定するやり方
“`.ssh/config
Host <呼ぶときの名前>
HostName github.com
User git
Port 22
IdentityFile ~/.ssh/<使う鍵(秘密鍵の方)>
TCPKeepAlive yes
IdentitiesOnly yes #これがないと他の鍵(デフォルトのid_rsaなど)も読み込まれてしまう
“`
を作成し
“`
git clone git@:/.git
“`
を叩く
参考ソース：
https://zenn.dev/hironorioka28/articles/35a287ffbcf533

### 設定ファイルなしのコマンドのみで実行する場合
“`
GIT_SSH_COMMAND=”ssh -i ~/.ssh/<鍵名> -o IdentitiesOnly=yes” git clone g

Xcode新規プロジェクト作成フロー(githubとローカルリポジトリを紐付ける)

新規プロジェクト作成後の忘備録

【前提】
githubアカウントを所有している。
【Ver】
Xcode 13.4.1
macOS Monterey 12.4

### やることの流れ図
“`mermaid
sequenceDiagram
autonumber
actor わたし
participant remote as リモートリポジトリ
participant local as ローカルリポジトリ
participant xcode as Xcode
わたし->> remote: 新規リポジトリ作成
Note left of remote: New repository
remote->> remote: .gitignoreに.DS_Storeを追記コミット
remote->>local: ローカル環境へクローン
Note left of local: git clone
xcode->>xcode: 新規PJ作成
　　 Note left of xcode: ディレクトリの整頓

リリース時にリリース内容をコメントする GitHub Actions のご紹介

# はじめに
リリース時にリリース内容をコメントする GitHub Actions を作ったので紹介します。

# リポジトリ
[Release Menu](https://github.com/noraworld/release-menu)

# 動作
具体的な動作としては、リリースブランチ (名前が `release` で始まるブランチなど) からプロダクションブランチ (`main` ブランチなど) にマージする PR を作成した際に、その中に含まれる変更内容の PR 一覧をリリース PR のコメントに残します。


また、オプションとして Slack に投稿する機能も実装しています。

![](https://raw.githubusercontent.com/noraworld/release-menu/

SourceTree（ソースツリー）| checkout（チェックアウト）| ブランチを切り替える

## checkout（チェックアウト）とは
Git：ブランチを切り替える
英語：宿泊施設の退館手続き、物品の貸出手続きなど
## SourceTree のやり方
### ローカルブランチ
ブランチをダブルクリック
### リモートブランチ
リモート>origin>「対象のブランチ名」
▼
右クリック
▼
「”origin/対象のブランチ名” をチェックアウト」クリック
▼
デフォルトのまま「OK」クリック

## コマンドのやり方
“`
git checkout ブランチ名
git checkout -b ブランチ名 //ブランチの作成とチェックアウトを同時に行う
git checkout -f ブランチ名 //ブランチを強制的に切り替える
“`
## 参考
– [【Git入門】チェックアウト(checkout)とは？使い方を基礎から解説！](https://www.sejuku.net/blog/71457)
– [【SorceTree】リモートブランチのチェックアウト【ブランチの切り替え】](https://yu-report.com/entry/sourcetreechec

2分で分かるGitHub

# 動画

# 内容
GitHubは複数人で開発をする際に使用します。
リモートリポジトリでソースコードのバージョン管理を行います。
ローカルリポジトリにダウンロード後、開発作業を行い再度リモートリポジトリにアップロードします。


今回は下記について記載します。

まずリモートリポジトリの内容をローカルにコピーします。
そうすると作業ツリーにブランチがコピーされます。その後、ファイルを修正し

バージョン管理に入れるものについて話そうとした時に描いた図

バージョン管理システムには、ソースコードやビルドセットは格納するけれど、バイナリやデータは格納したくない旨を説明する時に描いた図です。
パラメーターの発生源が不確かなので、もう少し精査する必要があります。


【Git】git stashのメモ

### 一時退避させる
“`Bash
# saveは省略可能
git stash save
git stash

# 任意メッセージを加えてsaveする
git stash save “hoge”
“`

### 未追跡のファイルも含めて全てスタッシュ
“`Bash
git stash -u
“`

### 保存されているスタッシュを一覧表示する
“`Bash
git stash list
“`

### N番目のスタッシュを適用し、残す
“`Bash
# NはN番目
git stash apply stash@{N}
“`

### N番目のスタッシュを削除
“`Bash
# NはN番目
git stash drop stash@{N}
“`

### N番目にスタッシュしたファイルを表示する
“`Bash
# NはN番目
git stash show stash@{N}
“`

### N番目にスタッシュしたファイルごとの変更内容を表示する
“`Bash
# NはN番目
git stash show -p stash@{N}
“`

### スタッシュ

【Github】初めてチーム開発へ参加してみて学べたこと

# 目次

[1.はじめに](#1-はじめに)
[2.チーム開発におけるマナー](#2-チーム開発におけるマナー)
[3.チーム開発の流れ](#3-チーム開発の流れ)
[4.まとめ](#4-まとめ)
[5.今後の課題](#5-今後の課題)

# 1. はじめに

この記事はチーム開発を経験したことがないプログラミング初学者向けの記事です。

記事の内容はチーム開発を円滑に行うために、最低限知っておきたいGit・Githubの使い方を含めます。

Git・Githubの自体の細かい仕様については解説しませんので、その点ご留意ください。

私自身もプログラミング学習中ですが、3人で1週間のチーム開発を行いました。
エンジニアではありませんが、チームでのGithubの管理者を経験しました。

これからチーム開発を行なわれる方へ向け、私の得た経験を共有いたします。

# 2. チーム開発におけるマナー

まず初めにチーム開発において大事だと感じた3点を記載します。
あくまでも私の主観ですので、一意見とご認識ください。

a. チーム開発のゴールを認識しよう
b. プロジェクトの進捗に影響を与え

git switch, git restore, git grep, git blameを使ってみよう

https://git-scm.com/

毎日息を吸うようにgitを使っているけど、gitのドキュメント見たことないなと思って実際に読んでみました。あまり使われていないが、便利そうなgitコマンドを見つけたので、共有します。

– `git switch`
– `git restore`
– `git grep`
– `git blame`
– `git log -p `
– `git commit –amend –no-edit`

## `git switch`

ブランチを切り替えるコマンドです。`git checkout`でできるのに、なぜわざわざ`git switch`を使うのかって思っていましたが、この記事を読んで意図を理解しました。

https://www.banterly.net/2021/07/31/new-in-git-switch-and-restore/

簡単に説明すると`git checkout`は

– `git checkout ` ブランチ・コミットを切り替える
– `git checkout —

【Git】cherry-pickを利用して別のブランチにある特定のコミットを取り込む方法

## はじめに
業務でGitを触る際にcherry-pickコマンドを利用して現在いるブランチに別のブランチにある特定のコミットを取り込む機会があったので、ついでに記事にしていきたいと思います。

## 今回やること
以下のように別のブランチにある特定のコミットを取り込みます。


## 作業手順

### 特定ブランチを取り込みたいブランチに移動する。

“`zsh:コマンド
git checkout <特定のブランチ>
“`

“`zsh:コマンド例
git checkout update-readme
“`

### 事前にコミットログを確認する。

“`zsh
% git log –oneline
2ce9304 (HEAD -> update-readme, origin/update-readme

特別な理由なしにgit-flowを新規採用するべきではない

追記:

その1: おかげさまで予想以上の反響をいただき、驚いております。少し過激なタイトルになっていましたので、修正いたしました。
その2: kumagi さんがいいことを書いてくれていた。本当にそうで、git-flow有識者による反論記事待ってます。

git-flowは実は僕も最後まで良さが分からなかった（masterブランチが壊れていない事はテストで確認すべきで、developブランチからマージする儀式で担保するものではないと思う）ので、gif-flow最高だよっていう角度からの反論を期待している https://t.co/q0BTVx0TfS

— くまぎ (@kumagi) July 11, 2022

その3: 本記事における git-flow とはワークフローのことで、同名のツールのことではありません。

追記ここまで

私がこれまでGitの研修講師やブランチ戦略のコンサルティングをおこなってきた経験に基づいて、この記事を書きます。

Gitのワークフローについては自転車置き場の議論になりがちであまり乗り気がしないのですが、最近少し発見があったのと、実際に多くの現場で明らかにフィットしないのに git-flow を検討したり採用したりしようとして苦労をしている様を目撃することが多いので書くことにしました。

この記事で主張する内容はタイトルの通りですが、まず前提として以下

git init する際に hint が大量に出てしまう

## 概要
`git init` する際に大量に hint が表示されてしまう。

“`sh
$ git init
hint: Using ‘master’ as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint: git config –global init.defaultBranch
hint:
hint: Names commonly chosen instead of ‘master’ are ‘main’, ‘trunk’ and
hint: ‘development’. The just-created branch can be renamed via this

git ブランチ作成

“`terminal
git fetch
git checkout -b new_branch origin/main
git push -u origin new_branch
“`

【Git】VimをGitのエディタのdefaultに設定する方法

## はじめに
VimをGitのエディタのdefaultに設定する方法を書いておきます。

## 本記事を書こうと思った背景
自宅のPCでTerraformのコードを触っている中で`git rebase`を実施しようとした際に、「atomのコマンドは存在しない」というエラーが表示されたため。

“`zsh
% git rebase -i –autosquash 9fd7947
hint: Waiting for your editor to close the file… atom –wait: atom: command not found
error: There was a problem with the editor ‘atom –wait’.
%
“`

既にatomはアンインストール済みですが、Git側の設定を変更することを忘れておりました。

## 対応
`Vim`をgitのエディタのdefaultに設定する。

“`zsh:コマンド
git config –global core.editor vim
“`

設定確認は以下になります。

“`z