What's New Qiita

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

  • 投稿日：2020-12-18T18:50:13+09:00

Herokuへデプロイする方法 ＆ アプリ名変えたい場合

前回投稿した記事「git init から git pushまでの流れ」の後、そのままHerokuへデプロイすることが多いので、その手順を自分用にまとめておきます。

間違っている箇所がありましたら、ご指摘いただけると助かります！！

Gitでコマンドを打つ

Git
$ heroku create 〇〇(アプリ名)

〇〇(アプリ名)　のところは、入力せずに打つと、自動でHerokuがアプリ名生成してくれます。
後で変更も可能です。（後述）

ちなみにアプリ名は、すでに他の人が使っている名前だと、
Name is already takenと怒られます。

次に、下記のコマンドを打ちます。

Git
$ git push heroku main

main のところは master の場合もあります。
おそらくどっちかです。

herokuのアプリ名を変えたい場合

リポジトリのディレクトリ内で変更する場合は

Git
$ heroku rename 〇〇(新アプリ名)

　
リポジトリのディレクトリ外で変更する場合は

Git
$ heroku rename 〇〇(新アプリ名) --app 〇〇(旧アプリ名)

こちらで可能です！

最後に

Herokuだと無料版は5つまで？しかアプリが作れないみたいなので
代わりのツールを探したいところです◎
何かオススメあったら教えてください～！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-12-18T18:12:10+09:00

JS周りのコードフォーマットをどうするか？

この記事は、ニフティグループ Advent Calendar 2020の23日目の記事です。

はじめに

今年、弊社ではフロントエンドの刷新業務として、Reactの開発を行う機会があり、そこで私も同じプロジェクトの開発メンバー(2~3人程度)と同時にコード開発を行っていました。

自分自身、本格的なチームでの開発というものが初めてだったため、「Gitのブランチの扱いが良く分からない...」だったり、「プルリク時のコンフリクトが頻繁に起こる...」など、共同開発で迷う場面が多かった気がします。。

そんな中、在宅期間中で「これができたら便利そう...とか、もっと効率良い開発方法はがあるのでは？」など、あれこれ考えることが多く、何かと便利機能を調べてみては試してみる、といったこともそれなりに出来たので学びとしては多かったです。

また、開発の面倒な部分を効率化出来れば、きっとエンジニアのモチベーションも上がるはず(!?)です。

そこで、チーム開発で一部導入してみた機能や、最初からもっとこうしておけばよかったな、といったことを書いていこうと思います。

Git開発

Git開発の流れとしては、以下のような手法で開発していました。

  • 機能ごとにfeatureブランチを切る
  • 各ブランチ毎にプルリクを出す

コンフリクトにどう対処するか問題

基本的に各自で開発した機能は被ることがないので、その場合はプルリクでコンフリクトが起こることはありません。
ただし、ちょっとした機能修正などコードを修正したタイミングでは、コンフリクトが起きることがあります。

コンフリクト修正機能

エディター自体にもコンフリクトを修正するような機能は用意されており、後からコンフリクトを修正することもできるのですが、
そもそもが「インデントが違う」などフォーマットが統一されていないがためにコンフリクトが起こっている場合、それを一々修正するのは面倒だと思います。

こういった問題を解消するために、JS用のコードフォーマッターを導入しました。

コードフォーマッターを入れたい

React(JS)での開発では、フォーマッターを入れると便利という事を知り、以下の２つを導入しました。

導入したもの

  • Prettier（フォーマッター）
    • ソースコードをルールに沿った形に良い感じに整形してくれるツール
  • ESLint（リンター）
    • ソースコードを読み込んで内容を分析し、問題点を指摘してくれる

Prettier

.prettierrcというファイルを用意し以下のようにフォーマットのルールを設定します。セミコロン有無や、インデント幅などを設定可能です。

.prettierrc
{
  "printWidth": 120,
  "tabWidth": 2,
  "useTabs": false,
  "semi": true,
  "singleQuote": false,
  "trailingComma": "es5",
  "bracketSpacing": true,
  "jsxBracketSameLine": false
}

例えば、app.jsに対してprettierを実行したい場合、prettier app.js --writeとコマンドを実行すれば、整形されたファイルが出力されます。

ここまででは、一先ずはコードフォーマットは出来るようになりましたが、一々コマンドを打たないとフォーマットができないのはかなり面倒です。

そこで、"ファイル保存をする毎にprettierを実行できるよう"、VSCodeのsetting.jsonに以下の一行を追加します

 "editor.formatOnSave": true

これで、かなりの手間が解消されました。

ESLint

prettierはコードフォーマッタのため、ESLintのような構文のチェックはできません。そのため、ESLintも併用で導入します。

同様に、.eslintrcにも設定内容を記述していきます。
（以下が設定例となります。）

.eslintrc
{
  "env": {
    "es6": true,
    "node": true,
    "browser": true,
    "jquery": true,
    "jest": true
  },
  "parser": "babel-eslint",
  "plugins": ["react", "prettier"],
  "parserOptions": {
    "version": 2018,
    "sourceType": "module",
    "ecmaFeatures": {
      "jsx": true
    }
  },
  "extends": ["eslint:recommended", "plugin:react/recommended", "plugin:prettier/recommended", "prettier/react"],
  "rules": {
    "prettier/prettier": "error"
  },
  "settings": {
    "react": {
      "version": "detect"
    }
  }
}

ESLint と Prettier を共存させる場合、
"extends": ["plugin:prettier/recommended"]を書くだけで、併用ができます。

"git commit"実行時にlinterテストを走らせる

さらに、linterテストが自動で走るようにしたいので、ESLintのテストが失敗した場合は"git commit"が通らないようにします。

使うものとしては以下です。

  • lint-staged
  • husky
yarn add -D eslint lint-staged husky

追加方法としては、以下をpackage.jsonに追記するだけでできます。

package.json
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    ".{js,jsx}": [
      "eslint --fix",
      "git add"
    ]
  },

実際に動かすと...

image.png

このように、git commit時にeslint --fixが実行され、該当するエラーを解消しないとコミットができなくなりました。

導入した結果

ここまでで以下のような事が出来るようになりました

  • "git commit"実行時に自動でlinterテストが走る
  • ファイル保存時にPrettierが実行される

コードフォーマットを自動化することで、無駄なことに人力で注視しなくなるので楽になりました。

なお、VSCode等でJSやHTMLなど専用のフォーマッターツールを別途入れている場合、Prettier、ESLintの設定を上手く変えてあげないと動作しないことがあるので注意が必要です。
今回は実装を簡単にするため最低限の設定にしてありますが、実際のチーム開発を行う場合には、エディターに入れる拡張機能などの環境を、事前に揃えておくなどの工夫が必要かと思います。

感想

初めてコードフォーマッターを導入してみたのですが、調べてみるとこれ以外にもかなり多くの事ができるようで、良い勉強になりました。

個人的には、プルリクなりコードを書くなりでも、きれいな状態（整理された状態）でいることはコードの品質面でもそうですが、自分が見ていても分かりやすいし実際にチームでも使ってもらえたりと、それだけでモチベが上がる気がします。

VSCodeのエディターの機能や、プルリクの自動化機能（GitHub Actions）など、既存ものを自動化して改善できる部分は意外とあるものの、一度面倒な部分を実感してからじゃないと中々思いつかない部分もあるのかなと感じました。

１から調べて実装して導入までやってみると、かなり知識も身に付くと感じたので、プライベートでもこういった経験を増やしていきたいです。

終わりに

次回は@RPcatさんの記事になります！お楽しみに！

参考

Prettier 入門 ～ESLintとの違いを理解して併用する～
【JavaScript】コミットする前にlint-stagedでeslintのチェックをする
VS Code上でファイル保存時にPrettierを走らせる

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-12-18T17:39:24+09:00

GitHub CLIを使う方法

はじめに

おはようございます。こんにちは。こんばんは。
Watatakuです。
今回は、GitHub CLIが登場したという事で早速使って行こうという記事です。
※この記事はmacを使っての解説です。

GitHub CLIとは

公式がリリースしたGitHubがコマンドラインツール。
https://github.com/cli/cli

インストール

brewでインストールできます。

$ brew install gh

インストールが完了するとghコマンドが使えます。
お察しだと思いますが、ghコマンドが今回の主役です。

Work seamlessly with GitHub from the command line.

USAGE
  gh <command> <subcommand> [flags]

CORE COMMANDS
  gist:       Manage gists
  issue:      Manage issues
  pr:         Manage pull requests
  release:    Manage GitHub releases
  repo:       Create, clone, fork, and view repositories

ADDITIONAL COMMANDS
  alias:      Create command shortcuts
  api:        Make an authenticated GitHub API request
  auth:       Login, logout, and refresh your authentication
  completion: Generate shell completion scripts
  config:     Manage configuration for gh
  help:       Help about any command
  secret:     Manage GitHub secrets

FLAGS
  --help      Show help for command
  --version   Show gh version

EXAMPLES
  $ gh issue create
  $ gh repo clone cli/cli
  $ gh pr checkout 321

ENVIRONMENT VARIABLES
  See 'gh help environment' for the list of supported environment variables.

LEARN MORE
  Use 'gh <command> <subcommand> --help' for more information about a command.
  Read the manual at https://cli.github.com/manual

FEEDBACK
  Open an issue using 'gh issue create -R github.com/cli/cli'

認証

最初に自分のGitHubアカウントと連携するために認証が必要です。

$ gh auth login

するといくつか認証のための質問がるので答えます。

? What account do you want to log into?  [Use arrows to move, type to filter]
> GitHub.com
  GitHub Enterprise Server

どのアカウントにログインしますか？と聞かれています。自分はGitHub.comです。

? How would you like to authenticate?  [Use arrows to move, type to filter]
> Login with a web browser
  Paste an authentication token

日本語にすると以下です。

？ どのように認証しますか？ [矢印を使用して移動し、入力してフィルタリングします]
> Webブラウザでログインします
   認証トークンを貼り付けます

自分はwebブラウザでログインします。

コマンドライン上に認証コードが表示されるので、
Enterキーを押してブラウザを起動します。
そのブラウザに先程の認証コードを入力します。

その後再び、質問が続けられるので答えていきます。
まずデフォルトのgitプロトコルを選択します。
HTTPSでいいでしょう。
最後に、GitHubの認証情報でGitを認証しますか？をyes

これで,自身のGitHubアカウントとの連携ができました。

ここまでできるとブラウザを開いてマウスカーソルで操作する必要がなくなり最高に便利です。
新しくリポジトリを作成する時や過去のプルリクエストの検索の際などに、いちいちブラウザを開いて集中力を途切れさせる必要はありません。そのままエディタ、ターミナルと向き合えば良いのです。

こちらに主要コマンドをまとめているのでご参照ください。

以上。
GitHubブログ ←参照

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-12-18T15:17:12+09:00

社内gitサーバで、kerberosベースのシングルサインオンを実現する

いっそ SaaS とかに移行したいところだが、社内規定と先立つものが……。

要点

  • Active Directory環境でパスワード不要のgitサーバを立てました。
  • apache で spnego認証ならmod_auth_gssapi が推奨らしい。
  • docker 使いました。ソースは github にアップしてあります 1

きっかけ

　今まで社内gitサーバの認証には、BASIC認証 + LDAP(Active Directory)を使用していました。Windowsクライアントでgitサーバに接続するとID/パスワードは「資格情報マネージャ」に保存されます。

　一度保存してしまえばID/パスワードを聞かれることはないのですが、社内のポリシーではパスワードの定期変更が必要です。
　パスワード相違のときは新しいパスワード入力を促すという仕組みなら、それほどストレスは感じなかったでしょう。しかし現状ではgitは認証エラーが発生したら、新しいID/パスワードを聞くこともなく終了してしまいます。

パスワード変更の都度、資格情報マネージャから認証情報を削除しないといけない。

めんどくさい。良い感じにシングルサインオンできないだろうかといろいろ調べました。2

環境

インフラ関連

役割 バージョン
ドメインコントローラー Windows Server 2019 Standard
gitサーバ docker desktop 2.4.1.0
クライアント Windows 10 Pro 1909
gitクライアント git for windows 2.29.2.windows.3

git for windows ではインストール時に認証を補助する「資格情報ヘルパー」を選択します。git 2.29 では Git Credential Manager Core がデフォルトになっているので今回はこれで確認しました。

Active Directory関連

項目
Active Directory ドメイン hoge.local
ドメインコントローラ pdc.hoge.local
レルム HOGE.LOCAL
チケット検証ユーザ krbuser01
gitサーバ名 gitsrv.hoge.local
gitを使用するユーザ user01

チケット検証ユーザは、ドメイン管理者に作ってもらいます。ただのドメインユーザです(gitサーバではなく、Active Directoryに作ります)。

Apache で spnego認証を実現するまで

そもそも spnego認証とは何か?

SPNEGO (読み方:スプネゴ) とは Simple and Protected gss-api NEGOtiation mechanism の略で、Microsoft が作成した SSO のためのプロトコルです。GSS-API の上で動作します。
GSS-API は (http, ldap, smtp, pop3, imap4 等の認証が必要な) 通信プロトコルの種類に依存せず、全ての通信プロトコル間で SSO を実現するためのフレームワークです。GSS-API では枠組みだけですので具体的な実装が必要です。その実装の 1 つが SPNEGO なのです。

【図解】初心者にも分かるKerberos認証とspnegoの仕組み ～SSOのシーケンス,統合windows認証について～ より。

今回の構築、このページにお世話になりました。GSS-APIの実装で、HTTPに特化したのが spnego (という認識で良いんですよね？)

spnego認証の設定は「 ApacheでActive Directory SSO 」を参考にしましたが、別のサイトでapacheのモジュールとしては、記事中で使用されている mod_auth_kerb ではなく mod_auth_gssapi を推奨していました。 Apache2-mod_auth_kerb Is Dead, Use Mod_auth_gssapi だそうです。

mod_auth_kerb 本家のメンテナンスはだいぶ前に止まっているらしい(各ディストリビューションではメンテされていると思いますが)のに比べ mod_auth_gssapi は

  • github で開発されていて設定値の説明がわかりやすい。
  • 開発も活発な模様。
  • debian(buster)でも パッケージ化 されている。

と良さそうだったのでこちらを使うことにしました。

Active Directory上の準備

  • gitサーバにから Active Directory に問い合わせるためのユーザが必要です。ドメイン管理者にユーザを作成してもらってください。
  • 作成されたユーザ名でkeytabファイルを作成します。このファイルは gitサーバで使用します。

ユーザの設定

Set-ADUser krbuser01 -KerberosEncryptionType AES256,AES128,RC4

# 内容確認
Get-AdUser krbuser01 -property MsDS-SupportedEncryptionTypes

keytab作成

ktpass -princ HTTP/gitsrv.hoge.local@HOGE.LOCAL -mapuser krbuser01@hoge.local -pass xxxxxx -crypto All -ptype KRB5_NT_PRINCIPAL -out kerberos.keytab  2> log

# 内容確認
Get-ADUser krbuser01 -property msDS-KeyVersionNumber

# 内容確認
dsquery * "CN=krbuser01,DC=hoge,DC=local" -attr msDS-KeyVersionNumber

# 内容確認
setspn -q 'HTTP/*' krbuser01

検証(gitサーバ構築後)

  • gitサーバ構築後、以下のような形で keytabファイルの挙動を確認できます。(Windows上で確認する方法がわからない……)
$klist -ke -t /etc/kerberos.keytab

Keytab name: FILE:/etc/kerberos.keytab
KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
  23 01/01/70 00:00:00 HTTP/gitsrv.hoge.local@HOGE.LOCAL (des-cbc-crc)
  23 01/01/70 00:00:00 HTTP/gitsrv.hoge.local@HOGE.LOCAL (des-cbc-md5)
  23 01/01/70 00:00:00 HTTP/gitsrv.hoge.local@HOGE.LOCAL (arcfour-hmac)
  23 01/01/70 00:00:00 HTTP/gitsrv.hoge.local@HOGE.LOCAL (aes256-cts-hmac-sha1-96)
  23 01/01/70 00:00:00 HTTP/gitsrv.hoge.local@HOGE.LOCAL (aes128-cts-hmac-sha1-96)

$ kinit -V -k -t /etc/kerberos.keytab HTTP/gitsrv.hoge.local

Using default cache: /tmp/krb5cc_0
Using principal: HTTP/gitsrv.hoge.local@HOGE.LOCAL
Using keytab: /etc/krb5.keytab
Authenticated to Kerberos v5

参考

Git サーバの設定

kerberos の設定

  • krb5.conf に Active Directory のドメイン構成を記載します。
[libdefaults]
  default_realm = HOGE.LOCAL

# The following krb5.conf variables are only for MIT Kerberos.
  kdc_timesync = 1
  ccache_type = 4
  forwardable = true
  proxiable = true

  fcc-mit-ticketflags = true

[realms]
HOGE.LOCAL = {
  kdc = pdc.hoge.local
  admin_server = pdc.hoge.local
  default_domain = hoge.local
}

[domain_realm]
.hoge.local = HOGE.LOCAL
hoge.local = HOGE.LOCAL

apache の設定

git サーバとしてとりあえず、 git-http-backend を使用します。

ServerName gitsrv.hoge.local:80

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/

    SetEnv GIT_PROJECT_ROOT /var/lib/git/
    SetEnv GIT_HTTP_EXPORT_ALL
    ScriptAlias /git /usr/lib/git-core/git-http-backend

    RewriteEngine On
    RewriteCond %{QUERY_STRING} service=git-receive-pack [OR]
    RewriteCond %{REQUEST_URI} /git-receive-pack$
    RewriteRule ^/git/ - [E=AUTHREQUIRED]

    <Files "git-http-backend">
      AuthType GSSAPI
      AuthName "GSSAPI Auth"
      GssapiAllowedMech krb5
      GssapiCredStore keytab:/etc/kerberos.keytab

      Require valid-user
    </Files>

    <Location /gssapi-test>
      AuthType GSSAPI
      AuthName "GSSAPI Auth"
      GssapiAllowedMech krb5
      GssapiNegotiateOnce On
      GssapiCredStore keytab:/etc/kerberos.keytab
      Require valid-user

      AllowOverride None
      AddHandler cgi-script .cgi
      Options ExecCGI MultiViews SymLinksIfOwnerMatch
    </Location>

    ErrorLog /opt/log/error.log
    CustomLog /opt/log/access.log combined
    LogLevel Debug
</VirtualHost>

問題が発生したときの切り分けのため、ブラウザで認証の状況が確認できるように CGIスクリプトを用意しました。

#!/usr/bin/perl

print "Content-type: text/html\n\n";
print "<table>\n";

for $key (sort(keys(%ENV))) {
    print "<tr><td>$key</td><td>$ENV{$key}</td></tr>\n";
}

print "</table>\n";
exit;

ブラウザで接続テスト

クライアントのチケットを全て削除して接続。

PS > klist purge

Current LogonId is 0:0x115ad2d
        Deleting all tickets:
        Ticket(s) purged!

ブラウザで http://gitsrv/gssapi-test/env.cgi にアクセスして画面にズラズラと環境変数が表示されれば成功です。

AUTH_TYPE   Negotiate
CONTEXT_DOCUMENT_ROOT   /var/www/
CONTEXT_PREFIX  
DOCUMENT_ROOT   /var/www/
GATEWAY_INTERFACE   CGI/1.1

中略

REMOTE_USER user1@HOGE.LOCAL
REQUEST_METHOD  GET

後略

認証の成功を確認した後、クライアントでチケットを確認してみましょう。

PS> klist

Current LogonId is 0:0x115ad2d

Cached Tickets: (2)

#0>     Client: user1 @ HOGE.LOCAL
        Server: krbtgt/HOGE.LOCAL @ HOGE.LOCAL
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
        Start Time: 12/17/2020 15:37:43 (local)
        End Time:   12/18/2020 1:37:43 (local)
        Renew Time: 12/24/2020 15:37:43 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x1 -> PRIMARY
        Kdc Called: pdc.hoge.local

#1>     Client: user1 @ HOGE.LOCAL
        Server: HTTP/gitsrv.hoge.local @ HOGE.LOCAL
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        Start Time: 12/17/2020 15:37:43 (local)
        End Time:   12/18/2020 1:37:43 (local)
        Renew Time: 12/24/2020 15:37:43 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: pdc.hoge.local

きちんとチケットが取得できています。

そしてgitで接続テスト

gitサーバ側の準備

一つ、空のBareリポジトリを作成しておきます。

$ mkdir fuga.git
$ cd fuga.git
$ git init --bare

git クライアントの準備

git の設定として以下の設定をしておく必用があるようです

git config http.emptyAuth true

いよいよ clone

PS> git clone http://gitsrv.hoge.local/git/fuga.git
Cloning into 'juroku-redmine'...
warning: You appear to have cloned an empty repository.

できました!! (空のリポジトリをクローンしているので警告がでています)

ハマったこと

　最初、ブラウザの接続は成功するけど、git clone は失敗する、という問題でハマりました。原因は git の URL指定時に、http://gitsrv/git/fuga.git とだけ書いて hoge.local を抜かしていたのが原因でした。

　ブラウザでの確認のときは、 http://gitsrv/gssapi-test/env.cgi で接続が成功していたのですが、gitはそうした接続には対応していない模様。

　当初は原因が分からず頭を抱えていましたが、接続後に klist コマンドで出力されるチケットの Server の項を確認して問題に気づきました。

その他

git kerberos 等で検索していると、git clone 時に URLに :@ を挟め (今回の例でいくと http://:@gitsrv/git/fuga.git) ということが書かれたりしていますが、今は不要なようです。

未確認事項

gitサーバが動いているホスト上でログインしようとすると kerberos認証ができず、basic認証のプロンプトが表示されてしまいます。他のクライアントから接続する場合は問題ありません。日常の使用に問題がないのであまり深追いしていませんが、kerberosの仕様かなにかでしょうか。もしご存じの方がいらっしゃれば教えて下さい。

  1. 設定に mitamae を使用しているのでアーキテクチャはamd64限定です。 ↩

  2. パスワードの定期変更を止めてもらうという社内政治はもっとめんどくさそうなので断念 ↩

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-12-18T13:12:22+09:00

git init から git pushまでの流れ

いつも新しいアプリを作成した時に、Gitのリポジトリを作成からGit上でpushできるようにするまでの設定でつまずくので、整理していきたいと思います。
初心者なので、間違いがあったらご指摘いただけると幸いです！

①GitHub上で新しくリポジトリを作成

自分のGitHubページ→「Repositories」のページへ行き、右上の青いボタン「New」で新しくリポジトリが作成できます。
WS000000.JPG
「Repository name」の部分にリポジトリ名を入力し、下の「Create Repository」をクリック。

今回はほかの項目はとくに触らずにいきます。
他の人に見られたくなかったら「Private」にポチつけます。

②GitHubとローカルリポジトリを紐づける

WS000000.JPG

こんな画面が出てくるので、Gitをローカルリポジトリのところで立ち上げて、「…or create a new repository on the command line」のところに書いているgit initから始めて上からコマンドを入力していきます。
echo "# test" >> README.mdのところは、やってもやらんでもどっちでも！って感じです。笑

Git
$ git init
Git
$ git add README.md

ここはgit add -Aにすれば一括でaddできます

Git
$ git commit -m "first commit"

ここもfirst commitの部分は自分の好きなコメントに変えてもOK

Git
$ git branch -M main
Git
$ git remote add origin https://github.com/GitHubのユーザー名/リポジトリ名.git

これでGitHubと、ローカルのGitを紐づける設定をするイメージです。

Git
$ git push -u origin main

これで設定が完了しました！

ローカルリポジトリを更新したら

履歴を残すためにも、更新したらgit pushするというのを癖づけておきたいところです。

Git
$ git add 〇〇

〇〇の部分はpushしたいファイル名です。
先ほどと同じく、git add -Aと打てば全ファイルが一括でaddされます。
（しかも変更がある分だけアップされるという。素晴らしい！！）

Git
$ git commit -m"コメント"

ダブルクォーテーションの中に自分の好きなコメントを入れます。
色々コメントの書き方とかあるみたいですが、ここでは割愛します。

Git
$ git push origin main

main のところは masterだったりするみたいです。
昔はmasterだったけど、色々あり　今はmainなのかな？

これでpushできました～！

まとめ

私はやり方を教えていただいたのですが
教えていただく前に自分一人でやっても全くわかりませんでした。。
なんかどの記事みても、Git分かってる前提でお話されてるので（こらっ！）

私のような初心者の皆さんのお役に立てばいいな・・・！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-12-18T09:22:30+09:00

WindowsのGitの改行コード自動変換を無効にする

背景

Windowsにgitをインストールしてgithubからリポジトリをクローンしたら
改行コードがLFからCRLFに変換されて困った。
どうやらGit for Windowsをデフォルト設定でインストールすると
チェックアウトするとき改行コードLFをCRLFに自動変換してしまうらしいので
自動変換されないように設定する。

環境

Windows 10
git version 2.28.0.windows.1

改行コード自動変換を無効にするコマンド

git config --global core.autocrlf false

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-12-18T09:22:30+09:00

WindowsのGitの改行コード自動変換設定

背景

Windowsにgitをインストールしてgithubからリポジトリをクローンしたら
改行コードがLFからCRLFに変換されて困った。
どうやらGit for Windowsをデフォルト設定でインストールすると
チェックアウトするとき改行コードLFをCRLFに自動変換してしまうらしい。

環境

Windows 10
git version 2.28.0.windows.1

改行コード自動変換設定

改行コード自動変換を無効にする

git config --global core.autocrlf false

改行コード自動変換を有効にする

git config --global core.autocrlf true

コミット時だけ改行コード自動変換する

git config --global core.autocrlf input

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-12-18T04:28:55+09:00

Git Hooksのpre-commitを用いて望まないコミットを未然に防ぐ

本記事はDeNA 21 新卒 Advent Calendar 2020の22日目の記事です。

はじめに

こんにちは、@7riatsuです。

突然ですが、皆さんは自分の意図しないコードをGitHubにプッシュしてしまった経験はありませんか？
僕はあります。それも人に見られると恥ずかしいような内容でした。

プログラムの動作確認時に出力を目立たせるため、以下のコードを書いていました。

test.rb
puts "?"
puts hoge #検証したい変数

hoge に適切な値が入っていることを確認したので、コミットをしてGitHubにプッシュし、レビューを依頼したところで悲劇は起きました。

「?がプッシュされているよ」

あろうことか、レビューを依頼する前に動作確認用に仕込んでいた不要な行をコミットしていたのでした。
その他にもデバッグ目的で仕込んだ console.log や binding.pry を誤ってコミットしてしまうことが多々ありました。
このような単純なミスは「レビュー前に確認をするべき」の一言で片付けるのではなく、仕組みで防ぎたいところです。

そこで今回は、Git Hooks の pre-commit を利用して、自分の意図しない不要な行のコミットを防ぐ方法をご紹介します。

Git Hooks とは

Gitの特定のアクションが発生した時にスクリプトを起動するもの。
クライアントサイドとサーバーサイドの二つのhooksに大別される。

  • クライアントサイドフック: commit や merge の際にトリガーされる
  • サーバーサイドフック:push 前後にトリガーされる

今回紹介する pre-commit はクライアントサイドフックに属する。

pre-commit とは

コミット実行時に一番最初に実行されるもの。
主な利用用途としては以下が想定される。

  • コミットしようとしているコードの検証
  • テストの実行をローカルで確認
  • コードスタイルチェック(lintなど)

更に詳しく知りたい方はGit公式ドキュメントを参照してください。

pre-commitの導入手順

それでは実際に pre-commit を動かすための準備をしていきましょう。

1. 下準備

# テスト用のディレクトリ作成
mkdir pre-commit-test
cd pre-commit-test

# gitの初期化
git init # このコマンドで後に使う.git/hooks/pre-commitが作成される

2. pre-commitのスクリプトを作成

以下のコードを .git/hooks/pre-commit にコピペしてください。

#!/bin/sh

# commitに含めたくないワードをスラッシュとパイプで区切って追加する
LIST="puts\|binding.pry\|console.log"

if git rev-parse --verify HEAD >/dev/null 2>&1; then
  against=HEAD
else
  against=4b825dc642cb6eb9a060e54bf8d69288fbee4904
fi

for FILE in `git diff-index --name-status --cached $against -- | cut -c3-` ; do
  if grep -w $LIST $FILE; then
    echo $FILE." has one of the word you don't want to commit. Please remove it"
    exit 1
  fi
    done
exit

※こちらの記事を参照

コミットしたくないワードを追加する場合、スラッシュとパイプで区切って LIST= の行に記載してください。
例えば新たに debugger を追加するなら、以下のように変更します。

LIST="puts\|binding.pry\|console.log\|debugger"

3. 追加したスクリプトに実行権限を付与

chmod +x .git/hooks/pre-commit

1~3の手順で準備は完了しました。
それでは早速、 pre-commit が動くかどうかを検証してみましょう。

検証

今回は例としてRubyのスクリプトを検証します。
もちろん、他のプログラミング言語で書いたスクリプトに対しても動作します。

まずは puts を含んだRubyのスクリプトを準備します。

main.rb
a, b = 1, 2

c = a + b
puts c
# => 3

次に main.rb をコミットしてみましょう。

git add main.rb
git commit -m 'putsを含む足し算を追加'
# puts c
# main.rb. has one of the word you don't want to commit. Please remove it

確かにputsを含んでいるのでコミットに失敗しました。

次はmain.rbからputsを除いてコミットしてみましょう。

main.rb
a, b = 1, 2

c = a + b

git add main.rb
git commit -m 'putsを含まない足し算を追加'
# [master (root-commit) b824f3b] putsを含まない足し算を追加
#  1 file changed, 3 insertions(+)
#  create mode 100644 main.rb

今度は正常にコミットをすることができました。

また、以下のコマンドでhooksをトリガーさせずにコミットすることも可能です。

git commit --no-verify

終わりに

特に他の人にレビューを依頼している場合、単純な指摘ではなく、もっと重要な指摘に時間を割いてもらうために、こういったミスは極力したくありません。
単純なミスは積極的に仕組みで防いでいきましょう！

宣伝

この記事を読んで「面白かった」「学びがあった」と思っていただけた方、よろしければ Twitter や facebook、はてなブックマークにてコメントをお願いします！
また DeNA 公式 Twitter アカウント @DeNAxTech では、 Blog記事だけでなく色々な勉強会での登壇資料も発信してます。ぜひフォローして下さい！
Follow @DeNAxTech

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-12-18T02:30:51+09:00

git rm コマンドについてのメモ【初心者用】

参加しているプログラミングスクールで、プログラムをpushした際に、あるファイルが余分なので削除してくださいとの話になった。
その時に、git rmコマンドが出てきたので、気になったので調べてみた。

git rm コマンドを実行すると？？

git rm[ファイル名]

コマンドを実行すると、ワークツリーとインデックスからファイルが削除され、git commit時にはリポジトリにファイルが削除された事が記録される。

  • ワークツリーとは？
    自分のパソコンで作業してる場所のこと

  • インデックスとは？
    自分のパソコンから一時的にファイルを預けておくような場所

  • リポジトリとは？
    Githubのようなオンラインでファイルを保管してくれるような場所

git rm --cachedとは？

git rm --cached [削除したいファイル]

を実行すると、実際のファイルを残したまま、Gitの管理対象から外すことができます。
僕の使っているテキストエディタ「VScode」では、ファイルは残っているものの、ファイル名がグレー色になっていました。
ファイルを残した場合は.gitignoreを追記しないといけないようですが、これはまた今度調べたいと思います。

git rm -rｆ --cachedとは？？

git rm -rf --cached [削除したいファイル]

今回プログラミングスクールで使用したコマンドはコレです。
.vscodeディレクトリの中にlunch.jsonというファイルが含まれており、.vscodeディレクトリ全てを削除したいという流れでした。

はじめ、git rm -f --cachedを実行した所、ターミナルで
fatal: not removing '.vscode' recursively without -r
と怒られました。

「git rm -f --cachedではディレクトリは削除できませんよ！」ということですかね。
最終的に、
git rm -rf --cachedを使い、無事にディレクトリと中のファイルごと削除する事ができました。

参考

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

日付別

タグ一覧