0.バージョン管理していない既存のVisualStudioのプロジェクトをGitHubで公開するまで
公開したプロジェクトは以下の通りです。
あらかじめ述べておきますが、GitHubのGUIだけでもプロジェクトを公開することができます。リポジトリを作って、ファイルをアップロードし、ファイルを選んでコミットボタンをクリックするだけです。「リリース機能」を使う場合は、本稿の「リリース機能を使う」と共通です。
GitHubのGUIでの公開方法はこちら
本稿では、ローカルマシンにおいてGitコマンドでリポジトリを作って管理し、リモート(GitHub)にpushする手法でチャレンジしています。回りくどいと思いますが、個人的なGitの勉強と備忘録を兼ねています。節の構成は以下の通りです。
目次
- 1 公開対象の既存プロジェクト
- 2 ローカルでGitを使ってリポジトリ作成
- 3 private属性でGitHub上にリポジトリ作成
- 4 ローカルのリポジトリをリモートにpush
- 5 README.md/LICENSEファイルを作る
- 6 ローカルにcloneしてファイルの不足の有無を確認
- 7 GitHubの「リリース機能」を使う
- 8 GitHub上のprivateリポジトリをpublicリポジトリに変更する
1 公開対象の既存プロジェクトについて
既存プロジェクトはVisualStudioのC++プロジェクト、C++言語によるライブラリとテストプログラムのソースコードから構成されています。dllをPythonから利用するライブラリとテストプログラムも含みます。
画像処理(ディザリング)および乱数発生器の代わりに使うことができるブルーノイズ系列発生器のソースコードです。8192行×8192列の巨大なブルーノイズマトリクスを原論文のアルゴリズムと比べて1000倍以上の高速度で生成することができます。ブルーノイズの詳細は以下の通り
2 ローカルでGitを使ってリポジトリ作成
基本的に、Gitでローカルにリポジトリを作成して、それをサーバーにアップロード(push)するという流れとなります。公開するまではアクセス制限をかけて操作、動作確認がすんでから公開という手順を踏みます。
まず、コマンドプロンプトあるいはPower ShellでVisualStudioのソリューションのフォルダへ移動(chdir/cd)します。
同じフォルダを表示するようにエクスプローラーを開いておくと、確認、やり直しに便利です。Gitでできるファイルは「隠しファイル」となっているのでエクスプローラーの「表示」タブで「隠しファイル」のチェックを入れておきます。
最初に"git init"で初期化します。次に、git configでユーザー名とメールアドレスを登録します。ここで注意があります。
個人開発でpublic公開する場合限定です。
user.emailに、実在するメールアドレスを入力してリポジトリを公開すると、"GitHubの方から来ました"というスパムメールが送られてきます。それが嫌な人は実在しないメールアドレスを入れておきましょう。GitHubのサービスでダミーのメールアドレス提供もあるそうですが自分は使っていません。
D:\src\bnmaskutf8>git init
Initialized empty Git repository in D:/src/bnmaskutf8/.git/
D:\src\bnmaskutf8>git config user.name TakanobuSaito
D:\src\bnmaskutf8>git config user.email none@somecompany.co.jp
Git関連のファイルは".git"という名前の隠しファイル属性のフォルダに全て格納されます。エクスプローラーの「表示」タブの「隠しファイル」にチェックしていれば、GUI上で内容を見ることができます。
最初のコミット時に失敗したり、綴り間違いなどで失敗したときは、面倒なリカバリ処理をするのではなく、エクスプローラー上で".git"フォルダを消して、コマンドプロンプトで"git init"からやり直す方が楽です。
PC上のgitを使ってgit initした場合、ブランチ名の初期値が"main"ではなく"master"となることがあります。"git branch"でブランチ名の確認ができます。そうした場合、後の説明との齟齬が生じますので、"git branch -m"を使ってブランチ名を"main"へ変更します。
ブランチ名の一時的変更、恒久的変更の方法
``` D:\src\bnmaskutf8>git granch master D:\src\bnmaskutf8>git branch -m "main" D:\src\bnmaskutf8>git granch main ``` 毎回変更するのは面倒なので、"git init"で作られるブランチ名を"main"に固定することもできます。固定できないときは、gitのバージョンが古いと考えらますので更新してください。 ```ruby:branch名の初期値 git config --global init.defaultBranch main ```"git config"でuser.nameとuser.emailを登録した次に、"git add ファイル名"でファイルをステージングします。その際にファイル登録の漏れがあるかどうかをチェックするのに、"git status"コマンドが役立ちます。
下記のステータスでは、"Untracked files"にPythonのファイル(拡張子.py)が残っています。これではあかん。".py"ファイルを"git add"、"git commit"する必要があることに気づきました。
D:\src\bnmaskutf8>git status
On branch main
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: README.md
modified: bnmaskutf8dll/bnmaskutf8dll.cpp
modified: bnmaskutf8dll/bnmaskutf8dll.vcxproj
modified: bnmaskutf8dll/bnmaskutf8dll.vcxproj.filters
modified: bnmaskutf8lib/bnmaskutf8lib.vcxproj
modified: bnmaskutf8lib/bnmaskutf8lib.vcxproj.filters
Untracked files:
(use "git add <file>..." to include in what will be committed)
BnmaskImportTest.py
BnmaskTest.py
Debug/
Release/
bnmask/
bnmaskutf8.opensdf
bnmaskutf8.sdf
bnmaskutf8.suo
bnmaskutf8.vcxproj.user
bnmaskutf8dll/Debug/
bnmaskutf8dll/Release/
bnmaskutf8dll/bnmaskutf8dll.vcxproj.user
bnmaskutf8dll/x64/
bnmaskutf8lib/Debug/
bnmaskutf8lib/Release/
bnmaskutf8lib/bnmaskutf8lib.vcxproj.user
bnmaskutf8lib/x64/
ipch/
x64/
"git add ファイル名"の次には、"git commit ファイル名 -m コメント文"でステージング・エリアのファイルをコミットします。各ファイルに対して"git add"と"git commit"を一回ずつやりますが、ファイル名にワイルドカード文字を使えるので、"git add *.cpp"や"git commit *.cpp -m "first commit""とすることもできます。
"git add"と"git commit"の処理では、余分なファイルを入れてしまったり、必要なファイルを入れ忘れたりすることがあるので、"git status"でその都度確認します。
余分なファイルを入れてしまったときは、リポジトリから消すこともできますが、".git"フォルダごと消して"git init"からやり直す方が楽です。やりなおすために、"git add"と"git commit"の操作は、直接コマンドプロンプトの後に打ち込まず、いったんテキストファイルにしておくと便利です。
なお、VisualStudioのプロジェクトにはいろいろなファイルがありますが、必要なファイルは ".sln" と ".vcxproj" 、 "*.vcxproj.filters" の3ファイルだけです。本件の場合のadd/commitリストは以下の通りです。バッチファイルの一部ですが、テキストファイルにして
git add *.sln
git add *.vcxproj
git add *.vcxproj.filters
git add *.h
git add *.cpp
git add *.py
git add makefile
pause
git add manual/*.*
pause
git commit *.sln -m "first commit"
git commit *.vcxproj -m "first commit"
git commit *.vcxproj.filters -m "first commit"
git commit *.h -m "first commit"
git commit *.cpp -m "first commit"
git commit *.py -m "first commit"
git commit makefile -m "first commit"
pause
git commit manual/*.* -m "first commit"
pause
3 private属性でGitHub上にリポジトリ作成
いったんprivateリポジトリを作るのは、不完全なリポジトリを全世界に公開することを避けるためです。
たとえばGitのリポジトリにaddし忘れたファイルがあって動作しないというトラブルが考えられます。
ホーム画面(Dashboard)で"New"ボタンをクリックすると、以下の画面が表示されるので、"bluenoise"というリポジトリを新設します。ラジオボタンは"Private"に変更して、チェックボックス"Add a README file"は外したまま、"Choose a license"のプルダウンは"License None"のままにしておきます。
README.mdファイルやLICENSEファイルはGitHub上でも後から追加できますし、ローカルのパソコンで作って"git push"することもできます。
4 ローカルのリポジトリをGitHubのリポジトリへpush
つぎに、ローカルのリポジトリをリモート(GitHub)へ"git push"します。
D:\src\bnmaskutf8>git remote add origin https://github.com/TakanobuSaito/bluenoise
D:\src\bnmaskutf8>git push origin main
GitHub上でREADME.mdファイルやLICENSEファイルを作ったり編集している場合、pushでエラーが発生することがあります。pushの前にpullしろとか言われてやってみると、またエラーが発生します。"git add"をしていないのに、更新するだけでもエラーの原因となります。
自分のケースでは個人開発なので、--forceオプションを付けてpushしてしまいます。ローカルのリポジトリがGitHubに強制的に反映されます。リモートのREADME.mdファイルやLICENSEファイルの方が新しくても、リモートの方は消えてしまうので注意してください。
D:\src\bnmaskutf8>git puth --force origin main
5 README.md/LICENSEファイルを作る
リモートで更新した場合、通常はGitHubのエディタで"README.md"や"LICENSE"を更新した場合は、ローカルに反映するには、"git pull origin main"となります。
ローカルで更新した場合、更新後に"git add"、"git commit"、"git push origin main"とします。
両方で更新した場合は、merge errorやmerge conflictとなり、困ったことになります。
error: Your local changes to the following files would be overwritten by merge:
LICENSE
上級者向けの正規の対処方法もあるようですが、自分のようなgit初心者にはとても難しいので"git push --force"に逃げてしまいました。強制的にローカルのリポジトリでリモートを上書きします。リモートの方が新しかったら、コピペでローカルの方を更新してから"push"しましょう。
チームでやっている場合は、あきらめて"git stash"やらのgitコマンド上級編を勉強してmergeのconflictに対処しましょう(投げやり)。
6 ローカルにcloneしてファイルの不足の有無を確認
これで公開という訳にはいきません。リモートのバックアップがビルドできるかどうか、動作するかどうかのチェックをローカルで行う必要があります。リモートのバックアップを、ローカルPCの「確認用のフォルダ」に"git clone"して、ビルドしたり動作確認したりします。
"git clone"するフォルダは、存在しないフォルダ名か、中身が空のフォルダ名にしてください。
D:\src>git clone https://github.com/TakanobuSaito/bluenoise d:/src/bnmaskutf8clone
Cloning into 'd:/src/bnmaskutf8clone'...
(後略)
動作確認用のクローンのフォルダは、あくまで必須ファイルの不足を確認するためのもので、ソースコードやドキュメントの修正をするためのものではありません。
不足がある場合は、オリジナルのフォルダで"git add"、"git commit"、"git push origin main"するべきでしょう。ソースコードの修正がある場合も、オリジナルのフォルダで修正しましょう。
7 GitHubの「リリース機能」を使う
リポジトリ画面の右側に、"About"、"Releases"、"Packages"を設定するリンクがあります。いったい何だろうと思って、"Releases"のところにある"Create a new release"をクリックすると、Pre release、Version 1.0.0、といった、バイナリによるリリースをすることができます。この機能を使うことで簡単に、リリース画面を作ることができます。GitHubでライブラリやツールを探していると、よく見かけるこれです。
リリースの方法
リポジトリだけだと、ソースのzipファイルとtar.gzファイルを作ってくれるだけですが、さらにビルドした結果の実行ファイルやライブラリファイルのバイナリを追加することができます。自分の場合、64bitのリリースビルドのバイナリーを追加することにしました。以下の画面で、"Select tag"をクリックして、バージョン番号を"v1.0.0"と記入します。"Release title"欄に”windows 64bit binary”と入力して、"Release notes"は"Generate release notes"でGitHubに自動生成してもらいました。
バイナリファイルを"Attach ninaries by dropping themhere or selecting them."の欄にドラッグ&ドロップするか、ファイル選択するかで追加して、一番下の「Publish release」をクリックします。すると、よく見かけるリリース画面を作って公開することができるようになります。
8 GitHub上のprivateリポジトリをpublicリポジトリに変更する
まず、リポジトリの画面から"Settings"を選択します。
"Settings"ページの一番下の"Danger Zone"という不穏な名称のグループが見えるまでスクロールします。リポジトリの削除や"private"/"public"の変更などの危険性のある操作をするためのグループです。
そこの"Change visibolity"ボタンをクリックすると、
ポップアップウィンドウが表示されます。そこの"I want to make this repository public"をクリックすることでリポジトリをpublicへ変更することができます。
publicにしたソースコードは全世界に公開されるので、公開前に秘匿すべきアカウント名やAPIキーなどが無いことを確認しましょう。LICENSEは正しいものを選択していますか?
公開したプロジェクトは以下の通りです。
これでGitHubへの公開完了となります。公開後に起きた問題や対処方法などがあったら追記いたします。