今さら聞けないGit 2023年09月20日

今さら聞けないGit 2023年09月20日

GithubでGit利用開始の手順

GitHubで新しいリポジトリを作成し、ローカルリポジトリと連携する手順のメモ。

1. 新しいリポジトリの作成
GitHubのサイトにログインして、新しいリポジトリを作成する。リポジトリを作成したら、そのリポジトリのURLをコピーしておく。

2. ローカルリポジトリの初期化
Gitのバージョン管理を行っていないプロジェクトでGitを利用する時にローカルリポジトリを初期化します。
“`
git init
“`

3. 最初のコミット
最初に空のコミットを作成して、履歴のスタート地点を作る。
“`
git commit –allow-empty -m “first commit”
“`

4. リモートリポジトリの追加
GitHubのリポジトリのURLを使用して、ローカルリポジトリと連携させるための設定を行う。
“`
git remote add origin [GitHubから取得したリポジトリのURL]
“`

5. リモートリポジトリへのプッシュ
ローカルの変更内容(この場合は最初のコミット)をリモートリポジトリにアップロードするための「プッシュ」を行う。
“`

元記事を表示

Gitの概要を解説

Gitに関する基本的な用語を定義し、
またそれらの関係性を図で説明することで基礎を固める。

# 目次
[Gitとは?](#Gitとは?)
[概要図](#概要図)
[用語一覧](#用語一覧)
[Git利用の流れ](#git利用の流れ)

# Gitとは?
 バージョン[^version]管理システム。
 ファイルやディレクトリの変更内容を記録し、それを履歴として管理する。

# 概要図
git_diagram.jpg

# 用語一覧
#### ・リポジトリ[^repository]
 ファイル(ディレクトリ)の変更履歴を保存する場所。

 **種類**
 リポジトリは2種類あり、
 *リモートリポジトリ*はサーバに置き、複数人で共有する。
 *ローカルリポジトリ*

元記事を表示

git の使用ケースごとの対応をまとめる

## はじめに
これは自分用の備忘録として書くため、大変見にくいと思います。
ご覧いただく際はご了承ください。
また、情報が溜まったら随時書き足していきます。

## ケース
### 新しくプロジェクトを始める時
あらかじめ新しいリポジトリをGUIにて作成しておいてください。
“` sh
cd [ プロジェクト直下 ]
git init
git remote add origin [ リポジトリのURL ]
git fetch
git merge origin/main
git add .
git commit -m “first commit”
git push origin main
“`
### 開発用のdevelopブランチを作る
拙記事では以下の画像のようなブランチ戦略を取ることとします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/412378/e60cc129-71c9-69c9-8a13-7ee09ea5c0d2.png)

“` sh
git checkout

元記事を表示

ぼっちではやろうと思わなかった`Gitコマンド`基本編

## 目次

– [初めに](#初めに)
– [1. `git add .`](#1-git-add-)
– [2. `git branch`](#2-git-branch)
– [3. `git pull`](#3-git-pull)
– [4. `git checkout -b [ブランチ名]`](#4-git-checkout–b-ブランチ名)
– [5. `git branch -D [ブランチ名]`](#5-git-branch–D-ブランチ名)
– [6. `git diff`](#6-git-diff)
– [7. `git commit -m “コメント”`](#7-git-commit–m-コメント)
– [8. `git push origin [ブランチ名]`](#8-git-push-origin-ブランチ名)
– [9. Mergeリクエスト (Pullリクエスト) を出す](#9-Mergeリクエスト-Pullリクエスト-を出す)
– [実際に経験したので追記コマンド](#実際に経験したので追記コマンド)
– [11. `git log –one

元記事を表示

株式会社エイチームの5daysインターンに参加した話

## 記事の概要

本日、5daysインターンが終了したので、5日間という短い期間の中で何をしたのか、どのようなことを学んだのか、エイチームに向いていそうな人について書きました。

https://www.a-tm.co.jp/recruit/news/39388/

![DSC_1700.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2989040/5f11869b-caa9-b26d-8880-81028cb91c5f.jpeg)

## なぜエイチームのインターンに?

サポーターズの`エンジニアサマーインターンExpo`にエイチームが出展していたことや、私自身、生まれも育ちも名古屋であり、エイチームという名前はよく見聞きしていたことが会ったことがきっかけです。

また愛知県の特徴としてTOYOTAをはじめとした製造業が強いため、組み込み系の就職先で埋め尽くされていることもあり、東海地区で一番大きいWeb系で働くことができるのは、ここ以外にほぼないことも挙げられます。

最後に **「エイチームに

元記事を表示

あんまり知られていないけど、地味に便利なgitコマンド

## はじめに

web系の企業でエンジニアをしながら個人的にもサービスを開発している橋田至といいます。

皆さんはgitコマンド使ってますか?
私は業務で使用するまではgitの意味がよく分かっておらず、add, commit, pushまで一気にやってくれたら便利なのになとか思ってました。

しかし、チーム開発では効率的に開発を進めるためにgitは非常に重要です。
GUIで便利にgitを操作できるツールもありますが、コマンド操作であれば共有が楽なためエンジニアとして会社で働きたい、共同開発したいと思っている人にはgitコマンドを覚えておくことは非常に重要です。

私自身未経験からエンジニアとして働き始めて、最初の壁がgitでした。
ここができないと開発する環境を整えるところで躓く上、みんなに迷惑がかかってしまいます。

実際私は働き始めて一週間後にアサインされた現場で`git push origin main –force`を実行してしまい、大変なことになりかけました?

他の方がローカルにmainブランチを落と

元記事を表示

gitコマンドの備忘録

レコチョクハッカソンインターンで学んだgitコマンドのまとめ(備忘録)です。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
1\. リポジトリ作成などに使うコマンド

$ git init
->カレントディレクトリにリポジトリを新しく作成する。作成されたリポジトリには「.git」という名前のディレクトリが作成され、gitのプログラムはこの「.git」ディレクトリを使用することで、リポジトリのバージョン変更履歴を管理している。

$ git clone コピーするディレクトリ名(or URL)
->すでに存在しているリポジトリを指定したディレクトリにコピーする。コピーするリポジトリはgithubのURLをコピーして使用することが多い印象。指定するディレクトリは省略可能で、その場合はカレントディレクトリにコピーされる。

$ git push マージ先のリモートリポジトリ マージ元のローカルリポジトリ
->ローカルリポジトリの変更点をリモートリポジトリにアップロードする。ただし自身が想定していない変更をリモートリポジトリにマージして

元記事を表示

GitのSSHキーを指定する方法

# はじめに

私の利用しているWindows環境では、なぜかごく稀にGitHubで使うSSHキーが上手く読み込めなくなることがありますが、この時に利用するSSHキーを強制的に指定することで問題を回避できました。(※これはWindows環境固有の問題なのかもしれませんが…)

そこで、この時の対応手順を備忘録として記事にまとめてみました。

# 手順

## 公開鍵の登録状況の確認

* GitHubにログインして、[Settings] > [SSH and GPG keys] と進み、[SSH keys]の欄に公開鍵が登録されていることを確認します。
* もし公開鍵が存在しなければ、正しい公開鍵をアップするだけで問題が解決するかもしれません。
* この時、手元にある公開鍵の指紋(fingerprint)を確認するには、以下のコマンドを使います。

“`dosbatch:
ssh-keygen -lf {鍵ファイルのパス}
“`

## 秘密鍵の保管場所を確認する

* OpenSSHを利用している場合、以下の`.ssh`フォルダに秘密鍵が保管されていることを確認します。

元記事を表示

gitで変更に特定の文字列を含んでいた場合はコミットできないようにする

自分のデバッグ用に一時的に変更した箇所等を誤ってコミットしてしまわないように、変更に特定の文字列を含んでいたらエラーにする。

.git/hooks/pre-commitを以下の内容で作成。

“`shell
#!/bin/bash

marker_message=”DO_NOT_COMMIT”
echo “check marker message ‘$marker_message'”
git diff –cached|grep ‘^+.*'”$marker_message”
if [ ${PIPESTATUS[1]} -eq 0 ]; then
echo “error. changes contain marker message ‘$marker_message'”
exit 1
fi
echo “OK. changes does not contain marker message”
“`

実行権限を付与
“`shell
chmod a+x .git/hooks/pre-commit
“`

これで以下のような変更を加えた場合にはコミットでエラーになる

元記事を表示

「Gitでのタスク依存関係」タスク1が終わらないとタスク2が進めないときに

## はじめに

基本的に新しいタスクを取り組むときに、`main`または`master`ブランチから新しいブランチを切ると思うよね。しかし、チーム開発でよくある問題で、「このタスクがまだマージされないから、関連するタスクが進めないよ」という時にどうすればいい?

## 具体的な事例

タスク1とタスク2の関係がある。タスク1が終わらないとタスク2が進めない状態。タスク1を先にやって、PR作成して、レビュー待ちの状態になっている。今はタスク2をやると思ったらまだレビューを待っている。

## 解決方法

### ブランチを切る

**基本的に`タスク1`(PR作成したブランチ)からタスク2のブランチを切る!**

git graphを見るとこういう感じ

“`
…—A—B—C master
\
D—F task1
“`

ここで`タスク2`のブランチを切る

“`
…—A—B—C master
\
D—F task1

元記事を表示

【Git】stashコマンド:checkoutし忘れて変更を行ってしまった場合

## checkoutをし忘れて変更を行ってしまったときに

自分がよくやらかすので、備忘録として。。。

以下のようなときに使いこなせると便利
– 実装した内容をまだ作成していないブランチに移動させたい
– 作業途中だけど少しだけ別のブランチに移動したい

### 実装した内容をまだ作成していないブランチに移動させたいとき

1. `git stash`で変更を退避
2. ブランチを作成しcheckout
3. `git stash list`で復元したい退避内容を探す
4. `git stash apply stash@{0}`で退避内容の復元を行う(stash@{0}は手順3で探した復元したい退避)
5. 最後に退避情報が不要となった場合は`git stash drop stash@{0}`で削除する

“`
$ git stash

$ git checkout {移動先のブランチ}

$ git stash list
stash@{0}: WIP on hogehoge: 1234567 fugafuga

$ git stash apply stash@{0}

$ gi

元記事を表示

git fetch vs pull fetchとpullの違い

## 背景
Git でfetchとpullのやりたきことが似ているのでどういう使い分けをしたらいいのか整理したいと思った

## 画像で整理
大まかに言うと、以下画像のような違いがある
![ブランチ整理.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/764409/a5234167-aa1c-30e0-8b19-1a1f1153976d.png)

## git fetchを使うケース
fetchだけをした状態だと、リモート追跡ブランチを最新の状態にする。
ローカルブランチにまでは影響が無いので、コンフリクトも発生しない。
ローカルリポジトリに反映させるには、“git merge“をする必要がある

コンフリクトが発生した時は“git fetch“だけして解消する

## git pullを使うケース
fetchとmergeを一気に行いたい時

元記事を表示

リモート追跡ブランチと上流ブランチ

## 背景
git pull とgit fetchの違いを理解する上でこれらの単語が出てきたので理解する

以下画像を見ながら整理する
![ブランチ整理.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/764409/0bf2cfc8-3435-b23a-5512-29eb4205d39b.png)

## 上流ブランチ
origin/developというリモートブランチをpullしてきた時にローカルにdevelopブランチができるが、
このpullしてくる元のブランチ(origin/develop)のこと

## リモート追跡ブランチ
上流ブランチと、ローカルブランチを関連付けるためのブランチ(DBで言う中間テーブル)
origin/developというリモート追跡ブランチはリモートのorigin/developブランチとローカルのdevelopブランチを接続(追跡)している。

元記事を表示

gitの基本操作を説明してみた

本記事では、プログラムのソースコードを記録するための分散型バージョン管理システムの一つであるGitの基本的な操作について初学者向けに説明します。

私は入社してすぐの研修でgitの操作が慣れるまで難しく、毎日格闘していました。

というわけでその時の私が見てもわかるように心がけ、説明していきたいと思います。

# 目次
– [分散型バージョン管理システム](#分散型バージョン管理システム)
– [gitのリポジトリ](#gitのリポジトリ)
– [gitの操作](#gitの操作)
– [事前準備](#事前準備)
– [usernameとemailの設定](#usernameとemailの設定)
– [clone(クローン)](#clone(クローン))
– [branchの作成](#branchの作成)
– [作業後の操作](#作業後の操作)
– [add](#add)
– [commit](#commit)
– [push](#push)
– [その他](#その他)

元記事を表示

Web技術について

未経験からエンジニアになるまでの勉強の記録。

現在はProgateにてRails,Python,react,HTML5,css3,javascript,
Git,GitHub,SQLあたりを勉強したが、
実際にRailsでWebアプリを作るとなると、
そもそもWebの基礎知識が無いことに気が付いたので、

一度アプリ作成は中断し、「Web技術の基本」という本を1冊読んでみようと思う。
今回はその本の第一章のまとめ。

———–

Web上の文章はハイパーテキストで構成されていて流れは下記の通り。
01. WebブラウザからWebサーバーにハイパーテキストの情報を送信
02. その情報をWebサーバーが受け取り、Webブラウザにコンテンツを返す
こうしてWebページが表示されているが、このやりとりは世界共通で、決められており、
**HTTP**という。さらにセキュリティを高めたやり取りを**HTTPS**という。

WebサイトにはHPなどの静的ページと、検索サイトやSNSなどの動的ページの2種類がある。
さらに、動的ページにはサーバーサイド・スクリプトとクライアントサイ

元記事を表示

【Gitクライアント】forkを使用したプロジェクトのSSH/URLの変更方法

## 経緯

事業所の移動により、社内サーバ(GitLabサーバ)の置き換えが発生、クローンしたプロジェクトURLが変更したことにより、プロジェクトのCommitoやPush、以前のプロジェクトURLでのクローンなどができなくなりました。

社内では非エンジニアの方がGitクライアント「Fork」を利用していた為、手順説明、周知などに手間取ってしまったので、今回備忘録として記事にします。

## 前提条件

Gitクライアント「Fork」を利用している。

今回URLを変えるプロジェクト内容は同一である。
URLの変更のみ(GIt配置場所)が変わった状態。

例:移動前プロジェクトA = 移動後プロジェクトA

## 環境情報

・Windows11
・Git
・Fork

## 手順

①Forkを起動し、プロジェクトURLを変更したいプロジェクトを表示します。
※個人情報に関する部分はグレーアウトしております。
![Untitled.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2602338/ed

元記事を表示

GitからクローンしたLaravelをDockerのみでパッケージをインストールする

## はじめに

こんにちは。
最近,`sail`を用いた開発をすることが多くなりましたね。(自分だけじゃないはず)
自分はパソコン3台(Windows11\*2,MacM1\*1)を使っており,色々なリポジトリをクローンしまくってます。
リポジトリをクローンしたら初めにパッケージが必要になりますが,パッケージをインストールしていないため,`sail`が使えません。
そのパッケージをインストールするためにローカルに`composer`等を入れるのはイヤです。
そこで`composer`等をインストールしなくてもできる方法をまとめておきます。

## `composer install`の実行

とても簡単でした。

“`bash:composer install
docker run –rm \
-u “$(id -u):$(id -g)” \
-v “$(pwd):/var/www/html” \
-w /var/www/html \
laravelsail/php82-composer:latest \
composer install

元記事を表示

アジャイルなノートの書き方入門 〜 構造化ドキュメンテーション

## Note as Code: 簡単に編集ができるアジャイルなノートを書こう

「[アジャイルソフトウェア開発宣言](https://agilemanifesto.org/iso/ja/manifesto.html)」には、「包括的なドキュメントよりも動くソフトウェアを」と書いてあります。

「コードをきちんと書けばドキュメントは要らない」とよく言われますが、そうは書いていません。ドキュメントは必要です。しかし、「包括的な」ドキュメントと書かれているので、あ

元記事を表示

Gitで設定ファイルが変更ツリーに表示されるのを防ぐ

接続文字列などが書かれた設定ファイル(config.json等)が変更ツリーに上がってきてしまい、誤ってコミットしてしまうことがありました。
こういった事故を防ぐために、変更の追跡をしないようにするコマンドを記載します。

### 変更を追跡しないようにする
変更ツリーに表示されなくなり、変更を加えてもコミットできなくなります。
“` shell
git update-index –assume-unchanged .\appsettings.json
“`

### 変更を追跡するようにする
変更ツリーに表示されるようになり、コミットできるようになります。
“` shell
git update-index –no-assume-unchanged .\appsettings.json
“`

元記事を表示

reference brokenエラーでGit fetchできない

## 事象

Sourcetreeで作業中にPCが落ちてしまった

まずSourcetreeがエラーで立ち上がらないので、 再インストールから始める。
インストールが終わって、フェッチしようとすると下記エラー

:::note alert
git -c diff.mnemonicprefix=false -c core.quotepath=false –no-optional-locks -c credential.helper= -c credential.helper=”C:/Users/hogeuser/AppData/Local/ATLASS~1/SOURCE~1/GIT_EX~1/GIT-CR~1.EXE” fetch origin
error: cannot lock ref ‘refs/remotes/origin/master’: unable to resolve reference ‘refs/remotes/origin/master’: reference broken
From https://github.com/*****/*****
! [new b

元記事を表示

OTHERカテゴリの最新記事