- 投稿日:2021-01-01T23:05:29+09:00
Git クライアントツールのススメ
はじめに
Git関連ツールのメモ代わりです。
Gitは皆さんよく使われると思います。
ですが、思ったよりクライアントツールが話に出ないandどれを使えばいいのかわからないという方が結構多い。そういった方のおすすめしたいツールが以下の二つ!!
・SourceTree
・Git Krakenクライアントツールとは?
簡単に言えば、リポジトリの管理をGUIで見やすく管理するツールです。
gitでcommit や push をするのはVScodeやコマンドプロンプトで実行できますが、
それを上記のアプリ内で実行することが可能です。ある程度の機能はVSCodeで行うものとそこまで差異はありませんが、異なる点を挙げるとすれば
・複数のリポジトリを一括で管理できる。
・リモートのリポジトリに存在するブランチや現在の作業ブランチをサイドタブに表示することができ、簡単に切り替えが可能
・別の方が行ったcommit,push,merge等を視覚的に理解できるようになる。(拡張機能のgitgraphに近い)といったところです。
gitkrakenに関しては無料の範囲内ではできることが限られているので使用の際は有料登録がおすすめです。
sourcetreeは初心者でもわかりやすくおそらくメジャーなツールに分類されるので情報もたくさんあると思います。
お試しで使ってみたいという方はSourceTreeがよいかと思います。実際のアプリの使用法はここでは説明しませんが、ぜひ使ってみてください!!
良い開発ライフを!!
- 投稿日:2021-01-01T22:25:55+09:00
Git のコマンド色々たたいてみる
はじめに
Git を使い始めて早5年ほど。操作系のコマンドだと未だ add, commit, push, merge 程度のコマンドしか使ったことがない。他にも色々とあるのは知っているが、どのような挙動を起こすのか把握しておらず、怖くて使っていない。この記事では色々試してみようと思う。
今回使う Git のバージョン
$ git --version git version 2.29.2試す
test 用のリポジトリ。
https://github.com/firedial/git_practice/treeマージ時にコンフリクト起こし、マージを取り消したい時
関係するブランチ
- conflict-master
- conflict-development
元々 conflict-master に
人のお金で焼肉食べたい。
という文書が書かれたテキストファイルがあり、そこから conflict-development ブランチを切って人のお金で寿司食べたい。
というテキストファイルに変更した。その後 conflict-master で人のお金で蟹食べたい。
というテキストアフィルに書き換わった。ここで、 conflict-master と conflict-development をマージするとコンフリクトを起こす。
$ git merge conflict-development Auto-merging command_test/conflict.txt CONFLICT (content): Merge conflict in command_test/conflict.txt Automatic merge failed; fix conflicts and then commit the result.その時のファイル状態は下記の通りである。
$ git status On branch conflict-master Your branch is based on 'origin/command-test', but the upstream is gone. (use "git branch --unset-upstream" to fixup) You have unmerged paths. (fix conflicts and run "git commit") (use "git merge --abort" to abort the merge) Unmerged paths: (use "git add <file>..." to mark resolution) both modified: conflict.txt no changes added to commit (use "git add" and/or "git commit -a")その状態からマージを取り消す。
$ git merge --abortそうすると、マージする前に戻る。
$ git status On branch conflict-master Your branch is based on 'origin/command-test', but the upstream is gone. (use "git branch --unset-upstream" to fixup) nothing to commit, working tree clean作業用ツリーの修正を元に戻したい時
関係するブランチ
- reset-master
焼肉食べたい。
と書かれたテキストファイルを編集することを考える。$ git diff diff --git a/reset_test/reset.txt b/reset_test/reset.txt index 393fada..3b153da 100644 --- a/reset_test/reset.txt +++ b/reset_test/reset.txt @@ -1,4 +1,4 @@ -焼肉食べたい。 +寿司食べたい。作業ツリーの変更を全て取り消す。
$ git checkout . Updated 1 path from the indexそうすると元に戻っていることが確認できる。
$ git status On branch reset-master Your branch is up to date with 'origin/reset-master'. nothing to commit, working tree clean
ただそれだけだと、新規に作成したファイルが残ったままになる。試しに
add.txt
というファイルと、add
というディレクトリを作成する。$ git status On branch reset-master Your branch is up to date with 'origin/reset-master'. Untracked files: (use "git add <file>..." to include in what will be committed) add.txt add/ nothing added to commit but untracked files present (use "git add" to track) $ git checkout . Updated 0 paths from the index $ git status On branch reset-master Your branch is up to date with 'origin/reset-master'. Untracked files: (use "git add <file>..." to include in what will be committed) add.txt add/ nothing added to commit but untracked files present (use "git add" to track)このように元に戻せていない。この場合は
git clean
を使う。そうすることでadd.txt
が削除される(この時、完全にファイルが削除されることに注意)。$ git clean -f Removing add.txt $ git status On branch reset-master Your branch is up to date with 'origin/reset-master'. Untracked files: (use "git add <file>..." to include in what will be committed) add/ nothing added to commit but untracked files present (use "git add" to track)ディレクトリを削除するには
-d
オプションもつける(これもディレクトリ配下全て削除されるので注意)。$ git clean -df Removing add/ $ git status On branch reset-master Your branch is up to date with 'origin/reset-master'. nothing to commit, working tree cleanadd 操作を取り消したい時
関係するブランチ
- reset-master
ファイル編集して add してみる。
$ git diff diff --git a/reset_test/reset.txt b/reset_test/reset.txt index 393fada..3b153da 100644 --- a/reset_test/reset.txt +++ b/reset_test/reset.txt @@ -1,4 +1,4 @@ -焼肉食べたい。 +寿司食べたい。 $ git add reset.txt $ git status On branch reset-master Your branch is up to date with 'origin/reset-master'. Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: reset.txt取り消しコマンドを叩く。
$ git reset HEAD . Unstaged changes after reset: M reset_test/reset.txtそうすると add する前に戻っていて、ファイル変更はそのまま保持されている。
$ git status On branch reset-master Your branch is up to date with 'origin/reset-master'. Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: reset.txt no changes added to commit (use "git add" and/or "git commit -a") $ git diff diff --git a/reset_test/reset.txt b/reset_test/reset.txt index 393fada..3b153da 100644 --- a/reset_test/reset.txt +++ b/reset_test/reset.txt @@ -1,4 +1,4 @@ -焼肉食べたい。 +寿司食べたい。commit 操作を取り消したい時(履歴は残らない)
関係するブランチ
- reset-master
コミットをしてしまったが、そのコミットを取り消したいことを考える。これはリモートにプッシュする前に留めておくべきである(そのことについては後で試してみる)。
コミットを追加。 push する前なので origin より一つ進んでいる状態。
$ git commit -m "寿司に変更" [reset-master ba77535] 寿司に変更 1 file changed, 1 insertion(+), 1 deletion(-) $ git log --oneline ba77535 (HEAD -> reset-master) 寿司に変更 6f798f4 (origin/reset-master) 焼肉そのコミットを取り消す。
HEAD~
はHEAD
の一つ前のコミットを指す。今回で言うと6f798f4
のコミットである。$ git reset --hard HEAD~ HEAD is now at 6f798f4 焼肉
上記のことはローカル内のことだったが、リモートにプッシュしてしまった場合どうなるのか試してみる。
コミットを取り消す作業者の作業: 赤色
共同作業者の作業: 青色まずは変更をリモートにプッシュする。
$ git commit -m "寿司に変更" [reset-master 9d698c9] 寿司に変更 1 file changed, 1 insertion(+), 1 deletion(-) $ git push Enumerating objects: 7, done. Counting objects: 100% (7/7), done. Delta compression using up to 4 threads Compressing objects: 100% (2/2), done. Writing objects: 100% (4/4), 414 bytes | 414.00 KiB/s, done. Total 4 (delta 0), reused 0 (delta 0), pack-reused 0 To https://github.com/firedial/git_practice.git 6f798f4..9d698c9 reset-master -> reset-master $ git log --oneline 9d698c9 (HEAD -> reset-master, origin/reset-master) 寿司に変更 6f798f4 焼肉共同開発者がその変更をプルする。
$ git log --oneline 9d698c9 (HEAD -> reset-master, origin/reset-master) 寿司に変更 6f798f4 焼肉コミットを取り消す。
$ git reset --hard HEAD~ HEAD is now at 6f798f4 焼肉 $ git log --oneline 6f798f4 (HEAD -> reset-master) 焼肉その変更をリモートにプッシュする。この時
-f
オプションを使って強制的にプッシュする必要がある。$ git push -f origin reset-master Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 To https://github.com/firedial/git_practice.git + 9d698c9...6f798f4 reset-master -> reset-master (forced update)そのコミットがなかったことになりました。めでたしめでたし????
$ git log --oneline 6f798f4 (HEAD -> reset-master, origin/reset-master) 焼肉取り消した後から別に変更を加える。
$ git commit -m "パスタに変更" [reset-master 44ebdc8] パスタに変更 1 file changed, 1 insertion(+), 1 deletion(-) $ git push Enumerating objects: 7, done. Counting objects: 100% (7/7), done. Delta compression using up to 4 threads Compressing objects: 100% (2/2), done. Writing objects: 100% (4/4), 420 bytes | 210.00 KiB/s, done. Total 4 (delta 0), reused 0 (delta 0), pack-reused 0 To https://github.com/firedial/git_practice.git 6f798f4..44ebdc8 reset-master -> reset-master $ git log --oneline 44ebdc8 (HEAD -> reset-master, origin/reset-master) パスタに変更 6f798f4 焼肉取り消されたコミットから変更を加える。
$ git commit -m "蟹に変更" [reset-master 5b60085] 蟹に変更 1 file changed, 1 insertion(+), 1 deletion(-) $ git log --oneline 5b60085 (HEAD -> reset-master) 蟹に変更 9d698c9 (origin/reset-master) 寿司に変更 6f798f4 焼肉そしてその変更をリモートにプッシュする。
$ git push To https://github.com/firedial/git_practice.git ! [rejected] reset-master -> reset-master (fetch first) error: failed to push some refs to 'https://github.com/firedial/git_practice.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.このように
error: failed to push some refs
と出て変更をリモートに反映できなくなる。commit 操作を取り消したい時(履歴は残る)
上記で述べた方法でコミットを取り消すと共同開発者に影響が出てしまう。そのため、リモートにプッシュ後の取り消しは
revert
を使うべきである。パスタに変更した(44ebdc8)のを取り消すことを考える。
$ git log --oneline 44ebdc8 (HEAD -> reset-master, origin/reset-master) パスタに変更 6f798f4 焼肉revert コマンドを叩く。
$ git revert 44ebdc8 [reset-master 971602a] Revert "パスタに変更" 1 file changed, 1 insertion(+), 1 deletion(-) $ git log --oneline 971602a (HEAD -> reset-master, origin/reset-master) Revert "パスタに変更" 44ebdc8 パスタに変更 6f798f4 焼肉焼肉食べたいに戻っていることを確認。
$ cat reset.txt 焼肉食べたい。他のブランチのコミットを取り込む
関係するブランチ
- cherry-master
- cherry-development
- cherry-test
cherry-master から cherry-development で開発をし、その修正を cherry-test に取り込んでテストを行う。
テスト中に修正不備を発覚し修正を行うが、間違って cherry-test の方に修正をコミットしてしまった。
その修正を cherry-development に取り込むことをやってみる。元々 pick.txt には下記の内容が入っている。
$ cat pick.txt 食べたいものリスト * 焼肉(人のお金で) * 寿司(人のお金で)それを cherry-development で下記のように修正。
$ cat pick.txt 食べたいものリスト * 焼肉(人のお金で) * 寿司(人のお金で) * 蟹その変更を cherry-test にマージ。
$ git merge cherry-development Updating fea6cfd..d41bd9c Fast-forward cherry/pick.txt | 1 + 1 file changed, 1 insertion(+)その際
人のお金で
という非常に大事な文言が抜けていることに気付き、修正するが cherry-test にコミットしてしまう。$ git commit -m "大事な文言追加" [cherry-test 806b5c2] 大事な文言追加 1 file changed, 1 insertion(+), 1 deletion(-)その修正を cherry-development に反映したい。そこで出てくるのが cherry-pick である。
修正したコミットのハッシュ値 806b5c2 を控える。
$ git log --oneline 806b5c2 (HEAD -> cherry-test, origin/cherry-test) 大事な文言追加 d41bd9c (origin/cherry-development, cherry-development) 蟹を追加 fea6cfd (origin/cherry-master, cherry-master) 食べたいものリストブランチを切り替えて、今の状況を確認。
$ git checkout cherry-development Switched to branch 'cherry-development' Your branch is up to date with 'origin/cherry-development'. $ git log --oneline d41bd9c (HEAD -> cherry-development, origin/cherry-development) 蟹を追加 fea6cfd (origin/cherry-master, cherry-master) 食べたいものリストそこで cherry-pick コマンドを叩く。
$ git cherry-pick 806b5c2 [cherry-development 8ca6349] 大事な文言追加 Date: Fri Jan 1 22:14:11 2021 +0900 1 file changed, 1 insertion(+), 1 deletion(-) $ git log --oneline 8ca6349 (HEAD -> cherry-development) 大事な文言追加 d41bd9c (origin/cherry-development) 蟹を追加 fea6cfd (origin/cherry-master, cherry-master) 食べたいものリストコミットが適用され、無事ファイルも修正されている。
$ cat pick.txt 食べたいものリスト * 焼肉(人のお金で) * 寿司(人のお金で) * 蟹(人のお金で)終わりに
ちょっと駆け足だったが、細かく解説できた方かなと思う。特に reset でコミットを取り消すとどうなるかを、実際試すことができてよかった。
今年もいくつかの記事がかければなぁと思いますので、暖かく見守ってもらえると嬉しいです。
- 投稿日:2021-01-01T22:16:27+09:00
Gitで「 fatal: not removing 'second.txt' recursively without -r 」エラー
GitとGitHubの学習中にエラーが発生したため、学習記録として記録します。
ターミナルにて、
git rm [ディレクトリ名]
git rm --cached [ディレクトリ名]
入力後に発生。git rm second.txt fatal: not removing 'second.txt' recursively without -rrecursively without -rをGoogle翻訳すると、
となっていたので試しにgit rm -r
で実行。git rm -r second.txt rm 'second.txt/text1'git rm -r --cached second.txt rm 'second.txt/text1'今度は成功しました?
- 投稿日:2021-01-01T19:42:36+09:00
git commit の -a オプションで git add を省略する
git commit -am "commit message"
-aオプションは変更分を自動検出する。
簡単に言うと
git add
を省略しgit commit
できる。ただし過去に
git add
したことがあるファイルに限る。
(= git管理の対象になっているファイルに限る。)
- 投稿日:2021-01-01T14:40:05+09:00
GitHubへpushする際、RPC failed; curl 55 SSL_write() returned SYSCALL, errno = 32 エラーが発生 (完全備忘録)
Githubへpushしようとした際に、
RPC failed; curl 55 SSL_write() returned SYSCALL, errno = 32 fatal: the remote end hung up unexpectedly初めてのエラーで何が起きているのか分からず、とりあえず何が起きているのか知るためにググる。。
エラーの意味
一度に多数かつ大容量のファイルをpushしようとするとデータの受け手側でチャンクが発生し、メモリが足りないことから発生している。
自分の場合はここの時点で、かなりの違和感...
・ 今回発生したタスクでは、gemの追加も、大容量のファイルを扱う実装はしていない。
・ ブランチを分け、細かくコミットしてpushする事を意識していた..なぜ??(とりあえず、解決方法を探す)
行ったこと①
「http.postBuffer」の設定を変更する。 (gitのhttp通信制限を増やしてみる)
$ git config --global http.postBuffer 524288000結果: → ダメ
更に倍にしてみる..
$ git config --global http.postBuffer 1048576000結果: → ダメ
行ったこと②
一度にpushせずに、コミットID毎に分けてpushしてみる。
$ git push <remotename> <commit SHA>:refs/heads/<new remote branch name>結果: → ダメ
詰まり始めてきたので、現状を整理する。。
コミット数も少なく実装内容は大容量データではないのにpushできない。
どこかのタイミングでホームディレクトリでgit init を実行してしまった..とか?....汗
とりあえず、以下を実行してみる。$ pwd $ ls -a ~/.git結果: $ ls -a ~/.git . HEAD description info refs .. config hooks objects・・・ビンゴ(汗)
今回のエラー原因は、
git init
を浅い階層で実行してしまったことが原因。
それによって、おおよそ全てのファイルが Gitの管理下になってしまったことで,容量が大きすぎてプッシュできない(というよりプッシュしてはいけない)状態になっていた。原因が分かったので、
浅い階層に作成してしまったGitローカルリポジトリがあることが、確認できたので次の2つの流れで作業する。① 現状のGitの管理下を確認
② 浅い階層に作成してしまったGitローカルリポジトリを削除していく【ここで確認しないといけないこと】
最新のGitHubのリポジトリを確認して、アプリ以外のファイルが入っているかどうかを確認する
アプリ以外のファイルが入っている → GitHubのリポジトリごと一旦削除しなければならない
アプリ以外のファイルが入っていない → ホームディレクトリのローカルリポジトリを削除する(GitHubのリポジトリは削除しなくていい)
$ rm -rf ~/.git (Gitローカルリポジトリを削除)【ルートディレクトリやデスクトップの方も確認しておく】
$ ls -a /.git $ ls -a ~/Desktop/.gitもし、ファイルが表示されるなら以下も実行する
$ rm -rf /.git $ rm -rf ~/Desktop/.git【何が起きていたか】
ホームディレクトリでgit init を実行した形跡があるということは,普段使用しているほぼ全てのファイルがGitの管理下に入っていたことになる。
つまり,その状況でプッシュに成功していた場合はリポジトリにアプリ以外の内容が入っている可能性がある。【コミットの差分を確認】
$ git diff HEAD~ HEAD【ローカルとGitHubのコミット履歴の違いを確認】
$ git log --oneline -5 $ git fetch $ git log --oneline -5 origin/現在のブランチ名 (今回は "master")次に、
【変更のあったファイルを確認】
下記コマンドで変更のあったファイルを確認できる。
(大量にファイルが表示されたり、アプリのファイル以外が含まれていた場合は,不要なコミットを削除する必要がある)$ git diff --stat HEAD~ HEAD $ git diff --stat HEAD~~ HEAD~【個別のコミットを確認する場合】
$ git diff --stat コミットID HEAD問題がありそうな差分がなさそうであれば、「浅い階層に作成してしまったGitローカルリポジトリを削除」
$ rm -rf /.git $ rm -rf /Users/.git $ rm -rf ~.git $ rm -rf ~/Desktop/.git $ git fetch $ git rebase origin/master # コンフリクトが起きた場合、次は実行しない $ git diff --stat origin/master HEADここまでやって、pushすると...
pushできました!! ^^
git init
は意外と危険なコマンド。
必ずカレントディレクトリを確認してから実行するようにします!(汗)失敗からも学んでいかないとです.. ^^;
参考サイト
Git公式ドキュメント
https://core-tech.jp/blog/article582/
https://bufferings.hatenablog.com/entry/2018/05/22/075014
https://stackoverflow.com/questions/6842687/the-remote-end-hung-up-unexpectedly-while-git-cloning
- 投稿日:2021-01-01T11:19:37+09:00
Git基本コマンド(ローカルレポジトリ編)
ステージにあげる
git add 'ファイル名' git add 'ディレクトリ名' git add .ワークツリーからステージへあげる(コミットする変更を準備する)
addすると、インデックスというファイルが生成される
リポジトリ―に上げる
git commit git commit -m 'メッセージ' git commit -vメッセージ付きで記録する
?git commit してエディタが開かない問題発生
どうやらPATH設定がうまく行っていないようだ。
codeコマンドを設定できない
つまり(Shell Command: Install code command in PATH)を
パネルで入力していも検索してもヒットしない問題。
↓
portable版ではなくinstall版に切り替えることで
PATHが通るようになった。
ようやく
git commitして
と表示が出る
1ファイルがチェンジされ1ファイルが追加された
現在の変更状況を確認する
git statusワークツリーとステージの間の変更を表示(ワークツリーとインデックスの比較)
ステージとリポジトリの間の変更を表示(インデックスとコミットの比較)
コミットすべきファイルの変更は無い、という意味次にファイルを変更して、再度git status
変更されたファイルがindex.htmlです、
ステージに乗っていません、という意味git add index.htmlして再度git status
変更されたファイルはindex.htmlです、
ステージに乗っています、という意味
変更内容の確認
//ステージに上げる前 git diff git diff 'ファイル名' //ステージに上げた後 git diff --staged変更履歴の確認
git log //一行表示 git log --oneline //変更差分表示 git log -p 'ファイル名' //表示するコミット数を制限 git log -n 'コミット数'
ファイル削除の記録
ファイル削除をステージに上げるには//ファイルごと削除(リポジトリからもワークツリーからも削除) git rm 'ファイル名' git rm 'ディレクトリ名' //ファイルを残したいとき(gitの記録からファイルを削除するとき) git rm --cached 'ファイル名'元に戻すには
git reset HEAD 'ファイル名' git chechout 'ファイル名'
ファイルの移動
git mv '旧ファイル' '新ファイル' //名前も変更されてなおかつステージに上がった状態になる
- 投稿日:2021-01-01T07:52:22+09:00
Gitの仕組み
gitはスナップショットを記録している。
差分を保存しているわけではない。
「branchをきる」「margeする」を高速にできる。
gitの利点は以前のバージョンに戻せる。ローカルリポジトリ…PC内にある履歴データの置き場
リモートリポジトリ…クラウド上の履歴データの置き場ローカルには3つのエリアに分かれている。
- リポジトリ…スナップショットの記録
- ステージ…変更されたファイルの指定
- ワークツリー…手元の作業場
add...変更されたファイルのみワークツリーからステージにあげる
commit(コミット)...スナップショットを記録する
gitの中で起きていること
git add...
ワークツリーに作成されたファイル→
リポジトリに圧縮ファイルを作成→
ステージに2つのファイルの紐づけを保存(インデックス)
git commit...
ステージのインデックスをツリーという構造でレポジトリに保存→
ツリーに変更内容を紐づける(コミット:ツリー名、作成者、日付、コミットメッセージ)
- 投稿日:2021-01-01T02:12:43+09:00
Gitでdebパッケージ開発:(その1)最小構成による野良パッケージ作成
自作ユーティリティをaptで管理したいという動機で、debパッケージの作り方を調べました。
真面目にやろうとすると色々情報を揃えてやらないといけないのですが、いきなり全部整備するのではなく、ステップバイステップで書いていこうと思います。なお、筆者の環境はUbuntu 18.04LTSです。debパッケージを作成する最小構成
最初のサンプルとして、次のシェルスクリプトをパッケージ化することを考えます。
#!/bin/sh echo " ^ ^" echo "=o.o=" echo " m m_|~" exit 0これを/usr/bin/mycatというファイル名で管理すれば、シェル上でmycatと入力すればいつでも可愛らしい猫を呼び出せるようになります。素晴らしい。
#念のため、mycatという名の実行ファイルが他に存在しないことを確認しておきましょう。
% which mycat mycat not foundさて、debパッケージを作るための最小構成条件は次の通りです。
- パッケージ管理ディレクトリ(任意の名前で構いません)の下にフェイクのルートディレクトリがあること
- さらにその下に
- インストールイメージがあること
- DEBIANディレクトリ(許可属性755または775)があること
- さらにその下にcontrolファイルがあること
ここでは次のようなディレクトリ構成にしましょう。
mycat └── Debian ├── DEBIAN │ └── control └── usr └── bin └── mycat最初の"mycat"がパッケージ管理ディレクトリ、その下にある"Debian"がフェイクのルートディレクトリです。さらにその下にあるusr/bin/mycatが、aptインストール後には/usr/bin/mycatとなるイメージです。mycatの許可属性は755としておいて下さい。
% mkdir -p mycat/Debian % cd Debian % mkdir -m 755 DEBIAN % mkdir -p usr/bin % cd usr/bin (〜mycatを上の中身に編集〜) % chmod 755 mycat % cd ../../DEBIAN (controlを以下の要領で作成)controlの中身は、少なくとも次の5項目を含んでいなければなりません。
- Package - パッケージ名
- Version - パッケージバージョン番号
- Description - パッケージの説明
- Maintainer - メンテナの名前と連絡先
- Architecture - 実行可能アーキテクチャ
各項目は':'(コロン)で区切られた後に書かれます。例えば次のような具合です。
Package: mycat Version: 1.0 Description: Call your lovely cat! Maintainer: (あなたの名前) <(あなたのe-mailアドレス)> Architecture: all#バージョン番号の付け方や実行アーキテクチャについてはここでは説明しませんが、お調べになることを強くお勧めします。
この上でパッケージ管理ディレクトリmycatまで戻り、dpkg-debコマンドでdebファイルを作成します。% cd ../.. % fakeroot dpkg-deb --build Debian .fakerootコマンドはfakerootパッケージに、dpkg-debコマンドはdpkg-devパッケージにそれぞれ入っています。コマンドが無いという人はそれぞれ上記をインストールしましょう。
% apt install fakeroot dpkg-dev
dpkg-debが成功したら、debパッケージファイルmycat_1.0_all.debが出来ているはずです。dpkgコマンドを使ってインストールしてみましょう。
% sudo dpkg -i mycat_1.0_all.deb途中、パスワード入力を求められます。成功したら、早速mycatコマンドを試してみましょう。
% which mycat /usr/bin/mycat % mycat ^ ^ =o.o= m m_|~やったー可愛い猫ちゃんが表示されました!アンインストールも試してみましょう。
% sudo dpkg -r mycat % which mycat mycat not foundパッケージを誰にも公開するつもりが無く、単にインストール&アンインストールを簡単にすることだけが目的ならば、ここで示したように野良パッケージを作れば十分だと思います。ただし、誰にも公開しないとしてもパッケージをきちんと管理したいならば、やはり情報を整備すべきです。次回以降、少しずつ説明して参ります。