20191215のGitに関する記事は8件です。

jenkinsとgitつなげる

https://open-groove.net/jenkins/tomcat-maven-git/

ls -l /usr/local/jenkins/plugins 以下に

・git.hpi
・git-client.hpi
・scm-api.hpi

があるのを確認

プロジェクト 設定

ソースコードの管理

✓ Git
・Repository URL
http://192.168.10.xx:8080/gitbucket/git/root/test.git
(gitbucketで設定されたURL)
・Credentials なし
以下デフォルト

手動で実行

## 以下動かない? 

/root/test/.git/hooks
ができるので

vi post-receive


!/bin/bash

curl -X POST http://192.168.10.xx:8090/jobs/app-test-job/builds


参考

https://ics.media/entry/3283
JenkinsでCI環境構築チュートリアル ~GitHubからWebサーバーへのデプロイ~

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

Git for Windowsでautocrlfの設定を間違えちゃった時の対応

この記事は ZOZOテクノロジーズ #5 Advent Calendar 2019 16日目の記事です。
昨日は @meganekids さんによる「エンジニアとプロジェクトマネージャー向けのAdobe XD勉強会で意識した4つのこと」でした。
別職種の人とのコミュニケーションを円滑にするための知識の土台作りはとても大事だと思うので、アフターケアを含め取り組む姿勢がとても素敵だと思いました。

本記事はWindowsではまりがちなgitの改行コード自動変換機能のお話です。

背景

私が所属しているMA(マーケティングオートメーション)チームではWindows ServerとLinuxのサーバを両方使って開発をしています。
Windowsでしか動かないVBScriptやLinuxでよく使うシェルスクリプトを両方扱っており、文字コードや改行コードに配慮しないと問題が発生してしまう、とてもエキサイティングな職場です。
(文字コードについてはこちらの記事に書いてますので興味があればどうぞ > Qiitaの記事)

改行コードについてはgitにautocrlfという自動変換してくれる機能があり、上手く使えば便利です。
しかし、この機能がONになっていると、commitログとファイルシステムが認識している実態に乖離が生じてデプロイ結果が期待と異なるケースがありえます。

Git for Windowsは親切なことに、インストール時にautocrlfの設定を任意で選択することができます。

スクリーンショット 2019-12-15 16.38.47.png

一番上の設定にすると、autocrlf=trueという設定になり、改行コードの自動変換が有効になります。
ここで選択できるのは良いのですが、その後悲しいことにGUIでは設定変更ができません(やり方あれば教えて欲しい)。

間違えてautocrlfがtrueになってしまったら、gitのコマンドを駆使してゴニョゴニョする必要があったので、そのときの対処法をまとめようと思います。操作自体は簡単なので、周辺知識の整理的な意味合いが強いです。

環境

この記事はWindows10を使っていてかつ、gitの環境をGit for Windowsでインストールした環境を想定しています。
Git for Windowsのバージョンによる差異は後ほど記述しますが
v2.19(私が最初インストールしたもの)とv2.24(記事作成時最新)が登場します。

autocrlf

改行コードは利用するOSによって標準で利用するものが異なります。
特にWindowsではCRLF, MacではLFが標準で利用されます。

サーバをLinuxOS上で動かしていれば、何かしらのシェルスクリプトを利用することはよくあると思いますが、
シェルスクリプトの改行コードがCRLFになっていると困るため、gitの設定にautocrlfという改行コードを自動変換する機能があります。

これはgitでcommitした時とcheckoutした時に自動的に改行コードを変換する仕組みです。
要は作業中の改行コードとcommitログとして記録される改行コードをシステム的に固定する機能のことです。

基本的にWindows Serverを使っているような環境(CRLFが必要な環境)で開発しているのであれば、autocrlfはfalseにすべきだと思います。
autocrlf=trueは最終的にgitに記録する改行コードをLFに固定化する時に使う設定なので、LF以外を駆逐するときに利用しましょう。

下記のgitのドキュメントのcore.autocrlfの項目に記載があるので、そちらを参照してください。
https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA-Git-%E3%81%AE%E8%A8%AD%E5%AE%9A

gitの設定はgit configというコマンドを使って変更が可能ですが、その際環境が3つある点に注意が必要です。

  • system: gitのシステム全体に適用される設定
  • global: ホームディレクトリ直下の設定ファイルを見るため、ユーザ単位で全適用される設定
  • local: gitで管理しているレポジトリの.git配下の設定ファイルを見る、レポジトリ単位の設定

それぞれ --system, --global, --local とオプションを指定して利用できます。

現在gitのconfigがどのファイルによって何に設定されているかは下記のコマンドでみるとわかりやすいです。

git config --show-origin core.autocrlf

--show-originをつけることで、どのファイルによる設定されているかがわかります。

ここが重要なポイントですが、gitの設定ファイルは
local > global > systemの順で優先されます。

個別に設定した内容は優先して適用されるようです。

git config --helpで出力されるドキュメントの中には下記のように書いてます。優先度については特に記述はないですが、一応載せておきます。

When reading, the values are read from the system, global and repository local configuration files by default, and options --system, --global, --local and --file <filename> can be used to tell the command to read from only that location (see the section called "FILES").

Git for Windowsによる自動設定

ここで実際にインストール時の設定がどのように反映されるのか見て行きます。

Git for Windowsはインストール時にautocrlfの設定を選ぶことができます。
この時しっかり理解して設定していればきっと問題は起きないでしょう。

もう一度インストール時の画面です。
スクリーンショット 2019-12-15 16.38.47.png

ここで一番上の選択肢を選ぶと、autocrlf=trueな環境のgitが完成します。

設定内容を確認します。

インストール直後はこうなります。

v2.24
$ git config --show-origin core.autocrlf
file:C:/Program Files/Git/etc/gitconfig true
v2.19
$ git config --show-origin core.autocrlf
file:"C:\\ProgramData/Git/config"       true

バージョンによって設定ファイルは異なりますが、このような設定になります。

Git for windowsのリリースノートによると v2.23へのアップデートよって設定ファイルの配置場所が変わったようです。

Note! As a consequence of making git config --system work as expected, the location of the system config is now C:\Program Files\Git\etc\gitconfig (no longer split between C:\Program Files\Git\mingw64\etc\gitconfig and C:\ProgramData\Git\config), and likewise the location of the system gitattributes is now C:\Program Files\Git\etc\gitattributes (no longer C:\Program Files\Git\mingw64\etc\gitattributes). Any manual modifications to C:\ProgramData\Git\config need to be ported manually.

設定の変更方法

環境毎に説明します。

local

とにかくこのレポジトリだけ対応したい。ということであれば下記の方法でlocalの設定を更新します。

git config --local core.autocrlf false

すると、設定値が下記のようのなります

$ git config --show-origin core.autocrlf
file:.git/config        false

これにて特定レポジトリに対する設定は完了です。
一番手軽で、影響範囲が少ないです。

global

基本的にautocrlfがfalseでよければこちらの方がまだ良いでしょう。

git config --global core.autocrlf false

--localに設定されていなければ、下記の表示になります。

$ git config --show-origin core.autocrlf
file:C:/Users/{username}/.gitconfig false

system

根本的に変えたいならこちらの設定を変えましょう。こっちを変えたほうが安心です。
しかし、こちらは権限の問題があるので、Git Bashを「管理者として実行」で起動させてからコマンドを実行する必要があります。

git config --system core.autocrlf false

その結果、v2.19ではなぜか別ファイルが作られます。なんでやねん。

$ git config --show-origin core.autocrlf
file:C:/Program Files/Git/mingw64/etc/gitconfig false

C:\\ProgramData/Git/configには true で設定されていますが、C:/Program Files/Git/mingw64/etc/gitconfigのfalseが優先されるようです。

こうなるならC:\\ProgramData/Git/configを手で書き換えた方が気分がいいですね。

ただ、v2.24では同じファイルが上書きされたので、新しいの使った方が綺麗に修正できます。

Git for Windowsが古い場合はv2.23以降のバージョンにアップデートして、その時autocrlfをfalseにする設定でインストールするが綺麗かもしれません。

再インストール

これでもいいです。
スクリーンショット 2019-12-15 16.38.55.png

一番下のラジオボタンを選べば、autocrlf=falseの状態でsystemのconfigが作られます。

最後に

今回もWindows環境と向き合う記事でした。バージョンの違いによる挙動の違いは結構混乱の元だと思うので、その辺を整理できてよかったです。
普段Macを使っているからという理由で億劫になりがちな問題ですが、CRLFな改行コードが必要な世界もあるということを理解しておくことは、開発をする上で大事なことだと思うのでこれからも立ち向かっていきたいですね。

明日は @satto_sann による記事なので、そちらもぜひご覧ください〜

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

【SourceTree】SourceTreeでBranchしてPushができなかった為、Git Bashで対応した

環境

SourceTree
Windows 10
Git Bash

SourceTreeにてBranchを追加してPush

The リモートブランチ '' (ローカルブランチ = 'hoge/fuga') is invalid. Ref names must follow git ref-format rules: 
https://www.kernel.org/pub/software/scm/git/docs/git-check-ref-format.html
エラー終了しました。エラーの内容は上記をご覧ください。

 →リモートブランチが空白になっている(未作成だから?)

Git Bashで単純なgit push実行

$ git push
fatal: The current branch hoge/fuga has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin hoge/fuga

 →upstreamでないため実行コマンドを提示された

--set-upstreamを付加してコマンド実行

$ git push --set-upstream hoge/fuga master
fatal: 'hoge/fuga' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

 →だめでした...

-u(追跡オプション)をつけてコマンド実行

$ git push -u origin hoge/fuga

 →push成功!

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

?【SourceTree】SourceTreeでBranchしてPushができなかった為、Git Bashで対応した

環境

SourceTree
Windows 10
Git Bash

SourceTreeにてBranchを追加してPush

The リモートブランチ '' (ローカルブランチ = 'hoge/fuga') is invalid. Ref names must follow git ref-format rules: 
https://www.kernel.org/pub/software/scm/git/docs/git-check-ref-format.html
エラー終了しました。エラーの内容は上記をご覧ください。

 →✖リモートブランチが空白になっている(未作成だから?)

Git Bashで単純なgit push実行

$ git push
fatal: The current branch hoge/fuga has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin hoge/fuga

 →✖upstreamでないため実行コマンドを提示された

--set-upstreamを付加してコマンド実行

$ git push --set-upstream hoge/fuga master
fatal: 'hoge/fuga' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

 →✖だめでした...

-u(追跡オプション)をつけてコマンド実行

$ git push -u origin hoge/fuga

 →?push成功!

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

GitHubチートシート

gitでUntracked filesを削除する

マージにおいて片方のファイルをそのまま取り入れる

2つのブランチ間でコンフリクトしているファイル fileA.txt と fileB.txt があるとする

# fileA.txt を現在チェックアウトしているブランチ側の対応に合わせる場合
$ git checkout --ours fileA.txt
$ git add fileA.txt    # add を忘れずに

# fileB.txt をマージさせたブランチ側に合わせる場合
$ git checkout --theirs fileB.txt
$ git add fileB.txt

$ git commit

https://qiita.com/shisho/items/c1075d394f1edf1a5928

git resetを取り消す

git addのを取り消す

# 全てのファイルを取り消し
$ git reset HEAD
# 特定のファイルのみ取り消し
$ git reset HEAD file_name
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

git pullは使わない?

周りにあまりgit pullを使っている人がいなそうだったので、調べてみた

git pullを使って考慮すること

git pullをすると、簡単な操作でリモートのブランチの変更差分をローカルのブランチにマージしてくれる。そのため、中では複雑な操作が流れている。細かい挙動を把握することはとても大変

git pullを使わない場合

・git push アップロード
・git fetch ダウンロード
・git merge 統合

git pullを意識しないことで、シンプルに頭の中で考えられる。
gitの操作について、細かく意識できる。

なれてきてから、pullを使用する。

まとめ

理解しないで、つかうのは危険だと感じた。
僕は基本SourceTreeを使っていたが、変更差分をみるのをSourceTreeにして、コマンド操作になれるように変えて細かい挙動も意識していこうと思った。

参考にさせていただいたサイト

Git pullを使うべきでない3つの理由

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

パスワードを聞かれずにGitHubに接続する設定方法

概要

初めてGitHubにアカウントを作った人が、コマンドでリモートリポジトリにプッシュできることを確認するまでの手続きをメモします。

対象読者

  • 複数のGitホスティングサービスを使いたい
  • リモートリポジトリとのやりとりにパスワードを聞かれないようにしたい
  • Gitの使い方はある程度わかる
  • GitHubは初めて

想定環境

  • Gitはインストール済み(まだの方はこちらから)
  • ローカルPCはMac

手順

GitHub側で新規リポジトリ作成

右上のメニューから新規のリポジトリを作成する。
“ここに好きな文言を設定” 2019-12-14 15.38.07.png

Repository nameにリポジトリ名を記入し、Create Repositoryで新規作成
“ここに好きな文言を設定” 2019-12-14 15.44.09.jpg

以下の画面に移るので、赤枠URLを覚えておく。
(特にSSHが選択されていることを確認。HTTPだと公開鍵登録したあとの通信がうまくいかない)
“ここに好きな文言を設定” 2019-12-14 15.53.09.jpg

ローカルに鍵を生成

$ ssh-keygen -t rsa -f ~/.ssh/github -C "適当なコメント"
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): (そのままEnterキーを押す)
Enter same passphrase again: (そのままEnterキーを押す)

【任意】秘密鍵の方をわかりやすくリネームしておく

$ mv ~/.ssh/github ~/.ssh/github.pem

秘密鍵のパーミッション変更

$ chmod 600 ~/.ssh/github.pem

Gitの接続設定

接続情報を追記する。

  • ここの設定で各Gitホスティングサービスの鍵情報を個別に設定することによって、プッシュ時に自動で接続情報を切り替えてくれるようになる。
  • Hostは任意でいいかと思って適当なものを入れていたが、接続に失敗した。注意。
$ vim ~/.ssh/config

Host github.com (※絶対これ)
    HostName github.com (※絶対これ)
    IdentityFile ~/.ssh/github.pem
    TCPKeepAlive yes
    IdentitiesOnly yes
    User git (※絶対これ)
    Port 22

GitHubに公開鍵を登録する

ローカルの公開鍵を確認+クリップボードへコピー
(catコマンドででてきた長い文章を頭から全てコピーしておく。ターミナルでは折り返しで表現されているかもしれないが、実物は長いひとつながりの一文のデータ。コピー時に改行コードが混ざるとうまく繋がらないので注意。)

$ cat ~/.ssh/github.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAB...... 

GitHubに戻って、右上メニューからSettingsを選択
“ここに好きな文言を設定” 2019-12-14 16.11.24.jpg

左メニューより「SSH and GPG keys」を選択し、右上緑色の「New SSH Key」を選択。
“ここに好きな文言を設定” 2019-12-14 16.17.20.jpg

接続確認する。

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

$ mkdir ~/githubtest
$ mkdir ~/githubtest/gittest/
$ cd ~/githubtest/gittest/
$ echo "Hello Git" >> test.md
$ git init

コミットし、リモートへ接続。

$ git add test.md
$ git commit -m "initial commit"
$ git remote add origin git@github.com:mu-editech/GitHubTestRepo.git
$ git push -u origin master

GitHubへ戻って、以下のような画面がでれば接続成功。

“ここに好きな文言を設定” 2019-12-14 17.33.56.png

おしまい。

参考文献

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

Jenkins Declarative pipelineでSlackにGitのコミットログも通知する

小ネタ。Groovy大好き。

Jenkinsfile内で以下のメソッドを書いておいて、 pipeline ブロック内で toSlack(channnel: "hoge-channnel", tokenCredentialId: "hoge-token") とすれば使える。

def toSlack(Map args) {
    def changeMsgs = []
    currentBuild.changeSets.collect { it.items }.flatten().each { entry ->
        def commitDate = new Date(entry.timestamp).format("yyyy/MM/dd HH:mm")
        def author = entry.class.name == "hudson.plugins.git.GitChangeSet" ? "<mailto:${entry.authorEmail}|${entry.author.toString()}>" : entry.author.toString()
        changeMsgs << "・${commitDate}-> ${entry.msg} by ${author}"
    }

    slackSend(
        channel: args?.channel,
        tokenId: args?.tokenId,
        color: "good",
        message: changeMsgs.size() > 0 ? changeMsgs.join("\n") : "・なし"
    )
}

これぐらいの行数のスクリプトだったり、他のジョブと共通化したかったりすると、毎回書くのはツラいので、実際はJenkins Shared Library化してます。

なので、 slackSendcolor の部分もビルド結果を変換してたりします。

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