今さら聞けないGit 

今さら聞けないGit 

git 作業覚書

# はじめに
Gitによる開発管理を一度通してやってみようと思ったので、その覚書を作成する。

# 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をインストールした。

# インストールの確認
VS codeで統合ターミナルを開き、以下のコマンドを実行
“`
git –version
“`
すると、以下のように返ってきたのでOK
“`
git version 2.40.0.windows.1
“`

# Gitの初期設定
以下のコマンドでgitの名前、メールアドレスを登録する
“`
git config –global user.name “Hoge”
git config –global user.email hoge@gmail.com
“`
この時、–globalではなく

元記事を表示

git pushの引数省略の設定

# 前提

 リモート接続時に、“`git remote add origin “`とリモートリポジトリの名前をoriginに設定。ちなみに“`origin“`は必須でなく、任意の名前をつけられる。

# 結論
“`
git push -u origin main
“`

設定ができているかは以下のコードで確かめる。
“`
git branch -vv

# 結果
* main 0315f63 [origin/main] initial commit
“`
“`[origin/main] “`を含めば成功。

以降 main ブランチで作業中に“`git push“`の引数を省略して実行すると、自動的にoriginの mainブランチにプッシュされる。
楽なので最初にブランチをプッシュをする時はuオプションを使うと良い。

間違いがあったらぜひ教えてください!

元記事を表示

Gitでコミットした後にメッセージを修正する

## 環境
Ubuntu 20.4
Git 2.25

## はじめに
コミット(git commit)した後でもメッセージを修正することができます。修正するコマンドは、状況に合わせて、2種類のコマンドがあります。

– 直前のコミット(HEAD)に対して修正する
– 過去のコミット(HEAD以降)に対して修正する

## 直前のコミットに対して

コマンドの雛形は次のようになります。
“`
$git commit –amend -m “修正後のメッセージ”
“`

現在のログの状況です。
“`
$git log –oneline
7869790 (HEAD) abc
ce9d4dd ab
4c0a5a0 aa
“`

直前にコミット(HEAD)したメッセージを修正します。
“`
$git commit –amend -m “修正したよ”
[detached HEAD 86b8012] 修正したよ
“`

abc(修正前)→修正したよ(修正後)に変更されました。
“`
$git log –oneline
86b8012 (HEAD) 修正したよ
ce9d4dd a

元記事を表示

Fork(Gitクライアント)でも「git commit –allow-empty」したい(Windows版)

前職のエンジニアブログの記事を引っ張り出すのは非常に忍びないんですが。。。随分前に「[Fork(Gitクライアント)でも「git commit –allow-empty」したい](https://tech.innovator.jp.net/entry/2018/09/25/120402)」という記事を書きました。

上記の記事ではMac版についての説明でしたが、今回はWindows版について書いてみようと思います。

### Forkとは

話を先に進めちゃってますが、そもそも[Fork](https://git-fork.com/)をご存知でしょうか。
「Fork」というキーワードから「Git」を連想された方は正解です。
ForkはシンプルなUIが特徴のGitクライアントです。
GitHubの[Fork](https://docs.github.com/ja/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo)と名前が衝突している点が少々イマイチではありますが、わりと好

元記事を表示

Git リポジトリを作ったときに大体実行するコマンドたち

## 概要

リポジトリを作ったときに大体実行するコマンドたちを簡単にまとめます。(筆者の場合です。)

## 詳細

実行する順番に羅列しておく。

“`shell
git init
git config –local user.name ‘自分の名前’
git config –local user.email ‘自分のメールアドレス’
git branch -M main
git commit –allow-empty -m “first commit”
git remote add origin リモートリポジトリアドレス
git push -u origin main
touch README.md
git add README.md
git commit -m “READMEの追加”
git push origin main
“`

このあとはREDMEを記入してコミットしたり、その他のファイルをコミットしたりする。

元記事を表示

gitコミットの取り消し

直前のコミットを取り消すには
“`
git reset –soft HEAD^
“`
ワークディレクトリの内容はそのままでコミットだけ取り消すことができる。

元記事を表示

【Git入門】チーム開発で必須なGit!基本の使い方を中学生でもわかるように書いてみた!

どうも、あかつきゆいとです。
UniProjectの創設者やってます。

今回はチームメンバーで、Gitの使い方がよくわかってない人、わかってるけど、
「てめぇその使い方はねぇ」って使い方を過去にしてて少し心配だった人がいるのでちょっと書いてみました。

# What’s Git?

Gitとはバージョン管理ツールのことですね。
バージョン管理ツールってのは、文字通り、ファイルやディレクトリの移動や作成、変更を記録してくれるものです。

## これがあると何が便利か?

これがあると、
「あ、やべぇ、間違ってファイル消しちまった」
なんて時でも、元に戻せます。

他には、チームメイトとファイルやディレクトリの更新を同期できるのでかなり捗ります。

## Install

これを見れば大体わかります。

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 resetの動き

## 環境
Ubuntu 20.4
Git 2.25

## はじめに
git resetの3つのオプションの違いについて書いてみました。
– –soft
– –mixed
– –hard

##### –mixed
ステージングエリアだけをクリアし、ワーキングディレクトリはクリアしません。git addした後、「このまま、commitしないで、やっぱり取り止めよう」となった場合に使います。

##### –hard
ワーキングディレクトリが、過去のコミット履歴の状態に戻ります。ステージングエリアに上がっているファイルがあればクリアされます。

##### –soft
コミットの取り消しだけが行なわれます。ステージングエリアとワーキングディレクトリの内容は、クリアされず現状のまま残ります。

## –mixedの動き
test1.txtとtest2.txtの2つのファイルを修正した後、ステージングエリアに上げます。
“`
$git add .
$git status
Changes to be committed:
(use “git restore –stag

元記事を表示

git hooksを使用して、git commit前に何がしかの処理を実行する

`git commit`前に諸々の処理を実行するのは、テンポが悪くなるため、実際にやるかどうかは要検討かと思います。
その上で備忘録として記事を残します。

### 最終的にやりたいこと
`git commit`実行前にfastlaneでテストを実行する
→[git hooksをトリガにしてfastlaneからユニットテストを実行する](https://qiita.com/wtrmiya/items/5adc97ca1c3dd1c7d311)

### この記事で記載していること
`git commit`実行前に何がしかの処理を実行する

### 前提
– ターミナルから`git commit`を実行してコミットする

### 本題

https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA-Git-%E3%83%95%E3%83%83%E3%82%AF
を参照すると、

“`
フックスクリプトを有効にするには、Gitディレクトリの `hooks

元記事を表示

Gitに不慣れな人はとりあえずgit statusを打ちまくっておけば大体なんとかなる説

# まずは結論

Gitに不慣れなうちは、何か操作をする前にとりあえず `git status` を打ちまくりましょう。
エラーでトラブっている時だけでなく、うまくいっている(と思っている)時も含めてです。
それがミスを未遂にとどめたり、困ったときの指針になったりします。

# 想定読者

Gitの基本は一通り学習済みだけど、以下のようにコマンド操作にはまだ自信がない人。

– トラブルが起きたらとりあえず `git reset –hard HEAD` で初期状態に戻してやり直してる
– ググって出てきたコマンドを打って雰囲気で解決してるけど、あまり理解できてない
– PRをレビューしてもらうとき、Gitの操作起因で間違った状態になっていることの指摘を多く受けたり、その解消に時間を費やしがち

# `git status` が役立つ事例紹介

ここからは、後輩の指導などでも発生した事例をもとに、どこで `git status` を使っていくか説明します。
実際に私は後輩を指導する時も「とりあえず `git status` しよう」と何度も言っています。

## ケース1: 「P

元記事を表示

Git hooksを使ってコミット時のルールを共有したい

タイトルの状況で色々と調べた内容をまとめました。
この辺を何もかも忘れているだろう数ヶ月後の自分に向けて書いています。

# 状況

やりたいこと
READMEなど、無断で変更されると困るファイルが誤って更新されてしまうことを防ぐために、特定のファイルをコミットしようとした時はエラーを出すようにしたい
使用OS
macOS 12.6

# 手順
## コミット時のルールを決めたい(一人用)
(前提: `git init`等でGitリポジトリが作成されている)
1. プロジェクトのディレクトリ配下にある「.git」ディレクトリに移動
(隠しディレクトリなので、表示されない時は「cmd + shift + .」キー押下で表示する)
2. 「hooks」ディレクトリ内にある pre-commitファイルを開く
3. 上記ファイルにルールを書き込む
4. pre-commitファイルに実行権限を付与する

## コミット時のルールを共有したい(複数名向け)
1. テ

元記事を表示

gitブランチが壊れた時の対処法

# ブランチが壊れてしまった

masterブランチに移ろうとしたら、以下のエラーが出てしまい、移動することができなくなってしまった。

`git switch master
fatal: bad object refs/heads/mobileToPC 2`

これは、`mobileToPC 2`の名前が問題で、スペースが含まれていることが問題であった。
Gitではブランチにスペースを含めることができない。そのため、このブランチを削除する必要がある。

以下のコマンドをうち、ブランチを削除する。
`git update-ref -d “refs/heads/mobileToPC 2”
`

*このコマンドを実行する時は、削除するブランチではないブランチで行うことがマスト!

#### gitブランチが壊れた時、参考になる記事

https://stackoverflow.com/questions/33012869/broken-branch-in-git-fatal-your-current-branch-appears-to-be-broken/4871652

元記事を表示

Gitの取り消しコミットを取り消す最中で取り消す

## コンフリクト解決中に取り消したい

分かりづらいのだが、コミットを一旦取り消してのちほどそれを復活させたいとき(取り消しコミットを取り消す)
コンフリクトが発生してその解決中に操作を取り消すことができる。

このような状態。コンフリクト解決中と見分けがつかない。

“`
$ git status

Unmerged paths:
(use “git restore –staged …” to unstage)
(use “git add …” to mark resolution)
both modified:
“`

## `git reset –merge` を使う

“`
$ git reset –merge
$
“`

## `git merge –abort` はできない

“`
$ git merge –abort
fatal: There is no merge to abort (MERGE_HEAD missing).

$
“`

## 参考

git ブランチ操作 ケース

元記事を表示

[Git] ローカルからリモートにプッシュする手順

## 1. 最新のリモートの情報を取得する
“`
git fetch -p
“`
## 2. 変更ファイルを確認する
“`
git status
“`
## 3. ステージングにファイルを追加する
“`
git add <ファイル名>
“`
## 4. 追加したファイルが正しいか確認する
“`
git status
“`
## 5. コミットする
“`
git commit -m “コミットメッセージ”
“`
## 6. コミットされているか確認
“`
git log
“`
## 7. プッシュする
“`
git push orgin <ブランチ名>
“`

元記事を表示

remote: Repository not found. Git Credential Manager使用

# 事象
別アカウントに切り替えて作業をした後に、元のアカウントに戻すとpushできなくなった。gitへのログインは2段階認証を適用するためGit Credential Managerを利用している。

“`zsh
$ git push origin dev
remote: Repository not found.
fatal: repository ‘https://github.com/<ユーザ名>/<リポジトリ名>.git/’ not found
“`

# 結論
macOSのキーチェーン>ログインからgitの認証情報を削除する。未検証ですが、Windowsでは資格情報マネージャーで同様の操作で解決可能と思われる。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/700284/98ec2c8f-0e1b-e21b-d39e-1286b62a5bc2.png)

元記事を表示

SpringとReactで簡単なWEBアプリを作ってみる – その①

勉強を兼ねて、簡単なWEBアプリを作ってみようかと思います。今回はGitでリポジトリ作成するところから始めます。

### 今回の作業
 ・リポジトリ作成
 ・Springプロジェクト作成
 ・Reactプロジェクト作成
 

### WEBアプリの仕様
今回は以下のようにしたいと思います。(超絶簡単に)

 フロント画面でボタンクリック
  ↓
 API呼び出してDB検索
  ↓
 結果をフロントに渡して表示
  ↓
 Spockでテストまでやりたい
 

### 開発環境
ざっくりと

・サーバ側
 IntelliJ
 Java21(Amazon Corretto)
 Spring 3.2

・フロント側
 VS Code
 React

・DB
 MySQL

Dockerも併せて使ってみたいけど、使い方がよく分からない
 

### Githubでリポジトリ作成
それでは作っていきましょう。「Create repository」をクリックします。
![スクリーンショット 2024-02-03 18.32.00.png](https://qiita-image-sto

元記事を表示

Gitコマンド早見表

# はじめに
個人的によく使うGitコマンドをまとめました。
Gitを既に使用している人向けの記事になります。

# 早見表
##### ローカルの変更内容を全てリモートに反映する際に使用するコマンド
“`
git add –all
git commit -m “コメント”
git push
“`

##### ローカルの変更内容を一部リモートに反映する際に使用するコマンド
“`
git add -p
git commit -m “コメント”
git push
“`

##### ローカルのステータスを確認する際に使用するコマンド
“`
git status
“`

##### ローカルの変更内容を確認する際に使用するコマンド
“`
git diff
“`

##### 現在選択中のブランチを確認する際に使用するコマンド
※–allを追加することにより、リモートのブランチを併せて確認できる。
“`
git branch
git branch —all
“`

##### ローカルのブランチを切り替える際に使用するコマンド
※-bを追加することにより、ブランチの追

元記事を表示

Gitコマンドの使い方

Gitはプロジェクトによってコマンド・GUI操作が分かれており、いまいち理解し切れていない部分があるので、勉強用にまとめてみる。

## 作業の流れ

### ①クローン
資材をローカル環境に取り込む。
“`
> git clone [URL]
“`

 

### ②ブランチ確認・チェックアウト
最初に現在のブランチを確認し、想定していないブランチにいる場合はチェックアウトする。
“`
> git branch
* master   // 大体こういう感じで表示される
develop

> git checkout develop
Switched to branch ‘develop’

> git branch
master
* develop   // ブランチが切り替わっている
“`

 

### ③最新資材をプル
作業用ブランチ(featureブランチ)を切る前に最新資材をプルする。
“`
> git pull origin develop
“`

 

### ④ブランチを切る・チェックアウト
現在のブランチ(今回の例ではdevelop)

元記事を表示

`git rabase -i` を使ってみよう

[git-rebase](https://git-scm.com/docs/git-rebase) はcommitの履歴を任意に書き換え直すコマンドで、使う人は使うけど使わない人は使わない機能だと思う。使い方を知っていると便利なのでちょっとやってみよう。(本記事は社内勉強会で使った文章のリサイクルです)

# 体験コーナー

## ちょっと汚れたコミットログを作ってみる

日々の開発をシミュレートしながらコミットツリーを作ります。業務でコードを書いているところを想像しながら以下のコマンドを実行していってください。全て実行するとちょっと汚れた `dev` ブランチができます。

“`bash
# 0. git リポジトリの作成

cd ~
mkdir git_rebase_practice
cd git_rebase_practice
# git init
git init .

# 1. 最初のコミット

# README作成
cat < README.md
README
EOF
git add .
git commit -m ‘init’

# 2. 機能Aの開発を開始

元記事を表示

息を吸うように使いたいgitのコマンド

gitのコマンドを生まれて初めて叩いてから1か月の自分が、既に100回以上は叩いた&毎回メモから探すコマンド達。
毎回バラバラのメモやURLから探すのも大変なのでまとめます!

## git init

新規でgitリポジトリを作成する。これをしないと何も始まらない。

“`bash
git init
“`

## git status

現在のGitの状態を確認するコマンド。
変更されたファイルがあるか、ステージングエリアに登録されたファイルがあるかなどを把握できる。

“`bash
git status
“`

## git add

ステージングエリアにファイルを登録する。
コミットする前にステージングエリアに登録をする必要がある。

“`bash
git add <ファイル名>
“`

## git commit

コミットするコマンド。`-m`オプションでコメントも一緒に入力できる。

“`bash
git commit -m “コメント”
“`

## git push

ローカルのコミットをGitHubなどリモートリポジトリに登録するときに使う。
add~

元記事を表示

OTHERカテゴリの最新記事