- 0.1. IntelliJ IDEA で git remote 操作ができない
- 0.2. git rebase 〜初級編〜 rebaseとは?
- 0.3. .DS_Storeを再作成後にgitでcommitしたら、過去のcommit履歴変更ができなくなった話
- 0.4. 実務で使うGitコマンドメモ
- 0.5. プルエラーが発生しました
- 0.6. 初心者が使うGit コマンド(備忘録)
- 0.7. GitHubのデフォルトブランチを改名する手順
- 0.8. when executing shell command on Git,specify the private SSH-key
- 0.9. 今さら聞けないGit
- 0.10. git remove last commit
- 0.11. gitでブランチのバックアップを取る方法
- 0.12. 仕事の始まりと終わりのショートカット(Git)
- 0.13. 僕が考える最低限のコードレビューのマナー
- 0.14. Gitのコマンド一覧(2) – branch, checkout, remote-
- 0.15. サルにはわからない!!リモートリポジトリを利用するgit初期操作まとめ
- 1. 前提条件
- 2. 環境
- 3. clone~pushの具体的な操作
IntelliJ IDEA で git remote 操作ができない
# 状態
– github を ssh 経由で使用している。
– IntelliJ IDEA 組み込みの git ui にてリモート関連操作 (push, pull等) を行うと次のようにエラーが出る。“`
Update Failed
CreateProcessW failed error:193
ssh_askpass: posix_spawnp: Unknown error
git@github.com: Permission denied (publickey).
Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
“`– IntelliJ IDEA 組み込みの git ui にてローカルの範囲の操作 (commit, switch, branch等) はできる。
– ターミナルからのリモート関連操作はできる。# 原因
OS の SSH-AGENT に SSH 鍵が登録
git rebase 〜初級編〜 rebaseとは?
# はじめに
Gitを使っている人の多くは、「rebase」という言葉は聞いたことがあると思いますが、「rebase」とはどういうことなのか、どうやって使うのかがよく分からない人も多くいます。また、なんとなく危険のある操作だとイメージを持っていて、使うのを戸惑う人もいるでしょう。ここでは、gitのrebaseという機能の説明と使い方を紹介したいと思います。
# rebaseとは
rebaseを理解するには、まずは簡単な例を見ていきましょう。![Git1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/553103/f4e39b4f-b96f-b652-afdc-936e83841c99.png)
上の図のように、masterからブランチを切ってそのブランチに対していくつかコミットをしています。コミット1はブランチを切った段階でmasterの最新のコミットで、これを「merge base」と言います。(切ったブランチをmasterにマージする時にベースとなるコミットなのでmerge baseです
.DS_Storeを再作成後にgitでcommitしたら、過去のcommit履歴変更ができなくなった話
# なにが起こったのか(端的に)
– .DS_Storeファイルを消して、再度作成されたものをGithub上にpushしたら、過去のcommitメッセージを変えることができなくなってしまった話。## なにが起こったのか(全貌)
1. とあるフォルダをGithub上のリモートリポジトリに上げる際に間違えて **.DS_Storeもいっしょに上げてしまった。**
1. あとで修正できると思い、しらばく放置していた。(ここまでは間違ってない)
1. さぁひと段落ついたから、Github上の.DS_Storeも消そうと思い、**ローカルリポジトリの.DS_Storeを消し、それをGithubにpushした**(これがすべての元凶)
1. 「あ、そういえば過去のcommitメッセージも誤字ってたからいま変えとこう」と思い、`git rebase`しようと思ったら、異変に気づく。
1. **「あれ、、.DS_Storeファイルがある。。?」**
1. よくよく調べてみたら、.DS_Storeファイルは何度消してもよみがえるアンデットらしい。
1. なので手段を変えて、.gitignoreファ
実務で使うGitコマンドメモ
11月より実務でコードを書いています。
1つのプロジェクトリポジトリをブランチ分けて開発していくスタイル。
# リモートリポジトリからローカルリポジトリに落としてくる
“`shell
git clone <リモートリポジトリのURL>
“`
社内サーバーだとプロキシを設定していたりするので結構詰まりました。“`config:.gitconfig
[https]
proxy = https://:8080
[http]
proxy = http://:8080
“`のように設定してあげたらcloneできました。
# ブランチの確認
“`shell
git branch -a
“`-aをつけることでローカル、リモート全てのブランチを確認できます。
今いる自分のブランチがハイライトされます。# ブランチの作成・移動
“`shell
git checkout -b <新しいブランチ名> <派生先ブランチ名>
“`-bをつけることで作成と移動が同時にできます。
例えば`model/test`というブランチを新しく、
プルエラーが発生しました
原因
「feature」ブランチと「FEATURE/XXX」ブランチをローカルに落とす際、
同じ名前のフォルダ・ファイルは共存できないためエラーとなっているようです。
対策(リモート:消す)
クローン先の「xxx/.git/logs/refs/remotes/origin」配下にある「feature」ファイルを消すこと
対策(ローカル:プル)
(1) TortoiseGit → Pull
(2) Prune のチェックを■からチェック有り (レ) に変更
初心者が使うGit コマンド(備忘録)
Linux上で使うよく使うgitコマンドを記載します。
これがQiita初投稿です。# 初期化
$ git init
このコマンドでGitリポジトリを初期化できる。# 集結
$ git add -A
このコマンドで指定したファイルをステージング状態(コミットの手前)にする。# ディレクトリに追加
$ git commit -m “ブランチ名”
このコマンドディレクトリに保存# 切り替え
$ git checkout “ブランチ名”
作業ブランチの切り替え# リモートリポジトリに追加
$ git merge “ブランチの小タイトル”# リモートリポジトリのブランチの更新
$ git push# コードを最新版ものに更新する
$ git pull# リポジトリごとダウンロードする
$ git clone “GithubのリポジトリURL”
GitHubのデフォルトブランチを改名する手順
## はじめに
この記事は、GitHubリポジトリのデフォルトブランチを改名する手順を共有するためのものです。
必要となる情報はすべてインターネット上にありますが、分散しているため作業手順を1つの記事にまとめました。
### 前提とする環境
この記事は、以下の環境を前提に書かれています。
– git version 2.30.1
GitHubのUIは、2021/11/09時点のものを前提としています。GitHubのバージョンアップによりUIは変わりますのでご注意ください。
### 前提とするリポジトリ構成
この記事では、改名前のブランチ名を`master`、改名後のブランチ名を`main`としています。ブランチ名はお手元の環境に合わせて読み替えてください。また、リモートリポジトリの名前は`origin`とします。
## 改名の手順
### ローカルで、ブランチ名を変更する
“`shell
git branch -m master main
“`このコマンドで、ローカルの`master`ブランチが`main`ブランチに改名されます。`-m`オプションは`–
when executing shell command on Git,specify the private SSH-key
“`
cd repo
git config core.sshCommand ‘ssh -i private_key_file’
# later on
git pull
“``.git/config` file content:
“`
[core]
sshCommand = ssh -i private_key_file“`
—
Refer:
https://stackoverflow.com/a/38474137
今さら聞けないGit
##まずはじめに
プログラミングを始めて恥ずかしながら、Gitに関しては毎回コマンドを調べながらで頭の中で整理されていなかったので記事投稿を機会にアウトプットしていきたいと思います。
git等のバージョン管理は何かプロジェクトをチームで作業する場合に非常に大事なことなのでこの記事をリマインドにご利用ください。今回は[サル先生のGit入門](https://backlog.com/ja/git-tutorial/)というサイトを参考に記述しました。
[サル先生のGit入門](https://backlog.com/ja/git-tutorial/)##Gitとは
分散型バージョン管理システムです。
ファイルの状態を好きなときに更新履歴として保存しておくことが可能。
編集したファイルを過去の状態にしたり、編集箇所の差分を見ることが可能。“`
Gitとは?
バージョン管理システム
“`また、チームで共有しているファイルがどのように編集されたかわからなくなったり、2人同時に編集してしまったために先に編集した内容が消えてしまったなどを防ぐことが可能です。
##リポジトリとは
git remove last commit
“`
git reset HEAD~
“`
gitでブランチのバックアップを取る方法
# はじめに
gitでrebaseなどのためにforce pushを行うと、remoteの状態も上書きされるのでなにかの問題が発生した時に簡単に戻せなくなります。それを避けるため、事前にバックアップを取るのが安全です。GitのGUIでブランチをコピーするなどの機能がありますが、コマンドラインを使っていればどうすればいいでしょうか?ここでgitのコマンドラインでバックアップを取る方法を紹介します。
# バックアップの手順
まずはバックアップしたいブランチをcheckoutし、`git branch -m`で名前を変更します。
“`
% git checkout my-branch
% git branch -m my-branch_backup
“`checkoutしているブランチ以外のブランチも名前を変更できます。
“`
% git branch -m [currentBranchName] [newBranchName]
“`改めてremoteの`my-branch`をcheckoutすれば、安心してrebaseなどの作業ができます。
“`
% git
仕事の始まりと終わりのショートカット(Git)
ふだん、ショートカットが手癖になっているので、その中身(~/.bashrcのaliasの一部)を記録しておく。
みんな大好きdocker-composeのエイリアスはdc。
“`bash:~/.bashrc
alias dc=’docker-compose’
“`仕事はじめは **gstart** で、リモートリポジトリから最新を引っ張ってきて、今日の日付でcheckoutして、dockerのお仕事用コンテナをupする。一番はじめのgit checkoutは念の為のおまじない。
“`bash:~/.bashrc
alias gstart=’git checkout target;git pull origin target;git checkout -b test-`date +%Y%m%d`;dc up -d’
“`
仕事の終わりは**gend**。gitマージして、その日のブランチのcommitコメント編集モードに入る。“`bash:~/.bashrc
alias gend=’git checkout target;git merge –squash
僕が考える最低限のコードレビューのマナー
コードレビューをする側に人間になって思ったこと。
最低限のマナーがあるんじゃないかって思い始めた。マナー講師始動…!!!!!!「相手に理解がしてくれるだろう」という前提で依頼するというのは、コミュニケーションとしても破綻してると思うので、相手に理解してもらう為に自分がまずできる出来る不安材料を取り除くのが大切だと思います。
自分が考えるコードレビューの時に必要な5箇条。
1. プルリクテンプレートを用意しよう
2. レビュー修正依頼の確認コメントはコミットIDで返答しよう
3. 確認依頼のコメントを残そう
4. 絵文字多用しよう
5. 双方お礼を忘れずに### 1. コードレビューにはプルリクエストテンプレートを用意しよう
PullRequest Template(プルリクエストテンプレート)はレビューの際に必須。
これがないとプロジェクトが破滅してるんじゃといった感じ。なぜ、プルリクエストのテンプレートが必要なのか
– コメントが書く人によって書くフォーマットがバラバラになり、毎回統一性のない書き方になる
– 何のタスクなのか、プルリクから読み取れない
Gitのコマンド一覧(2) – branch, checkout, remote-
# 概要
[Gitのコマンド一覧(1)](https://qiita.com/sepakTama/items/8abfd998975512c2fea2)では、ローカルリポジトリを作成する`git init`から、ローカルリポジトリに反映された変更点をリモートリポジトリへ反映させる`git push`までを記した。本記事では、ブランチとは何かから説明をし、ブランチに関するコマンドをまとめ、それに付随するoriginやローカルやリモートについて説明する。(rebase等に関してはGitのコマンド一覧(3)を参照すること)# 主に使っているコマンド
– init
– add
– commit
– push
– clone
– status
– log
– reflog
– **branch**
– **checkout**
– **remote**
– fetch
– merge
– pull
– rebase
– cherry-pick
– reset
– rm# ブランチの考え方
Gitを扱う上で重要になってくるのがブランチという考え方である。例えば、多人数で一つのシステムを開発
サルにはわからない!!リモートリポジトリを利用するgit初期操作まとめ
Github初学者の方へ
clone→add→commit→push
前提条件
git、vimインストール済み
環境
・Windows10
・端末:Windows PowerShellclone~pushの具体的な操作
1.リモートリポジトリのclone
ブラウザでGithubにログインし、使いたいリポジトリを見つけたら利用したいリモートリポジトリのURLをコピーする。そしてクローンしたいディレクトリに端末“`cd“`等で移動して端末で以下のように記述。
“`git clone [URL]“`
デフォルトブランチではないブランチをクローンする場合は
“`git clone -b [cloneしたいブランチ名] [URL]“`
と記述する。2.コードの編集
端末で以下の記述でbranchを新たに作成する。
“`git branch [作成したいブランチ名]“`
そして以下の記述でブランチを移動する
“`git switch [移動したいブランチ
【Gitの基本】リモートとローカルって何?
# 概要
本ブログではGitの本質的な部分(おそらくかなり重要な気がする)であるリモートとローカルの考え方について説明する。リモートとローカルが何かを理解することによってこの後につながっていく、ブランチであったりの理解が捗ると思われる。また、具体的なコマンドを知りたい人は[次のブログ](https://qiita.com/sepakTama/items/8abfd998975512c2fea2)を参照すること。
本ページでは以下について説明する。
– Gitとは
– リモートとローカル
– originって結局何?# 1.Gitとは
Gitとは分散型バージョン管理システムのことであり、多人数で一つの開発や分析をする際に非常に便利である。何が特に便利かというと
– 過去に行った編集を参照したり、過去のバージョンに戻れる
– 多人数で同一ファイルを操作できる
が挙げられる。
では具体的に見ていこう。(具体的なコマンドを見たい人は[ここ](https://qiita.com/sepakTama/items/8abfd998975512c2fea2)までスキップ)# 2. リモートとロ
GitlabのSAST(Spotbugs)を動かす時のメモ
# はじめに
Gitlabの機能としてセキュリティツールがいくつかあるので、試したときのメモ。
[GitlabのSAST(Semgrep)を動かす時のメモ](https://qiita.com/dyamaguc/items/b61186acc2344b917309)の続きです。# やること
Gitlab.com環境で[SAST](https://docs.gitlab.com/ee/user/application_security/sast/index.html)のうちSpotbugsを[WebGoat](https://owasp.org/www-project-webgoat/)に対してかけてみます。
# 環境
– Gitlab.com: 14.5.0-pre (2021年10月25日現在)
– [Spotbugs analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs): v2.28.6
– WebGoat: https://github.com/WebGoat/We
SourceTreeでワンクリックで変更差分・未追跡ファイルを無くして綺麗な状態にする
SourceTreeの作業ツリーにある変更差分と未追跡ファイルを消したい場合、
**変更差分 → 「コミットまで戻す…」**
**未追跡ファイル → 「削除」**
を実行する必要があり、ファイル数が多くなってきて、変更差分と未追跡ファイルが入り乱れていると、選択するのが結構面倒くさいです。**カスタムアクション**を設定すれば、**ワンクリックで作業ツリーを綺麗**にできます。
![img_1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/88968/ca1a5459-fca0-36e5-2fc4-3e95b39c8ead.png)## 1.カスタムアクションのファイルを用意
↓ Githubにカスタムアクションに設定するファイルを上げているのでこちらをクローンするかダウンロードして、任意のフォルダに保存してください。
https://github.com/onederappli/SourceTreeCustomActions
## 2.SourceTreeでカスタムアクションの設定
Git タグの使い方
### コミットを参照しやすくするためにわかりやすい名前をつけるのがタグ。よくリリースポイントにつける。
“`
// タグの一覧を表示
git tag
“`
↓“`
// タグのデータを表示
git show タグ名
“`### タグには2種類あり、注釈付き版のタグと軽量版のタグがある
### 注釈付きのタグにはタグ名にプラスでメッセージを追加できる
#### リモートにプッシュする場合は別途指定してあげる必要がある。プッシュの時に勝手についていかない
ソースツリーの場合は以下のキャプチャのプッシュするタグにチェックをするとリモートにプッシュされる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/756524/e0f68c3e-0cb8-3929-9784-48dce305d6be.png)
git プルにはマージ型とリベース型があるみたい
## マージ型
マージコミットが残るのでマージした記録を残したいときに使う## リベース型
マージコミットが残らないのでgithubの情報を取得したいときにだけ使う
ただ単にmasterの内容を取得する時にはこれでOK!
ソースツリーではプルする時に以下の「マージではなくリベースする」にチェックをつける
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/756524/78456d44-a6fe-736f-e47e-914132ccc2c9.png)