20191205のGitに関する記事は9件です。

Gitのエイリアスって便利やな

Gitでエイリアスを設定したら、すごく便利になったので、その設定方法と自分が使っているものをいくつか紹介。(備忘録的に書きます)

設定方法

git initしているディレクトリから、、、

cd .git
vi config

をたたくとconfigファイルが開く。

そこに

[alias]

を入力する箇所があるので、そこにガシガシ書いていく。

実際の画面

2019-12-05_21h46_29.png

「ada」に関してはaddコマンドでディレクトリ指定をしています。

使ってて便利だったエイリアス

ad〇 = add

ディレクトリ指定でaddできるようにするコマンド。

cmm = commit -m

コミットするためのコマンド。
開発が終わったらとりあえず「ad〇」→「cmm <コメント>」のコンボですぐにpushできるようにしている。

chd = checkout develop

developブランチにすぐに戻るためのコマンド。masterとかのも作ってもいいかもしれない。

brd = branch -D

ブランチを消すコマンド。「-D」のコマンドなので、ブランチの状況がどうであれ強制削除されるため、地雷を踏まないようにちょっと気をつけて使う。

最後に

一度エイリアスを設定してしまうと、もう抜け出せない。
この前自宅で開発環境作った時も、「git status」と打つのがめんどくさすぎたり、新しいブランチを切るのに「git checkout -b」というコマンドがわからなくて、ついググってしまったりと、自分好みに設定してしまうと、かなり速度を上げられる。

便利なコマンドほど、オプションがいっぱいついて、長くなりがち、タイポもしがちな自分にはもってこいの設定だなとしみじみ感じている。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

GASはTypeScript × claspでストレスフリー開発

記事を書き終わった後に全くLINE Botと関係のないものだと気づきました。。(完全にGASのお話になってます)
LINE BotのAdvent Calendarの作成者さん、すみません、、、:bow_tone1:

はじめに

弊社で使うLine botを作成した時に得た経験(GASストレス)を還元しようと考えたので記事に起こしました。

南無。

数多のエンジニアをピキらせたであろうポイント

ES6に対応していない

正直、これが一番ストレスの根源になってると感じます。

let・const、分割代入、ブロックスコープ、アロー関数、Class ...etc

// no let const
let hoge
const hage

// no destructuring
const piyo = ["hage", "piyo", "fuga"]
const fuga = ["hage", "piyo", ...piyo]  // output -> "hage", "piyo", "hage", "piyo", "fuga"

// no allow function
const foo = () => {}

// no class
class Hoge {
  constructor(piyo) {
    this.piyo = piyo;
  }

  getPiyo() {
    return this.piyo
  }
}

これら全て使えません。

ファイルを分割していてもグローバル変数扱い

エディター上でファイルが分割されていても、GAS側は一つのファイルとして認識します。

スクリーンショット 2019-12-05 17.02.55.png
スクリーンショット 2019-12-05 17.03.05.png

実行すると"global"が出力されました。

スクリーンショット 2019-12-05 17.04.02.png

:point_up:ハマるポイント:別のファイルで同じ関数名を定義してしまって、想定のしていなかった処理がされる

コード補完はできるだけ頑張る!

変数に格納された値を推測し、コード補完をしてくれます。

スクリーンショット 2019-12-05 17.59.14.png

(※ この配列を作成している末尾にセミコロンを忘れると補完してくれません。)

しかし、関数の引数として渡されると先程の補完機能が働かなくなってしまいます。

スクリーンショット 2019-12-05 18.04.12.png

コード補完機能は基本的にめちゃくちゃ弱いです。期待はほぼできません。
でもたまに補完してくれるのが可愛いですね。:point_up:

ローカルで開発しよう!

GASのエディターからは脱出しましょう。

ローカルの開発環境を立てるためにclaspを使います

claspはGoogle Apps Scriptをローカル環境で扱うためのライブラリ。
標準でTypeScriptに対応しており、ES6の記法も使えようになる。(非常に重要)

ではウキウキ気分でclaspをインストールしていきます。 ターミナルから以下のコマンドを実行。

$ npm i -g @google/clasp

続いてログインしましょう。

$ clasp login

実行すると、ブラウザが開くので「許可」を押して認証完了です。

任意のディレクトリでプロジェクトを作成しましょう。以下コマンドを実行

$ npm init -y
$ clasp create hoge_bot --rootDir ./src

clasp createを実行すると、プロジェクトのタイプを選択できます。適当なものを選択してください。
--rootDir ./srcで指定したディレクトリの直下はGASにpushされるイメージになります。

GitでGASのソースコードを管理

エディターから離れられたのでソースコードもGitで管理しちゃいましょう!

$ git init

node_modulesと.clasp.jsonは管轄外にしておきます。

$ touch .gitignore
gitignore
.clasp.json
node_modules

ノンストレスコーディング

GASの諸々のライブラリがnpmで配布されているのでインストールしておきましょう!

$ npm i -D @types/google-apps-script

以上でローカル環境構築は終わりです。
(更にprettier等を導入してコードを綺麗に保つとより気持ちいいです!!)

ソースコードが書けたらGASにpushしましょう。下記コマンドを実行

$ clasp push

clasp pushはTypeScriptで書かれたコードを自動でトランスパイルしてくれます。

ここでも罠... importはdefault exportのみしか受け付けられない

下記のように複数のexportされたものは受け取ることができない。

src/hoge.ts
export const hoge = "message hoge"
export const piyo = "message piyo"
src/fuga.ts
import { hoge, fuga } from "./hoge"

importしたければdefault exportにしなければならない。

src/hoge.ts
const hoge = "message hoge"

export default hoge
src/piyo.ts
const piyo = "message piyo"

export default piyo
src/fuga.ts
import hoge from "./hoge"
import piyo from "./piyo"

どうしても一つのファイルから複数の値を返したい、、、なんて時は関数を返すようにしてみましょう。

src/Messages.ts
const hoge = "message hoge"
const piyo = "message piyo"

type Name = "hoge" | "piyo"

const getMessage = (name: Name) => {
  switch(name){
    case "hoge":
      return hoge
    case "piyo":
      return piyo
  }
}

export default getMessage
src/fuga.ts
import getMessage from "./Messages"

const message = getMessage("piyo")   // output -> message piyo

getMessageでswitch使ってるのがとってもダサいです。もっとかっこいいやり方があるはずなのでご教授ください:relaxed:

まとめ

GASのエディターでコーディングしない。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Gitとは

Gitとは

Gitとはプログラムソースなどの変更履歴を管理する分散型のバージョン管理システムのこと。

Gitを使ったバージョン管理

Gitでは、ファイルの状態を好きなときに更新履歴として保存しておくことができる。そのため、一度編集したファイルを過去の状態に戻したり、編集箇所を示すことができる。また、古いファイルを元に編集したファイルで、他人の編集した最新ファイルを上書きしようとすると、サーバにアップロードした時に警告が出る。そのため、間違って他人の編集内容を上書きしてしまうといった失敗は起こらない。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

windowsでlinux形式のパーミッションを設定してgitにファイルを上げる

背景

会社の開発端末はwindowsなんですが、そのPCでシェルスクリプトを書いてgithubに追加する必要がありました。
シェルスクリプトなので実行権限を付与(chmod +x)してからgitに追加したかったのですが、windows上でどう実行していいかわからず少し調べました。
単にgit bashでchmodをやってもダメらしいことがわかりました。

答え

git addのオプションでパーミッションをつけてstageするものがありました!

git add --chmod=+x -- file.sh

あとはコミット&プッシュするだけ。便利ですねー
よかったよかった。

linuxやmacなら

chmod +x file.sh

これをやってからgit add -> git commit
でいいんですがね。

それでは。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【SourceTree】リモートの感嘆符を消す

内容

SourceTreeのリモートに「!」ビックリマークが付いて消えない

remote.png

設定

リモートタブからリモートリポジトリを選択して編集を押下

外部サービスとの拡張統合オプションのRemote Accountを「Generic Account」から自分に変更

結果

消えました
その後、「Generic Account」に切り替えても出なくなった

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【SourceTree】リモートのアイコンに出てくる感嘆符を消す

内容

SourceTreeのリモートに「!」ビックリマークが付いて消えない
リモートのアイコンをクリックすると正しくGitHubには飛べる

remote.png

やったこと

  1. 設定アイコンを押下
  2. リモートタブからリモートリポジトリを選択して編集を押下
    1. 必要な情報のURL/パスが正しい確認
    2. 外部サービスとの拡張統合オプションのRemote Accountを「Generic Account」から自分に変更

結果

消えました

その後、「Generic Account」に切り替えても出なくなった

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【SourceTree】リモートのアイコンに出てくる「!」(感嘆符)を消す

内容

SourceTreeのリモートに「!」ビックリマークが付いて消えない
リモートのアイコンをクリックすると正しくGitHubには飛べる

remote.png

やったこと

  1. 設定アイコンを押下
  2. リモートタブからリモートリポジトリを選択して編集を押下
    1. 必要な情報のURL/パスが正しい確認
    2. 外部サービスとの拡張統合オプションのRemote Accountを「Generic Account」から自分に変更

結果

消えました

その後、「Generic Account」に切り替えても出なくなった

追記

PC再起動したらまた出ててアカウント確認したら「Generic Account」になっていた
再度やったことと同じ対応で消せたがアカウントを固定にする設定が必要かも

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

empty submoduleを(reset等の後で)複数回remote addする

resetやブランチを移動するなどして、2回、git submodule addすると、If you want to reuse this local git directory instead of cloning again from (snip) use the '--force' optionなるエラーとなり、submoduleの追加に失敗する。
指定通りに--forceすればよい。以下のbashで検証できる。

function make_submodule() {
git submodule add -f https://github.com/cielavenir/submodule-child-readme.git
}

git clone https://github.com/cielavenir/submodule-test
cd submodule-test
git config user.name cielavenir
git config user.email cielartisan@gmail.com

make_submodule
git submodule

git reset --hard
rm -rf .gitmodules *
git checkout .

make_submodule
git submodule

しかし、submodule上にmirrorを作りたかった場合など、empty submoduleの場合は事情が違ってくる。.gitmodulesを力技で書く必要がある他、--forceに加え当該submoduleをaddする必要があるらしい。
以下のbashで検証できる。

function make_submodule() {
tab=$'\t'
if [ ! -d submodule-child ]; then
    git submodule add -b master -f https://github.com/cielavenir/submodule-child.git
    if [ ! -f submodule-child/.git ]; then
        echo '[-] need to write .git manually'
        echo "gitdir: ../.git/modules/submodule-child" > submodule-child/.git
    fi
    git add submodule-child
    cat << EOM >> .gitmodules
[submodule "submodule-child"]
${tab}path = submodule-child
${tab}url = git@github.com:cielavenir/submodule-child.git
EOM
fi
git add .gitmodules
}

git clone https://github.com/cielavenir/submodule-test
cd submodule-test
git config user.name cielavenir
git config user.email cielartisan@gmail.com

make_submodule
touch submodule-child/readme
git -C submodule-child add readme
git -C submodule-child commit -m 'initial'
git add submodule-child

git submodule

git reset --hard
rm -rf .gitmodules *
git checkout .

make_submodule
git submodule
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

-fを使った話

はじめに

なんだか前回のサークルのLTを聞いた人は既視感のある話題かもしれません。
いや、まさか人の†force†について言及した一週間後に自分が†force†すると思っていませんでした。そんな†force†を使った経緯や使い方について共有できたらいいなと思います。


あと、この記事は思ったよりコマンドや画面表示の記述が多いので読みづらいかもしれません。記事を書くのって想像していたより難しかったです。

なぜ?

経緯について話すと自分の雑な性格が露呈するので恥ずかしいのですが一言で申しますとコミットメッセージをタイポしたからですね。


重要なやりとりでなければスマホで入力する際も確認せず送信しているのでタイポの嵐です...。 コミットメッセージは重要ではないの?というツッコミは無しで

今回はコミットメッセージを編集する手順についてまとめて行きます。何番煎じか分りませんが自分がまとめた記事が一番自分が読みやすいと思うので、備忘録として綴っていきたいと思います。

-fを使った話 〜確認編〜

実際に間違えた内容を紹介すると

>git log

commit bb56b11bbab8b964fce0baf28f5e871ec70f4801 (HEAD -> master)
Author: shinooooo
Date:   Wed Dec 4 22:33:40 2019 +0900

    [Add]fuga

commit b9306ce7cbffa90858d68da9a340d9849747a338
Author: shinooooo
Date:   Wed Dec 4 18:15:49 2019 +0900

    [App]hoge


...


Addと書きたかったのですがAppと書いてしまったようです。このぐらい確認できないの???と思われるかもしれませんが個人作業且つ一作業やり終えて慢心していた僕は確認することなくpushしたようです。


個人作業だしこのくらい放っておいてもいいかもしれせんが雑な割に変な所は几帳面なので、今回はこのメッセージをどうにか直したいと思います。

-fを使った話 〜実践編〜

僕の場合

>git  rebase -i HEAD~2


とターミナルで打ちました。このコマンドのHEADというのは作業をした最新の場所を示すものであり、ここから二番目のコミットメッセージを変更したいのでHEAD~2と入力します。


するとエディタが起動し、

  1 pick 0ba423f [App] hoge
  2 pick 0a178a2 [Add] fuga
  3 
  4 # Rebase 8fdc7c1..0a178a2 onto 8fdc7c1 (2 commands)
  5 #
  6 # Commands:
  7 # p, pick <commit> = use commit
  8 # r, reword <commit> = use commit, but edit the commit message
  9 # e, edit <commit> = use commit, but stop for amending
 10 # s, squash <commit> = use commit, but meld into previous commit
 11 # f, fixup <commit> = like "squash", but discard this commit's log message
 12 # x, exec <command> = run command (the rest of the line) using shell
 13 # b, break = stop here (continue rebase later with 'git rebase --continue')
 14 # d, drop <commit> = remove commit
 15 # l, label <label> = label current HEAD with a name
 16 # t, reset <label> = reset HEAD to a label
 17 # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
 18 # .       create a merge commit using the original merge commit's
 19 # .       message (or the oneline, if no original merge commit was
 20 # .       specified). Use -c <commit> to reword the commit message.
 21 #
 22 # These lines can be re-ordered; they are executed from top to bottom.
 23 #
 24 # If you remove a line here THAT COMMIT WILL BE LOST.
 INSERT  git-rebase-todo   unix | utf-8 | gitrebase    3%    1:1  
-- INSERT --

このような画面に遷移すると思うので一行目の修正したいコミットメッセージを

   edit 0ba423f [Add] hoge

のようにpickeditに変更し、正しいコミットメッセージ[Add] hogeを記述します。

エディタを抜けますと、

Stopped at b9306ce...  [App]hoge
You can amend the commit now, with

  git commit --amend 

Once you are satisfied with your changes, run

  git rebase --continue

のように表示されますので

>git commit --amend

を実行しましょう。

detached HEAD 0ba423f] [Add]hoge
 Date: Wed Dec 4 18:15:49 2019 +0900
 3 files changed, 90 insertions(+)

というような表示されるので流れで

>git rebase --continue

を実行。

>git log

commit 0a178a210078bc08ce546f1874f4191b66a8ce0f (HEAD -> master)
Author: shinooooo
Date:   Wed Dec 4 22:33:40 2019 +0900

    [Add]fuga

commit 0ba423fd0c923d7c4fbc6426b0d222c268c3a05f
Author: shinooooo
Date:   Wed Dec 4 18:15:49 2019 +0900

    [Add]hoge

git logを実行し、しっかりと変更されているのを確認したらgit pushしましょう!

 >git push

 To https://github.com/shinooooo/hoge.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'https://github.com/shinooooo/hoge.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.


あれ?


どうやらgit pushではうまく行かないようです。整合性が保てんぞ的なニュアンスのエラーが出ます。それもそのはず。コミットメッセージを変更したローカルと変更していないリモートではズレがあります。コミットメッセージを書き換えるということは過去改変をするということに他なりませんから。これはちょっと無理矢理にでもpushしないと通してくれなそうです。


はい。勿体ぶっても仕方ありません。


 >git push -f

 Enumerating objects: 19, done.
Counting objects: 100% (19/19), done.
Delta compression using up to 4 threads
Compressing objects: 100% (13/13), done.
Writing objects: 100% (13/13), 2.82 KiB | 2.82 MiB/s, done.
Total 13 (delta 5), reused 0 (delta 0)
remote: Resolving deltas: 100% (5/5), completed with 2 local objects.
To https://github.com/shinooooo/hoge.git
 + 149f820...0a178a2 master -> master (forced update)

おわりに

共同開発でこの記事のgit push後のメッセージが出たら事故ですが個人作業且つ理由が明確なのでまあセーフということに致しましょう。共同開発で-fを使うのは非常に迷惑なのでなるべく避けたいですね。ちなみにこの記事を書いた日にはこのミスの他にも一度コミットメッセージをタイポしていたのでネタになると思い、急遽この記事を書くことを決意しました。


流石に何度も面倒くさいコマンド入力をしないといけないのでこれに懲りてしっかりとチェックをしてからpushしたいと思います。

この記事を読んで実践したくなった人や自身のタイポを許せない几帳面な人は

 >git log --oneline 


なんてコマンドを打って過去のコミットメッセージの粗探しをしてもいいかもしれませんね!^^
最後までお付き合い頂きありがとうございました!

参考

https://backlog.com/ja/git-tutorial/stepup/33/
https://qiita.com/ymzk-jp/items/00ff664da60c37458aaa

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む