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

故障かな?とおもったら【Git編】

故障かな?とおもったら

現象・症状 ご確認いただくこと 対処方法
gitコマンドが使えない .gitがありますか git initで初期化する
git clone リポジトリURLでクローンする
git addできない ファイルが.gitignoreの対象になっていますか 別のディレクトリに配置する
追跡対象外のファイルであっているか確認する
git commitできない git config --listuser.emailuser.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 add or git commit or git checkout時、Warningが表示される Windows環境が開発に関わると、設定によって改行コードが変換されることがあります git config --global core.autocrlf [true input false]で設定する
ブランチを削除しているのに、減っていない気がする リモートブランチは開発者自身で意図的に削除しない限り、ローカルには残り続けます git fetch -pをお試しください
編集してないのにgit blameで未コミットの行が表示される 改行、スペースで影響を受けることがあります git blame -wをお試しください

書こうと思ったきっかけ

どうしてもプロジェクトで数人はGit初心者という方がいるので、その方々がよく引っかかりそうなところで、自己解決できる&もし失敗しても復旧ができそうなところをピックアップしてみました
見逃しや抜けがあると思うので、コメントで教えて下さい
気が向いたら他のパートも記事にする予定

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

gitで対象ファイルをあるコミット履歴の状態に戻す

git checkout コミットハッシュ値 ファイルパス

git checkout abcdefghijklmnopqrstuvwxyz hoge/fuga.txt
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

チーム開発をして感じたこと

この記事はなに

高校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人で勝手に仕様変更せずにちゃんとみんなで話し合って同意を得ましょう。自分がこうした方がいいって思って勝手に消してしまうと、他の部分との兼ね合いでバグが生まれたりしてはいけないので、ちゃんと全員で相談しましょう。

最後に

こんな記事に最後まで読んでいただきありがとうございました。

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

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 /tmp

tarの解凍

解凍
$ sudo tar xf /tmp/gogs_*_linux_amd64.tar.gz -C /home/git

Gogsインストールディレクトリの所有権をユーザーおよびグループgitに変更

権限の変更
$ sudo chown -R git: /home/git/gogs

Systemdユニットファイルのコピー

$ sudo cp /home/git/gogs/scripts/systemd/gogs.service /etc/systemd/system/

gogs鯖の起動と確認

$ sudo systemctl start gogs
$ sudo systemctl enable gogs
$ sudo systemctl status gogs

webインストーラー

webインターフェースを開いて設定を行なっていきます

./web gogs

http://127.0.0.1:3000をブラウザで開いて設定を行います.

gogs-install.jpg

上のはGogsの公式が出している画像です.MySqlを使いたい場合,文字コードをUTF8にしたデータベースをMysqlで先に作っておきましょう.

Nginxの設定をします.
Nginxが入っていない人は導入をして,次のファイルを開いて編集します.

sudo nano /etc/nginx/sites-enabled/gogs.example.com
server {
    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 gogs

https://gogs.example.comにアクセスできれば,成功です

参考文献

https://linuxize.com/post/how-to-install-and-configure-gogs-on-ubuntu-18-04/

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

VSCode で「Git: remote: HTTP Basic: Access denied」というエラーメッセージが出たときの対処方法

VSCode で「Git: remote: HTTP Basic: Access denied」というエラーメッセージが出たときの対処方法

image.png

Gitサーバー側のIDのパスワードなどを更新した場合に出る模様。

要するに、Windowsが覚えている「資格情報」を更新すればよいのだが、更新するには、いったん削除するしか手段が無いっぽい。

詳しい情報はこちら↓
資格情報マネージャーにアクセスする
適用対象: Windows 10
https://support.microsoft.com/ja-jp/help/4026814/windows-accessing-credential-manager

対処方法

(1)

コントロールパネル>ユーザーアカウント>資格情報マネージャー

を開いて、「Windows資格情報」を選択

image.png

(2)

汎用資格情報から、該当する(エラーになる) Gitサーバーを選択して「削除」する。

(3)

再度、VSCode から、Gitにアクセス(例えば「変更の同期」とか)をすると、IDとパスの入力を求められる。

image.png

ここで正しい情報(あたらしいパスワード)を入れればつながるようになる、、、、はず。

以上、わかってしまえば簡単なことなんだけど、なかなかたどり着けないんですよねー。

みなさまのプログラミングライフの助けになれば幸いです。

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

SourcetreeからGitKrakenに移行しました?

おはようございます?

突然ですが久野は今チームでアプリを開発しています.そこではみんなGitKrakenを使っているのでお前も使えということで愛用だった(べつに使いこなしてはいない)SourcetreeからGitKrakenに移行しました.ヒィ

Sourcetree

sourcetree

日本人ならGit初心者はみんなSourcetree使うんじゃないかと勝手に考えています.日本語表示だし,GUIが見やすくてすごく直感的に操作できます.1人で開発したものを永遠GithubにあげるだけならSourcetreeでいいと思います.

GitKraken

gitkraken

ここからダウンロードできます.

チーム開発で
1.「だれが」「どこをコミットしたか」を視覚的に見る
2.developとbrunchのコードをワンクリックで行き来する
ってことができるのがGitkrakenの良いところです.

備忘録

  • WIP
    •  クリックすると右に編集中の画面がでる

おわり?

何か知るたびに備忘録を更新していきます.
エディタでもなんでも黒背景よりも白背景のが好きなので,Gitkrakenもライトモード欲しい.

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

git checkoutって色んな意味持たせ過ぎじゃない?

きっかけ

前回の記事(「こんなことしたい」って時にどんなgitコマンド使えば良いのか?)を書いているときに、
コマンドについて下図のようなお絵かきをして整理していたのですが

コマンドの整理

git checkoutって状況/条件によって挙動が色々ありすぎじゃない?

※ちなみにお絵かきしている途中で同じような物を公式がチートシートとして用意していることに気づきました...

git checkoutの挙動整理

ブランチ名を指定した場合

ローカルブランチに存在する リモート追跡ブランチに存在する git checkoutの挙動
× × ブランチを切り出す
× リモートからブランチをローカルリポジトリ内に持ってくる
参照するローカルブランチを切り替える

ファイル名を指定した場合

ワーキングツリー内の指定したファイルの編集内容をローカルブランチの内容でもとに戻す

チェックアウトという名前の範囲から逸脱していないか?

ブランチを切り出したり、ブランチを切り替えたり、ファイルの編集内容をもとに戻したりと
チェックアウトという名前を付けられていながら、実際にはある意味やりたい放題のコマンドになっている印象が強いです。

(svnをずっと触っていたこともあり)チェックアウトとは、「リポジトリから何かしらを持ってくる」ものだと思っていまいたため、gitを触り始めたときに「???」となったポイントの一つでした

新しいオフィシャル見てみたら新しいコマンドが追加されてた

このやりたい放題のgit checkoutについてgitのオフィシャルを読んでいたら最後のsee alsoにそれっぽい名前のコマンドが書かれていました。

コマンド 内容
git switch Switch branches(ブランチ切替)
git restore Restore working tree files(ワーキングツリー内ファイルの復元)

どうやら去年(2019年)の8月のアップデート2.23.0で追加されたコマンドのようです。
※使っていたgitが2.21.?だったので気づきませんでした……

新コマンド含めて、役割を再整理しよう

やりたいこと 使うコマンド
ブランチ切り出し git branch
ブランチ取得 git checkout
ブランチ切替 git switch
ファイル復元/編集内容取消 git restore

以後こんな感じで整理してコマンドを理解しておけば変なこともないよね?
と思っていたのですが
git switchgit restoreのDESCRIPTIONにこんな記載がありました

THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.

  • これは実験的なコマンドなので、挙動が変わる可能性があるよ

結論

やりたいこと 使うコマンド
ブランチ切り出し git branch
ブランチ取得 git checkout
ブランチ切替 git checkout git switch
ファイル復元/編集内容取消 git checkout git restore
  • コマンドの役割分担的に考えて、少なくともブランチ切り出しはgit branchで良いと思う
  • ブランチ切替、ファイル復元は新コマンド(git switchgit restore)が用意されているが、変更される可能性があるのでしばらくは様子見してgit checkoutを使い続けた方が良さそう

と言う微妙な結論になりました。

新コマンドの注意書きにでは挙動が変更となる可能性という書き方なので、少なくともコマンドがなくなる事はなさそうなので、今後のgitのリリースでgit switchgit restoreがどうなるのか注目しておいたほうが良さそうですね。

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

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。

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