今さら聞けないGit 2022年05月11日

今さら聞けないGit 2022年05月11日

GitHubからアクセストークンの有効期限切れメールが届いた際の対策方法

## 概要
「[GitHub] Your personal access token has expired」 というタイトルのメールがGitHubから送られてきた。
既に多くの記事で対策方法が記載されているが、自分の備忘録のため記載する。

## アクセストークン発行

GitHubにアクセスして、右上の自身のアイコンをクリックし、「Settings」ボンタンをクリックする。
![スクリーンショット 2022-05-09 110445.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1229062/82980a65-e034-8be5-8f93-529dc0755719.png)

「Developer settings」ボタンをクリックする。

![スクリーンショット 2022-05-09 110525.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1229062/20001bb6-eb72-fa8f-c6a0-7a9

元記事を表示

【Git】任意のGitHubリポジトリでプロキシを利用する【簡単設定】

# 任意のGitHubリポジトリでプロキシを利用する設定

以下のコマンドを実行します。
`GitHubリポジトリの組織名`は`https://github.com/usuba/sample`というGitHubリポジトリであれば`usuba`を指定してください。

“`
git config –global http.https://github.com/[GitHubリポジトリの組織名]/.proxy http://[プロキシのドメインかIPアドレス]:[プロキシのポート]
git config –global https.https://github.com/[GitHubリポジトリの組織名]/.proxy https://[プロキシのドメインかIPアドレス]:[プロキシのポート]
git config –global url.https://github.com/[GitHubリポジトリの組織名]/.insteadOf git@github.com:[GitHubリポジトリの組織名]/
“`

元記事を表示

[swift]SourceTreeでのGitflow

# はじめに

SourceTreeでgitを運用する際の備忘録です。

# Gitflowとは?

「A successful Git branching model」というワークフローが元になっているそうです。

https://nvie.com/posts/a-successful-git-branching-model/

大規模な開発をうまく運用していく為のフローですね。

# ブランチの種類

![at-it-git-15-001.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1112697/cc1a2328-7b66-ce18-4299-68b0eefaae0e.jpeg)

## メインブランチ

以下の2つは常に存在しています。

### ・master 
リリース済みのソースコードを管理する

### ・develop
開発中のソースコードを管理する

## サポートブランチ

タスクに合わせて、下記ブランチを切って進めていきます。

### ・feature
機能実装やバグ修正

元記事を表示

【Git】git cloneをする際に発生するPermissionエラー対処(git@github.com: Permission denied (publickey).)

# はじめに
GitHubから`git clone`する際に発生するPermissionエラーの対処方法について記載しております。
初歩的かもしれませんが、ご了承下さい。

# 前提
– GitHubに登録済みの状態(テストアカウント作成)
– Gitの初期設定が未実施の状態
– 使用端末はMacOS(初期でGit導入済み)

※通常では、Gitの初期設定を実施

https://qiita.com/wnoguchi/items/f7358a227dfe2640cce3

:::note info
今回は、GitHubからコードをクローンすることだけにフォーカスしております。
:::

# 内容
GitHubからSSH接続で`git clone`しようとすると以下エラーが発生。
クローンできず。

![スクリーンショット 2022-05-11 0.37.08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/636476/84ddaf2a-1865-6dda-3bfa-8844515dc945.png)

元記事を表示

ソースコードのバージョン管理をするためにGitとGithubを試してみた

## はじめに
最近ソースコードの管理が魔界状態になってしまっており、作業効率が落ちていました。そこでよりよいバージョン管理ができるようにGitとGithubを使用して、より楽な管理方法がないか試してみました。
今までにもGithubを使ったことも有るのですが、コードを適当においておく場所として使用するだけでした。

 よい機会ですので、コード管理の方法をしっかり勉強することにしました。将来の自分へのマニュアルもかねて、今回試してみたことをまとめておきます。
 今回はWindowsで動作確認を行いましたが、Macを使用してもほぼ同じ手順で試すことができます。

## GitとGithubの関係
 Gitとはファイルのバージョンを管理するために使用するツールです。発生するファイルの変更点をバージョンとして記録し、記録した地点へいつでも戻れる仕組みを提供します。
 わかりやすく説明すると、コミットというセーブポイントをたくさん設けることができ、ファイルを以前の状態に戻すことができます。また、いつだれが何の目的で作業したかが記録されているため、作業者以外でも作業内容を把握しやすいという特徴が

元記事を表示

開発時のgit関連でやることまとめ

## はじめに
開発時にgit関連でやることを良く忘れるので、以下に整理しておきます。

## 開発前
リポジトリをクローンする
“`bash
git clone リポジトリURL
“`

フォルダを移動する
“`bash
cd リポジトリ名のパス
“`

developブランチに変更する
“`bash
git switch develop
“`

リモートリポジトリ名のリネームする
“`bash
git remote rename origin fork-master
“`

リポジトリをフォークし、リモートリポジトリ名originとして紐づける
“`bash
git remote add origin フォークしたリポジトリURL
“`

フォークしたリポジトリにメンバーを追加する
(レビューしてもらう際に他メンバーがリポジトリを閲覧できるようにするため)

リモートリポジトリの状態を確認する
“`bash
> git remote -v
fork-master リポジトリURL (fetch)
fork-master リポジトリURL (push)
ori

元記事を表示

コードレビューのためのgithubリポジトリを作成する

Twitterを起点にWEB制作の情報収集や発信を初めて2週間が経ちました。SNS上ではどういうことが求められているのだろうと思って始めましたが、初学者の方々が多かったので無料のレビューと質問を受付するとツイートしたところ1週間で7件ほどのご依頼をいただきました。

レビューの方法はgithubのURLを送ってもらったり、ファイルを一式送ってもらったり、アップされているWEBサイトを見たりしていたのですが、コードレビューはgithubのプルリクエストをベースにしたほうが、学習している人たちもgithubの知識も深まって良いだろうと考えました。

gitの基礎知識については下記をご確認ください。

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

githubは始めて慣れるまでが結構大変のようなので、こちらにレビューの流れをまとめさせていただきます。
前提条件としてgithubのアカウント取得とリポジトリの操作ができる状態とさせてください。

本説明は私の環境での作業となります。
– macOS Monterey 12.3.1
– Visual Studio C

元記事を表示

チーム開発でのgitの使い方、流れまとめ

今まで基本独学でやってきたけど、チーム開発をする機会に恵まれたので、改めてそこで必要な流れをまとめました。
自分のメモ代わり。

# チーム開発でのgitの流れ

## 1.リモートのdevelopを取ってくる
初めてならclone。
以降はpull。
developブランチにいることは確認しておきましょう。

## 2.ローカルで作業ブランチを切って移動
現場で命名規則があれば従いましょう。

### 作業ブランチ切り忘れて開発しちまった!
addしてなければ大きな問題はない。

https://qiita.com/k6i/items/edc69a806095e4fc489c

“`
git checkout -b yourBranchName
“`
などで移動してしまえば問題ない。

## 3.開発したらaddする
“`
git add -A
“`
どこのブランチにいるかは確認しておきましょう。
心配なうちはstatusも見とくといい。

### addを戻すには、、、
https://qiita.com/yukure/items/89562e5eb1d03995dc5b

元記事を表示

PullRequest の特定フォルダー内のファイル差分だけをコマンドで取得したい!

# PullRequest の特定フォルダー内のファイル差分だけをコマンドで取得したい!

指定したフォルダーに差分があるときだけ、ビルド・テスト・デプロイを行う GitHub Actions を作りたい!

そんな状況になることがあると思います!

この問題を解決するために、ブランチのファイル差分を取得するスクリプトを調べてみました。

最終的にでき上がったスクリプトはこちらです!

“`bash
# ブランチ根本コミット取得する
baseCommit=$( \
{ diff -u <(git rev-list --first-parent ${BRANCH_NAME}) <(git rev-list --first-parent ${TARGET_BRANCH}) || true; } | \ sed -ne 's/^ //p' | \ head -1 \ ) # ブランチ先端コミット取得する headCommit=`git rev-parse ${BRANCH_NAME}` # コミットを比較し、ファイル差分を取得する git diff ${headCommit

元記事を表示

メモ: GitHubへの commit と push で使うアカウントが違う? (Windows)

# 概要

GitHub のアカウントを複数使っているのだけど、“git commit“ と “git push“ で使われるアカウントが違う!
ので修正します。

※ **Windows** の場合の記事です。Macの場合は資格情報の消し方が異なります。https://support.apple.com/ja-jp/guide/keychain-access/kyca2423/mac からキーチェーンアクセスを削除できます。

ひとつのリポジトリだけに適用される設定です。全体に適用したい場合は他の記事を探してください…。

# どんな動作?

VSCode で
“`
You don’t have permission to push to (URL). Do you want to fork it instead?
“`
のような通知が出ました。

“git push“ すると Git ではこんなエラー。
“`
remote: Permission to [使いたいアカウント]/Repo.git denied to [使いたくないアカウント].
fatal: u

元記事を表示

git flowとブランチモデルについて

# Git flowとは
リポジトリを分岐させてfeatureなどに分岐させたりして開発する手法です。

“`
git flow

“`
でgit flowを確認できる。

# Git Flowのイメージ
Git Flowを図で表すとこんな感じです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1748789/3251ccd5-f959-d7ce-d64f-2cc7785b71f1.png)

>引用元   https://qiita.com/KosukeSone/items/514dd24828b485c69a05

# メイン・ブランチ
⚫︎“`master“`ブランチといったリリースするときに使うブランチで管理者しかマージやデプロイができなかったりするみたいです。
管理者やベテランエンジニアでもリリースする時はかなり緊張するみたいです。
このブランチで開発はまずありえないです。

⚫︎“`develop“`ブランチという開発用のブランチです。
リリースの準備ができた

元記事を表示

GitHubにてPullRequest後のコンフリクト修正の流れ

# 前提
チーム開発にて自分がプルリクエストした後にコンフリクトの修正を依頼された場合の修正方法についての忘備録。
具体的な状況としては、自分のプルリクエストした後に他の人のプルリクエストがマージされたことでコンフリクトが発生し、そのコンフリクトを解消する時の流れについての記述です。

# 修正の流れ
1.masterブランチに移動する
“`
git checkout master
“`

2.ローカルのmasterブランチに最新状態のリモートリポジトリの状態を取り込む
“`
git pull origin master
“`

3.自分の作業していたブランチに移動する
“`
git checkout <作業していたブランチ名>
“`

4.masterブランチをマージ
“`
git merge master
“`
するとコンフリクトが起きている旨を表すメッセージが表示される
例)
“`
git merge master
Auto-merging static/app.css
CONFLICT (content): Merge conflict in stat

元記事を表示

gitで直前のコミットを上書きしたい

## 方法

直前のコミットに上書きするには、以下のコマンドを叩けばOK。

“`bash
git commit –amend
“`

## 参考

https://qiita.com/shuntaro_tamura/items/06281261d893acf049ed

元記事を表示

gitで複数コミットをまとめる際のコマンドまとめ

## はじめに
gitでPR作成時に複数コミットをまとめたい時があります。
その際にいつもググって対応していますが、今後の自分のためにコマンドをまとめておきます。

##

### git logでまとめたいコミット確認

“`bash
> git log –oneline
d12871a test3
db92104 test2
e4ae077 test1
“`

### git rebase -iで複数コミットをまとめる

今回は上記の3つを1つにまとめることを考えます。

まとめたいコミット分だけgit rebase -iします。
“`bash
git rebase -i HEAD~3
“`

すると、以下が表示されます。
古いコミットが上、最新のコミットは下に表示されます。

“`bash
pick e4ae077 test1
pick db92104 test2
pick d12871a test3
“`

一番上のコミットの`pick`を`s`に変更します。

“`bash
pick e4ae077 test1
s db92104 test2
s d1287

元記事を表示

Github Actionsの設定ファイル作成後にgit pushが失敗する時の対処方法

## 環境
macOS Monterey 12.3.1

## エラー内容
Github Actionsのワークフローファイルを作成後、
git pushすると以下のエラーが発生した。

“`sh
! [remote rejected] HEAD -> (ブランチ名) (refusing to allow a Personal Access Token to create or update workflow `.github/workflows/(ファイル名).yml` without `workflow` scope)
“`

## 原因
Githubのパーソナルトークン設定で’workfrow’を許可していなかった。

## 対処方法
#### 1. トークンを再生成する
Github → Settings → Developer Settings → Personal Access Tokens
→ Generate new token

‘workflow’、その他必要な項目にチェックを入れて再生成する。
(既存のトークンに追加も出来ると思います)
公式docs: h

元記事を表示

WSL に標準でインストールされている git においてブランチ名を表示する方法

# 始めに
 単純にブランチ名を表示する方法なら色々情報があったのですが、環境差異で微妙に手順が違ったので、備忘も兼ねて記事にまとめておこうと思います。

 手順のみ知りたい方は要約を、調査した内容を時系列に記録してるだけ

# やりたい事
↓な感じでコマンドライン上に、常にブランチ名を表示させる事が今回のゴールです!??
“`bash
user@:/home/username/my-repository #

user@:/home/username/my-repository (main) #
“`

# 環境
ホスト環境
 OS: Windows10 home
ゲスト環境
 OS: Ubuntu 20.04.1 (WSL2)
 git: 2.25.1

# 要約
“`bash
user@:/home/username/my-repository (main) #
“`
のように、コマンドライン上にブランチ名を表示させるためには、
“`bash:.bashrc
PS1=’${debian_chroot:+($debian_chroot)}\u@\h:\w$(__g

元記事を表示

複数 git アカウントを1台のPCで使い分ける方法

# はじめに

複数 git アカウントを1つの PC で使い分けたいとき(「社用と私用両方から github 使いたい」等)、
社用と私用アカウントを使い分けたいとき(「社用アカウントで github, 私用アカウントで gitlab」等)、
ありますよね。手順まとめます!

重視した点
めちゃくちゃ細かく書きました。
自分が PC 新調して再設定する度に細かい所忘れ去っており思い出すのに苦労しているので(おっさんおつ)、
忘れ去っててもサクサク設定出来るように。。

# やりたい構成

最初にイメージしやすく構成を書きます。
適当に、アカウント2つ(社用、私用)、それぞれに git ホスティングサービス2つ利用、の状況を考えます。
図にするとこんな感じ。
「アカウント1つ目で gitbucket と github、アカウント2つ目で github と gitlab」
としていますが、これはあくまで例で、実際やる場合の組合せは任意です。

“`bash
$ cd ~/git
$ tree -a
.
├── .gitconfig
├── business
│   ├── .gitco

元記事を表示

レビュアーの時によく使うGitHubの便利機能

# はじめに
GitHubにはコードレビューで使える便利機能がたくさんあったので、
今回はそれらを取りまとめてみました。
レビュアーとしてプルリクエストを見る際など参考になれば幸いです^_^

# 目次
[1.Hide whitespace](#1-hide-whitespace)  ( 差分をスペースやタブの差分を無視して表示してくれる )
[2.Pull Request File Tree](#2-pull-request-file-tree) ( Pull Request 上の差分をファイルツリーで表示してくれる )
[3.Suggested Change](#3-suggested-Change) ( レビュアーが提示してきたコードの修正案を即座に取り込める )
[4.Viewed](#4-viewed) ( レビューの進捗度がわかる )
[5.その他・小技](#5-その他小技)
[最後に](#最後に)

# 1. Hide whitespace
* Pull Request の差分をスペースやタブの差分を無視して表示してくれる機能

#### 使い方
URLの末尾に`?w=

元記事を表示

プルリクエストの実装中からマージするまでに気を付けていること

# 前置き
GitHubを使ったチーム開発をしていることを想定しています。
なんらかのバージョン管理ツールを使っていれば、適用できる内容かなと思います。
個人開発でも、多少手を抜くところはあっても大まかな流れは同じにしてます。

# 気を付けていること
自己レビュー的にやっていることが多くあります。
それでもレビューでコメントもらうことも多いですが、ミスはだいぶ減らせるのかなと思います。

## 実装
### 実装前
– おおまかな修正箇所を特定して、どこから手を付けるかを考える
– コミットをどう分けると分かりやすいかも少し考えます
– 既存のテストコードがどのくらいあるかも気にします
– 対象リポジトリ以外にも影響がないかなど影響確認もします
– 既存コードが入り組んでいたら、まずリファクタできないかを考える
– 仕様変更など新しいことを入れてからリファクタするよりも、まずきれいにした方がたいてい楽です
– テストコードが不足していたら、まず現行仕様のままテストコードを追加します
– リファクタだけで先にプルリクエスト作ることもあります

### 実装中

元記事を表示

.gitignoreって何?

# .gitignoreとは
***Gitの管理下におきたくないファイルを指定するファイル***のことです。

# どこにあるのか
ざっくりとした説明になりますが、ファイルの下の方にあります。

![スクリーンショット 2022-05-06 10.04.21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1748789/34031b0a-6e0c-6854-e21b-6f004271dba1.png)

# 設定方法
今回は.envをGitの管理下から外そうと思います。
.gitignoreで設定している時は下のように特に何もありません。
![スクリーンショット 2022-05-06 10.07.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1748789/b080d780-16fd-03df-7aea-8a7df3081e48.png)

.gitignoreで設定すると下のように.envの文字が薄くなります。

元記事を表示

OTHERカテゴリの最新記事