今さら聞けないGit 

今さら聞けないGit 
目次

デフォルトブランチをdevelopブランチに変更したいが出てこないんだが💢💢💢

以下の記事

[Github]デフォルトブランチを変える方法
https://zenn.dev/ukigumo_shiina3/articles/b3b16c709de61d

を読んでデフォルトブランチを変更しようとスクロールしてみたのですが
スクロールの底まで行ってもdevelopブランチが表示されず「なんで??」と思い、

「デフォルトブランチ 変更 develop 表示されない」とかいったワードで検索をかけて
それでも解決の糸口が掴めない状況でイライラしていたのですが
「Filter branches」というプレースホルダーの箇所で

「dev」と検索を打ったら表示されました!
正直、これは非常に分かりづらいので直して欲しいのですが。笑
単純な見落としです。笑

![](https://storage.googleapis.com/zenn-user-upload/1764eb80228d-20241107.gif)

元記事を表示

GitHubで草🌱を生やそう!!!『毎日のTILを記録する方法』

Hello!しっしーです🦁

先日、xの「らんてくん おすすめ記事」でみつけた💡

おおくまさんの記事を拝見させていただいたところ、

「GitHubに毎日草を生やしたほうがいい」

というご意見を拝見し、誠に感銘を受けたので、自分でも草を毎日はやす作業をしていこうと思い至りました。

GitHubに草を生やすとは?

については、こちらの記事で丁寧に記載されていらっしゃるので、一度拝見してみてください。

[https://qiita.com/kumaryoya/items/4cb59023ee8896a328d2#できるだけ毎日草を生やす](https://qiita.com/kumaryoya/items/4cb59023ee8896a328d2#%E3%81%A7%E3%81%8D%E3%82%8B%E3%81%A0%E3%81%91%E6%AF%8E%E6%97%A5%E8%8D%89%E3%82%92%E7%94%9F%E3%82%84%E3%81%99)

そんな中、では具体的にどうやって毎日草を生やしていくの?

というところに思い至った時に、GPTと相談しながら自分な

元記事を表示

vsCodeでRepositoryを簡単に切り替える方法

## はじめに
仕事で複数レポジトリを扱っているので、常にvscodeをいくつか開いて開発を行っていました。それがとっても面倒..
そこでウィンドウをレポジトリごとに開かなくてもレポジトリの切り替えができるように設定しました。
こんな感じで切り替えできます。
![chnage_repository.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3919187/f8a2ab14-a57f-cab6-e1a0-297ef92d47db.gif)

## 導入と設定
1. まずvscode-workspace-switcherをインストール
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3919187/6ff30a60-3649-800f-7aa0-94fbe5cbb067.png)

2. Visual Studio Codeのsetting.jsonに任意のpathを参照用に設定しておく
““

元記事を表示

srcフォルダがgitの管理外になっていた問題

– `.gitignore` ファイルを srcで検索しても、見当たらないものがない
– `find ./ -name .gitignore` で検索しても、`./.gitignore` しかない
– 最終的に`git check-ignore -v src/*`を掛けて、やっと `.gitignore`に`*`? みたいな記述があることがわかり、それを消したら問題解決した

元記事を表示

【Gitマージの罠】別のプルリクエストのマージも自動で勝手に行われてしまう現象

## 結論
先に結論からお伝えすると、以下が本記事でお伝えしたいことです。

### 本記事でお伝えしたいこと
**ブランチAがブランチBの全てのコミット履歴を含む場合、PR Aをマージすると、PR Bも自動で一緒にマージされ(たとGitによって判断され)てしまう**

※ブランチA, BとPR A, Bはそれぞれ以下の通り
ブランチA:developブランチから切ったfeatureブランチA
ブランチB:developブランチから切ったfeatureブランチB
PR A:「ブランチAをdevelopブランチにマージする」プルリクエスト
PR B:「ブランチBをdevelopブランチにマージする」プルリクエスト

## 「結論」の具体例
上記の具体例として、以下の1.~4.のようなシナリオがあります。

**1. featureブランチAの作成と開発**
– developブランチから切った、「featureA」というfeatureブランチを作成
– featureA上で、新しい機能Aを追加し、以下のコミットを実行
“`:ターミナル
git commit -m “新機能Aを追加”
`

元記事を表示

[git入門]個人開発者向け

git操作の基礎

個人開発をしているとなかなかgitの知識が身に付かないと悩んでいた僕が、チーム開発未経験でもgitを扱えるようになるためにgit操作を解説していきます。

今回はgit操作の基礎中の基礎であるコミット、プッシュ、プルリク、マージについて説明していきます。

1.「コミット」と「コミット&プッシュ」の違いについて

「コミット」だけの場合と「コミット&プッシュ」の違いに気づかず使ってました。そのレベルだった当時の自分に教えてあげるつもりで優しく説明していきます。

それを説明する前にgithubのリポジトリについて解説していきます。

リポジトリには大きく分けて二つあり、
・リモートリポジトリ
・ローカルリポジトリ
があります。

リモートリポジトリ:githubなどサーバー上にあるリポジトリのこと。他の人と共有したりできる。
ローカルリポジトリ:個人のPC上にあるリポジトリのこと。

コミットのみの場合

ローカルリポジトリに変更内容を反映させる。

コミット&プッシュ

ローカルとリモートど

元記事を表示

【Git】最新commit内容から修正をした内容のリセットについて

### 本記事の内容
最新commit内容から修正をした内容をリセットして
修正をする前の状態に戻りたいときのコマンドについて

### どのようなケースで使うか
図のような状況とします。
– push対象のbranch(main)から新規ブランチ(new_branch)を作成
– そのnew_branchの中で1の内容を修正や新規ファイルを追加をして2の内容にする
– 修正や新規ファイルを追加するにつれ、エラーなどにより1の内容に戻したくなった
![スクリーンショット 2024-11-04 12.28.12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/606327/cd2b2b9c-f2bf-fbec-c7f1-7debe11d62ab.png)

### 追跡中ファイルの更新内容をリセットする & 追跡されていないファイルの変更内容をリセットする
下記の手順で1の状態に戻れます。

#### 追跡中のファイルの更新内容のリセット
追跡中のファイルの更新内容をリセットします
“`
git c

元記事を表示

Docker で Git の CI システムを手作りする

## 背景

四苦八苦しながら Docker 環境構築をなんとか完了し、Ubuntu なんかを実験用でサクッと用意できることが分かって感動。

そして思ったのが、「これ活用したら、GitHub Actions っぽいことできるんじゃね?」

Docker をより詳しく知ることも目的に、Git リモートリポジトリに push されたら、自動 CI が動く簡易システムを作ってみることにしたのでした。

## つくりたいもの

GitHub Actions のシステムはだいたいこんなイメージ。 (実際にこういう実装と確かめたわけではない)

“`mermaid
sequenceDiagram
actor C as Client
participant G as GitHub
participant R as GitHub Repository
participant A as GitHub Actions
(runner)

C ->> R: push

R ->>+ A: CI start
A ->> R: Source checkout
R –>

元記事を表示

GitHub SSHキーを設定する手順

#### 1. SSHキーの確認
まず、SSHキーがすでに生成されているか確認します。

“`
ls ~/.ssh
“`
id_rsaやid_rsa.pubなどのファイルが表示されれば、SSHキーは存在します。

#### 2. SSHキーの生成(必要な場合)
SSHキーが存在しない場合、以下のコマンドで生成します:

“`
ssh-keygen -t rsa -b 4096 -C “your_email@example.com”
“`

生成されたキーは通常~/.ssh/id_rsa(秘密鍵)と~/.ssh/id_rsa.pub(公開鍵)に保存されます。

※`Enter file in which to save the key…`などが出てきた場合、
特に変更がなければ、Enterキーを押すことでデフォルトのパスに保存されます。もし別の名前や場所に保存したい場合は、そのパスを入力してEnterを押してください。デフォルトのままで問題ない場合は、何も入力せずにEnterを押してください。

#### 3. SSHキーをGitHubに追加
生成した公開鍵をGitHubに追加し

元記事を表示

GitとGithubの連携のやり方

久々にこの作業をしてみると、
完全に忘れていて、時間を無駄にしたので忘備録。

連携したい環境のターミナルで、以下を入力する。

まずは、キー作成をする。
githubで使用しているアドレスを入力すること

ssh-keygen -t ed25519 -N “” -C メールアドレス

これで生成された id_ed25519.pub をgithubのSSH and GPG keyに追加する。

以下を試して、通ればOK
ssh -T git@github.com

~/.ssh$ ssh -T git@github.com
Hi 〇〇(github ID)! You’ve successfully authenticated, but GitHub does not provide shell access.

これで完了

元記事を表示

Good Commitを学ぶ

チーム開発を行う上で、必ずと言っていいほど使用するGitだが、自分自身あまり意識できていなかったので、Git Commitに関するベストプラクティスを下記にまとめます。

– 1.Commit Often,but Not Too Often
– 2.Write Clear and Descriptive Messages
– 3.Use Branches Effectively
– 4.Review and Squash Commit
– 5.Automate Testing
– 6.Use Husky

1.Commit Often,but Not Too Often

コミットの頻度が多すぎても、少なすぎてもよくありません。バランスをとるように努めます。
各コミットは意味のある変更を表す必要があります。
無関係な変更を 1 つのコミットにプッシュしないでください。

2.Write Clear and Descriptive Messages

コミット メッセージでは、コミットの内容と変更を加えた理由を説明する必要があります。
コミットする内容に合わせて、タイプを使用します

元記事を表示

Gitで500KB以上のファイルを自動で無視する方法

以下に、500KB以上のファイルを検出し、`.gitignore`に追加する方法の概要と、500KB以下のサイズ制限をおすすめする理由を含めてまとめました。これにより、プロジェクトのサイズを効果的に管理し、リポジトリのパフォーマンスを維持することができます。

## Gitで大容量ファイルを自動で無視する方法(500KB以上推奨)

大規模なプロジェクトやデータファイルを扱う際、大容量ファイルがリポジトリのパフォーマンス低下を引き起こすことがあります。GitHubなどでは100MBを超えるファイルはアップロードできないため、ファイルサイズを管理することが重要です。500KB以上のファイルにサイズ制限をかけることで、効率的に管理できます。

### ステップ 1: `.gitignore`ファイルの作成

リポジトリのルートディレクトリに`.gitignore`ファイルを作成し、無視するファイルやディレクトリをリストに追加します。以下は一般的な例です。

“`gitignore
# Python関連の一時ファイル
__pycache__/
*.pyc

# 大容量ファイル
*

元記事を表示

Gitのコミットメッセージ作成をChatGPTで自動化してみた

## はじめに

ソフトウェア開発の現場では、Gitのコミットメッセージをきちんと書くことが推奨されていますが、内容を反映した適切なメッセージを考えるのは意外と難しい作業です。今回は、ChatGPTのAPIを活用して、Gitのコミットメッセージを自動生成するスクリプトを作成したので、紹介します。

## スクリプトの概要

このスクリプトは、OpenAIのAPIを使って、ステージングされたファイルの変更内容に基づいたコミットメッセージを自動で生成します。特に、大規模な変更や複数ファイルにわたる修正がある場合には、変更点を理解しやすく、簡潔なコミットメッセージが生成されるため、手作業の時間を大幅に削減できます。

https://github.com/takurot/autoCommitMsg

### 事前準備

このスクリプトを実行するには、OpenAIのAPIキーを取得し、環境変数として設定する必要があります。APIキーがない場合、スクリプトはエラーを返します。

### コードの詳細

では、実際のコードについて見ていきましょう。以下のコードは、変更内容をChatGPTに送信し、

元記事を表示

【自分用メモ】GitHub DeskTop ローカルリポジトリをリモートにアップロードする方法

## アップロード方法

①ローカルリポジトリを作成(このとき作成しなくても、「Local Path」指定時に新規フォルダ作成から作ってもOK)

②GitHub DeskTopを起動し、「Create New Repository」を選択

![スクリーンショット 2024-11-03 0.01.30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3876039/0bf7ad09-27ac-4062-e64e-1060999365a5.png)

③「Name」、「Local Path」を指定し、「Create Repository」を選択

![スクリーンショット 2024-11-02 23.55.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3876039/fabb7886-8e6c-ffb7-c7bc-6497d3f3be7e.png)

元記事を表示

【Heroku】Herokuにdeployする内容をcommit単位で指定する

### 本記事の内容
production環境のHerokuにdeployする内容をbranch単位ではなくcommit単位で指定する方法について

### どのようなケースで使ったか
mainブランチをHerokuにデプロイしていたのですが、
そのmainブランチの内容を更新していてある時点のdeployでエラー発生。

Herokuにdeployしている内容を正常に動作している内容を戻したい、が
Herokuで正常に動作している時点で
mainブランチから別のブランチ(release_yyyymmddのようなブランチ)を切っていれば
よかったものの
mainブランチのまま突き進んでしまったという状況でした。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/606327/aaca32c2-a6f6-e78c-3083-3cd31a26cc12.png)

### production環境のHerokuにdeployする内容をcommit単位で指定する
下記の手順で解決できました。
br

元記事を表示

【github】WindowsPC上でGithubとVSCodeを連携してみた

## 【初心者向け】VSCodeとGithubの連携 for Windows
私は、インフラエンジニアとして仕事をしているのですが、最近AWSというクラウドサービスに興味があり、勉強に励んでいるクラウド未経験の者です。
 
 その際に、IaCというAWS上のインフラリソースをコード化して作成や管理ができる機能について知り、自身のポートフォリオの準備のためにも、VSCodeでIacを作成したものをGithub上に公開しています。

 VSCodeとGithub連携は、初学者にとっても簡単なので、よければ参考にしてください。

## 作業手順
1.VSCodeのインストール
 インストール方法については、とても分かりやすく解説している、こちらの記事を見て作業を行ってください。

https://breezegroup.co.jp/201904/visualstudiocode/

2.Gitのインストール
 GitはGithubのコードのバージョン管理をしているシステムツールで、Windowsの場合は、下記のサイトから、自分でインストールする必要があります。

https://git-

元記事を表示

VivadoのプロジェクトをGitで管理する方法

## Vivadoのプロジェクトフォルダがひどすぎる!

Xilinx(現AMD)のFPGA開発環境であるVivadoは、GUIで使っているとプロジェクトフォルダ以下にとにかく大量のファイルを生成してきます。しかも、特定のサブフォルダ以下にまとまっておらず、プロジェクトのルートに大量のログファイルを置いたり、ソースファイルと同じフォルダに生成物を大量に生成してきたり、とにかくめちゃくちゃです。

ソースコードはGitで管理したいのに、というかちゃんと管理しておかないと途中で分からなくなったり、戻したいときに正しく戻せなかったりと何かと不便です。
学生時代に、同じくXilinxのISEという開発環境を使っていた時も同じ状況でしたが、その時は明らかなログファイルを除いて全部addしていました。そのため、過去のコミットをさかのぼる必要が出たときに不要なファイルや差分が多数表示されて面倒でした。

先人たちもいろいろとノウハウを公開していただいていたり、何ならxilinx(現AMD)から手順が公開されていたりします。これらを参考に、自分なりのやり方を試行錯誤してみたので備忘録として残しておきま

元記事を表示

Git の使い方メモ (コマンドや説明など)

## 概要

Git で使ったことのあるコマンドや説明などのメモです。

## 使用方法

### リモートリポジトリをローカル環境に複製する

#### `git clone`

現在のディレクトリ内に指定したリモートリポジトリをローカル環境に複製するコマンドです。

– リポジトリの URL は基本的に SSH 接続用の URL を使用してください

“`bash
git clone <リポジトリのURL>
“`

### 一時的に変更を退避する

#### `git stash`

作業中の変更を一時的に保存(退避)して、作業ディレクトリをクリーンな状態に戻すコマンドです。

– 現在の変更を一旦退避して別の作業を始めたい場合などに使用します
– コメントは必須ではありませんが、後で内容を確認しやすくするために使用できます

“`bash
git stash
“`

– コメントを付与する場合

“`bash
git stash save “コメント”
“`

– スタッシュを戻す場合は、`git stash apply`

元記事を表示

.gitignoreの書き方

## はじめに

gitを使う上で割と大事な.gitignoreについての覚書です。

## .gitignoreとは

“.gitignore“は、ローカルのディレクトリには含まれているが、Gitのリポジトリに複みたくないファイルやディレクトリを指定するためのファイルです。

これを適切に設定することによって、以下のようなファイルをリポジトリに含める必要がなくなり、何かと便利です。

– “.env“ファイルなど、トークンやAPIキー、パスワードなどの機密情報を含むファイル
– ローカルで生成されるキャッシュファイルやログファイル
– メモなど、開発者個人の作業ファイル
– 開発中のため、まだリポジトリに上げるべきではないファイル

## 書き方

“.gitignore“は、リポジトリのルートディレクトリに配置します。この名前でファイルを作成し、以下のように無視したいファイルやディレクトリを記述します。

### コメント

“#“で始まる行はコメントとして扱われます。

“`python
# これはコメントです
`

元記事を表示

【git】- オプションで直前にいたブランチを指定できる

## はじめに

git の操作を効率化したいエンジニア向けに、`-`オプションを紹介します。

※すでに`-`オプションをご存知の方には役立たない記事なのでスルーしてください。

## `-`オプションで直前にいたブランチを指定できる

たとえば次のシナリオを考えます。

1. ベースブランチ`develop`にいる
2. 作業ブランチ`hogehoge`を作って作業
3. マージまで完了したのでベースブランチ`develop`に戻る

この場合、gitコマンドの流れは次のようになります。

“`bash
$ git branch # ベースブランチ develop にいることを確認
* develop
$ git switch hogehoge # 作業ブランチを切る
# … コミット, プッシュなどは省略
$ git switch develop # ベースブランチ develop に戻る
“`

このとき、最後の`git switch develop`の代わりに`git switch -`と指定するこ

元記事を表示

OTHERカテゴリの最新記事