今さら聞けないGit 

今さら聞けないGit 
目次

【GitHub】ローカルリポジトリをリモートリポジトリにPushする

# はじめに
ローカルで作成したリポジトリをGitHub上のリモートリポジトリにプッシュします。

# 前提条件
– gitがインストールされていて、gitコマンドが使える状態

# GitHubでの操作

1. 新しいリポジトリを作成

任意の名前でリポジトリを作成します。
READMEや.gitignoreを作成するオプションがありますが、一旦スルーして空のリポジトリを作成します。

# ローカルでの操作
## 1. ローカルプロジェクト内でgitの初期設定を行う

リモートリポジトリで管理したいプロジェクトに移動します。
そこで以下のコマンドを実行します。
“`bash
git init
“`

これでプロジェクト内に`.git`フォルダが作成されます。

## 2. プロジェクトファイルをgit管理下に置く

“`bash
git add .
git commit -m “commit comment”
“`

## 3. ブランチ名の確認

以下のコマンドでbranch名を確認します。
“`bash
git branch
> main
“`
2024年7月現在、デ

元記事を表示

Git LFS を使いたいんじゃ!!!

こんちわ。

ゲーム会社でソシャゲを作ってます、あまがみです!
今回は、個人開発で Git LFS を使ってみたかったので、いろいろ調べてみました!

備忘録です!

# Git LFS とはなんぞや?
まず Git と Git LFS って何が違うん?というところから。

## Git
Git とは、プログラムのソースコードなどをの変更履歴を記録・追跡するための `分散型バージョン管理システム` です。

古いバージョンに戻したり、新旧のファイルを一元管理できたり、複数人で修正した部分を共有できたりします。

## Git LFS
Git LFS とは、Git の拡張機能です。
Git は 100MB 以上のファイルを扱えないのですが、Git LFS を使用することで、サイズの大きなファイルを管理することができます。

Git LFS では、サイズの大きなファイルの `meta` データのみを管理し、ファイル本体はリモートサーバーで管理する仕組みになっています。


つまり、Git LFS を使うことで、Git だけでは管理できなかった大きなファイル(asset

元記事を表示

Gitで別ブランチの変更を1ファイルだけ持ってくる

## はじめに
gitで別ブランチの変更をコミット単位で持ってこれる、cherry-pickコマンドはありますが、その変更の全てがほしいわけではなく、一部ファイルの変更だけが欲しい場面がたまにあります。

そういうときに使えるコマンドがあったので、紹介します。

“`zsh
git checkout <欲しい変更があるブランチ> — <欲しい変更があるファイルの相対パス>
“`

たとえば、featureブランチにある特定ファイルの変更が欲しい場合は下記のようになります。

“`zsh
git checkout feature — hoge/fuga/main.go
“`

ディレクトリ単位で持ってくることもできます。

“`
git checkout feature — hoge
“`

## 追記
restoreコマンドでも同じことができるようです。
むしろ、こちらのほうが推奨かも。
“`zsh
git restore -s feature hoge/fuga/main.go
“`

“`zsh
git restore -s feature hoge
“`

元記事を表示

【Git】GitHubの基本操作(草生やすまで)

# ローカルリポジトリを作成する
1. ディレクトリ作成 `mkdir xxx_xxxxxxxx`
2. 作成したディレクトリへ移動 `cd xxx_xxxxxxxx`
3. リポジトリ作成 `git init`
4. リポジトリ作成されたかの確認 `ls -a`
上記コマンドで .git ディレクトリが表示されてればOK
# リモートリポジトリを作成する
1. ブラウザで自身のGitHubリポジトリに移動
2. Repositoriesタグをクリック
3. Newをクリック
4. 以下の項目を入力
Repository name:リポジトリ名を入力
5. Privateの項目にチェックを入れる
6. Create repositoryをクリック
# リモートリポジトリとローカルのリポジトリを紐付ける
1. 「Quick setup — if…」の文言そばにある ssh をクリック
2. 以下のコマンドをターミナルで実行
`git remote add origin git@github.com:GitHubアカウント名/リモートリポジトリ名.git`
`git branch -M

元記事を表示

git switch と git checkout って何が違うの?

# はじめに
こんにちは、H×Hのセンリツ大好きエンジニアです。(同担OKです😉)
「新しいブランチを作成し、現在のブランチを新しいブランチに切り替える」という動作を行いたい場合、`git checkout -b `と`git switch -c `があると思います。

。。。これってどう使い分ければいいの?って思ったので調べました🤔

# git checkoutとは
ブランチの切り替えもありますが、**ブランチの切り替え以外にも多くの用途があるコマンド**です。

1. ブランチの切り替え
“`
git checkout
“`
2. コミットやタグの切り替え
“`
git checkout or
“`
3. ファイルの復元
“`
git checkout —
“`

大体こんなもんかなと思います。
checkoutって言っても、何をするのか具体的な挙動って想像しにくいですよね😮‍💨

それと同じ話が挙がった故に、後述する`git switc

元記事を表示

Generics: A Boon for Strongly Typed Languages

![Generics_typed_languages_36a2c0a02a.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3778885/058d68b5-b803-9d93-c619-245a68166d0c.png)

> Exciting News! Our blog has a new **[home](https://canopas.com/blog)**!🚀

## Background

Consider a scenario, You have two glasses one with milk and the other with buttermilk. Your task is to identify between milk and buttermilk before drinking it(of course without tasting and touching!).

Hard to admit that, right? Just because they seem sim

元記事を表示

git rebase と git merge の基本的な使い方と使用シーンを紹介します!

## `git merge` の紹介

マージの基本的な構文は:`git merge ` です。

マージ操作は、複数のブランチの開発履歴を一つに統合し、全てのブランチのコミットを保持します。そして、マージ操作の完了を示す新しいマージコミット(merge commit)が追加されます。

ここで、以下のような `fix` と `master` ブランチ、およびコミット履歴があるとします:

“`
A — B — C fix
/
D — E — F — G master
“`

この時点で、`fix` ブランチの最新のコードを `master` ブランチにマージしたいと考えています。

`master` ブランチで `git merge fix` コマンドを実行することができます。

これにより、`fix` ブランチのコミット内容(現在のブランチから分岐して以来の全てのコミット)が `master` ブランチにマージされます。

その結果、コミット履歴は次のようになります:

“`
A — B

元記事を表示

【git】プロキシが邪魔したお話

# はじめに
学校内のPCでリモードリポジトリにpushしようとしたらアクセスエラーが出たので、その解決方法の備忘録です。

# 実行環境
OS:windows11
開発ツール:VScode
gitコマンドは,VScodeのターミナル内でたたいています

# エラー
“`python:
unable to access ‘https://github.com/<リモートリポジトリ>.git/’: Failed to connect to github.com port 443
“`
github.comに接続できませんでしたというエラー

# 原因
gitでプロキシの設定をしていなかったため。
私の通信環境内でプロキシサーバを使っていたため、外部サーバへ直接のアクセスが禁止されており、github.comにアクセスできなかったのだろうと考えた。

# windows11でのプロキシ確認方法
`設定`>`ネットワークとインターネット`>`プロキシ`>`手動プロキシセットアップ`
これで自分のプロキシ設定を確認できます。

# 解決方法
「**接続しているプロキシを設定**」すること

元記事を表示

胸部単純X線写真からの画像キャプショニング:GIT編

# モチベーション

ググッときた。

# この技術が発展するとどう嬉しいのか

– 画像確認レポートや、診断レポートのテンプレにできるかもしれない
– 仕事が忙しいときや、疲れているときにでも、気づきを与えてくれる可能性

# アプローチ

今回は、Image To Textで、GITを利用する。
この他にも、大きなフレームワークとしては、次のようなものがある。

## Text To Text

キーワードから、文章を予測させる試みなど。
例えば、MeSHのような、標準化された用語をいくつか入力すると、レポートの文章が自動で作られるようなアプローチ。
逆もありで、長文を要約するアプローチも可能。
BERT、GPT、T5などのモデルで検証可能。

## Image To Text

画像を入力して、画像から直接、文章を予測させるアプローチ。
CNN+LSTM、CNN+GPT、GITモデルなどで検証可能。

## Image To Text To Text

これは、私の妄想フレームワーク。
例えば、画像から、キーワードだけをいくつか予測させておき、このキーワードから、Text To

元記事を表示

【AWS】CodeCommitを触ってみる(リポジトリ作成&クローン)

AWSのCodeCommitでリポジトリ作成からローカルにクローンまで行います。

# リポジトリを作成
CodeCommitのリポジトリの画面を開き、「リポジトリを作成」を押下します。

![画像4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2300564/084f61d2-6254-9568-624e-b1d97fc93b4f.png)
「リポジトリ名」と「説明」を入力します。
「Amazon CodeGuru Reviewer for Java and Python を有効にする」にチェックを付けると、リポジトリにプッシュしたソースコードをAmazon CodeGuruでレビューすることが可能になるようです。
入力できたら「作成」を押下します。

![画像3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2300564/16fff5ce-aad7-3d29-aa5c-285a08676705.png)<

元記事を表示

Gitでpushすると400エラーが出た

# はじめに
ディレクトリに写真を追加し,pushした時に以下のようなエラーが出た.
それを解決した手順を書いていく.

“`
Enumerating objects: 31, done.
Counting objects: 100% (31/31), done.
Delta compression using up to 8 threads
Compressing objects: 100% (28/28), done.
error: RPC failed; HTTP 400 curl 22 The requested URL returned error: 400
send-pack: unexpected disconnect while reading sideband packet
Writing objects: 100% (28/28), 9.97 MiB | 12.45 MiB/s, done.
Total 28 (delta 16), reused 0 (delta 0), pack-reused 0
fatal: the remote end hung up un

元記事を表示

【Git】特定のコミットまで戻ってコードを確認したいだけのときは、git resetではなくgit switchを使おう

# はじめに
`git reset –hard [コミットのハッシュ値]`を実行すると、指定したコミット以降のコミット履歴が消去されてしまうので、
過去のコミット時のコードを一時的に見たいときは、コミット履歴に影響を与えない`git switch -d [コミットのハッシュ値]`を使ったほうが良さそうということに気づきました。
(`git reset –hard [コミットのハッシュ値]`を実行してコミット履歴を消去しても、一応復元できますが。)
筆者自身、詳しいことを知らずに`git reset –hard [コミットのハッシュ値]`を使って焦ったことがあるので、両者の違いをまとめておきます。

# サンプルの解説
以下のようなテキストファイルがあるとします。
“`text:sample.txt
first
second
third
fourth
“`

ブランチについては、`feature-1`という作業ブランチにいるとします。
“`:git branch
* feature-1
main
“`

コミットの履歴については、`main`ブランチで空のテキ

元記事を表示

[gitlab] 同階層のコードを一気に最新化してくれるスクリプトを作った

# はじめに

仕事環境では、以下のように Group の中にそれぞれ機能ごとに Project が格納されている構造を取っています。

“`
sample
├── documents
├── sample-client
├── sample-database
├── sample-api
├── sample-admin-api
“`

一気に最新化したい場面が時折あったので、develop を pull したい階層にてスクリプトを実行すると、一気に最新化してくれるスクリプトを作ってみました。

# 前提

– Group 配下に Subgroup がある場合、その Subgroup は git pull してくれない
– `!!!!!!!!!!!` のところに pull してくる Project 名が出てくる

# スクリプト

“`bash
GROUP_LIST=($(ls))

for GROUP in ${GROUP_LIST[@]}; do
echo !!!!!!!!!!!!!!!!!${GROUP}!!!!!!!!!!!!!!!!!
cd ${GR

元記事を表示

[gitlab] リリース準備が面倒なので、一気に準備してプッシュまでしてくれるスクリプトを作った

# はじめに

仕事環境では、`package.json` にある `version` をバージョン名として、タグ切りを行っています。
タグを切ったバージョンがプッシュされることで、`.gitlab-ci.yml` によって自動的にビルドされる仕組みを提供しています。

そのため、リリースする際は以下の操作を行う必要があります。

1. `package.json` の `version` のマイナーバージョンを 1 上げる
1. `git flow` でタグ切りを行う
1. コードをプッシュする

結合テストフェーズでは頻繁にリリースを行って動作確認をする必要があったので、この操作は少し億劫でした。。。

なので自動化スクリプトを作成しました!!

# 使い方

リリースしたい Project と同階層に以下スクリプトを配置し、実行するだけです!
スクリプトを実行することで、上記手順を一気に行うことができます。

# 前提

– 以下のスクリプトはマイナーバージョンのリリースのみ対応。

# スクリプト

“`bash
#!/bin/sh

# develop と maste

元記事を表示

windowsにてファイルすべてが差分で競合してしまう。(改行コード疑い)

前提 :
環境はwindows
git bash install済み
min.css,min.jsなどの一行もののファイルではない。

以下ブランチが存在し developがおかしい場合の例
master
develop

masterで文字コード確認 これはlf
““
$ file index.html
index.html: HTML document, Unicode text, UTF-8 text, with very long lines (421)
““

developに移動
““
$ git switch develop
Switched to branch ‘develop’
Your branch is up to date with ‘origin/develop’.
““

developで改行コード確認 CRLFとなっていた
““
$ file index.html
index.html: HTML document, Unicode text, UTF-8 text, with very long lines (421), with C

元記事を表示

【Git】分かりやすく解説!fetch, merge, pull, rebase の違いと使い分け

# はじめに

こんにちは、エンジニア3年目の嶋田です。
この記事を開いていただきありがとうございます!

私がエンジニアとして働き始めてから、チームメンバーとのコードの統合においてGitのコマンドを効率的に使用することがどれほど重要かを学んできました。特にリモートリポジトリの変更をどのようにローカルに反映させるかは、開発のスムーズさを左右します。

`git rebase`を使用することが多いのですが、
他のコマンドとの使い分けや違いを理解できている自信がなかったのでまとめてみました。

Gitのコマンドの使い分けについて混乱しやすい点を解説したいと思います。

# 目次
– [Gitコマンドの使い分け](#Gitコマンドの使い分け)
– [git fetchの使い方](#git-fetchの使い方)
– [git mergeの使い方](#git-mergeの使い方)
– [git pullの使い方](#git-pullの使い方)
– [git rebaseの使い方](#git-rebaseの使い方)
– [まとめ](#まとめ)

## Gitコマン

元記事を表示

GitHubリポジトリの説明に絵文字を追加する方法

GitHubリポジトリの説明に絵文字を追加するのはとても簡単です!このガイドでは、その手順をわかりやすく説明します。

## 1. リポジトリのメインページに移動
まず、GitHubで自分のリポジトリのメインページに移動します。

## 2. 設定ページにアクセス
次に、画面右上の「Settings」(設定)タブをクリックします。

## 3. 説明フィールドを見つける
「Repository name & description」(リポジトリ名と説明)のセクションを探します。このセクションで、リポジトリの名前や説明を変更できます。

## 4. 絵文字を追加
「Description」(説明)フィールドに、絵文字を含めたいテキストを入力します。絵文字は、コロン(:)で囲まれたコードを使って追加できます。

**例:**

“`mathematica
:sparkles: This repository contains my TIL (Today I Learned) entries. :sparkles:
“`

## 5. 絵文字コードを探す
絵文字のコードは、[Emoj

元記事を表示

[gitlab] 新規参画者のために、Group 配下の Project をまとめて git clone するスクリプトを作った

# はじめに

仕事環境では、以下のように Group(=サービス) の中にそれぞれ機能ごとに Project が格納されている構造を取っています。

“`
sample
├── documents
├── sample-client
├── sample-database
├── sample-api
├── sample-admin-api

“`

そのため、新規サービスに参画したときや、新人たちは一つ一つ Project 数ぶん `git clone` する必要があり、とても面倒でした。
多いときは同じ Group 内に 30 以上も Project があったりします。。。

なので新規参画者のために効率化しようと思い、一発でまとめてクローンできるようなスクリプトを作成しました!

# 使い方

1. $(GROUP_ID) に clone したい Group(リポジトリ)を指定する。
1. clone したい階層にて git bash でコマンドを実行する。

# 前提

– Group 配下に Subgroup がある場合、その Subgroup は clone

元記事を表示

初心者向け git branch の作り方「とりあえずブランチ切って開発して」と言われた時

# git branchについて

git branchは基本的に個人開発で使うことは少ない機能です。
グループで開発している時に、他のメンバーと編集内容が衝突したりしないために使用します。

とりあえず、本記事は題意の通り「とりあえずブランチ切って開発して」と言われた時に、まず何をするべきなのか解説します。

まずは、あなたがやるべき流れとしては、編集を依頼されたコードを`git clone`した後、

“`tex
git branch `name` # ブランチを作成
git checkout `name` #ブランチを切り替え
“`
:::note info
切り替わったブランチでコードを編集する
編集完了次第、次のコマンドに進む
:::
“`tex
git add
git commit -m ‘comment’ # commentは好きなものにしてください
git push –set-upstream origin `name`
“`

こんな感じです。
おそらく「とりあえずブランチ切って」と言われた際に、何かの機能開発ややってほしいことを依頼されていませんか

元記事を表示

git push時のユーザー名とパスワード入力を省略する

# はじめに
毎回git push時にユーザー名とパスワードを入力するのが手間なので省略しています。

# やり方
.git/configファイルのurlで@の前にusername:passwordを加えるだけです。

“`:.git/config
[remote “origin”]
url = https://username:password@gitlab-hogehoge.git
“`

# おわりに
入力を省略してパスワードを忘れないように気を付けましょう!

元記事を表示

OTHERカテゴリの最新記事