今さら聞けないGit　

GitHubCopilotが使いたい高専生のススメ

# GitHubStudentに登録しよう！

## 何ができる

GitHubStudentに入るとさまざまなことができますがやはり目玉はCopilotでしょう
僕自身今まで無料で使える[Tabnine](https://www.tabnine.com/)をvscodeで利用していましたがCopilotにするとレベルの高さに感動しました

## 申請方法
1:[まずはアカウントを作成](https://github.com/)
アカウントのメールアドレスは自分のものと学生メアド両方を登録しておくことをおすすめします(学生メアドは卒業で消えてしまうため)
2:[Studentパックの申請](https://education.github.com/pack)
学校情報を入力します
3:画像の用意
ここが鬼門です👹
学生証の写真をただ撮るだけでは審査に落ちます
画像をお好きな編集ソフトを用いて以下の処理を行ってください
**自分の名前
学校名
入学・卒業年度
↑↑以下を英語で画像内に入力してください**
あとは数日待てば利用できるようになります
## まとめ
皆さんもGitHubStud

恥ずかしくて大声では言えないけど最近知った2つのgitコマンド

コードを管理するのにgitは利用されていると思います。
私も利用していますが、恥ずかしながら最近2つのコマンドを知りましたので紹介したいと思います！

## `git rm -r –cached .`

.gitignoreが反映されずに、プルリクエスト（マージリクエスト）にignoreされるはずのファイルの変更が表示されてしまう場合があります。

:::note warn
ignoreしたファイルが差分として表示されるのはキャッシュが残っているためです。
:::

`git rm -r –cached [ファイル名]`でファイル名を直接指定することも可能です！

## `git switch`
これまでブランチを切り替えるために`git checkout`を利用してきました。
ただ、`checkout`はブランチを切り替える以外にもファイルの変更を元に戻すためにも利用できます。

:::note info
1つのコマンドで2つの役割を備えているわけです！
今まで考えたことなかったですが、高機能なコマンドですね！
:::

`switch`コマンドはブランチの作成と移動のみを実行

Gitコマンドチートシート

# まえがき
**[DMM WEBCAMP Advent Calendar 2023](https://qiita.com/advent-calendar/2023/infratop)** 14日目記事です。

DWCメンター・卒業生が記事を投稿しておりますので、是非他の記事もご確認ください！

# 初めに
よく使うコマンドを厳選して載せています．
そのため，その他コマンドについては，`manコマンド`などを用いて各自で調べてください．

## git設定

| コマンド | 解説 | 補足 |
|:-|:-|:-|
| git config –list | gitの設定の確認 | |
| git config –global user.name “{name}” | user名の設定 | |
| git config –global user.email “{email}” | emailの設定 | |
| git config –global initdefaultBranch {ブランチ名} | デフォルトブランチ名の設定 | |
| git config

初心者のためのGitとGitHub入門

## Gitとは
分散型バージョン管理システムの一つで、Linuxのソースコードを効果的に管理するために開発されたものです。
以下のものはとても詳しく説明してくれてますので、ぜひ読んでみましょう。
[・さる先生のGit入門　〜バージョン管理を使いこなそう〜](https://backlog.com/ja/git-tutorial/)

### Gitの良さ
1. 変更履歴を順々に記録し、バージョンの差を確認できる
1. 複数の並行するバージョンを扱うことができる
1. どんなものも入れられる(Excelファイルや画像も可能)
1. チームで共有できる
:::note
バージョンを管理することでいつ・誰が・何を変更したかがわかる＋ファイルの最新の状態がわかる！
:::

### Git用語
`リポジトリ`:変更履歴を記録する場所
`commit`:個人リポジトリに変更履歴を記載
`push`:共有リポジトリに変更を共有

:::note
・個人での作業での流れ
自分のパソコンでファイルを変更しコミットで記録する→共有リポジトリに　pushで登録する
:::

`pull`:共有リポジ

Gitの基本操作を作業を例に学ぶ

|目次|
|—|
|[新規ローカルリポジトリを作成してGitHubにアップロードするまで](#新規ローカルリポジトリを作成してgithubにアップロードするまで)|
|[既存ファイルを変更してリモートリポジトリにプッシュするまで](#既存ファイルを変更してリモートリポジトリにプッシュするまで)|
|[リモートリポジトリの最新状態をローカルリポジトリに反映する(fetch-merge版)](#リモートリポジトリの最新状態をローカルリポジトリに反映するfetch-merge版)|
|[リモートリポジトリの最新状態をローカルリポジトリに反映する(pull版)](#リモートリポジトリの最新状態をローカルリポジトリに反映するpull版)|
|[ローカルリポジトリに新しいブランチを作成してリモートリポジトリにプッシュするまで](#ローカルリポジトリに新しいブランチを作成してリモートリポジトリにプッシュするまで)|
|[developブランチ更新してmainブランチに反映するためのプルリクを行う](#developブランチ更新してmainブランチに反映するためのプルリクを行う)|

# 前提事項

Gitの時間旅行者

## 対象の読者
– タイムトラベルしたい人
– 草を生やし忘れた人

## タイムトラベルしよう！

Gitは、開発者がプロジェクトの歴史を管理するための強力なツールです。
特に、–dateオプションを使用してコミットの日付を変更することが可能です。
これは、あたかもあなたが時間旅行者であるかのように、過去や未来の日付でコミットを作成することを可能にします。

構文
“`
$ git commit -m “コミットメッセージ” –date=”Month Day Time Year TimeZone”
“`
例えば、以下のコマンドは、2023年10月16日の21:43:50にコミットを作成します。
“`
$ git commit -m ‘過去に行く’ –date=”Oct 16 21:43:50 2023 +0900″
“`

以下は、1985年10月26日と2015年10月21日にコミットを作成します。これは、映画「バック・トゥ・ザ・フューチャー」のファンには特に面白いかもしれません。

“`
$ git commit -m “I’m Time Traveler” –

プログラマーのための調和の取り方: マージとリベース

Gitのトピックブランチでの作業において、mergeとrebaseの使い方

Gitを使って開発を行う際に、トピックブランチで作業しているとアップストリームの更新があった時にどのように取り込むか悩むことがあります。この記事では、mergeとrebaseの違いと、rebaseをオススメする理由について説明します。

## mergeの問題点

一番単純な方法として、mergeコマンドを使ってアップストリームの変更を取り込むことがあります。しかし、mergeコミットを作ると、後で変更を差し戻す場合に問題が生じることがあります。実際に経験したことがある人なら分かると思います。

また、mergeコミットが含まれると、merge-baseなどのGitコマンドが使い物にならなくなることもあります。

## オススメしたいこと

“`shell
$ git fetch
$ git merge origin/main # ← これを使用せずに
$ git rebase origin/main # ← こっちをオススメしたい
“`

## rebaseの利点

rebaseコマンドは、アップストリ

リポジトリの命名法

# リポジトリの命名について

リポジトリを建立するたびに名称をどうするかで悩む。githubリポって簡単に名称変更できないので、結構悩む。

## 関与している人のイニシャル

むかしむかし卒業研究で研究室配属されていたころ、指導教員から指示されたファイル名とかの命名規則だ。それって関与している人のイニシャルを並べるもので。たとえば、佐藤・山田・田中だとすると、`SYT`. そのあと、1，2ってかんじで序数をつけてたとおもう。いまでも気に入っていて、`git`習いたてのころは、こういう感じで命名してた。

数年してリポ名がわけわからないこととなっていることに気づく。関与している人がやめるとか、部署配置換などで関与しなくなるとか。。。の理由だ。

## ふつうにタイトルにするという選択肢

プログラム開発なら、プログラム名（_e.g._, pytorch…)とか、レポート出すんならレポートのタイトルとか。データ分析の結果格納用途なら、分析手法名 (_e.g._, ADOE….)とか。これだと長すぎることとなりがち。とくにレポートタイトルとなるとどうしても冗長となることとなりがち

git pushを試みた際にエラーが出てしまう件の備忘録（GnuTLS recv error (-54): Error in the pull function）

昔々あるところに、いつも通り何気なく`github`で遊んでいたこと時期がありました。
`git push`時に以下のようなエラーが出て`push`が失敗します。
（昨日までは元気に動いていたのに、、どうして、、）

“`
$ git push
GnuTLS recv error (-54): Error in the pull function
“`

検索結果、以下をすると解決した記録があった
（networkエラー、ライブラリ破損、バッファ溢れ、、）

> https://root-forum.cern.ch/t/unable-to-access-https-github-com-vgvassilev-clad-git-gnutls-recv-error-54-error-in-the-pull-function/48574
> The error you posted is an internet connection error. The installation procedure tries to download some dependencies and fail

グローバルなgitignoreファイルの置き場所

## これはなに？

一度作ってしまうと、書き換える機会もそんなに多くないという人も少なくはないと思います。
私はめったに変更しないタイプなもので、先日Macの初期設定をするときに、どこに置くんだったか…とすっかり忘れてしまっていました。
この記事では、置き場所はもちろんですが、忘れたときのリファレンスもご紹介できればと思います。

## コンピューター上のすべてのリポジトリについて無視するファイルを設定する

結論はこちらです。

“`vim
~/.config/git/ignore
“`

もしignoreファイルが存在していなければ作成して配置すればOKです。

## 忘れてしまったときのリファレンス

なにごともやはり公式が一番ではないでしょうか。

https://git-scm.com/docs/gitignore

日本語で読みたい…という方はGitHub Docsを確認しても良いと思います。

https://docs.github.com/ja/get-started/getting-started-with-git/ignoring-files#configur

【Git / zsh】git branchを打たずにターミナルにブランチを表示させるための設定

# はじめに
こんにちは、Webエンジニア目指して学習中の**さば**と申します🐟（X：@saba7678pg）

[はじめてのアドベントカレンダー Advent Calendar 2023](https://qiita.com/advent-calendar/2023/first-time) **13日目**として参加させていただきました。

エンジニア界隈の風物詩のようなものでしょうか、初めて実際に混ざることができてとても嬉しいです！
内容は駆け出しが書いた駆け出し向けの簡単な記事ではございますが、誰かしらの参考になりましたら幸いです🙇‍♂️

:::note warn
内容について、引用元を確認したり、手元で動作を確認しながら書かせていただきましたが、
万が一誤りや補足情報等ございましたら、お手数ですがコメント・DM等でお知らせ頂けますと幸いです。
:::

# 今回の記事の対象者
– Macユーザー
– シェルに`zsh`を用いている

# この記事でできること
[![Image from Gyazo](https://i.gyazo.com/b896b146fffda3e21

git pull origin developができない

## git pull origin developができない

### 解決コマンド例
以下のように2段階に分けて実行すると上手くいく場合がある。

“`git
$ git fetch origin develop
“`
“`git
$ git merge origin develop
“`

上記を理解する補足説明

– pullはfetchとmergeを1度で実行するコマンド
– fetchはリモートリポジトリの最新情報をローカルリポジトリに取ってくること。
– fetchという単語自体、「取ってくる、呼んでくる」という意味。
– mergeでその最新情報を反映させる。

ExcelVBAでGitする

そんなに絶望的か？
—
あるとき、VBAの開発環境に絶望したという記事を見て、そこで紹介されているVSCodeを使ったVBA開発環境の構築を試してみました。

https://blog.ue-y.me/vba2021/

自分の感想としては即座にデバックできないところなど、どうにも勝手が悪く返って使いづらい印象を持ちました。やはり長年慣れ親しんだVBEを捨ててVSCodeに移行するなどという気には到底なれません。
しかし、確かにコード管理がGitHubでできるのは便利だと思い、そこだけ取り入れてアドインにしてみました。以下のようなメニュー項目をVBEに追加して使用します。


とにかく「単純に」を目指して作りましたが、単純を積み重ねていくと自然と複雑になってしまうものですね。

必要な準備
—

#### パソコンにGitをインストール

ghqを使ったリポジトリ移動を高速化する

fishを使っており、[decors/fish-ghq](https://github.com/decors/fish-ghq) をinstallしてリポジトリ移動をしていました。
ただ使っていて重いなあと感じていたので、下記の関数を使うようにして高速化しました。
“Ctrl+g“で呼び出す想定です。

“`shell
function peco_select_ghq_repository
set -l query (commandline)

if test -n $query
set peco_flags –query “$query”
end

find $(ghq root)/github.com/*/* -type d -prune | sed -e ‘s#’$(ghq root)’/##’ | peco $peco_flags | read line

if [ $line ]
cd $(ghq root)/$line
commandline -f repaint
end
end

bind \cg peco_sele

はじめて動いているCICDを見て感動した👏 at Gitlab

## CICDがよくわかってなかった🤔
いままでの私の中のCICDのイメージといえば、
「なんかいい感じに自動でリリースしてくれるやつでしょ～、しらんけど🥱」
くらいの、ただただ便利なナニカっていうイメージでしかなく、
恥ずかしながら、実際に動いているところ、実際にどんな感じで書いているのかなど何も知りませんでした。

少し前に「GitLabでCICD組んでみてよ～」とのことで、知ってる子に教えてもらいながら、いろいろ組んで動いているものをはじめて目の当たりにしました。
からっぽなイメージがだいぶクリアなイメージになって、「まじですごい」ってなることが多かったです。

Qiitaにいる大多数のみんなは、CICDなんて当たり前じゃんって方が多いかもですが、
今回はGitlabのCICDがどんなもんで*どんな画面で動くのか*だけ、簡単にお話ししたいと思います。
少しでもCICDのイメージがクリアになって、GitLabなどで試してみようかな～って思ってもらえると嬉しいです。

## 目次

* [CICDって？gitlabで結局何ができんの？](#cicdってgitlabで結局何ができんの)

初めてのGit

## 初心者にはイメージがつかない、なぜGitを使うのか

なぜ、Gitというスキルが不可欠なのか疑問な方はいますか？

`２つしかありません`

“`
①ソースコードを前回コミットした状態に戻せる（セーブ機能）
②GitHubにアップして、他人同士でソースコードを共有できる（共同開発機能）
“`

だけです

Git及びGitHubの習得とは、これができるようになること。Gitを用いて

## セーブ機能の解説とコマンド

#### ① ソースコード編集したのち、やっぱり前回の状態に戻したい時。
“`
git restore
“`

## 共同開発機能の解説とコマンド及び操作

## GitHubとは

ソースコードとコミットの全履歴が、記録できる

Gitから、GitHubへアップすることで、他人と共有もできるし、自分用という使い方もできる

ここで言うアップとは、具体的には、プッシュと呼ばれる

## 開発の流れ

これから、Gitの使い方について説明したいところですが、

その理解をするには、開発の流れを知らないとならないので、先に開発の仕方につ

動かして試す、git restoreの動き

## 環境
Ubuntu 20.4
Git 2.25

## 内容
コミットを行った直後で、ワーキングディレクトリでは、何のファイルの修正も行っていない状態が以下です。
“`
$git status
nothing to commit, working tree clean
“`

test.txtを修正しました。ワーキングディレクトリで何らかの修正が入ると、ステータスのメッセージ内容が変わります。下記のメッセージは「ワーキングディレクトリで何らかの修正が行われたが、ステージングエリアにはまだ上がっていません。ワーキングディレクトリで、これ以上、修正が行われないようであれば、変更内容をステージングエリアに上げて、コミットへ向いましょう。」といった内容です。ステージングエリアに上げないのであれば、ワーキングディレクトリの変更内容を破棄することもできます。
“`
$git status
Changes not staged for commit:
(use “git add …” to update what will be committed)
(use “

Gitのコミット履歴をキレイに残すためのちょっとしたノウハウ集

この記事は[株式会社ビットキー Advent Calendar 2023](https://qiita.com/advent-calendar/2023/bitkey)の11日目の記事です。

# はじめに

ビットキーではFWエンジニアをやっています。普段はアセンブリとか通信プロトコルとか低レイヤー周りに興味が向いているんですが、今回は自分がGitを使った開発をしているときに気をつけていることとか、便利なTipsとかをノウハウとして雑多に書いてみようと思います。こういったノウハウって明文化して周りに伝えるきっかけがあまりないんですが、実際聞いてみるとちょっとうれしいことがあったりしますよね。

# こんな人に読んでほしい

– とりあえず`git add .`→`git commit`ってやってるけど、ちょっと変わった状況になると分からない
– GitHubでPull Requestを出すときに内容がごちゃついてしまう

※この記事のGit操作環境は基本的にコマンドラインを想定しています。とはいえ、世の中にあるGUI操作でもほとんど同じことができると思いますので、自分の環境に合わせ

Git/Github勉強会イベントを開催した話

## はじめに
こんにちは．PoPoです．
私は情報科学部の大学２年生として普段授業でプログラミングの学習をしたり，趣味として興味を持った言語に触れてアプリとか作ったりしてます．
今回は**Progate Pathの公認学生アンバサダー**として私が大学で在籍している技術系サークルでGit/Githubの勉強会を行いました．その勉強会での感想や反省点を備忘録として書きます．

### 自己紹介

– 名前：PoPo
– 年齢：20（26卒、4年制2年）
– 所属：情報科学部の大学２年生(公開してもいいけどなんとなく)
– 特技：興味を持ったことにすぐ取り組むこと
– 好物：**sushi**
– Progate Path公認アンバサダー

## 何をしたのか
私が所属している技術系サークルで参加者を募って，Git/G

Gitをブランチポインタの動きから理解する

# 導入

Gitを使い始めのころはよくこんな図でブランチを理解してませんでしたか？


– 黄色いラインがmainブランチ
– 緑のラインがそこから派生したdevelopブランチ
– HEADは今自分がいる位置（現在の作業ブランチ）

イメージとしては間違いではないですが、Gitが内部でブランチやHEADをどう管理しているかを知っておくことでもう少し解像度高く理解することができます。

# この記事のポイント

この記事で抑えておくべきgitの構造上の特徴は以下の３つだけです。

– コミットは一意なID（コミットハッシュ）を持つ
– コミットはその親のコミットへの参照を持つ
– ブランチやHEADは特定の１コミットを指し示すポインタである

一つ一つ見ていきます。

### ①コミットは一意なID（コミットハッシュ）を持つ