環境

Windows

• Windows 10 Pro
• TortoiseGit 2.11.0.0
• git version 2.30.0.windows.1
• VSCode 1.52.1
• Kleopatra Gpg4win-3.1.15

Linux

• Ubuntu Desktop 20.04.1 LTS
  • 言語設定が日本語の状態
  • XRDPで繋げる状態
• git version 2.25.1

手順

Windows編

1. Kleopatoraを起動
2. ファイル＞New Pair Key
3. 個人用のOpenPGP鍵ペアを生成
   1. 期限なし、パスフレーズは適当に
4. Exportから-----BEGIN PGP PUBLIC KEY BLOCK-----の中身を全部GitHubのGPG keys/ Add newに貼り付ける
5. 追加後にでてきたKey IDを git config --global user.signingkey KeyID として cmd に流す
6. 更に git config --global commit.gpgsign true を流す

7. 管理者権限で cmd を起動し次のシンボリックリンクを作成

   1. mklink /D %USERPROFILE%\.gnupg %AppData%\GnuPG

8. GitHubに適当なリポジトリを切り適当にVSCodeかTortoiseGitでコミットしようとすると鍵のパスワードを聞かれるので入力

9. PUSHしてGitHubのコミット履歴にverified signatureがついてたら成功

Linux編

1. Windows側のKleopatoraから公開鍵と秘密鍵をエクスポートして持ってくる
2. gpg --import FooBarpublic.asc で公開鍵をインポート
3. gpg -k でインポートされていることを確認し、下記 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 相当の部分をコピペ

pub   rsa3072 2021-01-17 [SC]
      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
uid           [  不明  ] Foo Bar <foobar@example.com>
sub   rsa3072 2021-01-17 [E]

1. gpg --edit-key XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
2. trust
3. 5 を選ぶ
4. quit
5. gpg -k で信用度が[ 究極 ]になっていることを確認
6. gpg --import FooBarSECRET.asc で秘密鍵をインポート
   1. SSHで繋いでいる時でタイムアウトする場合、GUIプロンプトからの入力になるので、どうにかして入力
   2. XRDP経由なら pkill gnome-session を叩くと入れる
7. なんか適当にコミットする
   1. GUIプロンプトが出てくるのでパスフレーズを記憶させるようにチェックしておく（GUI触るのだるいので）

目的

• エンジニアに不可欠のツールであるGitとGitHubを用いたワークフローを整理する

ワークフロー

今回は2種類のワークフローについてのまとめ
1.git-flow
2.GitHub Flow

1.git-flow

各ブランチと説明

• main…リリース済みのソースコードを管理する
• develop…開発中のソースコードを管理する
• hotfix…緊急の修正を行う、mainから分岐する
• feature…各自の開発を行う、developから分岐する
• release…リリース前の準備を行う、developから分岐する

ワークフロー

mainからdevelopを切る
↓
developからfeatureを切って各自開発
↓
開発が完了したらdevelopにマージしていき、全体の開発完了後developからreleaseを切る
↓
リリースの準備が完了したらmainとdevelopにreleaseをマージしデプロイ

2.GitHub Flow

各ブランチと説明

• main…リリース済みのソースコードを管理する
• feature…各自の開発を行う

ワークフロー

mainからfeatureを切る
↓
開発完了後pullリクエストを作成してコードレビューを依頼
↓
問題がなければmainにマージしデプロイ

Gitの開発の流れと、基本的なコマンド・便利なコマンド

会社にGitが導入されたので、忘備録としてまとめました。
随時更新していきます！

自分で 0 から開発に入る場合

1.まず初めにローカルリポジトリを作る！

プロジェクトのディレクトリ配下で git init コマンドを打ちます。
そうすると、プロジェクト内に .git ファイルが作成されます。

git init

２. ? これは必要に応じてですが、 .gitignore ファイルも作る

.gitignore ファイルは git で管理しないファイルやディレクトリを指定するためのファイルです。
ソースとして関係のないファイルは.gitignore に記述しておきましょう！

touch .gitignore

3.リモートリポジトリを追加する！

プロジェクト配下で ↓ のコマンドを打つことで、リモートリポジトリを作成できます。
ここの、origin というのは、リモートリポジトリのエイリアス(別名)を意味します。

git remote add origin https://~~~~~.git

---

自分が開発に参加して修正などを行う場合

1. まず、自分の作業場にリモートリポジトリの最新ファイルを持ってくる！
   

プロジェクトのディレクトリを作成したい場所で、git clone リモートリポジトリ でクローンした後に、
念のため git pullコマンドで作業場を最新にしましょう！

git clone https://~~~.git
git pull

---

最低限の環境の構築はここまでです。

ここから先は、ブランチの使い方(作業ごとに毎回ブランチを切るのか、dev ブランチのように開発専用ブランチを作るのか、など)
によって変わってくると思うので、これから更新していきます。

---

? git の基本的なコマンド

ファイルをステージに上げる

//git add ファイル名
git add index.html

//全て上げるときは . を使います！
git add .

ステージに上げたファイルをローカルリポジトリにコミットする

git commit コマンドを打つと、ターミナル上で Vim というエディタが起動し、そこにコミットメッセージを書くことになります。

コミットメッセージのいいとされている形はこんな感じです ↓

１行目：種別と対応内容

２行目：空行

３行目～：対応内容の詳細

//ステージにある全てのファイルをコミット
git commit

// ものすごく簡単な修正などで 詳細も何もない場合は -mオプションを使い、コミットメッセージをサクッと入力できます！
git commit -m "コミットメッセージ"

ローカルリポジトリをリモートリポジトリへプッシュする

//git push origin プッシュしたいリモートブランチの名前

// devブランチにプッシュしたいなら
git push origin dev

ブランチの作成・変更・削除

//ブランチ作成
git branch ブランチ名

//現在いるブランチの確認
git branch

//ブランチの切り替え
git checkout 切り替え先のブランチ名

//ブランチ削除
// -d オプションをつけておくことで、マージが未完了なブランチは削除できないです
git branch -d ブランチ名


//リモートブランチの削除
git push --delete origin ブランチ名

? 割と便利なコマンド

ワークツリーを最新のステージの状態に戻す

作業中に、このファイルで何してたかよく分からなくなった！ 一回全部戻したい！ というとき

// ステージの最新の状態に戻ります
git checkout -- ファイル名

コミットをやり直す

コミットしてから誤字に気づいた...

誤字の修正だけで、また新しく commit して コミットメッセージも書くのはイヤだ！ というとき、

あと、コミットメッセージ ミスった... ってとき

まず、修正を行い、git add する
そして ↓

// 最新のコミットを上書きする
git commit --amend --no-edit

コミットメッセージをミスったときは --no-editオプションをつけずに叩きましょう！ コミットメッセージも修正できます
git commit --amend

やりたいこと

ローカルの変更を

• github
• heroku

のリモートリポジトリに一括でpushしたい。

今回やってみた方法

こちらの記事を参考にしました　

git remote

でリモートリポジトリ名一覧を取得出来るので、
パイプを使ってxargsに渡し、各リモートリポジトリ名ごとにコマンドを作成します。

git remote | xargs -I reponame git push reponame main 
# -I reponame: 変数reponameを任意の場所で展開する

今回の環境では

$ git push heroku main
$ git push origin main

が順に実行されることになります

おまけ

エイリアス設定するとより楽になると思います

git config --global alias.pushall '!git remote | xargs -I reponame git push reponame main'

追記

githubにpushすると自動でherokuにデプロイしてくれる設定がありました...
初めからこれ使えばよかったですね
https://devcenter.heroku.com/ja/articles/github-integration

お読みいただきありがとうございました。

諸事情により、GitHubの既存のリポジトリにローカルで作成したプロジェクトを移植しないといけないという経験をしたのでここにアウトプット

流れはGitの初期化と同じ感じに

移植作業といっても、既存のリポジトリに初期化したプロジェクトをpushするのと同じ流れになるから普通に初期化の流れをやってみる。

$ git remote -v  // remoteのURLがないか確認
$ rm -rf .git  // remoteのURLがあったら実行
$ git init
$ git add .
$ git commit -a -m "新プロジェクトの移植作業"
$ git remote add origin git@github.com:管理ユーザー名/移植したいリポジトリ名.git
$ git push -u origin main -f  // 強制的にpushを実行

これで処理を実行すると、以下のようなエラーが発生。

error: src refspec main does not match any
error: failed to push some refs to 'git@github.com:管理ユーザー名/移植したいリポジトリ名.git

エラーが出たからとりあえずググる。

この記事 （ https://qiita.com/fukkatsu3/items/c488ec9559f6cca34313 ） を参考に確認してみると、

$ git branch
* master

mainブランチに移植したいのにmasterブランチの状態だったことを確認。

$ git push -u origin HEAD:main

記事をそのまま参考にしてやってみた。

$ git push origin HEAD:main
To github.com:管理ユーザー名/移植したいリポジトリ名.git
 ! [rejected]        HEAD -> main (fetch first)
error: failed to push some refs to 'git@github.com:管理ユーザー名/移植したいリポジトリ名.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 details.

依存関係とか諸々でpushを拒絶した模様。

今回は思考停止で上書きしてもよかったから、強制的にpushを実行。

$ git push -u origin HEAD:main -f

これでできた。

はじめに

　チーム開発では、実際に本番環境に反映させたいコードのみを反映させることが重要になります。
　commitメッセージに反する変更を加えずに開発を進めていく必要があります。
　これができないとコードレビューの際に、「これ消しておいて！！」の様なあまり生産的じゃない私的に時間を使ってしまいます。（僕はよくこれで怒られました！笑）
　この記事では自分が意図していない変更を含まない為に、commitを行単位で行う方法を普段自分が使っている手法を中心にまとめました。
　参考になれば幸いです。(作業環境はvscodeを想定しています)

1行単位でのcommitがなぜ必要なのか？

commitは作業ログではなく、実現した事ベースで行う事が望ましいと考えています。
参考コミットは作業ログではない！

その理由について簡単にまとめると。
##バグを生む可能性があるから
　機能を作る際に、それ以外の部分に影響を及ぼすコードは含まない事が望ましいです。
　lintの設定、フォーマッターによる既存部分の不要なフォーマッティング、他の部分でちょっとした動作確認をした際に書いたコードetc..。
　これらを本番環境に反映させると意図していない挙動になる場合があります。

##レビュアーがレビューしやすいから
　例えばAの機能を作る際にB、Cの機能のコードが入っていると、レビュアーの可読性が下がってしまいます。
　commit自体を機能ごとに分ける事が前提ですが、

1行単位でcommitする方法

git add -p

git add -pを使うと全ての差分をステージングするかどうかの取捨選択ができます。
例えばこのような変更があったとします。

これにgit add -pを行うと

diff --git a/src/compornents/Banner.scss b/src/compornents/Banner.scss
index 1d275cb..cd7b375 100644
--- a/src/compornents/Banner.scss
+++ b/src/compornents/Banner.scss
@@ -11,7 +11,7 @@

   &-title {
     font-size: 3rem;
-    font-weight: 800;
+    font-weight: 900;
     padding-bottom: 0.3rem;
   }

Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? 

と変更差分ごとにY/Nでステージングするかどうかを選択できます。
多くの差分がある際に有効です。

vscodeから行う

vscode上で差分をステージングすることも可能です。

目視で意図した通りに1行単位でステージングできます。

まとめ

commitやPRの粒度はプロジェクトのお作法によって食うrと思いますが、不要な変更を含めずにcommitできる様になるとチーム開発での不安は減ってくるかと思います。

---

フリーランスでフロントエンドエンジニアをしています。
お仕事のご相談こちらまで
gunners6518@gmail.com

技術ブログ

今さら聞けない！GitHubの使い方【超初心者向け】

要約

function g () {
  if [[ `pwd -P` == /mnt/* ]]; then
    git.exe "$@"
  else
    git "$@"
  fi
}

WSL めっちゃ便利

Windows Subsystem for Linux というものがあります。
Windows 上で Linux を動かすことのできるもので、/mnt/c/から Windows の C ドライブにアクセスして Linux のコマンドでやりたい放題できるという、とても楽しく便利なものです。

が……

Git めっちゃ遅い

Git がなぜだかめちゃくちゃ遅い場合があります。
どのくらい遅いかと言えば、「うっかり Powerline のような Git の情報を見せてくれるリッチなプロンプトを使っていると、プロンプトを表示するだけで数十秒もの遅延が生まれるレベル」です。

なにゆえ……？

Windows ファイルシステムにある Git リポジトリの操作がめっちゃ遅い

↓ 先人

• 【WSL】Powerline 入れたら死ぬほど遅くなった人へ - Qiita

Q. それじゃあ Windows ファイルシステムにある Git リポジトリを扱いたい場合どうすれば……？

Windows ファイルシステムでは Git for Windows を使うようにする

A. 素直に Git for Windows 使いましょう。あとプロンプトの Git 情報表示機能は OFF にしましょう。

適当に~/.zshrcなどで、WSL の Git と Git for Windows を自動で使い分けてくれる関数を定義しましょう。
ここではgという名前で定義します。

function g () {
  if [[ `pwd -P` == /mnt/* ]]; then
    git.exe "$@"
  else
    git "$@"
  fi
}

pwdにオプションがあるなんて初めて知りました……。
（シンボリックリンクから Windows ファイルシステムに入ったときのためのオプションです）。

おそらくこれで、g statusなどしても問題なく動いてくれると思います。補完は効きませんが。

おわりに（ポエム）

今ではすっかり、何をするにも WSL から行うようになりました。
コマンドプロンプト？　 PowerShell？　そんなのもありましたね（環境構築時に使う）。
Git Bash？　……いいやつだったよ（たまに使う）。

やはり慣れ親しんだ Linux コマンドたちで Windows を操作できるのがとてもありがたいです。
さらに、（今回のように）場合によっては Windows のexeを叩けるのでできないことは少ないです。
I/O 遅かったりメモリ大食らいだったりはしますが、それでもとても便利です。

どれだけ Linux を愛していようが、Windows はどうしても必要です。
そんな Windows が使いやすくなってくれるのは素直に嬉しいです。

WSL とか Windows Terminal とか Windows Package Manager（winget）とか、目が離せません。
頑張れ Microsoft！

おまけ

Git for Windows で、D ドライブなどにリモートリポジトリを作って遊ぶ場合、remote addの際には素直に WSL から Git Bash を呼び出して使ったほうがパス関連が楽です。

個人開発をするうえでの最低限のGit・GitHubの使い方をまとめました。

リポジトリセットアップ

①作業ディレクトリへ移動

$ cd ~/environment/<アプリ名>

②ローカルリポジトリを作成

$ git init

③現在のディレクトリにあるファイルをステージにすべて追加

$ git add -A

④ステージにある変更をローカルリポジトリへ反映

git commit -m "コミットメッセージ"

GitHub(リモートリポジトリ)にアップロード

①Newリポジトリを作成

②リポジトリ名、PublicかPrivateを選択

③HTTPSを選択し、URLをコピー

④IDEのターミナルでコードを入力

$ git remote add origin <コピーしたURL>

GitHubをリポジトリのoriginとしてGitの設定ファイルに追加する。

$ git push -u origin master

-uで過去のブランチ履歴を辿ることができるようになります。

これでGitHubへアップロード完了。

---

少し応用編

ブランチ

ブランチとは、複数機能を開発するためにリポジトリのコピーをし元ファイルを触らずに開発すること。

$ git checkout -b <ブランチ名>

新たにブランチを作成し、作成したブランチへ移動します。
このブランチをトピックブランチといいます。
元のファイルのブランチをマスターブランチといいます。

$ git status

変更したファイルのチェックができます。

$ git add -A
$ git commit -m "<コミットメッセージ>"

addでステージに追加し、コミットでリポジトリに反映。
この時点ではまだマスターブランチには反映されてません。

マージ

マージとは、マスターブランチに変更内容を統合すること。

$ git checkout master

checkoutはブランチの移動(マスターへ移動)

$ git merge <トピックブランチ名>

マスターブランチへマージする。

$ git branch -d <トピックブランチ名>

マージしたのでトピックブランチを削除する。

$ git push

pushでGitHubに反映させる。

qiita初心者なので書き練習も含めSourceTreeを導入して、Gitを使うのに参考になったリンク集

• Gitのインストール方法

  • いまさらGit for Windowsのインストール、GitHubに接続してみた。

  インストール時に専用エディタを選択させるので、Visual Studio CodeやAtomなど入れると良い。

• SourceTreeインストール方法

  • SourceTreeインストール手順＜Windows向け＞
  • git clone 出来ない( ﾉД`)…おぉー！出来たー( ;∀;)!!!
  • SourceTreeでGithubの認証に秘密鍵を使う (Windows)
  • Sourcetreeで変更内容をコミット、プッシュする
  • Sourcetreeでマージしよう

  SourceTreeでバージョン管理を行う(commit, merge等）

• GitHubの使い方

  • 今さら聞けない！GitHubの使い方【超初心者向け】

qiitaって、普通の文章のインデントできないのかな・・。現状空白のみ？
[Qiita]タブキーでインデントしたい