今さら聞けないGit 2022年04月06日

今さら聞けないGit 2022年04月06日

gitまとめ

# ファイルの出入り
git init
git add .
git commit -m “first commit”
git status

git remote origin
git push origin main

# チェック
ssh -T git@github.com
git remote -v

元記事を表示

GitHubへのプッシュ時にfatal: remote origin already exists.と表示された場合の解決策

# はじめに

こんにちは、かずやです。

この記事を読んでいるみなさんは、以下のエラーのせいでGitHubへリポジトリをpushできずお困りかと思います。

“`
$ fatal: remote origin already exists.
“`

本記事ではこのエラーの解決方法を順を追って紹介してまいります。

記事のとおりにコマンドを実行していけば、上記のエラーを解消しGitHubへpushできるはずです。

# 問題

`fatal: remote origin already exists.`と表示されてしまい、リポジトリをGitHubへpushできない

# 解決策

以下の3ステップでこのエラーを解消できます。

## ①originを削除する

`fatal: remote origin already exists.`は「すでにoriginが存在している」という意味です。

この状態を解消するために`git remote rm origin`というコマンドを入力してoriginを一度削除してください。

“`
$ git remote rm origin
“`

元記事を表示

Go+CodeCommitで任意の名称のライブラリを作成・利用する方法

# 目的
Goでモジュールを作成する際には`go mod init`で任意の名称を指定することができます。
しかし AWS CodeCommit を利用時にはCodeCommitのホスト名(`git-codecommit.${AWS_REGION}.amazonaws.com`)を使用する必要があります。
そこでCodeCommitを利用しつつ任意の名称でGoのライブラリを作成する方法を調査したのでそのやり方をまとめます。
# 経緯
こんな感じです。
– プロジェクトではCodeCommitを使わないといけない
– ~~モジュール名にCodeCommitのホスト名が含まれると、別リージョンにリストアした際にクライアント側からアクセスが出来なくなる~~
– 所感にも記載しましたが、Gitのホスト名を置換する機能を使うと解決です
– モジュール名にCodeCommitのホスト名が含まれることに気持ち悪さを感じている
– Goでライブラリを作成しないといけなくなった!!!

絶対に達成しないといけないわけではなく完全に好みですね。
# やり方
今回実現するのに、Gitのホスト名を置換

元記事を表示

deleted by themを追加したい時の魔法

メモ代わりに残します。

A to B でマージする場合に `deleted by them` が発生したけど追加したい場合、
一度 `rm –cached` して `add` してあげれば良い。
“`
git checkout B
git merge A
#=> deleted by theme: hoge_file
git rm –cached hoge_file
git add hoge_file
#=> new file: hoge_file
“`

元記事を表示

GitHub の公開リポジトリを自分のローカルリポジトリに clone し、自分のリモートリポジトリに設定する

# はじめに
この記事は GitHub 初心者向けの記事になります。
正直、自分は Git のコマンドの意味等をしっかり把握しているわけではないので、「ここ違うだろ」とか「それはこうやるんだよ」とか「ここ誤字!」等あれは指摘していただければありがたいです。
# こんな人に読んでほしい
GitHub に公開されているリポジトリを自分のローカルに持ってきて、デバッグしたり、いじってみたいときありますよね。
そんな時、「せっかくだし Git に慣れるためにもソースコードをいじって commit や push したい」と思う人もいるのではないでしょうか。
でも fork を使うと commit & push した際に、オリジナルのリポジトリを管理する開発者に通知が行ってしまうので fork は使えないしな~と。
参考 [リポジトリのcloneとforkの違い \- Qiita](https://qiita.com/matsubox/items/09904e4c51e6bc267990)

そこで今回紹介するは fork せずに、公開されているリポジトリを自分のリモートリポジトリに設定する方法で

元記事を表示

リモートリポジトリを既存ディレクトリにcloneする方法→git pull

### 実行環境
– windows10のwindows power shell
– —
### ①リモートリポジトリを既存ディレクトリにcloneする方法
簡潔に、以下のコードを実行するとできるはずです!!
`git pull`については②で記載しています…
“`
# 既存ディレクトリに移動
cd [ディレクトリのパス]

# ローカルリポジトリ初期化
git init

# リモートリポジトリの登録
git remote add origin [リモートリポジトリのアドレス]

# 最新のソースコード[origin]をリモートブランチ[main]からローカルにcloneする
git pull origin main

# ブランチ確認
git branch   # ここでmainブランチが表示されれば完了!
“`

### ②git pullについて

今回は`git fetch`と`git merge`を同時に行うことができる
`git pull`について記載します。

– `git fetch`とは
“`
git fetch origin ma

元記事を表示

Gitの基本操作

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

⑴「git init」がリポジトリを作成する
⑵「git add」がファイルをインデックスに追加する(Gitに管理する対象のfileをアップする)
⑶「git commit」でインデックスした内容を変更する
  git commit -m “ここにコメントを記載できます!”

“`
$ git init
$ git add .
$ git commit -m “Initial commit”
“`

### リモートにプッシュする
→超簡単に言えばアップデートしましょうねという話
⑴「git remote add origin “URL”」で新しいリモートの設定
⑵「git push origin master」ローカルのコードをoriginというリモートリポジトリに送る

“`
$ git remote add origin https://github.com/XXXX/XXXXXX.git
$ git push origin master
“`

### アップデートした内容を取り消す
インデックスされた特定のfileの変

元記事を表示

Visual Studio CodeとGitHubを用いたGitバージョン管理方法

# Visual Studio CodeとGitHubを用いたGitバージョン管理方法

無料のコードエディタであるVisual Studio CodeとGitHubを用いたGitバージョン管理方法について、[初期設定](#クローン)から[プルリクエスト](#プルリクエスト)までの実用的な流れと[競合発生時](#競合解消)の解消方法を解説いたします。

# ソフトウェアのインストール
以下のURLから必要なソフトウェアをダウンロードしてインストールします。

* Git
* ファイルの変更履歴等を管理するバージョン管理システム
* https://git-scm.com/downloads
* Visual Studio Code
* 無料で軽量かつ拡張機能が豊富なコードエディター
* https://code.visualstudio.com/
# GitHubのアカウント登録
以下のURLからGitHubを使用するためのアカウント登録を行います。Sign upを選択してアカウントを発行します。(Sign upはアカウント発行。Sign inはログインとなります)

元記事を表示

gitでよく使うコマンドを順に沿って整理してみた。(ブランチ編)

# はじめに
ブランチ編です。
ローカルリポジトリ作成、コミット、リモートリポジトリへのプッシュなどは下記の記事で
https://qiita.com/shular/items/de1a575dec2a0b2b111a

# 前提条件
MacOS Big Sur 11.6.5

# そもそもブランチとは
公式サイト( https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%A9%9F%E8%83%BD-%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E3%81%A8%E3%81%AF )によれば以下の通り書いてありました。
> ブランチとは、開発の本流から分岐し、本流の開発を邪魔することなく作業を続ける機能のことです。

バージョン管理は基本的に、古い変更履歴が新しい変更履歴でどんどん上書きされていくような一本道となっています。
しかし、gitでは、変更履歴の流れを途中で分岐させることができます。これが**ブランチ**と呼ばれる機能です。

# な

元記事を表示

GitHub備忘録

# gitHub備忘録

自分がGit触るために今まで調べたことをまとめる備忘録
(ソース元忘れたものもあります。すみません)

## 新規作成

1. 新しいリポジトリを作成する。
2. トークンの取得
[資料を参考に行う](https://docs.github.com/ja/github/authenticating-to-github/keeping-your-account-and-data-secure/creating-a-personal-access-token)
以下のような場合に使用する。発行されたパスワードはメモしておくこと。

“`bash:terminal
# http
$ git clone https://github.com/username/repo.git
# ssh
$ git clone リンク
Username: your_username
Password: your_token #ここに入力する
“`
3. gitconfigの編集

“`bas

元記事を表示

GitHub 上で表示されるコミットを署名付きにする方法

# 実現できること
この記事の手順を実践すると、GitHub 上のコミット欄に “Verified” マークをつけることができる。

![](https://raw.githubusercontent.com/noraworld/developers-blog-media-ja/master/sign-commits-with-gpg-key/Screen%20Shot%202022-04-03%20at%2015.49.42.png)

単にマークをつけられるだけでなく、そのコミットが本人のものであるということを証明することができる。つまり、[コミットの偽装防止](https://qiita.com/s6n/items/bb869f740a53a3bf169e) ができる。

# 環境
* macOS Big Sur Version 11.6.4
* gpg (GnuPG) 2.3.4
* git version 2.35.1

環境やバージョンによって、以降で使用する `gpg` コマンドの仕様が異なる可能性がある点に留意すること。

# GPG キーの生成
以下のコマンド

元記事を表示

MacのFinderで.gitや.gitignoreが見えない時

Finderで該当フォルダを開いたあと、以下ショートカットキーを押す。
“`
“command + shift + .(dot)”
“`

見えるようになりました
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/533960/03411777-c014-3033-b9a7-91076b196eb1.png)

元記事を表示

Gitのコミット署名の有効期限を更新するために行ったことメモ

約2年前、コミット署名を行うための準備メモを投稿しました。

https://qiita.com/cocoabreak/items/d96cd0ba56cdcbf62d32

PCのクリーンインストールついでに、署名用サブ鍵の有効期限を更新したので記録として残します。
なおこの記事を引用する場合「前回の記事」と記載します。

## ソフトウェアのセットアップ
以前のメモではScoopを使ってGPGをインストールしましたが、今回はwingetを用いました。
“`powershell
❯ winget search gpg
名前 ID バージョン 一致 ソース
—————————————————————–
GPG ICT Summit 9NBLGGH4XT16 Unknown msstore
GNU Privacy Guard GnuPG.GnuPG 2.3.4 Comman

元記事を表示

global git hook を作った話

# 概要

各リポジトリの git hook も読み込みつつ、どのリポジトリでも反映したい git hook がほしいなと思ったので作った

# 成果物

MITライセンスなので、お好きに clone するなり fork するなりしてくださいませ!
使い方は README.md に書いてます🐳

https://github.com/amabie-mamoru/global-git-hooks

# 背景

git hook の既存の仕組みはリポジトリごとに設定するもので global git hook 的な位置付けものは公式にはない
これに対してもちろん先人の方々が色々と global git hook 的な位置付けの記事を投稿されている

それらは以下のようなものがあった

* global git hook 的なもののサンプル
* ローカルの git hook を無視してグローバルの git hook を設定するもの
* 逆にグローバルの git hook をローカルに適応する(コピーする)もの

ただ、チームや団体で扱うリポジトリがある場合、以下のような課題を感じた

* 即使

元記事を表示

Gitの初期設定の備忘録

## 名前とメールアドレスを登録する

“`
$ git config –global user.name “FirstName ListName”
$ git config –global user.email “your_email@gmail.com”
“`

下記のコマンドで設定を確認できる

“`
$ cat ~/.gitconfig
“`

## コマンドの出力を読みやすくする

“`
$ git config –global color.ui auto
“`

## SSH Keyの設定

“`
$ ssh-keygen -t rsa -C “your_email@gmail.com”
“`
いくつか質問されるが全てenterでOK!

## 公開鍵をGithubに登録する

下記のコマンドで公開鍵をコピペしておく。

“`
$ cat ~/.ssh/id_rsa.pub
“`

「add deploy key」からキーを登録する。Keyに公開鍵をコピペする。Add keyする。
![スクリーンショット 2022-04-02 23.20.48.p

元記事を表示

【GitHub】GitHubにアップロードする際のメモ

# はじめに
ローカルのプロジェクトを初めてGitHubにアップロードする際のコピペ用メモです。

# ターミナル

“`
cd [プロジェクトをドラッグ&ドロップ]

git init

git add .

git commit -m “initial commit”
↓@の追加し忘れに注意
https://[アクセストークン]@github.com/[ユーザ名]/[リポジトリ名].git

git push -u origin main

強制的にプッシュする場合
git push -f origin main
“`

# おまけ
もし初学者の方で参考にされる際にアクセストークンってどこにあるの?ってなった場合は下記のページの最後に載せてあります。

https://qiita.com/_mkt_/items/689b49bb9b58239f6165

元記事を表示

【git】会社のGithub git repository を自宅Linuxマシンにclone して開発する

# はじめに

会社のGithub git repository を自宅Linuxマシンにclone して開発するとします。そのとき、

– 自分のアカウントを切り替えないと、自分の個人活動のアカウントで会社のgit repository に commit してしまいます。Pushは会社のアカウントでおこなわれているとしても、そのcommti tree に個人のアカウントがあることになり、恥ずかしい。
– 会社のGithub にssh-key を登録しますが、それは個人のアカウントとは違います。切り替え作業無しで行いたい。

という課題があったのですが、普通に解決できたのでメモしておきます。
~~会社の仕事もLinuxマシンで開発できれば効率的で良いのだけれどね。~~

# 内容

### 1. 会社用のssh-key を用意して会社アカウントのGithub に登録する

普通に鍵を作ります。ファイル名を指定し、既存のものと区別するようにしましょう。

“`bash
cd ~/.ssh
ssh-keygen -t ed25519 -C iam.slave@submissive.com

元記事を表示

Git 基礎構文メモ

gitは全く触った事ないのでメモ
説明はほぼ無しですがざっくり記載します、前提としてgitはインストール済み
## Git
### Gitの設定変更
“`
git config オプション名
“`
設定ファイルは3種類()内はオプション名
マシン全体に対する設定 “`/etc/gitconfig(–system)“`→基本触らない
ユーザーごとの設定 “`~/.gitconfig(–global)“`
プロジェクトごとの設定“`.git/config(オプション名は無し)“`
“`
$ git config –global core.editor ‘code –wait’
$ git config –global color.ui auto
$ git config –global user.name “ユーザー名”
$ git config –globa user.email “メールアドレス”
$ git config –global -l
“`
### ディレクトリ作成
“`
mkdir ディレクトリ名
cd ディレクトリ名
ls -a
`

元記事を表示

Docker ComposeとGitHubを使用して、Node.js + Express + MySQLの環境構築を行う

# 初めに
Docker Composeを使用して、Node.jsとMySQLのコンテナを作成し、Sequelzieを使用してDBにアクセスするところまでを記載する。
また、Node.jsのコンテナ上でExpressのプロジェクトを1から作成する記事は多く見かけたが、既にあるGitHubのリポジトリ(ExpressとSequelizeを含む)をcloneしてそこから環境を構築していく記事はあまり見受けられなかったので、今回はそちらの手順で行う。(実際に現場で開発する際は、既にGitHubが作成されている場合もあると思われるため)

#### 今回やりたいことの図
![SnapCrab_NoName_2022-4-1_10-29-57_No-00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1229062/bb0c1684-1998-7692-c970-899ba13c904c.png)

# 環境
■ 使用PC
MacOS Big Sur:バージョン11.6

※既に使用PCにはgitを導入状態

元記事を表示

AzureReposとGitHubを運用中のコンフリクトを解消するGit操作

## 現象
masterブランチにdevelop(staging)ブランチのマージプルリクエストを送ったとき、コンフリクトが発生。

## 原因
developおよびstagingブランチをmasterから派生後、何者かがmasterに直接変更を加えたファイルとコンフリクト。

## 前提条件
エディタはVSCodeを利用。
GithubとAzureReposと2つのリモートリポジトリで運用している。
origin がGitHub
azure がAzureRepos
とする。

## コンフリクトを解消してmasterマージする流れ

### 1. GitHubのdevelopブランチをAzureReposのdevelopブランチにプッシュする

“`
git checkout origin/develop
git pull origin develop
git push azure develop
“`

### 2. developでの動作確認が完了したのでstagingブランチにプッシュする

“`
git pull azure develop
git push azur

元記事を表示

OTHERカテゴリの最新記事