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

Bitbucket Cloud recently stopped supporting account passwords for Git authentication の解決方法

今朝 Bitbucket でブランチを push しようとしたら、昨日までは見なかったエラーに遭遇した。

こやつのため一切ブランチの操作ができなくなってしまった。（めっちゃ困る。）
なんとか調べてエラーを回避できたものの、これに関して日本語の資料はあまり見当たらなかった。また質問投稿者が Windows ユーザーであることが多く、Mac を使っていた私は Bitbucket の表示項目の違いに少々悩まされた。本記事は日本語で Mac ユーザー向けにまとめてみようと思う。

## エラー文全体

“`
remote: Bitbucket Cloud recently stopped supporting account passwords for Git authentication.
remot

AWS EC2 AmazonLinux2 Gitをインストールする

# 概要

– EC2 AmazonLinux2インスタンスにGitをインストールして`$ git`コマンドを実行できるようにする方法をまとめる。

# 方法

1. 下記コマンドを実行してyumを最新にする。

“`terminal
$ sudo yum update
“`

1. 下記コマンドを実行してGitをインストールする。

“`terminal
$ sudo yum install git
“`

1. 下記コマンドを実行してnot foundがでなければGitがインストールされている。

“`terminal
$ git
“`

gitを使ったバージョン管理の基本メモ(Win10, 社内ファイルサーバ)

# 全体像

### 新規作成から最初のコミットまで
01_ディレクトリの作成
02_カラのリモートリポジトリを作る
03_カラのリモートリポジトリをクローンしてローカルリポジトリを作る
04_ローカルリポジトリ上で開発を行う
05_変更内容をローカルリポジトリにコミットする
06_ローカルリポジトリのコミット内容をリモートリポジトリにプッシュする

### 最初のコミット以降の開発
(masterブランチで開発を行う場合)
07_リモートリポジトリの変更内容をローカルリポジトリにクローンする
08_マージする？
09_ローカルリポジトリ上で開発を行う(04と同じ)
10_変更内容をローカルリポジトリにコミットする(05と同じ)
11_ローカルリポジトリのコミット内容をリモートリポジトリにプッシュする(06と同じ)

(新しいブランチで開発を行う場合)
07_リモートリポジトリの変更内容をローカルリポジトリにクローンする
08_マージする？
09_ローカルリポジトリ上で新しいブランチを作成する
10_新しいブランチをチェックアウトする
11_ローカルリポジトリ上で開発を行う(04と同

githubのデプロイキーの指定の仕方

# 失敗したやり方
同じサーバ内で複数のリポジトリを扱っていたので`~/.ssh/config`に以下のような設定を書いて
“`shell:~/.ssh/config
Host repo-A
HostName github.com
User git
IdentityFile ~/.ssh/repoAkey
Host repo-B
HostName github.com
User git
IdentityFile ~/.ssh/repoBkey
“`
gitリポジトリの`origin`をそれぞれ`repo-A:/repoA.git`、`repo-B:/repoB.git`としていた
これでうまくいっていたのだが、デプロイキーを入れ替えたら全く機能しなくなってしまってハマった
# 原因
原因は`config`の設定に`IdentityFile`を指定しても必ずしもそれが使われるわけではないことだった
sshは使える鍵をいろいろ試してみて適合したらログインするという方法

DatabricksにてToDoを含むトレーニング向けノートブックの稼働確認

## 概要
Databricksにてトレーニングを実施する際に参加者に入力してもらうセルを空白にしておくことがよくあり、そのノートブックが想定のコードを入力した際の動作を確認する方法を共有します。

トレーニング実施する際には、正解を記載したノートブック（下記図の左）と作業を実施してもらうノートブック（下記図の右）を用意することがよくあります。トレーニング時には処理を段階的にセルに記載するため、作業を実施してもらうノートブックが適切に動作することを確認する必要があります。


実施方法は、Gitのチェリーピック機能により`#to-do`のセルを`#Answer`に書き換え、Databricks ReposにてPullしたコードをDatabricks Jobsで実行する方法です。正常終了する場合には下記図の左のように、異常終了する場合には下記図の右の

gitで社内サーバのリポジトリをクローンする手順

#社内サーバにあるrepo.gitをクローンする手順

Win + R →　CMD
↓
コマンドプロンプト上で、クローン先ローカルディレクトリに移動
または、クローン先ディレクトリをエクスプローラで開いて右クリック→Git Bash Here
↓
git clone [サーバ上の共有リポジトリのファイルパス]

##具体例
###CMDの場合(バックスラッシュ＝円マークが使えるので、エクスプローラ上でリモートリポジトリをShift＋右クリックし「パスをコピー」して
それをコマンドプロンプト上にペーストするだけ。)
“`
git clone “\\fs\sub-business\products\apps\repo.git”
“`

###Git Bashの場合(バックスラッシュではなくフォワードスラッシュを使う)
“`
git clone “//fs/sub-business/products/apps/repo.git”
“`

Bitbucketを使った初めてのプルリクエスト

## 概要
会社に入って初めてコードを修正し、プルリクエストを行ったので備忘録として書きます。
## そもそも「プルリクエスト」とは？
僕　「コード修正したので見てください！」
上司「わかったよ、見ておくね。問題なければリポジトリに取り込んでおくよ」
平たく言うとこんな感じです。
つまり、自分が修正したコードをリポジトリに取り込んでもらえるように依頼すること。

## 大まかな手順
①変更したファイルをリモートリポジトリへpushする。
②bitbucket上でプルリクエストを送る。

## 詳細
### 変更したファイルをgit add します。
“`gitbash
git add <ファイル名>または<ディレクトリ名>
“`
※思考停止で”git add .”としないように！前のブランチのコードとの差分が分からなくなってしまいます。

### 変更内容を確認
`git status`というコマンドでは以下の３つを確認することができます。
　・git add されているけどまだ git commit されていないファイルの一覧
　・編集・変更・削除されているが、まだ git

Gitリポジトリをミラーリングする

2つの Git リポジトリ間で、コードと Wiki をミラーリングする方法を紹介します。GitLab を使って動作確認をしていますが、GitHub でも同様だろうと思います。

また、例えば GitLab には、プロジェクトを新規作成するときに別の Git リポジトリから [インポートする機能](https://docs.gitlab.com/ee/user/project/import/) や、ずばり [ミラーリングする機能](https://docs.gitlab.com/ee/user/project/repository/mirror/) などがデフォルトで存在します。ここでは、ネットワークの問題や利用エディションの問題などで、これらの機能ではなく git コマンドだけで実現したいケースを想定しています。

### 確認環境

* Git 2.30.0
* GitLab 14.9.0-pre

### リポジトリ構成

* ミラーリング元のリポジトリ
* `https://gitlab.com/oohira/awesome-source.git`
* ミラーリング先のリ

Git Github プルリクしてみよう！！

チーム開発に必須なGit githubに関する備忘録を残そうと思います。

筆者のスペック
↓
今までの開発経験は全て単独で行ってきたためチーム開発は未経験です。
今回アサインしたプロジェクトで初のチーム開発をすることになり、いきなりgit githubでつまづいてしまったので
この記事を備忘録として残しておこうと思います。

ざっくりした手順ですが、

1,git branch (現在いるbranchを確認する)
2,git branch test (test branchを作成してこのブランチをmain(master branch)にプルリクする)
3,git checkout test (変更を加えていたtest branchへ移動してプルリクを送る準備を開始する)
4.git add . (変更したすべてのファイルをコミットの対象にする)
5,git commit -m “test” (変更した時にリモートで出力されるタイトルを”この中に”かく)
6,git push origin test (手を加えたファイルをリモートへ飛ばして送信する)
7,git status (フ

GitHubでリモートリポジトリを作成し、ブランチを切ってプルリクまで

# はじめに
GitHubの使い方やGitのコマンドをよく忘れるので備忘録として記録しておきます。

# GitHubでリモートリポジトリを作成

##### 　・ GitHubのトップページ左上の「New」をクリック

##### 　・ Create a new repository
Repository nameにリポジトリ名（今回はsample-repo）を入力。
誰でも閲覧できるようにする場合はPublicにチェック。
今回はリポジトリにREAD

Eclipse + Git Bash で疑似チーム開発

# はじめに
統合開発環境であるEclipse内で管理しているコードをGitで管理（もっと言うと**疑似チーム開発**）する手順をまとめます。

GUIを使った手順に関する情報は豊富なんですが、コマンド（CUI）使った手順でうまくまとまった記事がないなあと思い、自分の備忘録のためにも本記事を書くことにしました。

* GUIのマウス操作面倒だから、コマンド使いたいんじゃ！！！
* やっぱりコマンド打ち込むのカッコイイよね～～
* Gitコマンド単体なら勉強したけどEclipseとの連携がわからない・・・
* Eclipseの中でブランチって切れるの？？

みたいな人向けです。

# 環境
* Windows10
* Eclipse2019
（ちなみに使用言語はJavaですが、どの言語でも手順は変わらないはず。）

# 前提
* GitHubアカウントを作成、リモートリポジトリを作成済みであること
* [Git for Windows](https://gitforwindows.org/)をインストール済みであること

# 手順
## 1. Gitの設定
Windowsのスタート画面か

git add とgit commitの取り消し

先日、作業するブランチを間違えてしまいました。

作業が完了し、addとcommitをして、pushする直前に気づきました。

その時の対処方法です。

## git commit の取り消し

まずはcommit の取り消しをします。

“`
git reset –soft HEAD^
“`

こちらのコマンドで直前に行ったcommitを取り消すことができます。

## git add の取り消し

続いてgit add の取り消しをします。

“`
git reset HEAD
“`

こちらで直前に行ったaddを取り消すことができます。

これら２つのコマンドを実行することで、表題のaddとcommitの取り消しができます。

以下で補足します。

## HEAD

今自分が作業している場所を示すポインタのことです。

`HEAD^`は「一つ前のコミット」を表します。

## reset

特定の時点までファイルを巻き戻します。
3つのオプションがあります。

### –soft
HEADの位置のみ巻き戻す
例：`git reset –soft HEAD^`→直前の

GUIで実践！GitHub入門ハンズオン（with VSCode)

# はじめに
GitHubの入門・ハンズオンはCUI（コマンド）ベースのものが多く、初心者の方にはなかなか取っつきにくいのではないかと思います。
そこで、本記事ではGUIを用いてGitHub入門ハンズオンを行いたいと思います。GUIはVSCodeの拡張機能を使います。
主な対象者は次のような方々です
– GitHubを学ぼうと思ったがコマンドばかりでイメージがつきにくいという方
– 新人にGitHubを教えることに苦労している方

# ハンズオンの流れ
ハンズオンでは次のことを行います。
– Part1: 環境構築
– Part2: コードをダウンロードしてVSCodeで開く(clone)
– Part3: ブランチを切ってコードを変更し、GitHubにPushする
– Part4: Pull requestを出してレビューしてもらう

このハンズオンを行うことで、実際の開発におけるGitHubの利用の流れが理解できるほか、
clone, add, commit, push, fetch, pullといったコマンドをGUIを使って直感的に理解することができます。

# 前提条件
ここで

pushしてからrebaseはダメ！

## あるある

自分で作成したブランチで作業している間に開発ブランチの変更が先に進み、自分のブランチは古いままというとき、何気に`git rebase main`とか実行したくなりますが、ちょっと待ちましょう。

本流のブランチの変更を自分の作業ブランチに取り込むときには、rebaseとmergeの2つの方法があり、使い分けるのが望ましいです。

## rebaseとmerge、そもそもどう違うの？

よく見かけるのと同じ図です。
originはgitサーバー上にあるブランチ、localは手元で作業するブランチとします。

### rebase

rebaseは図のように、ブランチの根っこをすげ替える動かし方をします。
コミットログが図の上の状態の時、localブランチをチェックアウトした状態で`git rebase origin`を実行すると、コミットログは図の下のようになります。

![rebase.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230005/8a2a228f-78bb-9e02-

【GitHub】GitHub Actionsで独自のActionを定義する

## はじめに
最近、GitHub ActionsのWorkflowを構築するお仕事をしていたので、そこで発見したTipsについて書きます！
『**同一リポジトリ内で同じActionを呼びたい**』時に便利です！

## Node.jsのcomposite action
`composite action` ･･･ ユーザーが独自に定義したAction
“`yml:.github/workflow/node/action.yml
name: my-actions

runs:
using: ‘composite’
steps:
– name: set up Node.js
uses: actions/setup-node@v2
with:
node-version: ’14’
cache: ‘npm’ # or ‘yarn’
cache-dependency-path: app/node/package-lock.json
“`

#### !!!注意!!!
> The metadata f

git-frowモデルについてまとめ

# 概要
git flow モデルを参考に、社内の開発チームで設定したいブランチモデル及び、ブランチ命名規則を記載する。

git flowについては以下を参照
https://qiita.com/KosukeSone/items/514dd24828b485c69a05
以下で説明しているブランチ命名規則を軸として、
開発チーム内でブランチの名前の付け方をできる限り統一したい。

# ブランチ名の頭につけるフレーズ（\ バックスラッシュより前の部分）について

ブランチ名の頭に以下のフレーズをつけて、
そのブランチで行われている開発や修正が、どういった属性のものなのかを大きなくくりで分かるようにする。

## master

→ 本番環境にリリースしている最新の状態
→本番環境にリリースする際に、バージョン番号をタグ付けして管理をする。
→CDを導入しているプロジェクトでは、developブランチがmasterにマージされた時点で、masterブランチが本番環境に自動でリリースされる。
※特定のコミットに対してタグ付けをする参考資料
https://qiita.com/growsic

コミットのお作法

ある日`git checkout .`を誤って打ってしまい修正ファイルが全て吹き飛びました。

コミットを小さな粒度で行うことで、こういったミスはある程度対処できそうです。

量が多くなるほど適切な名前をつけないと、後々どういった内容のコミットか思い出すことが難しくなります。
コードはよく読んでもコミットの方針やメッセージ等を見ることはあまりないと思い「コミットのお作法」をまとめようと思います。
*主にチケット駆動の話

# メッセージの書き方
例) #100 fix 〇〇が✖︎✖︎の時エラーになる修正。
### 含ませるもの
1. プレフィックス
1. チケットNo
1. 修正の内容

*順番はプロジェクトによって変わる

### 1.プレフィックスをつける
どんな修正か一目でわかる。
ここらあたりで網羅できそう。
“`
add：新規（ファイル）機能追加
fix：バグ修正
update：機能修正（バグではない）
remove：削除（ファイル）
refactor：リファクタリング
upgrade：バージョンアップ
test：テスト関連
“`

### 2.チケットNo
チケットを管

Gitの使い方（3つの領域と操作方法）

Gitについて学んだことをアウトプットしようと思います。

# はじめに
Gitとはバージョン管理システムで、ファイルの変更履歴を残し、管理することができるツールです。複数の時点でのセーブデータをもつことができ、好きなセーブデータのところからファイルの編集が始められるようにするイメージかなと思ってます。この記事ではセーブデータを作る部分について書いていこうと思います。

# Git管理における3つの領域
ファイルをGitで管理するにあたって、ワーキングディレクトリ、ステージングエリア、リポジトリという3つの領域があります。

### 1.ワーキングディレクトリ
Gitの管理下にある、僕たちが作業をするディレクトリです。

### 2.ステージングエリア
実際にファイルの変更履歴を保存するための準備をするセーブポイントのようなものです。3つ目のリポジトリに履歴を残すためにはこの一度ステージングエリアを経由する必要があります。ステージングエリアはインデックスとも呼ぶみたいです。

### 3.リポジトリ
実際にファイルの履歴がセーブデータとして記録される領域です。リポジトリにはリモートリポ

git pullとgit pull –rebaseの違い

# はじめに
Gitの操作でpullはわかってもこのrebaseって何だ？みたいなことが
現場で発生しました。

この記事では***git pullとgit pull -rebaseの違い***について説明していきます。

# git pull -rebaseはどういう場面で使ったのか
自分が現場にアサインされた時に***ブランチのdevelopを切りfeatureブランチを作成した時***に
このgit pull -rebaseを使用しました。

このようなアドバイスを先輩からもらいました。

developをpullする時は

“`
$ git fetch
$ git pull -rebase origin develop
“`
を使ってとアドバイスをいただきました。

これは***余計なコミットを作らないためだそうです。***

# この記事を書いた理由
なんでこの“`–rebase“`が使われるのかがわからなかったので、
先輩に記事を紹介してもらい下の参考資料から調べてみました。

するとgit fetch pull merge rebaseの違いをそれぞれ知る必要が

Git fetch, merge,pullの違い

# はじめに
上のGit fetch, merge,pullがそれぞれ似ていてややこしいので調べてみました。
Git操作は開発現場では必須のスキルなので僕自身がgitの使い方を勘違いしたまま
現場に入ってしまったのが上の３つのコマンドの違いです。

それぞれ3つの違いを説明して行きます。
まずがgitの前提知識からです。

# ローカルリポジトリとリモートリポジトリの違い
Git にはローカルリポジトリとリモートリポジトリという２種類のリポジトリが存在します。

両者の違いは以下の通りです。

|リポジトリ|説明|
|–|–|
|ローカルリポジトリ|開発者が作業するPCにあるリポジトリ|
|リモートリポジトリ|開発者全員が共有できるリポジトリ(サーバーなどに上がっている)|

ローカルリポジトリで開発し、リモートリポジトリにプッシュして
開発者全員が共有できるようになります。

# ローカルリポジトリの中身
ローカルリポジトリは以下の4つがあります。

|***ワーキングツリー***|作業場所でこれからコードを追加する場所|
|–|–|
|***インデックス***|コミットす