Sourcetreeをインストール

　Windows10でバージョン管理が必要となったので、簡単にGitも一緒にインストール出来る
Sourcetree をインストールしてみた。
　(いろいろ躓いたので、自分用のメモとして残したものです。)

スタートメニューにSourcetreeがいない！

　インストールして動作確認が終わり、再度、アプリを起動しようとすると、スタートメニューにSourcetreeがいない。
Windows初心者なので、少し焦りましたが、以下の場所にありました。(隠しファイルの中です。)

C:\Users\username\AppData\Local\SourceTree\SourceTree.exe

　ショートカットを作って、以下に移動します。(これも隠しファイルの中です。)

C:\ProgramData\Microsoft\Windows\Start Menu\Programs

　ちなみに、このフォルダに直接ショートカットを作成する事は出来ません。

コマンドプロンプトでGitが使えない？

　次にコマンドプロンプトでgit —-versionを入力してみるとエラーになりました。pathを設定してあげないといけないらしい。SourcetreeのGitは以下の場所にありました。

C:\Users\username\AppData\Local\Atlassian\SourceTree\git_local\bin\git.exe

　同じ場所にあったbash.exeでGitのバージョンを確認してみると2.24.1でした。(2020.6.1時点)
　Gitの脆弱性が明らかになっておりバージョンアップが必要でした。(CVE-2020-5260)

Windows10にGitをインストール

　今後のことも考えて本家からGitをインストールすることにします。(最初からこうすれば良かった。疲れた。)

　標準の設定でGitをインストール。ただし、テキストファイルの改行のスタイルを設定だけ、Macからも使いたいのでCheckout as-is, commit Unix-style line endings:(“input”)を選択しました。

　この後、Sourcetreeの「ツール」メニューの「オプション」から「git」タブを選択して「Use System Git」ボタンで切り替えておきました。

　もっと良いやり方があると思いますが、これでしばらく動かしていこうと思います。

WindowsでのGitアップデート方法

　コマンドプロンプト(またはgit bashかPowerShell)を起動して以下のコマンドを入力します。

$ git update-git-for-windows

　これは簡単！(なお、2.13以前は使えないようです。)

gitリポジトリの中にいるときに、トップレベルのディレクトリに移動したくなることがよくありますよね。前にそれを1回のコマンドでできるようにするzsh用のプラグインを作っていました。今回それをfishシェル用に移植したので紹介します。

このプラグインでできること

fish-cd-gitroot というプラグインを作りました。これをインストールすればcd-gitrootというコマンドが使えるようになります。fish-cd-gitrootという名前だけど入力するコマンド名はcd-gitrootであることに注意してください。

使っている様子はこんな感じです。

# /home/mollifier/git_repoがgitリポジトリとする
# その中に次のようにディレクトリがあったとする
# doc/
# src/
#   |-scripts/
#   `-web/

> cd /home/mollifier/git_repo
> cd src/web
> pwd
/home/mollifier/git_repo/src/web
# リポジトリの奥の方にいる時でも、すぐにトップに移動できる
> cd-gitroot
> pwd
/home/mollifier/git_repo

# 引数を指定するとリポジトリトップからの相対的なパスに移動できる
> cd /home/mollifier/git_repo/doc
> cd-gitroot src/scripts
> pwd
/home/mollifier/git_repo/src/scripts

# タブで相対的なパスが補完できる
> cd-gitroot [TAB]
doc/  src/
> cd-gitroot src/[TAB]
scripts/  web/

インストール

fisherというfishシェル用のパッケージマネージャーを使ってインストールしてください。

> fisher add mollifier/fish-cd-gitroot

これでcd-gitrootコマンドが使えるようになります。特に設定とかはありません。

コマンド名が長くて打ちにくいと思う人は、aliasを設定してください。たとえば、次のように設定するとcduというコマンド名で実行できるようになります。

# ~/.config/fish/config.fishにこれを書く
alias cdu='cd-gitroot'

本当は、aliasではなくfunctionとして定義するのがfishらしいやりかたです。というか、fishではaliasを設定すると内部ではfunctionが定義されます。

function cdu --wraps=cd-gitroot
  cd-gitroot  $argv;
end

このあたりは今回の件とは関係ないので一旦置いておきます。aliasでも問題はありません。

手動インストール

fisherを使っていない人でも、一応手動でもインストールできます。

まず準備として、もしまだなければ~/.config/fish/functions/と~/.config/fish/completions/という2つのディレクトリを作成します。

> mkdir -p ~/.config/fish/functions
> mkdir -p ~/.config/fish/completions

そのあと、fish-cd-gitrootリポジトリの内容をダウンロードして、その中のfunctionsディレクトリ内のファイルを~/.config/fish/functionsの中に、completionsディレクトリ内のファイルを~/.config/fish/completionsの中にコピーします。

この方法でもcd-gitrootコマンドが使えるようになります。

使い方

gitリポジトリの中に入って、cd-gitrootと打てばリポジトリのトップに移動できます。引数を指定していたら、それをリポジトリトップからの相対的なパスと解釈して移動します。引数のディレクトリはタブで補完できるので、リポジトリの奥の方にいる時でも簡単に他の場所に移動できます。

また、-hまたは--helpオプションでヘルプメッセージが見れます。

謝辞

このスクリプトを作成するにあたって、nil2さんのFish用の補完スクリプトの作り方という記事を参考にしました。みなさんもfishシェル用の補完ファイルを作るときは参考にしてください。

最後に

こういうディレクトリ移動系の処理は、外部コマンドでは実装できません。なのでシェルを乗り換えるとそのシェル用に再実装する必要があります。fishはbashやzshと少し文法が違っているので、fishのシェルスクリプトに慣れるための練習も兼ねて作成しました。便利なのでぜひ使ってみてください!

概要

下記図に示すようにAzure DevOpsの機能であるAzure Pipelineにて、別の組織にあるAzure Reps（Git）にプッシュする方法を共有します。同様の手順にて、異なるテナントのAzure DevOpsに対しても適応可能です。

事前準備

• 2つのAzure DevOps組織を作成すること
• それぞれの組織にて、プロジェクトを作成すること

手順

1. プッシュ先のプロジェクト（上記図における組織B）にて、"User Setting"→"Personal access tokens"を選択。

2 . "New Token"を選択

3 . 下記表の通りに入力し、"OK"を選択。表示されるアクセスキーを控えておいてください。

項目	設定値
Name	※わかりやすい名称を入力
Organization	※プッシュ先組織名を選択
Code	"Read & wire"をチェック

4 . "Pipelines"を選択後、"Create Pipeline"を選択。

5 . "Azure Repos Git"を選択。

6 . プッシュするレポジトリーを選択。

7 . "Stater pipeline"を選択。

8 . 下記コードを張りつけ、変数の値を設定

変数	値
TmpRepoDir	_repo
UserName	※コミットするユーザー名
OrganizationName	※プッシュ先の組織名
ProjectName	※プッシュ先のプロジェクト名
RepositoryName	※プッシュ先のレポジトリー名

# Starter pipeline
# Start with a minimal pipeline that you can customize to build and deploy your code.
# Add steps that build, run tests, deploy, and more:
# https://aka.ms/yaml
variables:
  TmpRepoDir: _repo
  UserName: ryoma.nagata
  OrganizationName: import-git
  ProjectName: import-git
  RepositoryName: repository-from-otherorganizationname

trigger:
- master

pool:
  vmImage: 'ubuntu-latest'

steps:
- script: |
     cd /tmp && rm -rf /tmp/$(TmpRepoDir)
     git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" clone --mirror $(Build.Repository.Uri) $(TmpRepoDir)
     git -C /tmp/$(TmpRepoDir) push --mirror https://$(UserName):$(secreat_repos)@dev.azure.com/$(OrganizationName)/$(ProjectName)/_git/$(RepositoryName)
  displayName: 'Copy to Azure DevOps Repos'

9 . 右上にある"Variables"を選択。

10 . "New variable"を選択。

11 . 下記の入力を行い、"OK"→"Save"を選択。

項目	値
Name	secreat_repos
Value	※3の手順で取得したトークンキーを入力する。
Keep this value secret	チェックする。

12 . 右上にある"Save and run"を選択。

13 . 適切な入力を行い、"Save and run"を選択。

14 . ジョブ完了後、プッシュ先のレポジトリーにコードが配置されていることを確認。

[最新のコミットのみ取得]
git clone --depth 1 https://github.com/git/git

gitで外付けHDDにリモートリポジトリを作成する

環境

rails 5.2.3
Vs code

基本的な解決法

多くの場合 config/application.rb
内に config.assets.initialize_on_precompile=false
の記述を加えればこの問題は解決される。

これ以外の場合

RAILS_ENV=production bundle exec rake assets:precompile
を行いどのファイルが悪さをしているのかを調べる

自分の場合 application.css の
@import="bulma";
が悪さをしており　これを削除したところdeployがうまくった
(うまくいったがbulmaを消したためビューが崩れてしまった。)

今回のエラー

git push heroku master　をすると
[remote rejected] master -> master (pre-receive hook declined)
と表示される

調べていったところ、bundler のバージョンが2 以降であると対応されていないそうだ。

解決策

$ gem uninstall bundler # bundlerをアンインストール

$ gem install bundler -v 1.17.3 # version明記

$ rm Gemfile.lock # Gemdile.lockがgemのversionを明記しているため、一旦削除

$ bundle install

$ git　関連の諸々 ,,,

$ git push heroku master

$ heroku run bash

$ rails db:migrate or $ bundle exec rails db:schema:load

で解決されると思います。

参考文献

https://github.com/rubygems/bundler/issues/6784

背景

• 自身ではコミット権がない, active に開発されている github にある repo を fork で追随している
  • llvm-project や, pytorch など
• 自前 fork repo にいろいろオレオレ改変を入れている
  • e.g. CI ファイルとか

毎回(e.g. 毎日) git pull するのも面倒なので, GitHub Actions で自動追随しようと思いました. 現状うまく行ってません.

cron

GitHub Actions では, cron で定期処理ができます.

トラッキングしたい upstream repo に変更があったら, fork 先に知らせるみたいな機能は無いっぽいようなので, cron で定期チェックしてみます.

時刻は UTC-0 基準のようです.

うまく動くか試すのに, 1 分単位とかでやったときに, エラーがでるとメール通知がすごいことになるのでご注意ください.

うまくいかない例

以下のような記述をしましたが, うまくいきませんでした.
(毎日 4:00 am に実行する)

通常 checkout だと, unrelated histories エラーがでるので, --allow-unrelated-histories をつけて見ましたが, 結局は conflict が発生してマージできませんでした.

name: sync with upstream

on:
  schedule:
    - cron: '* 4 * * *'

jobs:
  sync:

    runs-on: ubuntu-latest

    steps:
      - name: checkout
        uses: actions/checkout@v2
      - name: sync
        run: |
          git config --global user.email "dummy@dummy.com"
          git config --global user.name "github actions"
          git remote add upstream https://github.com/llvm/llvm-project
          git fetch upstream
          git checkout master
          # TODO: Investigate why `--allow-unrelated-histories` required.
          # TODO: Only push there is a change
          git pull upstream master --allow-unrelated-histories && git push origin master

TODO

• git に, 自身の repo はどこかの fork であることを知らせればいけるか?
  • hub コマンドでなにかいけるかも?

• 自分とこの環境下におけるGit & GitLabレクチャー

Git操作の概要とGitLabとの操作の概要を示す．

Git操作の概要

Gitでのバージョン管理の概要を下図に示す．Gitでのバージョン管理を行うための初期化(init)，管理対象となるディレクトリ・ファイルに対する操作(add, mv, rm, commit)，現在の管理状態(status)からなる．

用語集

project : プロジェクト

gitで管理する対象全体．具体的には管理対象のトップディレクトリの名前となる．

repository : レポジトリ

保存されている管理対象．特にバージョンがついた状態で保存されている．作業が進むにつれて保存したものは増えていく．個々の保存したもの・その状態をsnapshot:スナップショットと呼ぶ．

GitLabなどサーバを用いる場合，自分のPCのrepositoryとサーバ上のrepositoryを区別したい場合がある．その場合，自分のPCのものをlocal repository:ローカルレポジトリと呼ぶ．

worktree : ワークツリー

その時作業しているもの．repositoryをセーブしたものと捉えるとworktreeは現在の状態と捉えられる．

index : インデックス

Repositoryで保存する対象を集めたもの．プロジェクトディレクトリ以下の全てがrepositoryへの保存対象となるのではなく，選んで対象にしたり対象から外したりすることができる．indexにあるものがrepository保存の対象となる．/dd>

例1:viやemacsなどの編集時に出る一時保存ファイルを保存対象外とする．

例2:卒論で1章から5章までの文章をtexで記載する．4章のみまだ編集途中である．そのため，4章を除いた章に関係するファイルだけ保存対象とし，4章のみ保存対象外とする．

コマンド

git init

• 初期化を行う．管理対象となるディレクトリ・ファイルのあるトップディレクトリで実行することで，git管理のための初期化(プロジェクトの作成)を行う．

git add [option] [files]

• 指定ファイルを管理対象としてindexに追加する．
• option
  • なし
  • -u
    • 変更のあったファイルすべてを追加する．
• files
  • 指定されたファイルを管理対象ファイルとしてindexに登録する．
  • "."(ピリオド)ですべてのファイルを指す．
  • 備考
    • 管理対象ファイルに変更があった場合，「変更があった」と認識しindexを変化させるコマンドとなる．言い換えれば，addしない限り変更してもバージョン管理されないし，そのように使用することである変更に対してバージョン管理しないようにできる．
• 例
  • git add -u
  • git add -u *.txt
  • git add txt.txt
  • git add .

git mv [source] [target]

• 管理対象ファイルを移動する．
• 備考
  • mv source targetとするとGitがファイルの移動を認識できず，困ったことになる．Gitが管理しているファイルを移動する場合，必ずgit mvを使用しなければならない．

git rm [option] [files]

• 管理対象のファイルを削除する．
• option
  • なし
  • -r
    • ディレクトリの削除する．
  • -cash
    • indexから対象を削除する．意味的には「管理対象からはずす」となる．実際のファイルは削除されない．

git commit [option]

• indexに基づいてworktree内のファイルをrepositoryに保存する(=スナップショットをとる．)
• option
  • なし
  • -a
    • worktree内の変更を自動検出し，repositoryに保存する．git add -u & git commitと同等となる．
  • -m "message"
    • repositoryに保存する際のメモを付与する．使用することを推奨する．メッセージには簡単な変更内容を記載すると良い．
• 備考
  • git addコマンドをしていないなどで，indexがファイル更新を認識していない場合は保存されないので注意が必要である．逆に言えば色々ファイルを変更しても全て一度にrepositoryに保存する必要はなく，一段落ついたファイルのみを保存することができる．

git status

• Gitの管理状態(対象ファイルは変更されているか？indexに入っているか？など)を表示する．

GitLabとの操作の概要

GitLabを使う場合のローカルPC上での操作の概要を下図に示す．ただし，GitLabにブラウザ経由でアクセスし，GitLab上で完結した操作もあるので注意が必要である．

コマンド

git clone [url]

• url
  • urlにあるプロジェクトをローカルPCにダウンロード．

git remote [option]

• option
  • add [name] [url]
    • 長いurlを短いnameにする別名付与．
    • 例:
      • git remote add origin git@gitlab.com:kentarou/git_seminar.git
  • -v
    • 登録一覧を表示．
  • -r [name]
    • 登録されているnameを削除．

git push [option] [repository name [local branch name[:remote branch name]]]

• ローカルPCのrepositoryをGitLabのrepository nameにアップロード
  • repository name
    • GitLab上のrepositoryを表すurlもしくはgit remoteで設定した短縮名．
  • local branch name
    • アップロードしたいローカルPC上のブランチ名．とりあえずmaster．
  • remote branch name
    • アップロード先となるGitLab上のブランチ名．省略するとlocal branch nameとなる？
  • option
    • なし
    • -u
      • 当該オプションを指定してpushしpushが成功すると，以後repository nameなどを省略できる．
    • -all
      • すべてのブランチ名をアップロード．
  • 例
    • git push git@gitlab.com:kentarou/git_seminar.git master:dev-kentarou
      • ローカルPCのmasterをgitlab上のdev-kentarouにアップロード．
    • git push origin master:dev-kentarou
      • 大体上に同じ．originと名前がところにアップロード．
    • git push origin master
      • originのmasterにローカルPCのmasterブランチをアップロード．
    • git push -u origin master
      • pushが成功すると，以後以下のコマンドでオッケーになる．
        • git push

git pull [repository name] [branch name]

• GitLab上からローカルPCへの取り込み．GitLab上のrepositoryのbranch nameで指定されたブランチをローカルPCの現在のブランチに持ってくる．

初期化について

Gitを使うための初期化処理にあたるものはgit initとgit cloneの2種類ある．
git initはローカルPC上で行う初期化処理となる．管理対象としたいディレクトリでgit initのコマンドを実行すると，repositoryの場所や設定の保存場所である.git/ディレクトリが作成される．
一方でgit cloneはGitLab上のプロジェクトをローカルPCに持ってくる処理となる．GitLab上のプロジェクトの中には.git/ディレクトリがあるので，git cloneした時点で初期化も終わっていることになる．