今さら聞けないGit 2022年08月03日

今さら聞けないGit 2022年08月03日

Git壊した

git でpushしようとしたら、commitもpullもできないのでワーキングツリーをきれいにできなかった。
branchもmainとmasterがごちゃごちゃになっていて、よくわからないフォルダとつながっていた

解決法
フォルダごと消してclone、gitにあげられていないファイルはコピーして上書き

元記事を表示

GitリポジトリをBitbucketからGitLabへ移行する

## はじめに
古いプロジェクトでBitbucketを利用していたため、
現在メインで利用しているGitLabへ移行しました。
めんどくさそうと思っていたのですが一括で移行でき簡単でした。

ちなみに作業中、特に問題はないですがBitbucket側でしばらくリポジトリを読み込めない状態になりました。
(GitLabのリンクでBitbucketへ移動するとセッションがおかしくなる?再ログインで戻った)
GitLab側は何も問題なく移行できていました。

## 移行
GitLabにて
Menu > Project > Create new Project > Import project > Bitbucket Cloud

![スクリーンショット 2022-08-02 16.21.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/564978/208de654-df19-9774-ab15-f06696f263ca.png)

Bitbucketへ移動するのでアクセス許可する

Import proje

元記事を表示

Gitの変更差分仕組みが気になったので調べてみた件

## はじめに
チーム開発では色んな人がコミット・マージする訳だが、ブランチ戦略を無視する猛者が出てくるとたまに意図しない挙動することがある。弊社でよくあるのはstaging・masterに直Pushとか(結構ヤバイ)。そーするとブランチ戦略を守ってる人からすると、たまにstaging→masterにPR出した時に勇者のリリース済みの変更点が表示される時がある。もちろん猛者の変更はmasterに既に存在している。つまり、stagingとmasterのファイルの内容は一緒なのに勇者の変更点が差分で現れるのだ。

ここで疑問に思った。

「Gitてファイルの中身の変更点で見てるんじゃねーのか??ファイルの内容って一緒なのに何故に差分が出るのだ?」

## TL;DR
* GitはKVS(Key Value Store)で情報を持つ
* `git add` した瞬間Blobオブジェクトが作成されてSHA-1生成されたハッシュ値とヘッダーという情報でIDが付与される
* Blobオブジェクト自体はファイルの内容を持ってる。
* `git commit`毎にtreeオブジェクトが生成されBlo

元記事を表示

Visual Studio 2019 gitignore 作成

gitignore の作成で、こんな便利なコマンドがあるのか!知らなかった。
今まで手で作ってた。。

コマンドプロンプトから、以下のコマンドで、gitignoreファイルが作成される。
“`
dotnet new gitignore
“`
(dotnetコマンドは、Visual Studio 2019がインストールされているだけで、入っていました)

### 参考
https://suzukaprogrammer.com/2022/06/gitignore/
https://wonwon-eater.com/dotnet-gitignore/

> dotnet core3.1で作成したgitignoreは以下の通りです
内容を直接コピーして使用することも出来ますが、dotnet coreのバージョンに伴って中身は変わっていきます。
バージョンが一致していれば構いませんが、出来れば各自の環境で作成することをお勧めします。

確かにdiffをとると、.NET 5で作成したのと少しだけ違いました。

元記事を表示

error: failed to push some refs to ‘github.com:jojo232/raistech-aws202208.git’

git pishしようと思ったら下記エラー発生

“`
! [rejected] main -> main (fetch first)
error: failed to push some refs to ‘github.com:jojo232/raistech-aws202208.git’
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., ‘git pull …’) before pushing again.
hint: See the ‘Note about fast-forwards’ in ‘git push –help’ for det

元記事を表示

Load key “/Users/sasakiyuuya/.ssh/github”: invalid format git@github.com: Permission denied (publickey).

WARNING: UNPROTECTED PRIVATE KEY FILE!

上記のエラーは無くなったが次なるエラーが発生。

“`
Load key “/Users/sasakiyuuya/.ssh/github”: invalid format
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
“`

何やら形式が無効でアクセスが拒否されたのことでリモートリポジトリから読み取ることができない、

よくわからなくなったので、下記サイトから一回リセットしてやり直し

https://qiita.com/aki4000/items/4c81bc2747bbd5e96d85

鍵を生成して、Githubに貼り付ける。

それでも下記ようなエラー発生
“`
no such identity:

元記事を表示

WARNING: UNPROTECTED PRIVATE KEY FILE!

下記コマンドを実行しようと思った結果
“`
git push -u origin main
“`

・エラー発生

“`
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for ‘/Users/sasakiyuuya/.ssh/github’ are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key “/Users/sasakiyuuya/.ssh/github”: bad permissions
git@github.com: Permis

元記事を表示

warning: unable to access ‘/Users/xxx/.config/git/ignore’: Permission denied

ローカルからGitHudに繋げようと思ったら障害が起こった。

“`
cd ~/
ls -al
“`
上記コマンドw打つと、ファイルが数多く並ぶ、その中で.configファイルのところがrootになっている。

そうしたら下記コマンドを実行

“`
sudo chown -R $(whoami) .config
“`

.configファイルの所有権限を現在のユーザー名に変更する。

エラー解消。

元記事を表示

Github なぜ、ssh認証は必要なのか?

## はじめに
この記事は、「なんとなく理解できた」を目的としているため、正確性、具体性に欠ける表現がございます。

精度の高い情報を求めている方には向かないので、ご理解ください。

##

まず、githubの通信方法としてgitから始まる文を通して接続をしてレンタルサーバーにアクセスをするという手段をとっている。

その時に、gitから始まる通信を暗号化する必要があるのだが、githubではSSHという暗号を使っている。

SSHという暗号は、何もしなくても使えるわけではなく、公開鍵・秘密鍵のどちらかが必要になる。

なので、SSHを使うには、鍵の作成が必須になってくるのである。

## おわり
最後まで見ていただき、ありがとうございます。
気になった点や、感想などをいただけると、嬉しいです。

元記事を表示

Gitの基礎知識

# はじめに
この記事は、Gitに関して全然詳しくない!
教えてもらったとき、いろんな用語が飛び交ってたけど意味が分からん!
といった超初心者向けです。
そのため、実際の操作方法は解説しておらず、大まかな概念のみまとめています。

# Gitとは
Gitとは、プログラムのソースコードなどの変更履歴を記録追加するための分散型バージョン管理システムのことである。
有名なプラットフォームとして、[Github](https://github.com/)や[BitBucket](https://bitbucket.org/product/)、[GitLab](https://about.gitlab.com/)などが挙げられる。

# 用語集
### ・分散型バージョン管理システム
ユーザーがそれぞれのPCにローカルリポジトリ(リモートリポジトリのコピー)を持つ方式のこと。
ユーザーは、ローカルリポジトリにある程度の編集を加えた後に、コピー元のリポジトリ(リモートリポジトリ)に変更を加える。

### ・リポジトリ
ファイルであったり、変更履歴を置いておく場所のようなもの。

### ・インデ

元記事を表示

【git】cherry-pickはやっぱり美味かった?

## やりたいこと
ブランチをそのままマージしたくはないけど、特定のコミットだけを取り込みたい。
cherry-pickを使ってみる。
![image_1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/969534/2f516d9e-1b63-48d3-0fc1-8417573847c2.png)
## 結論
◆他ブランチから指定したコミットを取り込んだ後に、そのまま自ブランチにコミットしてよいとき
“`
git cherry-pick [コミットID]
“`
◆他ブランチから指定したコミットを取り込んだ後に、そのまま自ブランチにコミットしないとき
“`
git cherry-pick -n [コミットID]
“`
## 検証

### 検証の流れ
1. featureAブランチとfeatureBブランチをを作成
2. featureAブランチにのみコミットを繰り返して、ファイルの中身を変更
3. fearuteBブランチに追加したいコミット履歴のみfeatureAからcherry-pickす

元記事を表示

【git】コミットIDを指定して派生ブランチを作成

## やりたいこと

ブランチを派生させるときに`git checkout -b [派生元のブランチ名] [派生先のブランチ名]`とコマンドを叩くが、これだと派生元のブランチの歴史を全てコピーすることになる。今回はそうではなく、コミットID指定して、途中から派生させたブランチを新規作成したい。

## 結論
“`
git checkout -b [コミットID]
“`
とすれば良い。簡単!
最後のコミット履歴要らないな。。というときに使えそう!

元記事を表示

ブラウザを開きたくなくてGitHub CLIをインストールした話

どうも`hrak0x59`です〜
期末試験中でなかなか更新できていなかったのですが、今日少し時間が取れたのでメモがわりにQiitaに殴り書きしていこうと思います〜

# 経緯
普段GitHubを使うときはブラウザからリモートレポジトリを作成しているんですが、これがめんどくさいんですよね…
てなわけでちょっと調べてみたらなんとあるじゃないですか、便利そうなものが!

https://cli.github.com/

`これを使えばブラウザを開かなくてもリモートレポジトリ作ったりissueいじったりプルリクを送ったりGitHubで使う操作をコマンドラインからいじれちゃうわけですね!`

# GitHub CLI
## インストールしてみよう
どうやらmacの場合はbrew経由でインストールすれば自動的に補完機能(gh completion)もセットアップしてくれるようなので自分の場合はbrewでインストールしてみます。
“`zsh
brew install gh
“`
## アカウントにログインしてみよう
次にgithubのアカウントにログインしてみます。
“`zsh
gh au

元記事を表示

既存のDjangoプロジェクトを使ってDjango+Nginx+MySQL環境をDockerで構築する

# 目標
既存のDjangoプロジェクトをdocker-composeで起動する。
# 筆者の環境
| 項目 | バージョン |
|–|–|
|wsl2|Ubuntu 20.04 LTS|
|Docker|version 20.10.17, build 100c701|
|docker-compose|version 1.29.2, build 5becea4c|
# 対象
1. 既にDjangoのプロジェクトを持っていてGitHubにあげている。(GitHub専用ではないのでGitさえ使えれば良いです。)
1. Dockerが使える
1. docker-composeが使える
# 対象かどうかをチェック
Dockerが使えるかどうか
“`bash
$ docker –version
Docker version ~.~.~, build ~~
“`
docker-domposeが使えるかどうか
“`bash
$ docker-compose –version
docker-compose version ~.~.~, build ~~
“`

元記事を表示

GitHub を登録

まずはユーザー名(GitHubに登録したもの)を登録
“`
$ git config –global usr.name “ユーザー名”
“`

メールアドレス(GitHubに登録したもの)を登録
“`
$ git config –global user.email “メールアドレス”
“`

mergeの際にファストフォワードが起きないようにする設定
“`
$ git config –global merge.ff false
“`

pullの際に毎回リベースする設定
“`
$ git config –global pull.rebase merges
“`

設定ができているかを確認
“`
$ git config –list
“`


“`
credential.helper=osxkeychain
user.name=”name”
user.email=email
core.editor=code –wait
alias.ci=commit
alias.st=status
alias.br=branch
alias.co=checkout

元記事を表示

開発用(feature)ブランチにmain(master)ブランチをマージした時 初心者向け

作業用(開発)ブランチで作業をしていて、メインブランチの最新状態を反映したくなった。
メインブランチをmergeコマンドで作業用ブランチに反映すると以下のメッセージが表示された。

“`:ターミナル
Merge branch ‘main’ into feature/create_comment
# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with ‘#’ will be ignored, and an empty message aborts
# the commit.
~

元記事を表示

既にGitで追跡済みのファイルはgitignoreで除外されない話

## はじめに

Git管理対象外にしたいファイルやディレクトリを `.gitignore` に記載することで実現することができます。
しかし、先日 `.gitignore` に指定してもGit管理対象外とならなずに躓いたため、その共有です。

## 結論

何が原因でGit管理対象外とならなかったかというと、既にコミット(またはステージング)済みのファイルを管理対象外としようとしていたためでした。

少し考えたら当然ですが、既にGitで追跡済みのファイルに対しては `.gitignore` に指定しても効力がないらしいです。

[gitのドキュメント](https://git-scm.com/docs/gitignore)に以下のような記載がありました。

> A gitignore file specifies intentionally untracked files that Git should ignore. Files already tracked by Git are not affected; see the NOTES below for details.

##

元記事を表示

Gitコマンド git logで各コミットで修正があったファイルも出力する

# 概要

– `$ git log`コマンドにて各コミットで修正されたファイルも一緒に出力する方法をまとめる。

# 方法

– git logコマンドに`–stat`オプションを付与する。
– なので下記のコマンドを実行する。

“`shell
git log –stat
“`

– `–name-status`オプションをつけると表示方法が変わる。

“`shell
git log –name-status
“`

元記事を表示

Railsチュートリアルでのherokuへのデプロイのエラー対処まとめ(第6版)【備忘録】

# 背景
第6版の第1章で、githubへのpushまではすんなり進んだのですが、herokuにデプロイする際にエラーが多発したため、主に備忘録用のエラー対処まとめです。

# 前提条件
railsやgemのバージョンなどは基本的に「22年7月26日時点の第6版」で指定されている通りです。

# エラー解決に必要だった処理や対処のまとめ
本題です。
エラー対処は大きく「1.デプロイ自体が失敗するエラー」を解決した後、「2.アプリケーションエラーの原因となるエラー」を解決するという流れでした。

## 1.デプロイ自体が失敗するエラー
### 1.Failed to install gems via Bundler
bundlerのバージョンがローカルとherokuで異なっていると発生するエラーのようです。
このエラーが出た際、エラーメッセージを辿っていくと
“`
remote: —–> Installing bundler 2.3.10
“`
といったメッセージが出ていますが、これがherokuのbundlerのバージョンです。
Gemfile.lockファイルの一番下に記

元記事を表示

Release Please Actionの紹介

[RSpec::ContextHelper](https://github.com/masaakiaoyagi/rspec-context_helper.rb)という小さなgemのリリースに[Release Please Action](https://github.com/google-github-actions/release-please-action)を使ってみたのですが、便利だったので紹介します


## これは何?
[Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/)に従ったコミットメッセージを付けることでリリースの自動化をするもの


## 何してくれるの?
以下のようなことが出来そうです
* [バージョン](https://github.com/masaakiaoyagi/rspec-context_helper.rb/pull/24/files#diff-fc01d50d6c08cd5b55f1596f331d2cd2c25bd19db0bb7cb72ee2e0476

元記事を表示

OTHERカテゴリの最新記事