今さら聞けないGit 2021年12月22日

今さら聞けないGit 2021年12月22日

[初心者向け]”Git”と”GitHub”の違いがわからない

**[目標]**
“Git”と”GitHub”の区別ができない人へ説明ができるようになる。

**[きっかけ]**
デザイナーの人たちと話してて「GitとGitHubって一緒だと思ってた。」という話をしていた。

—————————-

#「GitHubを略してGitって言ってるんじゃないの?」

:::note alert
A.違います!
:::

####例えば

#####友達と連絡を取りたい時、電話か、メッセージか、手紙かという手段があります。

電話なら→携帯電話、公衆電話、LINE通話など。
メッセージなら→Gmail、LINE、instaのDMなど。
手紙なら→便箋、ポストカード、ハガキなど。

####”友達と連絡を取りたい”という目的のために様々なツールやサービスがあります

それがwebサイト制作やアプリ開発において

####”ファイルや画像を共有したい”という目的があったとします。

共有するための手段は、[Git]か、[mercurial]か、[GoogleDrive]などの**手段**があります。

:::not

元記事を表示

とりあえずのGit入門

初心者がとりあえずGitを扱うためのページ

# Gitとは?

> Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

https://git-scm.com/

# Githubって?

– Github
– GitLab
– Bitbucket

**参考ページ**

https://backlog.com/ja/git-tutorial/

# とりあえずやってみよう

`$`はターミナルやコマンドラインで入力するコマンドであることを表しています。
実際に入力するときは`$`の後から入力してくださ。

## 1回目

Gitを初期化

“`
$ git init
“`

インデックスに変更を追加

“`
$ git add .
“`

コミット

“`
$ git commit -m “initial comm

元記事を表示

複数のGitリポジトリをまとめてPullするBat

batファイルが置かれているフォルダは以下のすべての
Gitリポジトリに対して、stash → pull → stash pop を行う。

“`pull.bat
@echo off

rem batファイルが置いてある場所のすべてのフォルダパスを取得
for /d %%d in (%~dp0*) do (
echo “start————>”%%d
cd %%d

echo “stash————>”
git stash
echo.

echo “pull————>”
git pull
echo.

echo “pop————>”
git stash pop
echo.

echo “————>end”%%d
)

pause
“`

元記事を表示

master にマージ済みのローカルブランチを全部消す

“`bash
for i in $(git branch | grep -v ‘\*’) ; do git branch -d $i ; done
“`

1. `git branch` でブランチ一覧を取得
1. `grep -v ‘\*’` で現在のブランチ(master)を除外
1. for で一つのブランチずつ、 `git branch -d ブランチ名` していく

マージしていないものは、以下のようなエラーで失敗するので問題ない。

“`
error: The branch ‘foobar’ is not fully merged.
If you are sure you want to delete it, run ‘git branch -D foobar’.
“`

元記事を表示

lazygit入門

## tigではできないこと

git操作する際 [tig](https://github.com/jonas/tig) を使っていますが、[tig](https://github.com/jonas/tig) ではできないことがいくつかあります。

例えば

– git branch
– git pull
– git push

実はデフォルトではできないが、~/.tigrc に設定を書くとできるようになるみたいです。
[Tig で Git を自由自在に操作するための .tigrc 設定例](https://qiita.com/sfus/items/063797a1dd8fdc7d032f#fetch–pull–push)

pullやpushをするために設定を書くのは面倒なので、lazygitに入門しました。

## lazygitの概要

lazygitとはGoで作られたCLIのgitツールです。

https://github.com/jesseduffield/lazygit

## install

いろいろな環境に対応していますがMacだと、`brew insta

元記事を表示

【Omnibus GitLab】アップグレード手順(Ver.11 ~ Ver.12.10.14まで)

GitLabサーバーのアップグレードしてますか?
古いバージョンのまま放置されてる方も多いのではないでしょうか?

[GIGAZINE:1Tbpsを超えるDDoS攻撃にGitLabサーバーが悪用されていると判明](https://gigazine.net/news/20211105-gitlab-servers-exploited-ddos-over-1-tbps/)

脆弱性があるGitLabサーバーを悪用されるケースもあるらしいので、
なるべく早めに**最新バージョン**にしましょう。

3部構成で、GitLabのアップグレード手順をまとめます。

– 1.【Omnibus GitLab】アップグレード手順(Ver.11 ~ Ver.12.10.14まで)
– 2.[【Omnibus GitLab】アップグレード手順(Ver.13 ~ Ver.14.5.2まで)]() ※12/23公開予定
– 3.[【Omnibus GitLab】サーバーアップグレードの注意点・エラー対処法]() ※12/24公開予定

### 今回は、**Ver.11 〜 Ver.12.10.14**のアップグ

元記事を表示

コードレビュー時に使用する略称一覧

コードレビュー時に使用する略称を使い方と合わせて紹介します。

PR
プルリクエスト(プルリク)の略。
ちなみにGitLabなどはプルリクのことをマージリクエストと言う。

LGTM
Look Good To Meの略。
自分は良いと思いますという時に使用する。

WIP
Work In Progressの略。
対応中という意味。

FYI
For Your Informationの略。
ご参考までにという意味。

MUST
絶対に直すべき箇所。

WANT
できれば直してほしい箇所。

IMO
In My Opinionの略。
自分だとこう考えるという時に使用する。

IMHO
In My Humble Opinionの略。
Humbleは謙虚という意味。IMOの丁寧な言い方。

NITS
nitpickの略。
些細な指摘の時に使用する。

Q
Questionの略。
自分の知らないことについて質問する時に使用する。

元記事を表示

[初心者向け]sourcetreeを使いたいけど、コマンドとかわからない for mac

[対象]
・**macユーザー**
・業界に入りたてで、コマンドや[git]がわからない人
・とりあえずsourcetreeを使えればいい人
・とりあえずGitHubからクローンしたい人

[前提]
**GitHub**のアカウントを作成済である

#1.ダウンロードする

[公式sourcetreeサイトURL]

https://www.sourcetreeapp.com/

##[Download for Mac OS X]を選択
![1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2388076/f15f4808-fe31-c4c6-2aeb-76af781994f8.png)

##[Important information]のダイアログ表示 

**[内容]:同意しますか?**

**チェック**を入れて**[Download]**を選択

![2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2388

元記事を表示

[初心者向け]sourcetreeを使いたいけど、コマンドとかわからない for windows

[目標]**コマンド操作**を使わずに[sourcetree]を使って[GitHub]からクローンできる

[対象]
・**windowsユーザー**
・業界に入りたてで、コマンドや[git]がわからない人
・とりあえずsourcetreeを使えればいい人
・とりあえずGitHubからクローンしたい人

[前提]
**GitHub**のアカウントを作成済である

#1.ダウンロードする

[公式sourcetreeサイトURL]

https://www.sourcetreeapp.com/

![1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2388076/8ce52fe3-3214-cc1d-6487-2c8b82ca6316.png)

[Download for windows]をクリック

![2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2388076/6f21f09f-b3c6-4f66-be0

元記事を表示

FolkしたリポジトリからのPRをローカルに取り込む方法

コマンドは

“`
git fetch origin pull/PR番号/head:好きなブランチ名A
“`

例えば#1のPullRequestをローカルに取り込みたい場合
ローカルPCで

“`
git fetch origin pull/1/head:好きなブランチ名A
git checkout A
“`

> ref: [GitHubの該当ドキュメント](https://docs.github.com/ja/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally)

ただのgit fetchでPRのブランチも取れると思っていたら、違ったので調べました。

元記事を表示

githubで「.」を押してみよう

## ある日の出来事
不可視ファイルを`command + f`で検索しようと思ったのだが…
肝心の`command + f`を叩き忘れていた。
なんなら検索するリポジトリも間違えていた。
何故なら…
眠かったからだ
![スクリーンショット 2021-12-20 19.02.12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/224153/abf67337-36e7-c79a-091a-1172787d41f1.png)

そして「.」を入力
![スクリーンショット 2021-12-20 19.12.53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/224153/d4cfbf78-f6f6-aeb1-5bcc-14b45ad27c45.png)

「…」
「…」
「何…だと…!?」

こうして深い眠りから解放されるのであった。
めでたし、めでたし

元記事を表示

git GUI クライアントのススメ ~TortoiseGit はいいぞ~

# はじめに
 ソースコードなどのファイルが醸成される過程で辿ってきた遍歴を記録し、またチームメンバーが寄ってたかって編集したことによって生じた複数の未来をいい感じに交わらせるために、git のようなバージョン管理システムを使う機会は多くあると思います。こういったツールが持つ機能や操作にはどのようなものがあり、歴史を管理し時に書き換える際にはそれらをどのように組み合わせていくのかを理解し、手足のように使いこなすまでには数々の困難が待ち構えています。リポジトリ、ワークツリー、インデックス……ただでさえ複雑な機構を漸くそういうものかと飲み込んでなんとか使えるようになったと思ったらコンフリクトが発生し、まだ知らないコマンドを駆使して解消することを求められ……というように。
 git それ自体が複雑怪奇で難解な仕組みであること自体はそういうものなので諦めるとしても、実際に(特に初心者が)使うにあたってその難易度を徒に上げ、ないしは操作を面倒にしているものに CUI があると思います。コマンドの綴りを覚えオプションの綴りや省略形を覚えるまでは毎度毎度 Google 先生やサル先生のお世話にならな

元記事を表示

【Git】ブランチを切り替え忘れて作業してしまった時の対処法-コミット前-

#はじめに
> ブランチ切らずに作業してしまった!
>

Git始めたての頃はよくやってました。

いや、最近でもたまにあります。

そこで、ブランチを切り替えつつ、変更内容も引き継ぐ方法をまとめました。
※個人ブログから技術的アウトプットはQiitaへ引っ越ししたので、こちらは過去に書いたブログとなります。

# コミット前の変更を引き継ぎ、ブランチを変更する

未コミットの場合は、**スタッシュ** でOK

# SouceTreeのコマンドでスタッシュの手順説明

現場ではSouceTreeを使っているので、SouceTreeの手順を記載

### 1. 右上のスタッシュをクリック

![https://cdn-ak.f.st-hatena.com/images/fotolife/h/hiroism0329/20210112/20210112162913.png](https://cdn-ak.f.st-hatena.com/images/fotolife/h/hiroism0329/20210112/20210112162913.png)

### 2. スタッシュをクリッ

元記事を表示

github delete keychain

# https://docs.github.com/en/get-started/getting-started-with-git/updating-credentials-from-the-macos-keychain

元記事を表示

LaravelでHerokuデプロイ(git push heroku master)するとThe ‘composer install’ process failed with an error.が発生

## はじめに
こんにちは、[@kazuma_dev](https://twitter.com/kazuma_dev)です。
とあるTechPitのチュートリアルでHerokuデプロイエラーが起きたのでメモ。

https://kazumadev.herokuapp.com/

## 前提・実現したいこと
– `Laravel`でHerokuデプロイ`git push heroku master`すると`The ‘composer install’ process failed with an error.`が発生

## 発生している問題・エラーメッセージ
– `laladock`ではなく`laravel`ディレクトリにてHerokuデプロイ

“`zsh:zsh
~/laravel-sns/laravel $ rm -rf .git
“`

“`zsh:zsh
~/laravel-sns/laravel $ git init
“`

“`zsh:zsh
~/laravel-sns/laravel $ git add .
“`

“`zsh:zsh
~/laravel

元記事を表示

リリースノートみんなどうしてます?~ある現場の場合+社内のちょっとした便利ツール発展の経緯~

## 導入
リリースノートの情報って、皆さん、どのようにして集めています?
結構大変ですよね?

Excel で地味に管理したり
課題管理ツール(JIRA,Backlog 等々)から完了したものを抽出したり
と色々とやっていると思います

今のプロダクトでは Git のログを元にして作っているんですが、そこでも地味に変遷がありまして、その話を書いてみます。

## 基本
Backlog の課題で管理しているのですが、基本的に Git のログのタイトルは Backlog の課題番号+課題名に統一しています。
ですので、今回リリースする分の commmit 間(基本は前回リリース tag ~今回リリース tag)のログに存在する課題=リリース対象=リリースノートの元となっていて

| Git の log | 加工 |リリースノートの元 |
|:-:|:-:|:-:|
|DevOps の設定調整
HOGE-1353 ~な障害の修正
HOGE-751 ~機能の実装
Merge branch ‘~’
| → |HOGE-751 ~機能の実装
HOGE-1353

元記事を表示

gitでエラー fatal: remote origin already exists が出てきた

#はじめに
gitの学習中にてエラーが出てしまった

#エラーの内容

“`
$ git remote add origin https://github.com/user名/repository名.git
fatal: remote origin already exists.
“`

#解決方法
エラーの内容にある通り既にoriginは存在していますよーとのこと。
調べてみるとrmコマンドでoriginを消してから再度addすれば良いなどの記事がありました。
ですが、そもそもoiginが存在しているので

“`
$ git push -u origin main
“`

で普通にpushできました。

#反省
gitの概念がわかっていないためエラーが出て時間を使ってしまいました。
基本的な概念をもう一度インプットしたいと思いました。

初心者が故のなんともお恥ずかしいエラーの記事でした。

元記事を表示

駆け出しエンジニアがgitを基礎から叩き込む(HEADと追跡ブランチ)

ユータローです。昨日今日と自分用の備忘としてまとめていましたが、いい機会だったのでQiitaを初更新してみます。間違ってたらすいません。

#書いた理由
Gitを始めて触ってから一年ほど。業務に入ってからpull requestやブランチのマージという初歩的な部分でつまづくことが多かったので、一旦gitの基礎から叩き直すことにしました。

これまでの認識としては

“`ruby:qiita.rb
git add ファイル   #ファイルをステージ(という一時保管場所におく)
git commit -m ‘messaage’   #変更内容を記す
git push origin ブランチ    #公開する

“`

程度で、一連の作業としてとりあえずやっておけばいいようなところがあったと思います。ただ当然ながらこれではイレギュラーの事態が起こった時に対応することができず、コマンドを試しに打ってみて動くか確かめるような状態でした。

—————————————

よくあるイレギュラーの事態としてはブランチを

元記事を表示

git-allでgitを入れるとWEBサーバがインストールされる件

## はじめに
https://git-scm.com/book/en/v2/Getting-Started-Installing-Git に記載してあるとおりにgit-allでインストールしてしまうと意図せずサーバが起動して様々なリスクとなる可能性がある。
インストールされる理由としてはGitWebを使用する為なので、GitWebを使用していない人はgit-allではなくgitのみをインストールしたほうがよい。(同ページ記載のhttps://git-scm.com/download/linux の方法)

## 簡単な検証
### 検証環境
– Ubuntu 20.04

### git-allインストール前の使用中のポート
“`bash
$ sudo lsof -i
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
systemd-r 609 systemd-resolve 12u IPv4 23743 0t0 UDP localhost:domain
systemd-r

元記事を表示

環境構築 ~WindowsにShopify-CLIをインストールする~

WindowsのPCにShopify-CLIをインストールするまでの工程を解説します。
今までのShopifyのテーマ改修では[Theme Kit](https://github.com/Shopify/themekit)が使用されていましたが、
Online Store 2.0からShopify-CLIを使用する必要があります。

# 環境構築
Shopify-CLIをインストールする前に

– Ruby(バージョン2.7以上)
– Git

が必要になります。すでにインストールされているのかコマンドプロント/ターミナルで確認してください。
不足している場合はインストールします。

## 確認方法
“`Linux
$ ruby -v
“`
“`Linux
$ git –version
“`
インストールされている場合は、バージョン番号が返ってきます。

“`linux
$ ruby -v
ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x64-mingw32]
“`
“`linux
$ git –version
gi

元記事を表示

OTHERカテゴリの最新記事