今さら聞けないGit　

【UiPath】UiPathプロジェクトをGitHubで管理してみよう！（2）_issueを立ててブランチを切ってみよう

## はじめに

UiPathではGitHub(ギットハブ)を使用してプロジェクト管理を行うことができます。
初心者向けで簡単にまとまっている記事がなかったのでまとめてみました。

– [第1回 UiPathでGitHub管理を始める](https://qiita.com/FlatBone/items/696bfb89fd5ee2881526)
– **第2回 GitHubでissueを立てて、ブランチを切る←今ココ**
– 第3回 GitHubでmergeする

第1回ではGitHubのアカウントを作成し、リポジトリを立ててUiPathとつないだところまでやりました。

### この記事でわかる・できること

– GitHubでissueを立てる方法が分かる
– GitHubでブランチを作成する方法が分かる
– UiPathでブランチを切り替えて作業する方法が分かる

### この記事で触れないこと

– merge(次回やります)

### この記事の対象者

– UiPath Studio 開発者
– GitHubとか差分管理はなんとなく聞いたことあるけどよくわからない…な人

#4 リモートで削除済みのローカルブランチを削除する

# はじめに

`git pull`した際、「error: cannot lock ref ‘refs/remotes/origin/main’:～」というエラーが発生して失敗しました。再度pullしたところ問題なく最新が取得できたようでしたが、なにか対応が必要かと思い調べてみました。

# 原因

リモートで削除されたブランチがローカルブランチに残っていることで発生するようです。ただ、そういった状況は普通に起こりそうなので、その上でなにか問題がありそうですが…。（調査中）

# 解決方法

`git remote`コマンドに`prune`というオプションを付与して実行すると、リモートで削除済みのローカルブランチが削除できます。

“`console
git remote prune origin
“`

以下のコマンドでも同じです。

“`console
git fetch –prune
git pull –prune
“`

また、`–dry-run`オプションをつけると削除対象のブランチを確認できます。ブランチの削除は行われません。
“`console
git r

WindowsでSourcetreeが起動しない時の対処法

# 現象
Sourcetreeを起動するポっと出て消える


# 結論
C:\Users\ユーザ名\AppData\Local\Atlassianに行く
この長い名前のやつを消す


無事起動！
![image.png](https://qiita-imag

Gitコマンド:中級編

# はじめに
こんにちは！
前回、[Gitコマンド:初級編](https://qiita.com/yam_dev/items/18078f0b53bda3c6dd6e)を書きました。

初級編をマスターしたら、さらにGitを使いこなせるように、中級編のコマンドを解説します！

### git branch

Gitでは、複数の開発ラインを「ブランチ」として管理している。
`git branch`コマンドで、現在のブランチ一覧を表示できる。

“`bash
git branch
“`

新しいブランチを作成するには、`git branch <ブランチ名>`コマンドを使用。

“`bash
git branch new-feature
“`

作成したブランチに切り替えるには、`git checkout <ブランチ名>`コマンドを使用。

“`bash
git checkout new-feature
“`

### git merge

異なるブランチの変更をマージするには、`git merge`コマンドを使用。
これは main ブランチに new-feature ブランチ

Gitコマンド:初級編

# はじめに
こんにちは！

システム開発に欠かせないGit。
様々なコマンドがあるのですが、よく忘れます、、、
備忘録を兼ねて、まずは初級編としてまとめてみました。

# コマンド（初級編）

### git init

新しいプロジェクトを開始する際に使います。
`git init`コマンドを実行することで、そのディレクトリにGitリポジトリを作成。

“`bash
git init
“`

### git clone <リポジトリURL>

GitHubなどのリモートリポジトリからコードをダウンロードしたい場合は、`git clone`コマンドを使用。

“`bash
git clone https://github.com/username/repository.git
“`

### git add <ファイル名>

コードを変更したら、`git add`コマンドで変更をステージングエリアに追加。

“`bash
git add myfile.txt
“`

複数のファイルを一度に追加したい場合は、ワイルドカードを使用。

“`bash
git add *.tx

【AWS】Codepipelineで[GitHub] No Branch [xxx] found for FullRepositoryName と出た場合

# 概要
AWS CodepipelineでGithub接続バージョン2を利用していたら以下のエラーになりました。こちらの解決方法を紹介します。

> [GitHub] No Branch [xxx] found for FullRepositoryName [xxx/xxxx_xxx]


### 前提：CodePipeline設定
– Sourceのアクションプロバイダーは GitHub バージョン2 を利用
– Buildのアクションプロバイダーは AWSCodebuild を利用
– CodePipeline と GitHub の連携は CodeStarSourceConnection を使用
– Github側の AWS Connector for GitHub は以前からインストール済

# 原因と解決方法
エラーメッセー

gitでマージ済みのローカルブランチを一括削除

## 概要

開発を進めていると、いつの間にかローカルブランチが増えてしまって管理が大変…なんてこと、よくありますよね。特に、マージ済みのブランチはそのまま放置してしまいがちです。

でも大丈夫！ Git コマンドを使えば、**マージ済みのローカルブランチを一括削除**し、スッキリとしたブランチリストを維持できます。

## なぜマージ済みのブランチを削除する必要があるの？

– **ブランチリストが見やすくなる:** 不要なブランチを削除することで、必要なブランチを見つけやすくなります
– **誤操作を防ぐ:** マージ済みのブランチが残っていると、誤って古いブランチで作業してしまう可能性があります
– **Git の動作を軽量化:** ブランチが多いと、Git の処理速度に影響が出る場合があります

## マージ済みのローカルブランチを一括削除する方法

以下のコマンドをターミナルで実行するだけで、マージ済みのローカルブランチを一括削除できます。

“`
git branch –merged | grep -v \* | xargs git branch -d
“`

#

devcontainer内でgitを使いたい

# 背景

devcontainer内でgithubにpushしたい。できないと開発中煩わしい。

pushはsshキーを使う。

OSはwindows11。

# 解決法

### Step1(devcontainer内でgitコマンドを使えるまで)

devcontainerの使用イメージにデフォでgitがインストールされているイメージを使用するか、dockerfileでRUNを使用してgitをインストールする。

`mcr.microsoft.com/devcontainers/python:1-3.12-bullseye`はpythonを使用したいかつ、デフォでgitが入っているので使用。

“`docker
FROM mcr.microsoft.com/devcontainers/python:1-3.12-bullseye
“`

これで、gitコマンドは使えるはず。

### Step2(デフォルトブランチをmainにする)

`git init`コマンドを打つと

“`docker
vscode ➜ /app $ git init
hint: Using ‘mas

まだgit stashで消耗してるの？Git Worktreeで作業効率アップ！

こんにちは、皆さん！今日は多くの開発者が日々直面している問題、そう、ブランチの切り替えについて話したいと思います。「あ、ちょっと待って！このコード、コミットしてないけど…」というシーンを想像してみてください。そんな時、みなさんはどうしていますか？多くの人が`git stash`を使っているのではないでしょうか。

でも、実は`git stash`よりもっと便利で、作業効率を劇的に向上させる方法があるんです。その秘密兵器とは…**Git Worktree**！

## Git Worktreeとは？

Git Worktreeは、同じリポジトリの複数のブランチを異なるディレクトリで同時に作業できるようにする機能です。つまり、ブランチごとに独立した作業ディレクトリを持つことができるのです。

## Git Stashとの比較

| Git Stash | Git Worktree |
|———–|————–|
| 一時的な変更の保存 | 複数のブランチを同時に扱える |
| 切り替え時に毎回操作が必要 | 切り替えが瞬時 |
| 変更の管理が複雑にな

Git で無限に rebase が終わらない時

`git rebase` をしていたら謎現象に当たったのでメモ書き

以下のようなコミット履歴があったとします。

“`
aaaaaa: A
bbbbbb: B
cccccc: C
“`

`git rebase -i aaaaaa^` で `aaaaaa` を `edit` にして保存します。その後 `aaaaaa` で作業を反映し `git rebase –continue` をすると当然 TODO は次の状態になります。

“`
bbbbbb: B
cccccc: C
“`

B, C は `pick` なので通常なら何事もなく commit されて終了なはずですが、なぜか `bbbbbb` がすでに反映されている状態で更に追加しようとしました (なぜ?)

“`
error: could not lock ‘.git/MERGE_MSG’: File exists
error: could not apply bbbbbb… B
hint: Resolve all conflicts manually, mark them as resolved with
hi

Ubuntu 24.04でGitとDockerを導入しLaravel Sailを起動するまでのまとめ

## はじめに
以前投稿した[Laravelのインストール記事](https://qiita.com/motuneko253/items/4ca503b2a2beba5fa232)にて、WSL2上にLaravel Sailを構築しましたが、いきなりサーバのお引越しを行います。
今回はVMware上に建てた仮想マシンのUbuntu 24.04を使用し、Dockerの導入およびGitでCloneをしたソースでLaravel Sailの起動が出来る所までやりたいと思います。

## 環境
冒頭でも記載しましたが、今回はUbuntuの最新バージョンであるLTSの24.04を使用していきます。

### OS情報
“`ruby:コマンド
$ cat /etc/os-release
PRETTY_NAME=”Ubuntu 24.04 LTS”
NAME=”Ubuntu”
VERSION_ID=”24.04″
VERSION=”24.04 LTS (Noble Numbat)”
~省略~
“`

## Gitの設定
WSLのUbuntu 24.04ではgitをインストールすると記載していた方もい

Gitがファイル名の大文字小文字を認識せず、監視対象にしてくれない

# 経緯
新しいPCで作業した時、ファイル名をキャメルケースだったのをパスカルケースに変更する作業を行いました。
その際に、変更してもGitの変更履歴に載ってこなくて困ったので、その対象法です。

# Gitには、大文字小文字の認識設定があった
デフォルトだと、Gitは大文字小文字の認識を違いとはみなさず、監視対象にしません。
それを、以下のコマンドで変更することができます。

“`teerminal
# 大文字小文字の違いを監視する
git config core.ignorecase false
“`

ちなみに、現在の大文字小文字で差分を監視するか、という設定項目を確認するコマンド
“`terminal
git config –get core.ignorecase
“`

全ての設定項目確認は以下のコマンド
“`terminal
git config –list
“`

git addで不要なファイルを除外する方法

“`zsh
git add — . ‘:!path/to/files’
“`

`–`はオプションの終わりを示し、後に続くものはファイル名として扱われます。

`:!`は否定パターンを示します。これに続くパスは追加から除外されます。

Gitクローンの403エラーのトラブルシューティング自分用備忘

[こちら](https://zenn.dev/st43/articles/d560e33d58622f)で解決。

パスワードに使っているPATにRead/Write権限を設定する必要があった。

何も考えずgit add . することから卒業しよう

# はじめに
こんにちは！新人エンジニアの @shinkaaaai です。

Gitは多くのソフトウェア開発の現場で使われており、研修などで学ぶ機会も多いと思いますが、Gitの真意が理解できずに、とりあえず使えるコマンドだけ覚えているという人も多いのではないでしょうか。(というか私がそうだった:sob:)

特に`git add`は初心者には中々理解が難しく、私もとりあえず`git add . `とやっていた期間が結構ありましたが、先日社内の @k_uki512 主催のGitのLT会に参加した際に`git add`のありがたさを実感したので共有したいと思います。

# 基本のおさらい
Gitはワーキングディレクトリとステージングエリアとローカルリポジトリという3つの状態を駆使して変更履歴を管理しています。

> https://git-scm

GitHubでパーソナルアクセストークンを設定する

GitHubが2021年8月13日以降、パスワードによる認証を廃止したため、パーソナルアクセストークン（PAT）あるいはSSHキーでの認証を行う必要がある。SSHキーでの設定方法は[こちら](https://qiita.com/mz_mz_mz/items/1c9a73031870b082675c)。

### 1. パーソナルアクセストークン（PAT）を生成

1. [GitHubのウェブサイト](https://github.com)にログイン
2. 右上のプロフィールアイコンをクリックし、Settings を選択
3. 左側のメニューから Developer settings を選択
4. Personal access tokens を選択し、次に Tokens (classic) を選択
5. Generate new token ボタンをクリック
6. トークンに適切な名前を付け、必要なスコープ（例えば、repo など）を選択
7. Generate token をクリック
8. 表示されたトークンをコピー　※このトークンは一度しか表示されないため、安全な場所に保存

##

Git操作について

## Git操作について記載
※参考 兼 自身のメモ用
※随時追記

“`bash:
# リモートリポジトリの複製
$ git clone
“`

“`bash:
# ブランチの作成（ブランチ名を指定しないと既存ブランチの確認ができる）
$ git branch ブランチ名
“`

“`bash:
# ブランチの切り替え
$ git checkout ブランチ名
“`

“`bash:
# ステージングエリアへの移行
$ git add
“`

“`bash:
# リポジトリへのコミット
$ git commit -m “コミットメッセージ”
# amendオプション（最新のコミット情報を変更できる）
$ git commit –amend -m “コミットメッセージ”
“`

“`bash:
# ブランチのマージ
$ git merge ブランチ名
“`

“`bash:
# リモートリポジトリへの反映
$ git push
“`

“`bash:
# ローカルリポジトリへの反映
# リモート→ローカルの追跡ブランチ
$ git fetch

gitコマンド集備忘録

# gitのコマンド備忘録

gitのコマンドを忘れてもいいように記事に残します

# ブランチ確認
git branch

# 全てのファイルをステージングへあげる
git add .

# ステージングのファイルをメッセージ付きでコミット
git commit -m ‘message’

# プッシュ
git push

# ローカルブランチ削除
git branch -d ブランチ名

# リモートブランチ削除
git push origin :ブランチ名

# ステージング、コミット、プッシュまでまとめたシェル
“`shell:git-add-commit-push.sh
#!/bin/zsh

# git add .
git add .

# コミットメッセージの入力を求める
read -p “Enter commit message: ” commit_message

# git commit -m ”
git commit -m “$commit_message”

# git push
git push

“`

今日から始めるセキュリティシフトレフト on AWS ①Git Hooksでシークレット情報を守る

# はじめに
昨今、システム構築におけるセキュリティの重要性は依然と比べて高まってきている。
AWSでも様々なマネージドサービスでセキュリティを担保してくれているが、マネージドサービスの利用方法も含めたソフトウェア寄りのセキュリティは責任共有モデル上、ユーザサイドの責任となる。

https://aws.amazon.com/jp/compliance/shared-responsibility-model/

本記事では、ソフトウェアのセキュリティを早期から効率よく高める＝セキュリティシフトレフトの方式を考察していく。

第1回は、システム実装の入口となる、Gitにおけるセキュリティ向上を行う。

後工程のセキュリティは、最悪、プロダクション環境へのデプロイをしなければ守ることができるが、誤ってGitに対してシークレットをCommitしてしまうと、即座に悪用されるリスクに晒されることになる。

Commit前にこういった状況を回避するための仕組みを紹介していく。

# Git Hooksを活用しよう
## Git Hooks概要
Git Hooksは、その名の通りGit操作に対するフ

【Git】コミット時のコメントの付け方

# はじめに
Gitでコミットする場合はコミットメッセージが必須となります。
※コミットメッセージが空のままで実行するとコミットに失敗します。

このコミットメッセージですが、本当に適当に書いている人が多いです。。。
この記事ではコミットメッセージの重要性と記載方法について記載していきます。

# Gitコミットメッセージはなんで記載するの？
まず、コミットメッセージの記載する理由は以下の通りだと考えています。
・一目でどんなコミット内容なのか判断するため
・何故この修正内容になったか理由や意図について簡易的に説明しやすいようにする為
・revertしたい時にどのコミットを対象とするか判断しやすい
　→revert自体はあまり推奨されるコマンドでは無いですが、、
・ある時点でどのような修正が入ったか確認したい時に便利
　→例えば、
　　　大体この辺りのバージョンから特定のバグが発生するようになった、
　　　では具体的にどのコミットから発生するようになった？
　　とかの場合に役立つ
・コー