20210603のGitに関する記事は12件です。

[Swift]Dateの使用でいつもハマるので自分用に記事を書いてみた[SwiftUI]

今回作成したアプリ はじめに 今回はユニットテストについて学びたく勉強していたところ”Date使ってテスト書くといいよ”と言うアドバイスを頂いたので挑戦してみたらDateに関して結構勉強になったのでまとめてみました。 またUIKitとSwiftUIの両方で書いてみたのでUIKitはGitで公開し、この記事では主にSwiftUIで書いたものを掲載していきます。 環境 ・ macOS Big Sur 12 ・ Xcode : 12.5 Dateを使ってみる 今回は記録した日時と、現在の日時の差分によって表示するものを変えると言う実装をする為、とにかくDateを使用する所から始めた。 @State var dateText = "" var body: some View { VStack { Button(action: { let date = Date() dateText = "\(date)" }, label: { Text("Button") }) Text(dateText) } } 上記のコードはボタンを押すと現在の日時を取得して表示すると言うもの。 Formatterを使用して表示を定義する ただ表示するだけって基本的にあまり使用する事はないので基本”Date使うならFormatter”ぐらいの勢いで必要な気がする。 時間と分だけを表示させたい場合は以下の通り(Buttonのaction内以外は省略) let date = Date() let dateFormat = DateFormatter() dateFormat.dateFormat = "HH:mm" dateText = dateFormat.string(from: date) .dateFormatでは表示する日時の表現を定義できる。以下表にまとめた。 年 月 日 時間 分 秒 YYYY MM dd HH mm ss 2021 6 3 22 26 45 エリアの指定は.locale エリアの指定をしておかないと正確な時間が取れないのでこちらもデフォルトで書く。 dateFormat.locale = Locale(identifier: "jp_JP") エリアの指定を日本にした時は特に和暦に気を付ける これも最初わからなかった部分だが、iPhoneの設定で和暦を設定しているとYYYYの西暦表示の部分がめちゃくちゃな数字を返してくる時がある。 上記を防ぐには予め .timeStyleと.dateStyleを定義しておくとよい。 let dateFormat = DateFormatter() dateFormat.timeStyle = .full dateFormat.dateStyle = .full dateFormat.locale = Locale(identifier: "ja_jp") dateFormat.dateFormat = "YYYY/MM/dd HH:mm:ss" let date = Date() dateText = dateFormat.string(from: date) dateFormat.dateFormat = "YYYY/MM/dd HH:mm :ss"を削除すると以下のように表示される。 時間の差分を取得したい場合 timeIntervalSinceを使用すると差分が簡単に取れる。 @State var dateText = "" var body: some View { VStack { Button(action: { let dateFormat = DateFormatter() // 日時をString型で定義 let textLogDate = "2021-01-01 12:00:00" let textNowDate = "2021-01-01 12:01:20" // styleで和暦設定に対応 dateFormat.timeStyle = .full dateFormat.dateStyle = .full // dateFormatを初期設定した"2021-01-01 12:00:00"と同じ形式になるように定義 dateFormat.dateFormat = "yyyy-MM-dd HH:mm:ss" // localeを日本に dateFormat.locale = Locale(identifier: "ja_JP") // String型の日時をDate型に変換 let logDate = dateFormat.date(from: textLogDate) ?? Date() let nowDate = dateFormat.date(from: textNowDate) ?? Date() // timeIntervalSinceを使用すると差分を取得できる->nowDate-logDate let dateSubtraction: Int = Int(nowDate.timeIntervalSince(logDate)) dateText = "\(dateSubtraction)" }, label: { Text("Button") }) Text(dateText) } } なお、取得した差分は秒数の為、今回は80秒となる。 以上これからを使用して日時の差分を取得するアプリを作成してユニットテストを書いてみました。(こちらはUIKitで書きました) https://github.com/yuujioka/TimeCalculate まとめ 毎度毎度Dateの差分を取るときに演算しようとしたりして、アレ?ってなったり、Dateの形式指定するときにアレ?ってなったり、日時を指定したものをDate型にするときにアレ?となり、同じような鉄釘踏みまくっていたのでいい加減鉄ゲタ履こうと自分用に書きました! また日時取得はDateだけでなく、Calendarクラスを使用して取得、加工することも可能なので是非そちらもチャレンジしてみたいと思います!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[Swift]Dateの使用でいつもハマるので自分用に記事を書いてみた

今回作成したアプリ はじめに 今回はユニットテストについて学びたく勉強していたところ”Date使ってテスト書くといいよ”と言うアドバイスを頂いたので挑戦してみたらDateに関して結構勉強になったのでまとめてみました。 またUIKitとSwiftUIの両方で書いてみたのでUIKitはGitで公開し、この記事では主にSwiftUIで書いたものを掲載していきます。 環境 ・ macOS Big Sur 12 ・ Xcode : 12.5 Dateを使ってみる 今回は記録した日時と、現在の日時の差分によって表示するものを変えると言う実装をする為、とにかくDateを使用する所から始めた。 @State var dateText = "" var body: some View { VStack { Button(action: { let date = Date() dateText = "\(date)" }, label: { Text("Button") }) Text(dateText) } } 上記のコードはボタンを押すと現在の日時を取得して表示すると言うもの。 Formatterを使用して表示を定義する ただ表示するだけって基本的にあまり使用する事はないので基本”Date使うならFormatter”ぐらいの勢いで必要な気がする。 時間と分だけを表示させたい場合は以下の通り(Buttonのaction内以外は省略) let date = Date() let dateFormat = DateFormatter() dateFormat.dateFormat = "HH:mm" dateText = dateFormat.string(from: date) .dateFormatでは表示する日時の表現を定義できる。以下表にまとめた。 年 月 日 時間 分 秒 YYYY MM dd HH mm ss 2021 6 3 22 26 45 エリアの指定は.locale エリアの指定をしておかないと正確な時間が取れないのでこちらもデフォルトで書く。 dateFormat.locale = Locale(identifier: "jp_JP") エリアの指定を日本にした時は特に和暦に気を付ける これも最初わからなかった部分だが、iPhoneの設定で和暦を設定しているとYYYYの西暦表示の部分がめちゃくちゃな数字を返してくる時がある。 上記を防ぐには予め .timeStyleと.dateStyleを定義しておくとよい。 let dateFormat = DateFormatter() dateFormat.timeStyle = .full dateFormat.dateStyle = .full dateFormat.locale = Locale(identifier: "ja_jp") dateFormat.dateFormat = "YYYY/MM/dd HH:mm:ss" let date = Date() dateText = dateFormat.string(from: date) dateFormat.dateFormat = "YYYY/MM/dd HH:mm :ss"を削除すると以下のように表示される。 時間の差分を取得したい場合 timeIntervalSinceを使用すると差分が簡単に取れる。 @State var dateText = "" var body: some View { VStack { Button(action: { let dateFormat = DateFormatter() // 日時をString型で定義 let textLogDate = "2021-01-01 12:00:00" let textNowDate = "2021-01-01 12:01:20" // styleで和暦設定に対応 dateFormat.timeStyle = .full dateFormat.dateStyle = .full // dateFormatを初期設定した"2021-01-01 12:00:00"と同じ形式になるように定義 dateFormat.dateFormat = "yyyy-MM-dd HH:mm:ss" // localeを日本に dateFormat.locale = Locale(identifier: "ja_JP") // String型の日時をDate型に変換 let logDate = dateFormat.date(from: textLogDate) ?? Date() let nowDate = dateFormat.date(from: textNowDate) ?? Date() // timeIntervalSinceを使用すると差分を取得できる->nowDate-logDate let dateSubtraction: Int = Int(nowDate.timeIntervalSince(logDate)) dateText = "\(dateSubtraction)" }, label: { Text("Button") }) Text(dateText) } } なお、取得した差分は秒数の為、今回は80秒となる。 以上これからを使用して日時の差分を取得するアプリを作成してユニットテストを書いてみました。(こちらはUIKitで書きました) https://github.com/yuujioka/TimeCalculate まとめ 毎度毎度Dateの差分を取るときに演算しようとしたりして、アレ?ってなったり、Dateの形式指定するときにアレ?ってなったり、日時を指定したものをDate型にするときにアレ?となり、同じような鉄釘踏みまくっていたのでいい加減鉄ゲタ履こうと自分用に書きました! また日時取得はDateだけでなく、Calendarクラスを使用して取得、加工することも可能なので是非そちらもチャレンジしてみたいと思います!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[Swift]Dateの使用でいつもハマるので記事を書いてみた

今回作成したアプリ はじめに 今回はユニットテストについて学びたく勉強していたところ”Date使ってテスト書くといいよ”と言うアドバイスを頂いたので挑戦してみたらDateに関して結構勉強になったのでまとめてみました。 またUIKitとSwiftUIの両方で書いてみたのでUIKitはGitで公開し、この記事では主にSwiftUIで書いたものを掲載していきます。 環境 ・ macOS Big Sur 12 ・ Xcode : 12.5 Dateを使ってみる 今回は記録した日時と、現在の日時の差分によって表示するものを変えると言う実装をする為、とにかくDateを使用する所から始めた。 @State var dateText = "" var body: some View { VStack { Button(action: { let date = Date() dateText = "\(date)" }, label: { Text("Button") }) Text(dateText) } } 上記のコードはボタンを押すと現在の日時を取得して表示すると言うもの。 Formatterを使用して表示を定義する ただ表示するだけって基本的にあまり使用する事はないので基本”Date使うならFormatter”ぐらいの勢いで必要な気がする。 時間と分だけを表示させたい場合は以下の通り(Buttonのaction内以外は省略) let date = Date() let dateFormat = DateFormatter() dateFormat.dateFormat = "HH:mm" dateText = dateFormat.string(from: date) .dateFormatでは表示する日時の表現を定義できる。以下表にまとめた。 年 月 日 時間 分 秒 YYYY MM dd HH mm ss 2021 6 3 22 26 45 地域や言語に関してはLocaleを使用する dateFormat.locale = Locale(identifier: "jp_JP") Localeで使用するIDの一覧↓ 地域ごとの時間を取得する時はTimeZoneを使用する dateFormat.timeZone = TimeZone(identifier: "Asia/Tokyo") TimeZoneで使用するIDの一覧↓ 和暦に気を付ける これも最初わからなかった部分だが、iPhoneの設定で和暦を設定しているとYYYYの西暦表示の部分がめちゃくちゃな数字を返してくる時がある。 上記を防ぐには予め .timeStyleと.dateStyleを定義しておくとよい。 let dateFormat = DateFormatter() dateFormat.timeStyle = .full dateFormat.dateStyle = .full dateFormat.locale = Locale(identifier: "ja_jp") dateFormat.dateFormat = "YYYY/MM/dd HH:mm:ss" let date = Date() dateText = dateFormat.string(from: date) dateFormat.dateFormat = "YYYY/MM/dd HH:mm :ss"を削除すると以下のように表示される。 時間の差分を取得したい場合 timeIntervalSinceを使用すると差分が簡単に取れる。 @State var dateText = "" @State var timeZone = "" var body: some View { VStack { Button(action: { let dateFormat = DateFormatter() // 日時をString型で定義 let textLogDate = "2021-01-01 12:00:00" let textNowDate = "2021-01-01 12:01:20" // styleで和暦設定に対応 dateFormat.timeStyle = .full dateFormat.dateStyle = .full // dateFormatを初期設定した"2021-01-01 12:00:00"と同じ形式になるように定義 dateFormat.dateFormat = "yyyy-MM-dd HH:mm:ss" // localeを日本に dateFormat.locale = Locale(identifier: "ja_JP") // timeZoneを日本に dateFormat.timeZone = TimeZone(identifier: "Asia/Tokyo") // String型の日時をDate型に変換 timeZone = dateFormat.string(from: Date()) let logDate = dateFormat.date(from: textLogDate) ?? Date() let nowDate = dateFormat.date(from: textNowDate) ?? Date() // timeIntervalSinceを使用すると差分を取得できる->nowDate-logDate let dateSubtraction: Int = Int(nowDate.timeIntervalSince(logDate)) dateText = "\(dateSubtraction)" }, label: { Text("Button") }) Text(dateText) Text(timeZone) } } } 時間は日本時間を表示しており、取得した差分は秒数の差分となるので、今回は80秒と表示される。 以上これからを使用して日時の差分を取得するアプリを作成してユニットテストを書いてみました。(こちらはUIKitで書きました) https://github.com/yuujioka/TimeCalculate まとめ 毎度毎度Dateの差分を取るときに演算しようとしたりして、アレ?ってなったり、Dateの形式指定するときにアレ?ってなったり、日時を指定したものをDate型にするときにアレ?となり、同じような鉄釘踏みまくっていたのでいい加減鉄ゲタ履こうと戒めの意味も込めて書きました! また日時取得はDateだけでなく、Calendarクラスを使用して取得、加工することも可能なので是非そちらもチャレンジしてみたいと思います!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[Swift]日付を取得し差分を出す方法

今回作成したアプリ はじめに 今回はユニットテストについて学びたく勉強していたところ”Date使ってテスト書くといいよ”と言うアドバイスを頂いたので挑戦してみたらDateに関して結構勉強になったのでまとめてみました。 またUIKitとSwiftUIの両方で書いてみたのでUIKitはGitで公開し、この記事では主にSwiftUIで書いたものを掲載しています。 環境 ・ macOS Big Sur 12 ・ Xcode : 12.5 日付を取得する @State var dateText = "" var body: some View { VStack { Button(action: { let date = Date() dateText = "\(date)" }, label: { Text("Button") }) Text(dateText) } } ボタンを押すと現在の日時を取得して表示する。 Formatterを使用して表示を定義する ただ表示するだけって基本的にあまり使用する事はないので基本”Date使うならFormatter”ぐらいの勢いで必要な気がする。 時間と分だけを表示させたい場合は以下の通り(Buttonのaction内以外は省略) let date = Date() let dateFormat = DateFormatter() dateFormat.dateFormat = "HH:mm" dateText = dateFormat.string(from: date) .dateFormatでは表示する日時の表現を定義できる。以下表にまとめた。 年 月 日 時間 分 秒 YYYY MM dd HH mm ss 2021 6 3 22 26 45 地域や言語に関してはLocaleを使用する dateFormat.locale = Locale(identifier: "jp_JP") Localeで使用するIDの一覧↓ 地域ごとの時間を取得する時はTimeZoneを使用する dateFormat.timeZone = TimeZone(identifier: "Asia/Tokyo") TimeZoneで使用するIDの一覧↓ 和暦に気を付ける これも最初わからなかった部分だが、iPhoneの設定で和暦を設定しているとYYYYの西暦表示の部分がめちゃくちゃな数字を返してくる時がある。 上記を防ぐには予め .timeStyleと.dateStyleを定義しておくとよい。 let dateFormat = DateFormatter() dateFormat.timeStyle = .full dateFormat.dateStyle = .full dateFormat.locale = Locale(identifier: "ja_jp") let date = Date() dateText = dateFormat.string(from: date) Localをen_USに変えると表示が以下のように変わる dateFormat.dateFormat = "YYYY/MM/dd HH:mm :ss"をdateFormat.locale = Locale(identifier: "ja_jp")の下に追加すると以下の表示となる。 時間の差分を取得したい場合 timeIntervalSinceを使用すると差分が簡単に取れる。 @State var dateText = "" @State var timeZone = "" var body: some View { VStack { Button(action: { let dateFormat = DateFormatter() // 日時をString型で定義 let textLogDate = "2021-01-01 12:00:00" let textNowDate = "2021-01-01 12:01:20" // styleで和暦設定に対応 dateFormat.timeStyle = .full dateFormat.dateStyle = .full // dateFormatを初期設定した"2021-01-01 12:00:00"と同じ形式になるように定義 dateFormat.dateFormat = "yyyy-MM-dd HH:mm:ss" // localeを日本に dateFormat.locale = Locale(identifier: "ja_JP") // timeZoneを日本に dateFormat.timeZone = TimeZone(identifier: "Asia/Tokyo") // String型の日時をDate型に変換 timeZone = dateFormat.string(from: Date()) let logDate = dateFormat.date(from: textLogDate) ?? Date() let nowDate = dateFormat.date(from: textNowDate) ?? Date() // timeIntervalSinceを使用すると差分を取得できる->nowDate-logDate let dateSubtraction: Int = Int(nowDate.timeIntervalSince(logDate)) dateText = "\(dateSubtraction)" }, label: { Text("Button") }) Text(dateText) Text(timeZone) } } } 時間は日本時間を表示しており、取得した差分は秒数の差分となるので、今回は80秒と表示される。 以上これからを使用して日時の差分を取得するアプリを作成してユニットテストを書いてみました。(こちらはUIKitで書きました) https://github.com/yuujioka/TimeCalculate まとめ 自以上TimeZoneとLocaleの一覧やtimeIntervalSinceを使用して差分を取得する方法でした。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

mainブランチにマージする時に楽になる方法 => rebaseを使う

想定シーン mainブランチから派生させて作業ブランチでいくつかコミットしている間に、 リモートリポのmainブランチのコミットが進んでいる場合、 作業ブランチをpushする前にmainブランチにpullする際や、作業ブランチをpushしてgithub上でmainブランチにマージする場合、マージコミットが作られてしまうし、マージする際にファイルの変更分をチェックする作業が面倒 => rebaseを使うとこの面倒な作業を省略できる シナリオ① rebaseなし =>マージコミットが作られるし、面倒 シナリオ再現手順 git pull origin main git checkout -b no_rebase_no_conflict local.txtを作成 git add local_no_rebase_no_conflict.txt git commit -m "no conflict no rebase on local" github上でmainブランチでremote_no_rebase_no_conflict.txt作成 github上でmainブランチでcommit git checkout no_rebase_no_conflict git pull origin main(ここで上記で述べた面倒な作業をしなくていはいけないし、マージコミットが発生) git log --oneline -all --graph(このコマンドでコミット履歴が分岐して把握しにくくなることが確認できる) git push origin no_rebase_no_conflict シナリオ② rebaseあり =>マージコミットが作られないし、楽 シナリオ再現手順 git checkout main git pull origin main git checkout -b no_conflict_yes_rebase local.txtを作成 git add local_no_conflict_yes_rebase.txt git commit -m "no conflict yes rebase on local" github上でmainブランチでremote_no_conflict_yes_rebase.txt作成 github上でmainブランチでcommit git checkout no_conflict_yes_rebase git pull --rebase origin main git log --oneline --all --graph(このコマンドでコミット履歴が綺麗で把握しやすいことが確認できる) git push origin no_conflict_yes_rebase
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

後々、mainブランチにマージする時に楽になる方法 => rebaseを使う

想定シーン mainブランチから派生させて作業ブランチでいくつかコミットしている間に、 リモートリポのmainブランチのコミットが進んでいる場合、 作業ブランチをpushする前にmainブランチにpullする際や、作業ブランチをpushしてgithub上でmainブランチにマージする場合、マージコミットが作られてしまうし、マージする際にファイルの変更分をチェックする作業が面倒 => rebaseを使うとこの面倒な作業を省略できる シナリオ① rebaseなし =>マージコミットが作られるし、面倒 シナリオ再現手順 git pull origin main git checkout -b no_rebase_no_conflict local.txtを作成 git add local_no_rebase_no_conflict.txt git commit -m "no conflict no rebase on local" github上でmainブランチでremote_no_rebase_no_conflict.txt作成 github上でmainブランチでcommit git checkout no_rebase_no_conflict git pull origin main(ここで上記で述べた面倒な作業をしなくていはいけないし、マージコミットが発生) git log --oneline -all --graph(このコマンドでコミット履歴が分岐して把握しにくくなることが確認できる) git push origin no_rebase_no_conflict シナリオ② rebaseあり =>マージコミットが作られないし、楽 シナリオ再現手順 git checkout main git pull origin main git checkout -b no_conflict_yes_rebase local.txtを作成 git add local_no_conflict_yes_rebase.txt git commit -m "no conflict yes rebase on local" github上でmainブランチでremote_no_conflict_yes_rebase.txt作成 github上でmainブランチでcommit git checkout no_conflict_yes_rebase git pull --rebase origin main git log --oneline --all --graph(このコマンドでコミット履歴が綺麗で把握しやすいことが確認できる) git push origin no_conflict_yes_rebase
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Git squash

git squash してみた gitのコミットが頻雑になったのでスカッシュ実施 コミットが頻雑になってしまったので、コミットを一つにまとめたく、スカッシュしてみました。 以下にまとめます。 git checkout master <- target branch git merge --squash develop <- source branch git add . git commit -m "squash merge" git push 今まで勘違いしてました。 source branchでスカッシュしてました。 target branchでやらかしてました。 よもや、よもや、不甲斐なし 引用先
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【初心者】GitとGithubの扱い方をまとめてみました

はじめに 個人での開発をスムーズに進めるため、また”チーム開発”をするときのためにも、『Gitの概念や扱い方』をしっかり理解しておく必要があると感じました。 僕が今参加している『あべちゃんのフロントエンド塾』でも”サブ課題”として掲げられているので、学習した内容をアウトプットしていこうと思います。 Git Gitとは「バージョン管理ツール」です。 開発をしていると、「エラー」が発生することは日常茶飯事で、そういったときにGitを使うことで”エラーが出る前のデータ”に戻したりすることが出来ます。 ゲームなどでいうところの「セーブ、ロード」みたいなものだと捉えています。 【コマンド一覧】 僕がよく使うコマンドを書き出していきます。 git clone 後述する"Github"上に「リモートリポジトリ」がある場合、git clone リモートリポジトリのURLとすることで、自身の「ローカルリポジトリ」にデータを”クローン”することが出来る。 git pull git cloneのようにリモートリポジトリからローカルリポジトリへ、データをコピーできる。 git init ローカル環境で作ったディレクトリを”リポジトリ”に変換するためのコマンド。 git add 何かのファイルに変更を加えた場合に、git add ファイル名とすることで、そのファイルを”インデックス”に登録することが出来る。 また、git add .とすることで、変更を加えたファイル”全て”をまとめてインデックスに登録することも可能。 git commit git addしたファイルをgit push出来るようにするために、コミットする必要があります。 git commit -m "コメント"とすることでpushする前の準備が整います。 ”コメント”と書いてある部分には「どのような変更を加えたのか」という”メモ”を簡潔に残すことが出来ます。 git status ローカルリポジトリの”コミットの状況”などを見ることが出来ます。 まだgit addやgit commitされていないファイルがあると”赤字”で表示されます。 git checkoutでブランチを切り替える際にも、コミットされていないファイルなどがあるとエラーになるので、git statusでこまめに確認をする。 git remote add origin git remote add origin https://github.com/ユーザーネーム/リポジトリネーム.gitのようにすることで、Githubのリモートリポジトリとローカルリポジトリを連結することが出来ます。 git push リモートリポジトリにローカルリポジトリのデータを登録するコマンド。 git push origin mainのように入力します。 git log git commitをしていくと"ログ"という「セーブポイントの記録」みたいなものが貯まっていきます。 git logをすることで、それらを見ることが出来て、さらにgit log --onelineとすることで、たくさんコミットがある場合はそれらを”1行”ずつの、簡潔な表示にして見ることも可能です。 git reset --hard HEAD たとえば、一度git commitして”セーブ”したあとに、そこから更にファイルに変更を加えたとします。 でも「やっぱりこの変更微妙かもしれない」となったときにgit reset --hard HEADとすることで、”最後にコミット(セーブ)した場所”まで”リセット”することが出来ます git branch 基本、アプリなどを開発してリリースする場合は"mainブランチ"を使うことになるのですが、「何か修正・変更を加えたい」となったときにmainブランチで作業をしてしまうと、そのアプリを実際に使っている人たちにバグなどの影響を与えてしまうかもしれません。 なので、そういった修正などは”別のブランチ”を用意して、その中で作業をしていきます。 git branch ブランチ名とすることで、新しいブランチを作成出来て、git branchだけ入力すれば”現在作成されているブランチ”を一覧で見ることが出来ます。その中でも”色の付いている”ブランチ名は、”今自分がいるブランチ”ということを表しています。 git checkout git checkout ブランチ名とすることで、すでに作成しているブランチに”移動する”ことが出来ます。 ちなみにgit checkout -b ブランチ名とすると、”新しくブランチを作りつつ、そのブランチに移動”することが出来て便利です。 Github GithubとはGitをオンライン上で管理するサービス。 ”リモートリポジトリ”というものを作って、そこにデータを保存したり、そこからデータを取り出して色んな人と共同作業を出来るようにしたり、”静的”なアプリであればそこで作成したURLからそのアプリをブラウザで閲覧することもできます。 【リモートリポジトリを作る】 画面右上にある「New repository」をクリック。 上から順に、 好きなリモートリポジトリの名前を付ける。 世界中に公開してもいい場合は「Public」、嫌な場合は「Private」を選択。 最後に「Create repository」でリモートリポジトリを作成。 最後に、このような画面になってリモートリポジトリの完成です。 まとめ 基本的な内容を、自分なりにまとめてみました。 今回あらためて調べ直したことによって、git mergeやコンフリクトの解消、プルリクの作り方など、あまり個人開発では触れていなかった部分を学ぶことができました。 冒頭でも言ったように、GitやGithubをしっかりと理解して使いこなせれば、開発をより「スムーズ、安全に」進めていくことができます。 今回学んだことを、自身の開発のなかでどんどん使っていき、体に染み込ませたいと思います。 まだまだ荒削りな記事ですが、自身の成長とともに内容をアップデートしていきたいと思っています。 また、記述内容に誤りなどもあるとは思いますが、フィードバック頂けますと幸いです。 最後までお読みいただき、ありがとうございました! 参考
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

GitHubにpushした時のエラー

GitHubのpush時にエラー発生 git push origin masterと入力し、GitHubに変更内容を反映させようとしたところ 下記のようなエラーが発生して怒られてしまいました。 ! [rejected] master -> master (fetch first) error: failed to push some refs to 'https://github.com/MASAKi-cell/php01.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. 解決方法 調べてみると、stackoverflowで同じようにエラーに直面している方がいました。 Issue pushing new code in GitHub リモートリポジトリを作成した際、Readme.mdを作成しており、ローカルリポジトリでは その内容がcommitしてないので、反映させる必要がある様です。 git fetchコマンドでリモートから最新情報をローカルに持ってくる リモートリポジトリの内容がローカルに反映されていないので「fetch」コマンドを使用して、リモートリポジトリの最新情報を取得していきます。 さらに「merge」してmasterへの最新情報を持ってくるようにします。 git fetchの詳細は下記Qiita記事を参照してください。 【初心者向け】git fetch、git merge、git pullの違いについて $ git fetch origin master $ git merge origin/master これで、ローカルにReadme.mdが反映されるので、再度「git push origin master」と打ち込むと正常に反映されます。 以上です。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

ファイルを変更せずにもう一度git pushがしたい

はじめに 一度、リモートリポジトリにpushしたファイルを、変更せずに再度pushしたいと思ったことはありませんか? 私はあります。(詳細は下の「背景」へ) でも、ファイルに変更がないので、commitがない。そうなるとpushもできないかと思います。 今回の記事では、ファイルを変更せずにもう一度pushする方法をご紹介します。 背景 いつものようにリモートリポジトリにファイルをpushしたところ、pushしたファイルはリモートリポジトリに反映されているものの、いつも動いてくれるCircleCIが動いてくれない。 CircleCIの設定は変更していないので、アプリ側の問題ではないと考え、再度pushを試してみたいと思ったものの、ファイルを変更していないので、当然commitもなくpushができない。 さぁ、どうしたものか。 方法 空のcommitをすることで再度pushをすることができるようになります。 入力したコマンドは次のとおりです。 git commit --allow-empty -m "コミットメッセージ" あとはいつもどおり、pushをするだけです。 git push リモートリポジトリ名 ブランチ名 さいごに 私の場合は、この方法により再度pushをすることで、CircleCIがきちんと動いてくれ、一件落着となりました。(最初に動かなかった理由は不明ですが…) この方法のデメリットとして、多用すると意味のないコミット履歴が増えていくことになるので、ご注意ください。 そもそも、ファイルを変更せずにpushしたいというニーズがあるかは疑問ですが、この記事が誰かの参考になれば幸いです。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Gitでcloneしてから自分のブランチを作成するまでの流れ

記事を作成した経緯 プログラミングの課題管理をする際に、Githubで管理したい!ということで、説明用に記事を作成しました。 コード ①作業フォルダの作成&移動 $ mkdir workspace && cd workspace ② リポジトリをclone $ git clone https://github.com/XXXXX/xxxxxx.git ③IDEでcloneしたファイルを開く④ターミナルを開く ⑤現在のブランチを確認 // ブランチの確認 $ git branch //現在のブランチが表示 * master できない場合は、.gitがあるフォルダの直前まで移動してください。 隠しフォルダは、「⌘+shift+.」で表示できます。 ⑥ブランチを切り替え(今回はdeveloper) ※masterから切る場合は不要 //ブランチの切り替え $ git checkout developer // 確認 $ git branch // master 配下のdeveloperブランチに切り替わった master * developer ⑦developerの配下にブランチを切る // developerの配下にブランチ(member1)を作成&切り替え // git checkout -b <作りたいブランチ名> <親ブランチ名> $ git checkout -b member1 develper // 確認 $ git branch master developer * member1 // 作成・切り替わってる ⑧リモートとして登録 // git push -u origin <ブランチ名> $ git push -u origin member1 ⑨完成 Github等確認すると、新しくブランチが作成されていることが確認できます。  追記:コードを修正する場合  適当にコードを修正(index.htmlを作るなど) コミット 〜 プッシュまで $ git add -A $ git commit -m "コメント" //2度目以降はpushのみ $ git push
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【Windows】動かして学ぶ!Gitの使い方【TIL】

1. はじめに 本記事は、GitHubを使ったことのない人を対象に、今日学んだこと1をプッシュして草を生やせるようにするための記事です。 個人開発のバージョン管理をGitでしたい! 草を生やしてモチベーションを維持したい! という人のために、今回はTILリポジトリを作成しプッシュするところまで解説します。 GitHubに学習記録を残すついでに、Gitの動作を学ぶ。Gitの解説記事を読んだ時に頭の中でイメージがつき、理解がしやすくなる。Git学習の足掛かりとして作成しました。 ■対象読者 動かしながらGitの理解を進めたい! とりあえず個人でしかGitHub使わないよ! GitHub登録したけど草生やしたことないよ!という方向け 注意事項(クリックで開く) ・本記事はチーム開発での運用を考慮していません。 ・コマンドも必要最低限です。 ・まずは動かしてGitに慣れることを目的としています。 ・筆者は最近草を生やし始めたレベルです。(この記事はそのアウトプットです) ・ちなみにQiitaも初投稿です。(指摘・コメント歓迎です) 2. 前提 GitHubアカウント作成済み 3. 環境 Windows10 Git version 2.31.1 4. 用語説明 ・リモートリポジトリ GitHub上に存在するリポジトリ(保管庫) ローカルリポジトリ上でステージング→コミット→プッシュすることで、リモートリポジトリにローカルリポジトリの内容が更新されます。 プッシュした段階でリモートリポジトリが更新され、GitHubに草が生えます。 ・ローカルリポジトリ PC上に存在するリポジトリ(保管庫) ・ブランチ ブランチはその名の通り"枝"という意味ですが、イメージ的には"作業場"をイメージすると分かりやすい気がします。 //新規ブランチを作成します。 git branch ブランチ名 mainブランチは"動作保証の済んだ完成品"を置くブランチとして、もう1つ開発作業用のブランチを作ります。ローカルのmainブランチから切り出した開発作業用のブランチを仮にdevelopと名付けます。 ローカルのdevelopブランチ上で作業をし、プログラムが完成しました。テストも完了済みで品質は保証されています。これをローカルのmainブランチにマージ(結合)します。 最後にローカルのmainブランチの内容をリモートのmainブランチにプッシュすることで、ローカルの内容がリモートに更新されます。 このようにブランチを分けるのは、他人の作業の影響を受けないようにするためです。 また、マージ後に問題が発生しても、コミット履歴を参照すれば追跡調査が容易になります。 GitFlowによるとmainブランチには直接プッシュせず、マージ専用にするべきという考え方があります。GitaFlowの概要については以下の記事が参考になりました。 Git-flow ~Gitのブランチモデルを知る~ ・クローン リモートリポジトリをコピーしてローカルに持ってくること。 //カレントディレクトリにリポジトリを作成 git clone //指定したパスにクローンを作成 git clone 作成先のディレクトリパス ・ステージング コミットを行う前準備。 ステージングエリアに変更内容を追加します。 //カレントディレクトリ配下の更新ファイルを全てステージング git add . //Git管理下の全ての更新ファイルをステージングエリアに追加 git add -A //ステージングするファイルを選択することも可能 git add ファイル名 ・コミット ステージングエリア内の変更内容を記録します。 イメージ的には、ゲームでいうセーブ2に近いです。 コミットした時点で変更内容が記録され、いつでもその地点に戻すことが出来ます。 //変更内容をコミット git commit -m "コメントメッセージ" コミットの際には、変更内容を表すメッセージを入力してコミットします。 コミットの粒度は、以下の記事が参考になりました。 【初心者向け】「コミットの粒度がわからない問題」の模範解答を考えてみた ・プッシュ コミットの内容をローカルリポジトリからリモートリポジトリへ送信し、リモートリポジトリに反映させます。 つまりローカルの内容をリモートに更新させる作業です。 //リモートリポジトリの指定したブランチにプッシュ git push origin ブランチ名 ここで登場するブランチ名ですが、初期設定のままだと"main"3です。 originはGitHubのリポジトリURLが設定されています。 言い換えれば下記のコマンドでも実行が可能です。 git push https://github.com/GitHubユーザ名/リポジトリ名.git ブランチ名 ・フェッチ/マージ/プル フェッチは、リモートブランチの情報をリモート追跡ブランチに反映させます。 //指定したブランチに移動 git checkout ブランチ名 //指定したブランチの情報を取得し、現在のリモート追跡ブランチに反映させる git fetch origin ブランチ名 //上記画像例の場合:main(リモート)→origin/mainを更新 git checkout main git fetch origin main マージは、ブランチとブランチを結合します。 2つのブランチの差分を出し、その差分を結合するイメージです。 //指定したブランチに移動 git checkout ブランチ名 //指定したブランチを現在のブランチにマージ git merge マージするブランチ名 //上記画像例の場合:developにorigin/mainをマージ git checkout develop git merge origin/main プルは、フェッチとマージを連続して行います。 //指定したブランチに移動 git checkout ブランチ名 //指定したブランチを現在のブランチにマージ git merge マージするブランチ名 //mainブランチとdevelopブランチがある場合、次のコマンドでmainにdevelopをマージ git checkout main git merge develop 5. 事前準備 Gitコマンドを打つ前に事前準備として、リモートリポジトリとローカルリポジトリを作成しましょう。今後Gitで管理するリポジトリ達です。 GitHubアカウントは事前に作成しておいてください。 GitHubにリモートリポジトリを作成 Repository name:筆者は既にTILが存在するので、TIL-testとして作成しています。 Description:空欄でもOKです。 Public/Private:とりあえずPrivateで作成しています。外部に公開したい方はPublicで。 Initialize this repository wtih:とりあえずREADMEファイルだけ作成するように設定しています。 最後にCreate repositoryを押下します。 リモートリポジトリTIL-testが完成しました。 デスクトップにローカルリポジトリフォルダを作成 必須作業ではありませんが、リモートリポジトリをクローンする先のフォルダを作成します。 名前はなんでもいいです。とりあえずGit-LocalRepositoryという名前のフォルダを作成しました。 コマンドプロンプト表示 ちなみに筆者はVSCodeとGitを連携して、VSCode上のターミナルからGitコマンドを使用しています。 今回はコマンドプロンプトで行いますが、普通に便利なのでVSCode利用者は連携することをおすすめします。 参考:【初心者向け】VSCodeとGithubの連携 for Windows ~連携操作からプッシュまで~ リモートリポジトリをローカルにコピーする(クローン) はじめに、リモートリポジトリのURLを取得しておきましょう。 次に、先ほどのコマンドプロンプト上で以下のコマンドを入力します。 //リモートリポジトリをクローン(複製)する git clone リモートリポジトリのURL //結果 C:\Users\kuron\OneDrive\デスクトップ\Git-LocalRepository>git clone https://github.com/MeidyRouge/TIL-test.git Cloning into 'TIL-test'... remote: Enumerating objects: 3, done. remote: Counting objects: 100% (3/3), done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 Receiving objects: 100% (3/3), done. Git-LocalRepositoryフォルダにクローンが生成されました。 隠しファイルの.gitフォルダはGitがこのフォルダを管理するためのフォルダです。 これで準備はOKです。 6. 演習:個人開発を想定したGit運用(簡易ver) 簡易的なGitの運用演習です。GitHubに草を生やせるようになるレベルになります。 まずこれができれば、Git学習の足掛かりとしては成功です。 README.mdファイルを編集してみる 適当にファイルの中身を変更して保存。 変更内容をステージング⇒コミット⇒プッシュする //カレントディレクトリを移動(windowsコマンド) cd TIL-test //変更内容をステージング git add . //コミット(コミットメッセージはご自由に) git commit -m "メッセージ" //ローカルの内容をリモートへプッシュ(更新) git push origin main リモートリポジトリが更新されました! もちろん草も生えます。 これで個人開発において、最低限のGit運用ができるようになりました。 6.演習の内容を図に起こすと、このようになります。 7. 演習:個人開発を想定したGit運用(ブランチ利用) 次はブランチについて、動かして学んでみましょう。 ブランチという概念を学ぶことで、ブランチの移動・作成・削除、ブランチ同士のマージなどを扱えるようになります。入門者(自分)にとっては、このブランチが結構くせ者でした。 ※Gitコマンド実行前にREADME.mdを好きなように修正しておいてください。 ブランチの作成&移動 //新規ブランチ(develop)作成 git branch develop //main → developブランチに移動 git checkout develop ここで、現在のブランチを一度確認しておきましょうか。 //ブランチの確認 git branch -v //結果 C:\Users\kuron\OneDrive\デスクトップ\Git-LocalRepository\TIL-test>git branch -v * develop d55785e add:プッシュテスト main d55785e add:プッシュテスト OK。developブランチになってますね。 ステージング⇒コミット⇒プッシュ //現在のディレクトリ配下の変更内容を全てステージング git add . //コミット git commit -m "コミットテスト" //ローカルのdevelop → リモートのdevelopブランチにプッシュ git push origin develop //結果 C:\Users\kuron\OneDrive\デスクトップ\Git-LocalRepository\TIL-test>git push origin develop Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 8 threads Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 450 bytes | 450.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 remote: remote: Create a pull request for 'develop' on GitHub by visiting: remote: https://github.com/MeidyRouge/TIL-test/pull/new/develop remote: To https://github.com/MeidyRouge/TIL-test.git * [new branch] develop -> develop ローカルのdevelopブランチをリモートに向けてプッシュしました。 * [new branch] develop -> develop という一文を見てもらうと分かる通り、リモートリポジトリにdevelopブランチが新たに生成されていることが分かりますね。 なんやかんや開発し、完成したと思ったらマージします。 マージ&プッシュ //mainブランチに移動 git checkout main //develop → mainブランチにマージ git merge develop //ローカルのmain → リモートのmainブランチにプッシュ git push origin main //使用済みのブランチを削除 git branch -d develop リモートリポジトリmainブランチにプッシュできたか確認してみる。 できました! 新規ブランチを作成し、開発用のブランチの中で開発 → 完成した時にmainブランチにマージすることで、mainブランチには動作の保証されているバージョンのものだけを管理することができます。 個人開発でブランチは必要なのか? 当記事を書いている内に興味深いスレが見つかりました。コミットの粒度についても触れており、大変有意義なスレです。補足としてどうぞ。 参考:Git - 一人Gitでブランチは必要か?|teratail 7.以上、演習で行った内容を図に起こすと、このようになります 8. 演習:チーム開発を想定したGit運用(一例) 最後に、チーム開発を想定したGit運用の一例4を紹介します。 mainブランチは品質が保証された完成品をマージさせるためのブランチ。 developブランチは、完成したdevelop-〇ブランチをマージさせるためのブランチ。 develop-A,develop-Bは個人のブランチです。A君、B君の開発用ブランチと考えてください。もしくはA機能開発用ブランチ、B機能開発用ブランチと考えても結構です。 このようにB君にはB君専用のブランチを与えることで、A君の更新内容に影響されずに開発を行うことができます。 7.演習と異なるのは、pushの前にpullを挟んでいるところです。 補足:push前にpullする理由ってなに? developブランチをみんなで使うことを想定しています。 自分の作業が一段落しました。pushするまでの間に他者がdevelopを更新しているかもしれません。もしdevelopをpullせず、自分のブランチをpushしてしまうと、リモートブランチdevelopがローカルのdevelopに反映されていないので、リジェクト(エラー)が発生します。 それを防ぐため、push前にpullをしてね! ということだと思います。 また、開発環境を常に最新の状態を保つという考え方自体が重要という話も伺いました。 補足:最後に使用済みブランチを削除する理由は?再利用するのは良くないの? A.新しいブランチはマージする際に競合する可能性が低くなる。最新のmainブランチから切り出したブランチは最新であることが保証されている。 参考:マージされたブランチを再利用するのは良い習慣ですか? A君がdevelop-Aブランチからプッシュし、developブランチにマージした後、B君がdevelop-Bブランチの作業内容をdevelopブランチにマージした場合、A君が使いまわしているブランチにはB君の修正が反映されていないため、最新のブランチではない。 最新にするためにdevelopブランチをdevelop-Aブランチにマージするくらいなら、最初からdevelopからブランチを新しく切り出せばいい。ということだと思います。 ブランチは作業場(※イメージ)なんだから、その作業が終わったらその作業ブランチは取り壊して新しい場所で作業しなさい! という意見もありました。 コマンド自体は7.演習とほとんど変わらないので省略。個人開発の場合、自分以外の開発メンバーがいないので、ここまでする必要はないと思います。 9. おわりに さて、無事に草が生えたでしょうか。この記事がGit学習の足掛かりになれば幸いです。 もしGitコマンド中にエラーが出て進めない! これってどういう意味? なんでステージングする必要があるの? など疑問が浮かんだ時はチャンスです。人は興味を抱いたことはすんなり覚えられるので、お手持ちのパソコンでググってみましょう! 以上! Today I Learning(TIL)参考:Githubのリポジトリ「TIL」を使って小さなアウトプットを習慣化する ↩ 上書きセーブではなく別枠セーブ ↩ 以前はmasterでしたが、良い表現ではないとのことで修正されました。現在はリモートリポジトリ作成時に初期ブランチ名としてmainが設定されます。過去のGit記事でgit push origin masterと記載されているものが多いのはそういうことです。 ↩ 筆者はGitのチーム開発はしたことがありません。経験者に「こんな感じ?」と聞きながら作成しました。その認識は明らかに間違っている、という指摘がもしかしたらあるかもしれません。 ↩
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む