今さら聞けないGit 

今さら聞けないGit 

【Progate】Gitコース 学習内容まとめ

## 自己紹介
29歳。文系卒。新卒入社でWebディレクターを2年半経験。
その後は番組の字幕制作の仕事に従事。
現在はエンジニア転職を目指して勉強中。

## Gitの印象
ソースコードの変更履歴を保存したり、過去の状態に復元できたりする。チーム開発には不可欠。

## 使い方
### Gitの準備
~~~terminal
$ git init
~~~

### 共同開発の流れ
add(ファイル追加)
   ↓
commit(記録)
   ↓
push(アップロード)
   ↓
pull(ダウンロード)

### 共有するファイルを選択
~~~terminal
$ git add ファイル名
~~~

### 記録(コミット)
__必ず__ 何をどう調整したのかメッセージを残そう(チームや未来の自分を助けることになる)。
~~~terminal
$ git commit -m “メッセージ”
~~~

### リモートリポジトリの登録
リポジトリはファイルを補完する場所。ここにファイルをアップロード/ダウンロードして共有する。

※リポジトリ名は”origin”とすることが多い

元記事を表示

共有ファイルサーバーでGit管理する!

お疲れ様です。

タイトルの通り、共有ファイルサーバでGit管理する方法を備忘として残しておきます。
権限の関係で、clone出来ない状況を経験したので、その場合の回避方法も記載します。(あくまで私の解決方法なので、すべての方に適応するとは限りませんので悪しからず)

※前提:Gitクライアントは各人のPCにインストールされていること
→[「git for windows」](https://gitforwindows.org/)入れましょう。

# その1
シンプルにbareリポジトリのみを作成。
プロジェクト開始時に誰かがbareリポジトリを以下手順で作成します。

リモート(中央)リポジトリとして管理したいディレクトリを「current/remote.git」とします。
リモートに乗せたいプロジェクトのディレクトリを「current/local」とします。

1. リモートリポジトリとするディレクトリに、bareリポジトリを作成
2. ReadMeをcommit、pushしておく
2. 第三者がcloneする
2. 終わり

“`Bash
$ pwd
// current/re

元記事を表示

Git Hooksのpre-commitが動かない

# はじめに
Git Hooksのpre-commitの設定時、うまく動かなかった時の対処方法をまとめました。

# pre-commitとは
「pre-commit」はGit Hooksの一種で、コミットが実際に行われる前に自動的に実行されるスクリプトです。
このhookを使用すれば、コミット時に、コードのチェックを行ったり、特定のファイルをコミット対象から外したりなど、自動で検証を行うことができます。

# pre-commitが動かない時の確認事項
### pre-commitファイルの実行権限
pre-commitに実行権限が付与されていないと動かないので、以下のコマンドで実行権限を付与します
“`
chmod +x pre-commit
“`

### configファイルの確認
.git/config の中身を確認して、hooksPathで設定しているパスにpre-commitがあるか確認
“`
[core]
hooksPath = .git/hooks/
“`

### コミットプロセスの確認
–no-verify オプションを使用すると、設定しているhook

元記事を表示

git clone 時に SSL 証明書エラーが出たときの対処法

# はじめに

git clone 時に SSL 証明書エラーが出た。以下のようなエラー文出たときの対処方法です!

# 問題

実務にて、とある顧客環境の gitlab リポジトリをクローンしようとしたときに以下のようなエラーが出てしまいました。。

“`bash
$ git clone https://git.xxx/yyy/zzz.git
Cloning into ‘zzz’…
fatal: unable to access ‘https://git.xxx/yyy/zzz.gt/’: SSL certificate problem: unable to get local issuer certificate
“`

# 解決方法

結果から言うと単純ですが、SSL 認証を false にすることで回避できます(当たり前)

具体的には、以下コマンド実行し、SSL 証明を off にします。

“`bash
$ git config –global http.sslVerify false
“`

確認

“`bash
$ git config -l
“`

元記事を表示

自動Linterでルールに合わないソースをコミットさせない!

# 導入
よくプロジェクトで、結構開発中にLinterを実行せずにGitにプッシュされ、実はソースコードのインデントやルールがめちゃくちゃに…という経験のある方に必見です。

今回は、Next.jsのプロジェクトで`tsx`および`ts`ファイルを対象に、Gitコミット時にLinterを自動実行し、ルールに合致しない場合にコミットを防ぐ設定方法を紹介します。
使用するツールは、`husky`と`lint-staged`、および`ESLint`の3点です。

# 手順

## 前提

– **Node.js**と**npm**がインストールされていること
– **Git**がインストールされており、プロジェクトがGitで初期化されていること

## 1. `husky`と`lint-staged`のインストール

ターミナルを開き、以下のコマンドを実行して`husky`と`lint-staged`をインストールします。
これらはコードの品質を保つためにGitフックを使ってコミット時に自動でコードチェックやフォーマットを行うためのツールです。

元記事を表示

git clone 時に長いファイル名でエラー

# はじめに

現在このリポジトリを新規クローンすると失敗することがあります。
その解決方法の共有です!

# 問題

以下のようなエラーが出た場合は、長いファイル名が含まれていることが原因である可能性が高いです。

“`bash
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with ‘git status’
and retry with ‘git restore –source=HEAD :/’
“`

または

“`bash
open(“{くっそ長いpath}”): Filename too long unable to index file ‘{くっそ長いpath}’
“`

# 解決

このような状況となった場合、以下のどちらかで対応できます!

1. 対象のディレクトリにおいて、git bash で `git config –local core.longpaths

元記事を表示

ファイル名の大文字小文字だけを変換した場合、Git に観測されないことがある

# はじめに
ファイル名の大文字小文字だけを返還した場合、Git に観測されないことがありました。。。
その解決方法の共有です!

# 問題

はじめに、で書いた通りですが、ローカルで git status しても検知してくれなかったり、ローカルの build 時にエラーにならないけど、CICD 上の build ジョブでエラーとなることなどがありました。

# 解決方法

以下の手順で git が再検知してくれます!

1. 該当ファイルを削除
2. `git commit`(この時に大文字で書いたファイルと小文字で書いたファイル両方が Git 上で削除扱いで `commit` される)
3. 該当ファイルを復活させる
4. `git commit`

# おわりに

結構無理やりな方法で直しましたが、もし他にいい方法を知っている方がいましたら是非コメントしてください!

## 参考

https://himenon.github.io/docs/javascript/case-sensitive-paths-error/

元記事を表示

Github Issueを立ててみる

GithubでIssueを立てる方法をおさらいします。

# 前提

自分で開発しているプライベートリポジトリに立てるIssueで、身内向けのもの。
(OSSというわけでもなく、ある程度気軽に書き込んで構わない。)

# GithubのIssueとは

>GitHub Issues は、作業を計画、議論、追跡するためにリポジトリで作成できる項目です。
issue は簡単に作成でき、さまざまなシナリオに合わせて柔軟に対応できます。 issue を使用して、作業の追跡、フィードバックの送受信、アイデアやタスクに関する共同作業、他のユーザーとの効率的なコミュニケーションを行うことができます。

https://docs.github.com/ja/issues/tracking-your-work-with-issues/about-issues

わかったような、わからないような……。

Issueとは、英語で

>〔議論すべき〕重要な話題[問題]、問題点、論点、争点

といった意味らしいです(参考:[英辞郎 on the web](https://eow.alc.co.jp/search

元記事を表示

Git コミットの取り消しまとめ

## はじめに
皆さんは直前のコミットの粒度やコミットするファイルを変えたい場合どうコミットを取り消していますか?
また、コミットメッセージはどうやって変えていますか?
今回はコミットの取り消し方法についてまとめてみようと思います。

## コマンドからコミットを取り消す
一般的にコミットを取り消すには`git reset –soft HEAD^`のコマンドを使用して取り消していると思います。
直前のコミットを取り消してくれます。
“`bash
$ git commit -am “test”
[main 32a5f91] test
1 file changed, 1 insertion(+)

$ git reset –soft HEAD^
“`

## GitLensから取り消す
実はVScodeの拡張機能であるGitLensからもコミットの取り消しを行えます。
私はこのやり方をよく使います。
まず、GitLensの拡張機能を入れます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.

元記事を表示

徹底解説!Git・GitHubに関する基礎知識とコマンド

## はじめに

Git、GitHubについて超基礎知識からまとめてみた。

## 基礎知識

– バージョン管理とは、
– ソースコードをはじめとしたファイルのバージョン(変更履歴)を管理すること。
– ファイルの追加および変更の履歴を管理することで、過去の変更箇所の確認や特定の時点に戻せるなどができる。
– これがないと、チーム開発でメンバー間での連携が困難になり、生産性が損なわれる。

– Gitとは、
– バージョン管理をするためのシステム。
– 特徴としては、「分散型」のバージョン管理システム。
– 「集中型」:特定の場所にあるリポジトリへの接続が必須。
– 「分散型」:個々人のマシン上(ローカル)にリポジトリを作成して開発を行うことができ、現在のチーム開発における主流。

– リポジトリとは、
– バージョン管理によって管理されるファイルと履歴情報を保管する領域。
– Gitでは、まずは個々人のリポジトリ(ローカルリポジトリ)上で作業を実施後、作業内容をネットワーク先のサーバー状などにあるリポジトリ(リモートリポジトリ)に集約する流れで

元記事を表示

SourceTree: 特定のコミットのファイル一覧をクリップボードにコピペ

# 背景

特定のコミットにおけるファイル差分を把握したかった時に、
そのファイル一覧が欲しかったので調べた記録

# 結論

以下を bat ファイルを用意して、カスタム操作に割り当てるだけ

“`bat: コミットファイル一覧の取得
@echo off

git diff-tree –no-commit-id –name-only -r “%1” | clip
“`

## カスタム操作について

https://confluence.atlassian.com/sourcetreekb/using-git-in-custom-actions-785323500.html

# あとがき

カスタム操作って滅多に使いたくなる時があるわけじゃないけど、やっぱり便利ですな

こうやって残していくと、いつか役立つ時が来る :thinking:

元記事を表示

ローカルリポジトリを作成してgithubにリモートリポジトリとしてコマンドで追加する方法

本記事ではローカルリポジトリを作成してgithubにリモートリポジトリとして追加する方法について記載する.

以下のgitの知識は知っていることを前提とする.gitの基礎のついてわからない方は一読することをお勧めする.

https://qiita.com/tarakokko3233/items/ad7e1a1a14d3e2f10da3

# githubCLIのインストール
“`
brew install gh
“`

# githubにログインする
“`
gh auth login
“`
`GitHub.com`か`GitHub Enterprise Server`かを選択する.個人利用なら`GitHub.com`を選択すれば良い,
“`
? What account do you want to log into? [Use arrows to move, type to filter]
> GitHub.com
GitHub Enterprise Server
“`

`HTTPS`か`SSH`を選択する
“`
? What is your prefer

元記事を表示

リポジトリのフォーク(fork)について

# はじめに
フォークされているリポジトリがあるプロジェクトへ参画することになったのですが、恥ずかしながらフォークという言葉に聞き覚えがなかったため調べてみました。

# フォーク(fork)とは?
GitHub Docsを見てみると下記のように書かれています。
>フォークとは、元の “上流” リポジトリとコードと可視性の設定を共有する新しいリポジトリです。

うーん、ピンときませんね。
一つ一つ分解して見ていくことにしましょう。

## 上流リポジトリについて
オリジナリのリポジトリのことを「**上流の**」リポジトリと呼びます。
フォークを使うと上流のリポジトリをベースとして、Github上に別のリポジトリとして新たに作成されます。

また、リポジトリをフォークした後は、上流のリポジトリから更新をフェッチしてフォークを最新の状態に保つことができ、プルリクエストを使ってフォークから上流のリポジトリに変更を提案できます。

## フォークの可視性について
フォークは「コード」と「可視性の設定」を上流リポジトリと共有するリポジトリです。
例えば、上流のリポジトリがパブリックである場合、フ

元記事を表示

非プログラマーでもGitを触ってみよう

# はじめに

https://forest.watch.impress.co.jp/docs/news/1593848.html

今後のWindowsのアップデートでエクスプローラーからGitのコミットメッセージが見られるようになるらしいです。
この記事を読んでいる方の中にはGitってそもそも何?という方もいるかもしれません。
もしかしたら非エンジニアの方もGitを使うことが求められる時代が来るかも…?

# 注意事項

## 扱わないこと
– プッシュなどのリモートの操作 (ローカルで完結するGitの使い方を説明します)

## この資料の対象者
– PC中級者向け (数年PCを使ってきて一通りのことはできるようになってきた段階)

# なんでGitを使うの
ファイルのバージョン管理ができるからです。
この管理ができると何が起こるかというと…

– ファイルの変更履歴が残る
– 以前のバージョンに戻すせる
– だれがどこを変更したのかがわかる

などなど、ファイルを扱う上での様々なメリットがあります。

これをやらないと…

![Bad Situation.png](

元記事を表示

Gitでよく使うコマンドまとめ

個人的「質はともかく継続する」17日目です

# よく使うコマンドまとめ

{ } …任意の値をいれる箇所

### 初期化

“`bash
git init
“`

### ステージング

“`bash
git add “ファイル名”
“`

### コミット

“`bash
git commit -m “メッセージ” “ファイル名”
“`

### ログを確認

“`bash
git log
“`

### 状態を確認

“`bash
git status {FILENAME}
“`

### ステージングの取り消し

“`bash
git restore –staged {FILENAME}
“`

### コミットの取り消し

logでCOMMIT IDを取得後

“`bash
git revert {COMMIT ID} –no-edit
“`

元記事を表示

Git迷宮からの脱出:Linear historyで実現する美しい開発ワークフロー

私の会社で開発しているプロダクトの git がぐちゃぐちゃで、これを何とかしたい。
前職では **Linear history** を採用していて履歴をクリーンに保っていたので、**Linear history** を推しておく。

## 現在の git の問題点

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3741957/c10e6cf0-1b30-bf87-f8e2-b4b7bafed25f.png)

* **コミットが整理されていない**:
Merge Request(以下、MR)の中で、追加修正があると、同じコミットメッセージで大量にコミットされている(数十コミットの場合もある…)
* **レビュー時に不要なコミットが混ざる**:
GitLabを使っているため、Mergeのコミットで取り込まれたファイルは変更の一覧には出ないがコミットには残るので、一見するとMR担当者が修正したファイルなのか、MRで変更があったファイルなのかわからない
* **Gitリポジトリの

元記事を表示

Sourcetreeでスタッシュ(stash)の中身が見れなくなった不具合の解決方法

![スクリーンショット 2024-06-24 110814.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1470013/01afd1ac-cdb6-cb08-cbcd-cb9d9ae7c0ab.png)
Sourcetree(Windows版)を最新版にアップデートしたところ、今まで確認できていたスタッシュの中身が突然見れなくなりました。(バージョン3.4.18.0)

https://jira.atlassian.com/browse/SRCTREEWIN-14306
どうやら不具合として報告があって、バージョン3.4.17で修正されたようです。

https://product-downloads.atlassian.com/software/sourcetree/windows/ga/ReleaseNotes_3.4.17.html
>Fixed: Clicking on a stash no longer shows the changed files or diffs.

あれ?でもこちらの

元記事を表示

.gitkeep ファイルを再帰的にセットする方法

指定したフォルダ内の全てのディレクトリに `.gitkeep` ファイルを作成する方法

# create_gitkeep.sh

“`bash
#!/bin/bash

# 引数が指定されているかチェック
if [ -z “$1” ]; then
echo “使用方法: $0 <ターゲットフォルダのパス>”
exit 1
fi

# 引数として指定されたフォルダ
TARGET_DIR=”$1″

# 再帰的にサブディレクトリに移動して .gitkeep ファイルを作成
find “$TARGET_DIR” -type d -exec sh -c ‘cd “{}” && touch .gitkeep’ \;

echo “再帰的に .gitkeep ファイルを作成しました。”
“`

# 実行権限を付与

“`bash
chmod 700 create_gitkeep.sh
“`

# 実行

“`bash
./create_gitkeep.sh /path/to/folder
“`

これにより、指定したフォルダ内の全てのディレクトリに `.gitkeep` ファ

元記事を表示

Git Config Alias

“`.gitconfig
[alias]
co = checkout
br = branch
cm = commit -m
st = status
undo = reset –soft HEAD^
ll = log –oneline
sw = switch
swc = switch -c
swfc = switch –force-create
unstg = restore –staged
wip = commit -m \”wip\”
“`

元記事を表示

git push origin main パスワードのサポートが〜 

結論:パーソナルアクセストークンを利用する。

症状:パスワードのサポート切れのようなエラーメッセージにより、githubにpushできない

対処:
1.githubのページの自分のアイコンから設定を開く
2.開発者用〜(Developer〜)を選択
3.トークンの新規発行をして、それをターミナルで利用する

注意:完全初学者のアウトプットのため、すべての場合に対応できるものではありません。
さらに、トークンはおそらく再表示できないものだと思いますので、忘れずにコピーすること。

元記事を表示

OTHERカテゴリの最新記事