f@ctor

今さら聞けないGit　

今さら聞けないGit　
目次

ブランチプロテクションの設定をcurlで変更する方法

テストブランチをブランチプロテクションで保護設定をして削除できないようにしていますが、少しの間だけブランチ削除を許容する必要がありました。そのためcurlでブランチプロテクションの強制削除を有効化にするための方法をメモしておきます

## エンドポイント

ブランチプロテクションのREST APIエンドポイントが用意されているので、そちらを叩きます。
ブランチプロテクションのエンドポイントを叩くにはpersonal_access_tokenが必須です。
“`
curl -L \
-H “Accept: application/vnd.github+json” \
-H “Authorization: Bearer ${PERSONAL_ACCESS_TOKEN}” \
-H “X-GitHub-Api-Version: 2022-11-28” \
https://api.github.com/repos/${owner}/{repository}/branches/${branch}/protection
“`

https://docs.github.com/j

元記事を表示

【Git】【GitHub】基本コマンドまとめ

初学者の学習内容の備忘録です。
間違いや補足等あればご指摘いただけると幸いです。
今回はGitの基本的なコマンドをまとめました。

# コマンド一覧
**ステータスやログの確認**
“`terminal:ターミナル

git status

git log –oneline

git log -p

git show [hash]

git diff

git diff –staged

git checkout [hash]
“`
**gitの初期化**
“`terminal:ターミナル
git init
“`
**ユーザーネーム、メールアドレスの追加**
“`terminal:ターミナル

git config –global user.name

元記事を表示

gitでcommit する際の接頭辞についてまとめてみた

# はじめに
commitをする時、接頭辞のfixやfeatはよく使うので迷わないのですが、choreやrefactor使い分けに迷うことがあるので、まとめてみました。

# 接頭辞の使い分け
インターネットでいろいろ調べてみると、

https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#type

を参考にしている方が多かったので日本語に訳して分かりやすく自分なりに噛み砕いてみます。

## feat
featureの略です。新しい機能をcommitとするときに使います。

## fix
そのまんまですね(笑)。バグを修正するときに使います。

## docs
ドキュメントを修正するときに使います。

## style
空白、書式、セミコロンの欠落といったコードの意味に影響を与えない変更をするときに使います。

## refactor
これもそのまんまです(笑)。リファクタリングをするときに使います。

## perf
performanceの略です。パフォーマンスを向上させるためのコード変更をする場合に使いま

元記事を表示

初めてのGitHub　～エンジニアへの第一歩～

# プログラミングを始めるにあたって
これからコードを書き始める皆さんに，1つアドバイスしておくと，

### バージョン管理はめちゃめちゃ大事！！

プログラミングを始めると、コードを書いているうちに、
「あのときのコードの方が良かったけど，どこ変更したか忘れた…」
とか、
「ここを変更したのは良いけど、どういう意図で変更したっけ」
と感じる瞬間が必ずでてきます。そんなときに頼りになるのが
**バージョン管理** です！

バージョン管理の利点を話すと、
1. 変更履歴を追跡できる
バージョン管理システムを使えば、いつ、誰が、何を変更したのかをすべて記録できます。これにより、問題が発生した場合でもすぐに元の状態に戻したり、どの変更が問題の原因になったのかを特定したりできます。

2. チーム開発が円滑に進む
複数人で開発を行う際には、各メンバーがそれぞれの作業を進めつつも、最終的に1つのプロジェクトに統合する必要があります。バージョン管理システムを使えば、各メンバーの作業内容を簡単に統合でき、誰かの変更が他のメンバーの作業に影響を与えないように管理できます。

3. 安全に開発でき

元記事を表示

PhpStormで空行の空白が勝手に削除される 👿【Settings/Preferences | Editor | General | Remove trailing spaces on:】

原因はこいつじゃない
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/435735/8647dd3c-c816-7019-64ce-9c29c5e0a3a8.png)

.editorconfigが原因

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/435735/71f06f51-d726-c2fc-d5f7-233d5c204cc4.png)

“`ini:.editorconfig
root = true

[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
indent_style = space
indent_size = 4
trim_trailing_whitespace = true ←削除するよ

[*.md]
trim_trailing_whitespace = false

[*.{yml,

元記事を表示

Gitを触ったことのないエンジニアがヤバいと言われる理由を考えた

## これは何?

TwitterでGitをさわったことのないエンジニアがヤバイという発言が物議を醸していたのでなぜヤバイと言われるのかを考察しました。

## 考えられる理由

### 業界標準への理解が低い/業界の大局を追えていないように見える

現代のソフトウェア開発のバージョン管理のデファクトスタンダートがGitです。
基本的には，Gitリポジトリのホスティングサービスである，GitHubやGitLabを使うパターンが多く，こういったサービスを使うことで現代の開発フローは実現されていると思います。
そのため，Gitを使ったことがないと業界のお作法的なものができていないと思われてしまう可能性があると考えられます。

### 最新技術へのアンテナが低そうに見える

現代のOSSのほとんどがバージョン管理にGitを使用しており，GitHubやGitLabにソースコードを公開しているパターンが多いです。。そのため，OSSのコントリビュータになるにはGitを使える必要があり，Gitを使ったことがない=OSSのコントリビュータになる気がゼロということがわかってしまいます。(コントリビュータ

元記事を表示

SQLServerのDBをGit管理・デプロイを自動化してみようの会

普段DBを活用してシステムを構築していると、仕様変更などのタイミングで、
– ストアドプロシージャに纏めたDB処理を変更する
– テーブルに新しいカラムを追加する

といった場面によく出くわします。ですがPythonやC#等のプログラミング言語と違い、SQLのバージョン管理は一般的ではなく、情報が出回っていません。

そしてDB管理では筆者はよくこういった事象に悩まされていました。

– 重要な処理が気付いたら変更されていたが、**誰がどう変更したのか分からない**
– ロールバックしようと思ったが、**構成情報が残っていない**/どこに戻ればいいか分からない
– テストDBサーバーから本番DBサーバーへの**デプロイミス**(ALTER TABLE漏れやINDEX、デフォルト値の設定忘れ等)

こういった問題を解消すべく、社内システムのDBのバージョン管理やデプロイの自動化方法などを少しばかり調査・検証をしたので情報共有します。ご参考あれ。

なお私は担当システムの都合上SQLServer専門ユーザーなので、他のDBサーバーの管理ツールの話は他の人にお任せします。((無責任

#

元記事を表示

git stash applyした後の諸々変更した後に，もう一度stashの時点から戻りたいとき

`git stash apply stash@{0}`を実行した後に諸々変更を加えていたが，もう一度stashの時点からやり直したい時があったのでその時の作業コマンドをメモする．

### 適当なブランチを切る
git stash applyした後の作業内容を一旦temp_branchに退避させる．
“`
git checkout -b temp_branch
“`
その後にコミットする
“`
git add .
git commit -m “temp commit”
“`

### 戻る
“`
git checkout develop
“`

### 新しい作業ブランチでstashを適用
“`
git stash branch temp_stash_branch
“`

### 退避させたブランチを削除
“`
git branch -D temp_branch
“`

元記事を表示

(開発2) yumパッケージインストール

## ■概略
オープンソースエンジニア歴30年超の筆者が2023年からIBMi(AS400)を学びだした学習記録です
IFSをオープンソースエンジニアが慣れ親しんだUNIX環境にするために、yumでパッケージをインストールします

## ■yumコマンドのインストール(オフライン)
　筆者がASCからインストールしたところ安定しなかったのでACSなしでオフラインインストールする方法が下記

参考URL : https://bitbucket.org/ibmi/opensource/src/3e06f584c88b39f1964d2a58aa094a234a8f77d2/docs/yum/

Offline Install Instructions (without ACS)を実行する
１. Download bootstrap.sh and bootstrap.tar.Z to your PC
２. IBMiの/tmpに転送
“`
PC $ scp bootstrap.sh IBMi:/tmp
PC $ scp bootstrap.tar.Z IBMi

元記事を表示

(入門2)RGP言語(RGP3,RPGLE,FFRPG)とエディタとgitの関係

## ■概略
オープンソースエンジニア歴30年超の筆者が2023年からIBMi(AS400)を学びだした学習記録です
IBMiで使われている言語のの種類とエディタの関係、更にgitの関係をまとめました

## ■RGP言語の種類とエディタとgitの関係
※RPGにはRPG3、RPGLE、FFRPGの3種類があります
※これまでIBMi開発でgitはあまり使われていませんが、開発である以上必要だと思います
　しかしRPG3のソースメンバーはIBMiネイティブ(筆者の造語・IBMiオリジナルのファイルシステムのこと)上にあり直接gitで管理できません
※RPG言語の種類別に使えるエディタとgit管理の方法をまとめます

**◯まとめ**
※RDiはIBM純正の有償の開発環境、VSCodeはMicrosoft製のオープンソースの開発環境
　VSCodeで開発する方法を後の記事でまとめます
※SEUは5250で利用可能なエディタ
※gitは行単位でテキストの差分を管理できるシステム。現在のソースコードはほぼgitで管理されている

【AWS】GiteaをEC2で起動してみた

## はじめに

この記事ではAWSでGiteaを起動する方法を記載しています。

## Giteaとは

セルフホスト可能なリポジトリ管理ソフトウェアであり、強力なCI/CDをあらゆるところで起動できるソフトウェアです。

主な特徴は以下のとおりです。

– Goでできている
– MIT LICENSE
– Dockerに対応

[サイト](https://about.gitea.com/)

## 準備するもの

– EC2が起動できるAWSアカウント
– AWS Systems Manager Session Manager（SSM）も利用します
– ほんの少しのやる気

## 実際に動かしてみよう

おおおまかな手順

– EC2の構築
– SSMを使ってEC2にログイン
– シェル上でDocker Compose upを実行

## EC2の構築

EC2はコンソールぽちぽちしても良いですが、今回はCloudFormation Templateを用意しましたので
テンプレート作ります。

以下のテンプレートをCloudFormationで適用してください。

“`y

gh repo clone / git clone で error: RPC failed; HTTP 400 curl 22 The requested URL returned error: 400が出る

## Error

git cloneしようとすると以下のエラーがでる

“`
gh repo clone xxx
Cloning into ‘xxx’…
error: RPC failed; HTTP 400 curl 22 The requested URL returned error: 400
fatal: expected ‘packfile’
failed to run git: exit status 128
“`

## 解決策

“`
git config –global http.postBuffer 524288000
“`

このコマンドで`~/.gitconfig` に以下のような設定が入るので適宜調整。（clone後不要であれば削除)

“`~/.gitconfig
[http]
postBuffer = 524288000
“`

## 原因

http bufferサイズのせいのよう

https://stackoverflow.com/questions/62753648/rpc-failed-http-400-cur

[Unity]プライベートリポジトリでもUPMを使いたい

# はじめに
プライベートリポジトリでもUPMで制作したアセットを公開したいなー。verdaccio自分でホストすると大変なんだよな～と思ってたら
めちゃくちゃシンプルなソリューションがあったので共有

# GCMをつかう
Gitをインストールする際に、オプションでGCM(git Credentinal Manger)をインストールする。
これだけです。あとは普通にリポジトリ指定したらブラウザで認証させられ、以降はキャッシュした認証情報で簡単にプライベートリポジトリからインストールできます。
参考
・https://medium.com/tichise/unity-package-managerでプライベートリポジトリのgit-urlを用いてpackageを追加する-ecaa46fda2eb

・https://docs.github.com/ja/get-started/getting-started-with-git/caching-your-github-credentials-in-git

# 最後に
なんでこの機能を見つけられなかったのか全くの謎…と思った

ローカルの既存プロジェクトを、GitHubにアップロードする手順

# はじめに
通常、GitHubからプロジェクトをクローンして作業を開始しますが、既存のローカルプロジェクトをGitHubにアップロードすることもあります。

この記事では、ローカルで作成したプロジェクトをGitHubにアップロードする手順を詳しく説明します。

# 手順
### 1. Gitリポジトリを初期化する
作成したプロジェクトのディレクトリに移動し、Gitリポジトリとして初期化します：
“`bash
cd /path/to/your/project
git init
“`

### 2. GitHubリポジトリを作成する
1. GitHubにログインし、新しいリポジトリを作成します
1. リポジトリ名を入力し、必要に応じて説明を追加します
1. 「Initialize this repository with a README」のチェックを外します
1. 「Add .gitignore」と「Add a license」も選択しません
1. 「Create repository」をクリックします

:::note warn
このとき、README、.gitignore、ライ

実務未経験者の人に読んでほしいGitHubの実務tips

## 更新履歴

### 2024-09-05
– masterをmainブランチにし、masterに対する言及をしました。

The default branch for newly-created repositories is now main

– httpsかsshか、についてはいろんな見方があることを追記

https://qiita.com/yamadagenki/items/5e4ee79a7a680b1675e8#comment-530951f8a5c241da8b3e

https://qiita.com/yamadagenki/items/5e4ee79a7a680b1675e8#comment-bf321c65c934125a21a4

– 「PRの作成タンを押したら終わりではない」の項目を追加

## はじめに

株式会社シンシアでは、実務未経験のエンジニアの方や学生エンジニアインターンを採用し一緒に働いています。

※ シンシアにおける働き方の様子はこちら

https:

GitHubでの基本的な開発フローを理解する

# はじめに
GitHubは現代のソフトウェア開発において不可欠なツールです。本記事では、git clone, git branch, git push, git pull などの基本的なコマンドを使った実践的な開発フローを解説します。これらのコマンドの理解と適切な使用は、効率的な開発とスムーズなチーム協働の鍵となります。

# 典型的なワークフローの例
1. リポジトリのクローン（git clone）
1. 新規フィーチャーブランチの作成（git branch）
1. 開発と変更のコミット（git commit）
1. リモートへの変更の共有（git push）
1. プルリクエストの作成とレビュー
1. メインブランチへのマージ
1. ローカルの更新（git pull）
1. 不要ブランチの整理

既存プロジェクトをgithubにアップロードする場合、下記をご参照ください。

https://qiita.com/oharu121/items/5439c843d0ca1bb83448

# リポジトリをセットアップする
### 1. GitHubでSSH鍵の設定
SSH鍵の生成方法は

ローカルプロジェクトを GitHub Pages で公開する

### 前提

– Node.js がインストール済みであること
– git がインストール済みであること
– GitHub でリモートリポジトリを作成済みであること

#### リモートリポジトリが未設定の場合

以下の記事を参考にセットアップする
[Git の環境構築をしよう！(Progate)](https://prog-8.com/docs/git-env-win)

### 開発環境

“`
$ npm -v
10.2.4

$ git -v
git version 2.45.2.windows.1
“`

## ローカル環境の作業

#### 公開するプロジェクトの概要

– React + TypeScript で作成した Web アプリ
– ビルドツールは Vite を使用

#### リモートリポジトリ（GitHub）への追加

:::note
Windows 環境の場合、以下のコマンド操作は Git Bash や WSL2 で実行すること。
（コマンドプロンプトだとデプロイ時にエラーが発生するため）
:::

1, ローカルプロジェクトに移動しターミナルを開く

誤ってプッシュしたコミットを git revert で取り消す方法

# はじめに
今回は、私が実際の開発現場で経験した、誤ってリモートリポジトリにプッシュしてしまったコミットを `git revert` で取り消す方法について、まとめました。初心者の方でも安心して使える手順を紹介しますので、参考にしてみてください。

# git revertとは
`git revert` は、Git（ソースコード管理ツール）のコマンドのひとつで、過去に行った特定の変更を取り消すためのものです。具体的には、「前にした変更をなかったことにしたい！」というときに使います。

# 実際の使用例
スクショのコミットメッセージ「console.logの削除」を誤ってリモートリポジトリにプッシュしたケースを想定して、取り消したい思います。

![スクリーンショット 2024-08-30 20.11.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3536873/e9defce2-a77b-d60a-d08c-32c1e8a368be.png)

### リバート対象のコミットを確認

ローカルの

git rebaseを使って誤ってコミットしたファイルとフォルダを削除する

# はじめに
開発中に誤って.envファイルやその他の機密情報を含むファイルをGitHubにアップロードしてしまうことは、誰にでも起こり得るミスです。これらのファイルにはAPIキーやデータベースの接続情報など、外部に漏れてはならない情報が含まれていることが多いため、早急かつ適切な対応が必要です。本記事では、誤って機密ファイルをアップロードしてしまった場合の具体的な対処法について解説します。

:::note alert
.gitignoreに追加してコミットしても、すでにコミットされたファイルはリポジトリから自動的に削除されません。手動で削除が必要です。
:::

:::note warn
ファイルを削除して新しいコミットを作成しても、過去の履歴には依然としてファイルが残っているため、履歴のクリーンアップが必要です。
:::

# 対処の基本ステップ
### 1. .gitignoreに追加する
まず、誤ってコミットしたファイルが再度コミットされないように、.gitignoreファイルに対象のファイルやディレクトリを追加します。
“`bash:.gitignore
# Depende

Gitリポジトリ内の改行コード(CRLF)の混在チェック (Windows環境)

# きっかけ
具体的なコマンドがググっても意外とすぐに出てこなかったので…

# コマンド
ターミナル環境(シェル)によってコマンドに微妙に違いがある。

“`bash:Git Bash
git grep –cached -l -I $’\r’
“`
“`powershell:PowerShell (VSCodeデフォルト)
git grep –cached -l -I “`r”
“`

# さいごに
`core.autocrlf`より`.gitattributes`を設定して根本的に混在を防ぎましょう。
[.gitattributesで改行コードの扱いを制御する](https://qiita.com/nacam403/items/23511637335fc221bba2)
[もう迷わない .gitattributes で改行コードを統一](https://qiita.com/Yossy_Hal/items/6fe2d14cddd6e16796d7)

OTHERカテゴリの最新記事