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

Gitでやると嫌われること

Gitアドベントカレンダー18日目です。遅れてすいません。

Git使うことによる利点はいっぱいですがこんな人は嫌われます。

自分も最近はGIT使いになったのでこれまでのあったことで困ったことを書いておこうと思います。
思い当たった人ごめんなさい。

しょっ中git pushしちゃう。

これ実は前職で経験したのですがSubversionと間違えてしょっ中Gitに上げちゃう人います。
これ一番困るんです。
何故なら常に開発していると一定間隔でcommitするんですが。
割り込まれちゃうので自分のソースが消えると言ったことが何度かありました。
Subversionみたいに常にリモート管理んらやらなくてはいけませんが。
Gitは分散管理です。
自分のところで開発コードが管理できます。
Git commitは自分のパソコンにソースを管理するコマンドです。
開発がある程度迷惑をかけない時点でgit pushでリモートサーバにソースコードを送信します。
これがGitの鉄則です。

自分の開発ソースがどこになるか見失う

実はこれは私が去年やらかしました。
あまりにもGit pushの嵐に困った自分は開発用gitと管理用Gitに分けて自分のパソコンに保存していました。
ところがそのソースがないとできない開発が出てきてしまい管理用に一回git pullしてから開発すればいいやと思い作業していましたが間違って開発用のgitにpullしてしまい開発ソースを何回か破棄してしまいました。
当然開発は遅れます。

ビルドが遅れる

これは実は半年前の職場でやってしまったことなんですが。
gitブランチが多くあるとどのブランチが自分の環境にあるか確認する作業が当然のことでてきます。
実際は上司がやることになっているのですが忘れてしまい何度かビルドが止まると言う手痛い事がありました。
自分はハード系は初心者でしたがLinuxの知識はそれなりにありました。
でも、それではハード系では生きてはいけないと言うことを痛感させられました。
あと言えることは先輩のミスでもかぶるのはビルダーということです。
今はどののようにしてるかはわかりませんがプレビルドしてるのかな???。

嫌なことばかり書いてますが。いい点は多いですよ。

良い点といえば自分の環境が汚れない。
これに越したことはありません。
SubversionやCVSの嫌なところはリモートで管理しているため簡単にソースが他の人に書き換えられてしまいしょっ中修正に追われてしまうことです。
Gitは分散管理なので自分のコードを書いてテストしてからあげることができます。
その分だけ人の修正が減るわけです。

最後にこれだけは言わせてください。
Linusさすが俺たちのGod様こんなツール作ってくれてありがとう

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

Gitでビルド番号を出す

Windowsのビルド番号の様に使ったのでメモ

コミットの数をビルド番号として対応
printfで5桁のゼロ埋めをしています

$ printf %05d "$(git log --oneline | wc -l)"
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

成果物を作った際のgitの使い方の反省点

ミス、その1

gitの弱点としてファイル名の変更はバージョン管理できていないということです。
例えば、これは自分が実際に起こったミスですがAbout.vueと記載していたつもりがAを小文字のaにしてabout.vueと記載していました。
developブランチでそれに気が付いて、About.vueに変更し、masterブランチにマージするとなんとabout.vueのままで変更がされていませんでした。
vueの場合、コマンドでローカル環境を立ち上げるので2度手間です。

またあればどんどん追加していきます。

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

成果物を作った際に起きたgitの使い方の反省点

ミス、その1

gitの弱点としてファイル名の変更はバージョン管理できていないということです。
例えば、これは自分が実際に起こったミスですがAbout.vueと記載していたつもりがAを小文字のaにしてabout.vueと記載していました。
developブランチでそれに気が付いて、About.vueに変更し、masterブランチにマージするとなんとabout.vueのままで変更がされていませんでした。
vueの場合、コマンドでローカル環境を立ち上げるので2度手間です。

その2

成果物作る際にエラーが起こった場合にブランチを作成するのだが、解決したらすぐに削除すること。また自動デプロイを導入している場合は必ず、いきなり本番環境にマージしないでかならずdevelopブランチを経由すること。あるいはdevelopブランチを経由しない場合はエラーが解決したらかならずdevelopブランチも削除すること。

ちょっと文章が伝わりにくいので、どんどん修正していきます。

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

【Git】ブランチ切り替えできない時。ブランチの派生元確認方法と削除方法。

概要

git branchの超基本的な理解とgit checkoutができない場合のエラー解決法について書いています。

エラー内容

$ git checkout [移動先のブランチ名]

でgit branchを移動しようとした際にエラーが発生。

error: Your local changes to the following files would be overwritten by checkout:
    ファイル名
Please, commit your changes or stash them before you can switch branches.
error: The following untracked working tree files would be overwritten by checkout:
    ファイル名
Please move or remove them before you can switch branches.
Aborting

ワーキングツリーに知らないファイルがあるので、コミットかスタッシュしてからブランチ移動しろとのこと。

原因確認

エラー発生時のgit branchの状況は以下。

  master
  step4
* step5

step4で実装した機能をプルリクしている状況の中で
step5のブランチを切って進めている時。

確認してみるとstep5にいる時のファイルがstep4の時のファイル内容と異なっている。
さらに、masterには移動ができる状態だったのでstep4→step5ではなく、master→step5とブランチを切ってしまっているなと気づきブランチの派生状況を確認するため以下で今のブランチの派生元ブランチを特定。

$ git show-branch
* [master] Merge pull request #3 from ktanizaw/step3
 ! [step4] add:管理画面アクセス制限、削除制限
  ! [step5] Merge pull request #3 from ktanizaw/step3
---
 +  [step4] add:管理画面アクセス制限、削除制限
 +  [step4^] add:ユーザー管理画面
 +  [step4~2] add:ログイン時のユーザー機能制御
 +  [step4~3] add:ユーザー作成タスク詳細画面
 +  [step4~4] add:管理者画面、ユーザー一覧、削除、編集、作成
 +  [step4~5] add:ログイン・ログアウト機能
 +  [step4~6] add:ログイン・ログアウト機能
 +  [step4~7] add:seedデータ、アソシエーション
--- [master] Merge pull request #3 from ktanizaw/step3

*が現在のブランチ。
!がその他のブランチ。

ブランチの右には最新コミットが表示されている。
masterとstep5の最新コミットが同じということで、
やはりmasterからstep5のブランチを作成していた。

---以下についている+はコミット内容で、インデントが揃っているブランチに対してのコミット。
今回はstep4にのみコミットしていたので全てstep4のインデントと同じになっている。

解決方法

step5の内容をstep4と同じにしてからコード追加をしたいだけだったため、
間違えて作成したstep5のブランチを削除することに。
移動ができない原因の不要なファイルを削除して、masterに移動してstep5を削除していきます。

$ git status


でファイルの状況を確認し、赤文字の中にある
Changes not staged for commit:のファイルは以下で削除。

$ git checkout file_name #特定のファイル
$ git checkout . #すべて


Untracked files:のファイルは以下で削除。

$ git clean -f
$ git branch -d [ブランチ名]

これでスッキリして、新しく正しい位置からブランチを作成できました。

参考

https://qiita.com/konweb/items/061475d6376db957b3c4
https://qiita.com/hogeta_/items/33d2334c9b1919bd5120

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

AzureDevOpsでマージしたブランチを元に戻す(Revert)

まだ merge するつもりじゃなかったのに、Pull Request(以下PR) を Completeして merge してしまった!

どうしよう・・・

そんな時、どうすれば戻せるのかってときに役立てるかと思いメモします。(あとはConflict:競合が発生したときにこのPR一旦戻したいときとか)

(実際に戻したわけではないので戻した後、ちゃんと変更履歴とかが残ってるのかはわかりません。戻るだろうなって確信を得ているので記事にします。)

それと初めて Revert という機能を使用したのでメモします。

やったこと

PRをCompleteすると上のほうに、緑の四角形が出てると思います。

その右端に[Revert]ってボタンがあります。

  • Revert:日本語訳 元も戻す

その名の通り、Completeした内容を元に戻せます。

押したらあっという間に魔法のように戻ると思ってました。

そんなわけあるわけないんですけど。

[Revert]ボタンを押すと以下のDialogが出てくると思います。

Revert1.png

「Revert pull request <プルリクエスト番号>」

  • Target:このPR先ブランチ名
  • Topic branch name:新規ブランチ名

項目ごとにみるとデフォルトでこんな感じのことが書いてあります。

Revertを押すと、このPRを打ち消すブランチ(Topic branch name)を作成してくれるようです。

つまり、このブランチから間違えてmergeしてしまったブランチに対してPull Requestを送り、それをCompleteすることでようやく元に戻せるようです。

実際にPRだけ作成して、対象Fileをみると間違えてマージした内容を打ち消すような変更がありましたので、安心しました。

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

git clean で管理外のGitサブディレクトリを消す

git clean -fd で消えない子達を消す方法。

Gitリポジトリの中に別のリポジトリを持ってきていると、git clean -fd では以下のようになって全ては消せない。

$ git clean -fd
Skipping repository sub-repo/

ありそうな状況としては、submoduleの検討段階とか?

Conclusion

git clean -ffd で全消しできる。

git clean help を読む

git clean -f の説明によると、-fだけだと.gitのあるディレクトリは消さないのでf2つ付けろと書いてある。

-f, --force
    If the Git configuration variable clean.requireForce is not set to false, git clean will refuse to delete files or
    directories unless given -f, -n or -i. Git will refuse to delete directories with .git sub directory or file unless a
    second -f is given.

参考

https://github.com/gitlabhq/gitlab-ci-runner/pull/141

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

[学習記録]Railsチュートリアル[1.4.x~1.5.x][2019/12/18]

TL;DR

  • n(n∈N≧2)番煎じの「Railsチュートリアルの備忘録的Something」

  • Railsチュートリアル1章の1.4「Gitによるバージョン管理」から1.5「デプロイする」を参考に、Git及びBitbucketのセットアップを行い、Herokuにデプロイするまでの手順をまとめた。

  • コマンドの詳細な説明は省き、このコマンドは何をするためのコマンドであるかについてだけ書いておく。


1.4 Gitによるバージョン管理

1.4.1 インストールとセットアップ

//systemセットアップ
git config --global user.name "Your Name"
git config --global user.email your.email@example.com

//git initでセットアップ
cd Railsアプリケーションのルートディレクトリ
git init

//プロジェクトのファイルをリポリトジに追加
git add -A

//待機中のプロジェクトファイルの状態を確認する
git status

//ステージングエリアで控えている変更をリポリトジにコミットする
git commit -m "commit message"

//commit messageの確認
git log

1.4.2 Gitのメリット

重要なディレクトリやファイルを削除してしまっても復旧が容易にできる

//ある重要なディレクトリ(app/controllers/)を削除してしまった
rm -rf app/controllers/

//現在の状態を確認
git status
 On branch master
 Changed but not updated:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

      deleted:    app/controllers/application_controller.rb

 no changes added to commit (use "git add" and/or "git commit -a")

//変更が行われたのは現在の作業ツリー内のみなので、以前のコミットをチェックアウトする
git checkout -f

//app/controllers/が存在するか確認する
ls app/controllers/
 application_controller.rb  concerns/

//app/controllers/が存在していることが分かったので復旧終了

1.4.3 Bitbucketを利用するための準備

//作成した公開鍵を出力する
cat ~/.ssh/id_rsa.pub

//Bitbucketへのリポリトジの追加
git remote add origin git@bitbucket.org:ユーザー名/Railsアプリケーションの名前.git

//リポリトジへのプッシュ
git push -u origin --all

1.4.4 gitの操作の練習

例.README.mdファイルについて操作する

Branch

//トピックブランチ(短期間だけ使う一時的なブランチ)を作成し、それに切り替える
git checkout -b modify-README

//すべてのローカルブランチを表示
git branch
//現在使用中のブランチには*がつく
  master
* modify-README

Edit

//Railsアプリケーションのルートディレクトリに移動
cd Railsアプリケーションのルートディレクトリ

//READMEを編集(変更内容はなんでもいい)
vi README.md
[README.md]
# Ruby on Rails Tutorial
## "hello, world!"
This is the first application for the
[*Ruby on Rails Tutorial*](https://railstutorial.jp/)
by [Michael Hartl](http://www.michaelhartl.com/). Hello, world!

Commit

//ブランチの状態を確認
git status

//現存するすべてのファイルへの変更を一括でコミットする
//commit messageは現在形かつ命令形で書くようにすること
//例. Improve the README file
git commit -a -m "commit message"

Merge

//masterブランチに移動
git checkout master
//masterブランチにmodify-READMEの変更をマージする
git merge modify-README
//トピックブランチを削除する(任意)
git branch -d modify-README

Push

//Bitbucketに変更を反映させる
git push

1.5 デプロイする

1.5.1 Herokuのセットアップ

//本番環境(production)にpg gemをインストール
vi Gemfile
[Gemfile]
group :development, :test do
  gem 'sqlite3', '1.3.13'
end
group :production do
  gem 'pg', '0.20.0'
end
を追記

//本番用以外のgemをインストール
bundle install --without production

//変更した内容をコミットする
git commit -a -m "Update Gemfile for Heroku"

Herokuのアカウントを作成 -> Heroku公式サイト

//Heroku CLIをインストールする(Cloud9限定)
source <(curl -sL https://cdn.learnenough.com/heroku_install)

//Herokuのバージョンを確認(= Herokuが正常にインストールされたかを確認)
heroku --versionw
  heroku/7.35.0 linux-x64 node-v12.13.0

//Herokuにログインする
heroku login --interactive

//HerokuにSSHキーを追加
heroku keys:add

//Herokuサーバーにサンプルアプリケーションの実行場所を追加
heroku create

1.5.2 Herokuにデプロイする(1)

//Gitを用いてHerokuにリポリトジをプッシュする
git push heroku master

1.5.3 Herokuにデプロイする(2)

heroku createを実行した際に生成されたアドレスをブラウザで表示する。

ブラウザはなんでもいいと思う(要検証)

1.5.4 Herokuコマンド

herokuコマンド一覧

//アプリケーションの名前を変更する
//ただし、Application-nameはユニークな(他と被らないような)名前にすること
heroku rename Application-name

//小文字のアルファベットからランダムに7つ選んだ文字列を生成する
('a'..'z').to_a.shuffle[0..7].join

//Herokuアプリのログをリアルタイムで確認する
heroku rails --tail
or
heroku logs -t

参考

vdeep / Herokuでよく使うコマンドまとめ

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