- 投稿日:2020-03-24T22:19:03+09:00
故障かな?とおもったら【Git編】
故障かな?とおもったら
現象・症状 ご確認いただくこと 対処方法 gitコマンドが使えない.gitがありますかgit initで初期化するgit clone リポジトリURLでクローンするgit addできないファイルが .gitignoreの対象になっていますか別のディレクトリに配置する
追跡対象外のファイルであっているか確認するgit commitできないgit config --listでuser.email、user.nameが設定されていますかgit config --global user.email 'あなたのemail'とgit config --global user.name 'あなたのお名前'で設定するgit add ファイル名でステージングしていますかgit add ファイル名でステージングするgit pushできないgit remote -vでなにか表示されますかgit remote set-url origin リポジトリURLで設定するgit config --global user.name 'あなたのお名前'で設定してください他の開発者の変更が反映されない git fetchのみではローカルブランチには反映されませんgit mergeでマージを行うgit pullで反映するブランチはあっていますか git checkout ブランチ名でブランチを移動するブランチはマージされていますか git merge ブランチ名でブランチをマージする自分の変更が他の開発者に反映されない git pushでリモートブランチに反映しましたかgit push origin ブランチ名でプッシュする過去の編集が反映されない or 削除された 編集を行ったブランチですか git checkout ブランチ名で編集したブランチに移動するgit stash listを確認するgit stash popで直前の編集内容を反映するgit stash stash@{i}で特定の編集内容を反映するgit checkout ファイル名を実行した場合、直前のコミットまで編集内容が取り消されますgitではサポート対象外となっております git mergeをすると、コンフリクトした2つのブランチで同一ファイルを編集すると発生することがあります ファイルを編集して git add ファイル名及びgit commitを実施するgit addorgit commitorgit checkout時、Warningが表示されるWindows環境が開発に関わると、設定によって改行コードが変換されることがあります git config --global core.autocrlf [true input false]で設定するブランチを削除しているのに、減っていない気がする リモートブランチは開発者自身で意図的に削除しない限り、ローカルには残り続けます git fetch -pをお試しください編集してないのに git blameで未コミットの行が表示される改行、スペースで影響を受けることがあります git blame -wをお試しください書こうと思ったきっかけ
どうしてもプロジェクトで数人はGit初心者という方がいるので、その方々がよく引っかかりそうなところで、自己解決できる&もし失敗しても復旧ができそうなところをピックアップしてみました
見逃しや抜けがあると思うので、コメントで教えて下さい
気が向いたら他のパートも記事にする予定
- 投稿日:2020-03-24T22:06:38+09:00
gitで対象ファイルをあるコミット履歴の状態に戻す
- 投稿日:2020-03-24T15:05:35+09:00
チーム開発をして感じたこと
この記事はなに
高校2年生3人でチーム開発をして感じたことなどを書きます
ある程度以上できる方にとっては当たり前のことなので、読まなくてもいいと思います
初心者の中の初心者みたいな感じの人向けです3人のスキル
メンバー 使える言語 チーム開発経験 僕 C++,Kotlin,HTML,CSSなど 〇 m_arcy C++,Pythonなど × 39umi C++,HTML,CSSなど × 僕はチーム開発を経験したことがありますがそのプロジェクトはうまくいきませんでした(笑)
今回のプロジェクトはまぁまぁよかったかなという感じはします(笑)作ったもの
概要
「IdeaTree」という、アイデアが出ないときに連想語を提案することでアイデアを出す手助けをするアプリケーションです。
LINK : IdeaTree
少しバグがあるかもしれません...(小声)使った技術等
- 言語
- Python
- JavaScript
- HTML
- CSS
- フレームワーク&ライブラリ
- Django
- vis.js
- html2canvasなど
開発期間
1ヵ月と少し
チーム開発をして感じたこと
1,Gitは導入しましょう
普通に考えて当たり前ですがこれはめちゃくちゃ大事です。
失敗した前のプロジェクトでは導入していませんでした(僕がいまいち使い方を理解していなかった)
他のメンバーがGitの使い方を知らなくても導入すべきです(最初にGitの使い方を教えておけば、開発を進める中で見返りが返ってくると思いました)
僕は本当に必要なところだけドキュメントを書いてメンバーに共有しました。2,Gitはちゃんとやっておいた方がいいです
導入しましょうって言ったんですけど、理解が曖昧だとやばいです。実際やらかしました。コンフリクトが起きたり、コンフリクトを解消しようとしてヤバいことが起きました。(もう何も触れないでください。コンフリクトを解消しようとしてバグらせたのは僕、もっとちゃんと勉強します。)
開発するメンバーが決まったなら、最初1日をGitの使い方にあててもいいんじゃないかって思いました。逆にチームメンバー全員がしっかり理解していれば開発がめっちゃ進めやすいと思います。3,何を作るかを考えてから言語とかを選びましょう
これも本当に当たり前の話です。
僕たちは「Python書きたいな~、じゃあフレームワークはDjangoで行くか~」みたいな感じで全員Web開発未経験にもかかわらず言語,フレームワークを選んでから何を作るかを決めました。実装し終えて思ったのは「これ、もっと簡単にできたやろ...」。こんな感じになりました。
その言語を学ぶために1個アプリを作る場合ならいいと思いますが、そういう特別な理由がない限りは何を作るかを決めてから言語を選ぶべきだと思います。ダメな例)
A君「なんか一緒に作ろうぜ!!」
B君「ええで!なんの言語使う?」いい例)
A君「なんか一緒に作ろうぜ!!」
B君「ええで!どういうもの作る?」4,進捗報告はこまめにしましょう
これも当たり前と言えば当たり前です。
失敗したプロジェクトでは1週間たっても返信がないチームメンバーがいました。さすがにこういうのだけは避けたいなぁと思って進捗報告を徹底しました。何日に一度とかは自由でいいと思いますが、最初のうちは1週間に1度くらいはした方がいいと思います。5,全体的におおまかなスケジュールを立てておきましょう
これも当たり前です。
とりあえずのスケジュールは決めておきましょう6,立てたスケジュールからめっちゃ進んでるくらいがちょうどいいです
特に全員が開発慣れしてない場合だと、スケジュールも曖昧だったりします。最初は予定通り進んでいても最後になるにつれて難しい課題が残ってきます。そうなってくるとやる気が起きなくなります(ダメ)。なので、最初の方にめっちゃ進んでるくらいじゃないと最後の方で期限に間に合わなくなってくるのでここは意識すべきだと思います。
失敗したプロジェクトでは最初予定通りに進んでいましたが、中盤終盤になるにつれてやばくなって破滅しました。7,仕様変更が出てきた場合はみんなに話しましょう
実装していくうえで「ここはこうした方がよさそう。」みたいな仕様変更が出てくるかもしれません(僕たちも結構出てきました)。そういう時は1人で勝手に仕様変更せずにちゃんとみんなで話し合って同意を得ましょう。自分がこうした方がいいって思って勝手に消してしまうと、他の部分との兼ね合いでバグが生まれたりしてはいけないので、ちゃんと全員で相談しましょう。
最後に
こんな記事に最後まで読んでいただきありがとうございました。
- 投稿日:2020-03-24T12:20:48+09:00
Ubuntu18.04でのGogs鯖の導入
はじめに
Ubuntu18.04でgogs鯖を立てる記事です.
経緯としてはサークルの代表からGit鯖立てろ!ってことでGogs軽そうで良さげじゃねと導入(失敗編)
PackageのInstall$ wget -qO- https://dl.packager.io/srv/pkgr/gogs/key | sudo apt-key add - $ sudo wget -O /etc/apt/sources.list.d/gogs.list \ https://dl.packager.io/srv/pkgr/gogs/pkgr/installer/ubuntu/16.04.repo $ sudo apt-get update $ sudo apt-get install gogsコマンドはGogsのガイドをそのままコピーで楽ちん!!!と思ったら動かなかった...
あ,UbuntuのVersionが18.04.4やんけ!!!UbuntuのVersition確認$ cat /etc/lsb-release導入(成功編)
まずsqliteがないとダメらしいのでインストール
SqliteのInstall$ sudo apt install sqlite3次にgitのversionが最新版かどうか確認(一番最初にしろ)
$ git --version git version 2.17.1次に,gitユーザの獲得
sudo adduser --system --group --disabled-password --shell /bin/bash --home /home/git --gecos 'Git Version Control' git最新版が0.11.91だったので以下のコマンドを実行Versionを変えれば他のバージョンをgoogledriveからinstallできる
install$ VERSION=0.11.91 $ wget https://dl.gogs.io/0.11.91/gogs_0.11.91_linux_amd64.tar.gz -P /tmptarの解凍
解凍$ sudo tar xf /tmp/gogs_*_linux_amd64.tar.gz -C /home/gitGogsインストールディレクトリの所有権をユーザーおよびグループgitに変更
権限の変更$ sudo chown -R git: /home/git/gogsSystemdユニットファイルのコピー
$ sudo cp /home/git/gogs/scripts/systemd/gogs.service /etc/systemd/system/gogs鯖の起動と確認
$ sudo systemctl start gogs $ sudo systemctl enable gogs $ sudo systemctl status gogswebインストーラー
webインターフェースを開いて設定を行なっていきます
./web gogshttp://127.0.0.1:3000をブラウザで開いて設定を行います.
上のはGogsの公式が出している画像です.MySqlを使いたい場合,文字コードをUTF8にしたデータベースをMysqlで先に作っておきましょう.
Nginxの設定をします.
Nginxが入っていない人は導入をして,次のファイルを開いて編集します.sudo nano /etc/nginx/sites-enabled/gogs.example.comserver { listen 80; server_name gogs.example.com; include snippets/letsencrypt.conf; return 301 https://gogs.example.com$request_uri; } server { listen 443 ssl http2; server_name gogs.example.com; proxy_read_timeout 720s; proxy_connect_timeout 720s; proxy_send_timeout 720s; client_max_body_size 50m; # Proxy headers proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; # SSL parameters ssl_certificate /etc/letsencrypt/live/gogs.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/gogs.example.com/privkey.pem; ssl_trusted_certificate /etc/letsencrypt/live/gogs.example.com/chain.pem; include snippets/letsencrypt.conf; include snippets/ssl.conf; # log files access_log /var/log/nginx/gogs.example.com.access.log; error_log /var/log/nginx/gogs.example.com.error.log; # Handle / requests location / { proxy_redirect off; proxy_pass http://127.0.0.1:3000; } }最後に,nginxを再起動して,gogsのドメインとルートUrlの変更を行なって,gogsサービスを再起動したら終わりです!!
//Nginxの再起動 $ sudo systemctl restart nginx $ sudo nano /home/git/gogs/custom/conf/app.ini [server] DOMAIN = gogs.example.com ROOT_URL = https://gogs.example.com/ //Gogsの再起動 $ sudo systemctl restart gogshttps://gogs.example.comにアクセスできれば,成功です
参考文献
https://linuxize.com/post/how-to-install-and-configure-gogs-on-ubuntu-18-04/
- 投稿日:2020-03-24T11:38:36+09:00
VSCode で「Git: remote: HTTP Basic: Access denied」というエラーメッセージが出たときの対処方法
VSCode で「Git: remote: HTTP Basic: Access denied」というエラーメッセージが出たときの対処方法
Gitサーバー側のIDのパスワードなどを更新した場合に出る模様。
要するに、Windowsが覚えている「資格情報」を更新すればよいのだが、更新するには、いったん削除するしか手段が無いっぽい。
詳しい情報はこちら↓
資格情報マネージャーにアクセスする
適用対象: Windows 10
https://support.microsoft.com/ja-jp/help/4026814/windows-accessing-credential-manager対処方法
(1)
コントロールパネル>ユーザーアカウント>資格情報マネージャー
を開いて、「Windows資格情報」を選択
(2)
汎用資格情報から、該当する(エラーになる) Gitサーバーを選択して「削除」する。
(3)
再度、VSCode から、Gitにアクセス(例えば「変更の同期」とか)をすると、IDとパスの入力を求められる。
ここで正しい情報(あたらしいパスワード)を入れればつながるようになる、、、、はず。
以上、わかってしまえば簡単なことなんだけど、なかなかたどり着けないんですよねー。
みなさまのプログラミングライフの助けになれば幸いです。
- 投稿日:2020-03-24T11:33:51+09:00
SourcetreeからGitKrakenに移行しました?
おはようございます?
突然ですが久野は今チームでアプリを開発しています.そこではみんなGitKrakenを使っているのでお前も使えということで愛用だった(べつに使いこなしてはいない)SourcetreeからGitKrakenに移行しました.ヒィ
Sourcetree
日本人ならGit初心者はみんなSourcetree使うんじゃないかと勝手に考えています.日本語表示だし,GUIが見やすくてすごく直感的に操作できます.1人で開発したものを永遠GithubにあげるだけならSourcetreeでいいと思います.
GitKraken
ここからダウンロードできます.
チーム開発で
1.「だれが」「どこをコミットしたか」を視覚的に見る
2.developとbrunchのコードをワンクリックで行き来する
ってことができるのがGitkrakenの良いところです.備忘録
- WIP
- クリックすると右に編集中の画面がでる
おわり?
何か知るたびに備忘録を更新していきます.
エディタでもなんでも黒背景よりも白背景のが好きなので,Gitkrakenもライトモード欲しい.
- 投稿日:2020-03-24T01:37:06+09:00
git checkoutって色んな意味持たせ過ぎじゃない?
きっかけ
前回の記事(「こんなことしたい」って時にどんなgitコマンド使えば良いのか?)を書いているときに、
コマンドについて下図のようなお絵かきをして整理していたのですが
git checkoutって状況/条件によって挙動が色々ありすぎじゃない?※ちなみにお絵かきしている途中で同じような物を公式がチートシートとして用意していることに気づきました...
git checkoutの挙動整理ブランチ名を指定した場合
ローカルブランチに存在する リモート追跡ブランチに存在する git checkoutの挙動× × ブランチを切り出す × ○ リモートからブランチをローカルリポジトリ内に持ってくる ○ ○ 参照するローカルブランチを切り替える ファイル名を指定した場合
ワーキングツリー内の指定したファイルの編集内容をローカルブランチの内容でもとに戻す
チェックアウトという名前の範囲から逸脱していないか?
ブランチを切り出したり、ブランチを切り替えたり、ファイルの編集内容をもとに戻したりと
チェックアウトという名前を付けられていながら、実際にはある意味やりたい放題のコマンドになっている印象が強いです。(svnをずっと触っていたこともあり)チェックアウトとは、「リポジトリから何かしらを持ってくる」ものだと思っていまいたため、gitを触り始めたときに「???」となったポイントの一つでした
新しいオフィシャル見てみたら新しいコマンドが追加されてた
このやりたい放題の
git checkoutについてgitのオフィシャルを読んでいたら最後のsee alsoにそれっぽい名前のコマンドが書かれていました。
コマンド 内容 git switchSwitch branches(ブランチ切替) git restoreRestore working tree files(ワーキングツリー内ファイルの復元) どうやら去年(2019年)の8月のアップデート2.23.0で追加されたコマンドのようです。
※使っていたgitが2.21.?だったので気づきませんでした……新コマンド含めて、役割を再整理しよう
やりたいこと 使うコマンド ブランチ切り出し git branchブランチ取得 git checkoutブランチ切替 git switchファイル復元/編集内容取消 git restore以後こんな感じで整理してコマンドを理解しておけば変なこともないよね?
と思っていたのですが
git switchとgit restoreのDESCRIPTIONにこんな記載がありましたTHIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
- これは実験的なコマンドなので、挙動が変わる可能性があるよ
結論
やりたいこと 使うコマンド ブランチ切り出し git branchブランチ取得 git checkoutブランチ切替 git checkoutgit switchファイル復元/編集内容取消 git checkoutgit restore
- コマンドの役割分担的に考えて、少なくともブランチ切り出しは
git branchで良いと思う- ブランチ切替、ファイル復元は新コマンド(
git switchとgit restore)が用意されているが、変更される可能性があるのでしばらくは様子見してgit checkoutを使い続けた方が良さそうと言う微妙な結論になりました。
新コマンドの注意書きにでは挙動が変更となる可能性という書き方なので、少なくともコマンドがなくなる事はなさそうなので、今後のgitのリリースで
git switchとgit restoreがどうなるのか注目しておいたほうが良さそうですね。
- 投稿日:2020-03-24T01:29:00+09:00
git pull時に 【Your local changes to the following files would be overwritten by merge】とエラー
エラー内容
$ git pull origin masterをすると
error: Your local changes to the following files would be overwritten by merge: config/routes.rb Please commit your changes or stash them before you merge.が出てくる。
原因
pullした内容と自分の編集した箇所(ここではconfig/routes.rb)が被っている。
解決策
pullした内容の箇所が自分も編集している所の為、
mergeする前にcommitするかstashしてと言われる。なので、今回はコミットを選択。
$ git add * $ git commit -m "コミット名" $ git push origin 自分の作業ブランチでpushし、Github上で
コンフリクトが起きなければ再度、$ git pull origin masterとpullすればOK。
コンフリクトの場合はコンフリクト内容を修正してから再度、pull。






