株式会社シベスピ 従業員ブログ

シベスピの社員ブログ。技術・想い・経験沢山書いていきます!

会議について

ご無沙汰してます。佐藤です。
コロナ禍をいかがお過ごしでしょうか?
コロナ疲れ、リモート疲れも一周し、慣れてきた感じでしょうか?

当社のある池袋駅周辺では、マスクしていることを除けば、ほぼコロナ前と同じ景色になってきたように思います。

とはいえ、仕事の方はどうかというと、対面での会議はまだ少なく、WEB会議を一日中行っているような感じで、不要な会議までどんどん増えているように思います。

WEB会議が増えていく中で、今一度会議の目的を意識し、見直しする機会が必要だと感じたので、
今回は会議をテーマにしてみました。
そもそも、WEB、対面に関わらず、何のために会議を行うのか、みなさんは意識されておりますでしょうか?

○○に△△を報告が行いたい。
○○に××について相談がしたい。
○○に□□の提案がしたい。
  ・
  ・
  ・

さまざまな目的があると思いますが、何となく会議に参加している人、多くないですか?

・何をやるのかわからないけど、呼ばれたのでとりあえず参加してる人、いませんか?
・会議中一言もしゃべらない人、いませんか?
・会議中に、他のことやっている人、いませんか?

このような人がいる(もしくは、自分が当てはまる)場合は、ぜひ、会議自体の見直しを行ってみて下さい。
効率的な会議になっていないのであれば、そもそも目的を果たす場は会議で無くても良いかも知れません。

会議体を見直すにあたっては、まずは下記について考えてみると良いです。

①誰が主催者か?
 〇〇課長、〇〇部長 など

②会議のアウトプットは何か?
 課題の共通認識
 ○○の稟議を通す
 〇〇について解決策を、方針を出す など

③参加者は誰が妥当か?
 検討するにあたって必要な人は誰か
 この人に知っていて欲しい など

参加者に明確に会議の目的を伝えていないと、何を求められているのか、ゴールが何かわからず、内職などを行う人や、ただ聞いているだけの人が多くなると思います。

ただ認識を持って欲しいだけであれば、会議に参加してもらわなくても、資料の共有や会議の議事録、録画などを渡せば済むケースがほとんどです。

対面式であれば、話を聞いていないことや内職を行っていることは一目瞭然でしたが、
WEB会議では、ただただ参加しているだけの人が増えているように思います。

特にWEB会議では、目的を持って、それを周知し、なるべく少人数で行うようにすれば
有意義な会議へと変わっていくと思います。

みなさん、意識してみて下さい。

糖質制限について

研修期間を含め、入社してから半年が経ちました。瀧です。
今回は、糖質制限のメリットとデメリットについて紹介します。

はじめに

普段から食事では白米やパンなどの炭水化物をたくさん食べていたのですが、9月の健康診断で初めて悪い結果が出てしまい、これを機に糖質制限を始めました。

糖質制限を行ったメリットとデメリット

糖質制限をはじめてから少し経ったので、そのメリットとデメリットを書きます。

メリット

①痩せやすい体質になります。
 私は元の体重から3kg減量することができました。
②単純な食事制限に比べて食べられるものが多いです。
【どちらが効果的!?】糖質制限とカロリー制限の違いを解説 – EPARKくすりの窓口コラム|ヘルスケア情報
中性脂肪コレステロール値が改善するため、生活習慣病が予防できます。
④食事を意識するだけなので、毎日運動するより取り組みやすいです。

デメリット

①米、パン、麺などの主食類を我慢しなければいけません。
②糖質の摂取に神経質になりすぎて、全く食べないと低血糖状態になることがあります。
 危険なので急激な糖質制限は避け、緩やかに行いましょう。
③いくら食べてもおなか一杯になった感覚がありません。
 主食類が食べられないため、満腹感を得るには食べるものの工夫が必要です。

最後に

今までは外食や自炊した際、基本的に主食類をたくさん摂取していたので食べるものが全く変わりました。
低血糖状態に関しては、急激に糖質を制限した際になりやすいので、
最初は白米などの主食の量を減らすことからはじめて、緩やかに糖質制限を行うようにしましょう。
私は急激に糖質制限を行ったため、めまいや視界不良など体調に影響が出てしまいました。

もし、肥満体質で痩せたいけど体を動かすのは億劫だ!と思っている方や、肥満が原因で健康状態に影響が出ている方は、上記の注意を守って糖質制限に取り組んでみてはいかがでしょうか?

”安すぎず高すぎずチェーン店ではないが入りにくいわけではないお店”の探し方

こんにちは。藤本です。

今日は私にとって2020年最大の学びについて書きます。

いい感じのお店を全然知らない!

皆さんは安すぎず高すぎずチェーン店ではないが入りにくい訳ではない、いわゆる"いい感じのお店"のレパートリーを持ってますか?

私は東京に出てきて2年目になりますが、とりわけ友達が多いわけでもなく、休日は専ら家に引きこもっているため、"いい感じのお店"のレパートリーが全くありませんでした。

先日、北海道からきた友人に会った際、私は東京でしか食べられないものを期待していた彼に、日高屋を地域の有名店であるかのように案内しました。
(北海道にないお店で有名店である事実に嘘はありません)

しかしながら、こういったシーンの他にも"いい感じのお店"のレパートリーが必要になるシーンは来てしまうのです…

・久々に会う後輩にちょっとエエ恰好したいとき
・恋人未満の女性を気取らずに誘うとき
・地方の両親が上京してきて案内するとき
等々…

あまり安いお店や誰でも知っているチェーン店に連れて行くのもきまりが悪いし、常連さんしか来ないようなお店に入るのも非常にハードルが高い。

しかし、安すぎず高すぎずチェーン店ではないが入りにくい訳ではない、そんな"いい感じのお店"を探すにあたって、Googleの検索欄に「池袋 安すぎず高すぎずチェーン店ではないが入りにくい訳ではないお店」で検索しても出てきてくれやしません。
足で探そうにも、外食経験値の低い私には外観だけではそのお店の価格帯や雰囲気がわからず、前情報なしにお店のドアを開く勇気もありませんでした。

女子会検索のすゝめ


上記の悩みを外食慣れした友人に相談したところ、解決する方法を伝授してくれました。

「エリア名+女子会」で検索すればいいのサ

「いやいや私は別に女子会をしたいわけではないのだよ」とは思いましたが、実際に検索をしてみたら、とりわけパヤパヤのお店が出てくるわけではなく、前述のような”いい感じ”のお店がたくさん出てきました。

実際に検索してみた

今回は弊社がある池袋で検索をしてみましょう。

「池袋 女子会」で検索
f:id:chivsp:20200927015252p:plain

今回は食べログを見てみましょう。

雰囲気のいい焼き鳥屋さん
f:id:chivsp:20200927015255p:plain

串焼きにビールとワインのお店
f:id:chivsp:20200927015257p:plain

魚と日本酒のお店
f:id:chivsp:20200927015258p:plain

等々…

女子会で検索したお店に行くと聞くと、27才の野郎には抵抗がありましたが、出てくるお店はまさしく私の求めていた"安すぎず高すぎずチェーン店ではないが入りにくいわけではないお店"だったのです!

皆さんも、特に男性の方は是非一度お試しください。
新たなお店と出会えるかもしれません。

以上

グランピングについて

コロナ禍で入社し半年が経とうとしています。小川です。

今回は、在宅勤務や自粛で疲れた体をリラックスする方法の一つについてです。

はじめに

9/19から9/22まで、埼玉県にあるSOLABASEという熱気球が体験できるグランピング施設に行きました。
www.solabase.com

コロナ過におけるグランピングの魅力

人との接触が少ない

知り合いのみでコテージなどを貸し切るため、人との接触が少なく、感染リスクを最小限に抑えることが出来ます。
ただ、一緒に行った人の中に体調の悪い人がいたら全員に移る可能性があるので、そこだけは注意が必要です。

自粛疲れを癒すことが出来る

私自身久しぶりに都外に出ましたが、自然の中で仲間と共に過ごすことでリフレッシュすることが出来ました。

誰でも簡単に始められる

グランピングを行う施設にはバーベキューの設備などが用意されていることが多いので、手ぶらで行くことが出来ます。
また、地元の食材を購入することで、地元の応援もできるという点もあります。

最後に

在宅勤務はいい点も多いのですが、ストレスをためる原因にもなりえます。
それぞれのリフレッシュ方法を使用してうまく向き合っていくことで、作業効率も上がります。
皆さんのリフレッシュ方法があれば教えてください!

バージョン管理システム"Git"はじめの一歩【後編】

さて、それでは後編です。前編では、gitの基本的な部分について説明いたしましたね。commit、push、pull、clone・・・それぞれ違いは理解できましたか?

後編では、ブランチについて説明し、最後に例を出して理解を深めます。

ブランチという考え

gitにはブランチといわれる機能が備わっています。そのブランチとは何なのか、何のためにあるのかを説明していきます。
f:id:chivsp:20200903210908p:plain

ブランチとは更新履歴の流れを分岐して記録することができる機能です。

複数人で作業している場合、Aさんは新機能の追加、Bさんはバグ修正・・・という風に担当が決まっているものです。

そういったときにみんなが毎回毎回すでに稼働が確認されているリリース版で作業を行うと、バグが起きたときに大変です。
修正するのに時間がかかってしまいますし、なによりリリース版が一旦停止してしまうというとんでもない事態になりかねません。

そこで、リリース版以外にも(木の枝のように)ブランチを作成し、分岐して作業を行います。
f:id:chivsp:20200903210950p:plain
ブランチには2種類のブランチがあります。統合ブランチとトピックブランチです。

統合ブランチ

f:id:chivsp:20200903211023p:plain
統合ブランチは「いつでも動作ができる、実行できる」状態にしておくブランチです。先ほどの説明で言いますと、リリース版です。
このブランチは1人1人の作業が終了したものがマージされてきます。
このブランチでバグが起きることはないようにしなくてはなりません。

基本的に動作の確認ができたもののみがマージされます。
作業途中のものや、まだバグが取り除かれていないものはマージされません。

トピックブランチ

f:id:chivsp:20200903211406p:plain
トピックブランチは担当者だけが使うブランチです。
追加機能班なら、追加機能ブランチを作成し、それにどんどん変更履歴を保存していきます。バグ修正班なら、バグ修正ブランチを作成し、それに変更履歴を保存していきます。

このトピックブランチは、細かな編集をするときに利用されることが多いので、動作が確認できなくても大丈夫です。

トピックブランチのトピックが完了次第、統合ブランチに統合していきます。
バグ修正が完全に完了したら、統合ブランチに統合しましょう。もちろん正しく動くかどうかは確認が必要です。

ブランチの切り替え(checkout操作)

ブランチとは木の枝のようにそれぞれの用途に合わせて作成し、それぞれの変更履歴を保存していくという機能でした。

ここで、例えばAさんはとても優秀な人で、機能追加とバグ修正の2つを担当しているとしましょう。

Aさんは「バグ修正が完了したので、機能追加に取り掛かろう」となるわけです。しかし、自分のローカルリポジトリにはバグ修正が完了した状態のディレクトリなので、このディレクトリ上で機能追加を行ってはいけません。なぜなら、Aさんは今“バグ修正”のブランチにいるのです。

そこでAさんは「機能追加のブランチに行かなくちゃ」となります。
ブランチを切り替える操作はcheckout操作です。
f:id:chivsp:20200903211238p:plain
またまた図の中に新たな言葉が出てたので説明します。

HEAD

gitの世界でHEADは「今いるブランチの最新の場所」を意味します。
今回の場合Aさんはバグ修正が完了したところなので、HEADはバグ修正ブランチの先頭にいます。

以上の説明、いかがでしょうか。
なんとなく、gitの使い方がみえてきたのではないでしょうか?
逆に、まだ曖昧な部分がある気がすると思った方もいるかもしれません。

最後に、mergeとブランチ、追加でrebaseについて例を出して説明し、理解を深めてもらえればと思います。
今までの復習と思って見てください。

例を出して理解を深める

さて、あなたは今、下図のAさんとします。
Aさんはtopic-branchの先頭(HEAD)にいます。
f:id:chivsp:20200903211506p:plain
Aさんは自分の作業が完了し、masterブランチ(以下master)へのマージを試みています。
しかし、masterにいきなりmergeをしたら、コンフリクトが発生してしまうかもしれません。

そこでAさんは一旦topic-branchにmasterの変更履歴をmergeしようと考えました。

ここで行うのがmerge操作でしたね。(コマンドは git merge master(コマンドって何?って人は気にしないで大丈夫です。))
f:id:chivsp:20200903211558p:plain

さあ!Aさんはmerge操作が完了し、コンフリクトも解消できました。いよいよ、Aさんはmasterにmerge操作を行うことができます。
しかし、Aさんはまだtopic-branchにいるので、このままではmasterにtopic-branchの変更履歴をmergeすることができません。

Aさんはmasterへとブランチを切り替える必要があります。
f:id:chivsp:20200903211651p:plain
ここで行われるのがcheckout操作です。(コマンドはgit checkout master)
f:id:chivsp:20200903211712p:plain
ようやくこれでAさんはmasterに移動することができました。
それではtopic-branchをmasterにmergeしましょう。
f:id:chivsp:20200903213103p:plain
以上でmasterにtopic-branchをmergeすることができました!!

続いて、発展編「rebase操作」です。
これまで説明していないので、いきなり理解するのは難しいかもしれません。

最初の状態は先ほどと一緒です。
f:id:chivsp:20200903211753p:plain
Aさんはmasterにtopic-branchをマージしたいので、rebaseしようと考えました。

rebase操作をするとどうなるのか?
下記のようになります。
f:id:chivsp:20200903211818p:plain

なんと、ブランチが生える場所が変わってしまうのです!
こうすることで、mergeとほぼ同様の「masterの変更履歴の内容をtopic-branchに取り込む」ということができます。
もちろんコンフリクトは発生する可能性があるので、そちらは解消してあげましょう。

あとは、同じ操作です。masterにmergeするには、一度masterに移動する必要(checkout)があります。
f:id:chivsp:20200903211846p:plain
最後にmerge操作です。
f:id:chivsp:20200903211859p:plain

終わりに

以上でgitの概要(内容?)の説明は終わりました。
最後には例を挙げて説明したので、理解しやすかったのではないでしょうか?

もちろん、今回の内容でgitのすべてを解説できたわけではありません。
もっと様々なコマンド(fetch操作など)があり、解説しだすとキリがありません。
ここからは自分で調べて、詳しくなっていってほしいと思います。
私もまだまだ知らない部分が多いので知識をつけていきたいです。

バージョン管理システム"Git"はじめの一歩【前編】

はじめに

皆さんにもこんな経験が1度はあると思います。

f:id:chivsp:20200903204020p:plain
git_01

チームで何かを作り上げる時にどうしても発生してしまう問題。
最新のファイルがどれか分からなかったり、変更箇所が重なったり・・・

そういう問題を解決するシステムが「バージョン管理システム」です!

Gitとは?- 何ができるようになるのか

gitとはバージョン管理システムのことです。下記の図のようなことができるようになります。

f:id:chivsp:20200903204148p:plain
git_02

ファイルの更新履歴の保存

gitではファイルを更新した記録を行うことができます。
この「記録」には、ファイルの中身のどこが更新されたかだけでなく、

  • 誰が追加したのか。
  • いつ変更したのか。
  • どこが更新されたのか。
  • 新たに追加したファイルはどれか。

など、詳細な情報が記録されるので、トラブルが起きにくくなります。

前の状態に戻す

gitではファイルの更新を記録するだけでなく、なんと前の状態に戻すことができます。
最新のファイルのプログラムでなにかバグが発生していた場合に、「とりあえず動く状態に戻そう!」ということができるわけです。
その後、時間をかけて変更された箇所を見ていけば、何がバグの原因となっているか特定することができるでしょう。

編集箇所の差分を表示

今の状態って前の状態からどこが変更されてるんだっけ?と、多くの箇所を修正していると、全ての変更箇所を頭の中に入れておくことは難しいです。
そんな時には、前の状態との差分(違い)を一目で分かりやすく表示してくれる機能があります。

上書き時に警告

チームで開発しているときに、Aさんが変更た箇所をBさんも変更した場合「変更箇所かぶってますよ!どっちが正しいものですか?」と警告を出してくれます。



いかかでしょう。Gitの魅力が伝わりましたか?
上記の4つの機能だけでなく、深く知ればもっと様々なことができるようになります。

前提知識

下記の図を見てください。
f:id:chivsp:20200903204606p:plain
たくさん知らない単語が出てきましたね。
1つずつ解説していきます。

ディレクト

ディレクトリとは簡単にいうとフォルダという認識でOKです。フォルダの中には写真だったり、動画だったり、論文だったり、多くのファイルがあります。
ここでは、「ディレクトリ(フォルダ)」と「ファイル」の違いがわかっていれば問題ありません。
ディレクトリの中にいくつかのファイルが入っている」という説明が理解できたら、次に進みましょう。

リポジトリ

リポジトリとはディレクトリの状態を記録する場所です。
このリポジトリという場所に、ディレクトリ内の変更された箇所が保存されていきます。
リポジトリにはローカルリポジトリとリモートリポジトリの2種類があります。

ローカルリポジトリ

ローカルリポジトリとは言葉の通り、ローカルなエリアにあるリポジトリです。
つまり、自分のPC内に保存されます。

リモートリポジトリ

リモートリポジトリは、自分のPCではなく、サーバーなどの遠くにあるリポジトリです。(サーバーって何?って人はひとまず遠い場所という認識でOK。ここで大事なことは、「自分のPC内には保存されない」ということです。)

どうして2つもあるの?

ローカルリポジトリとリモートリポジトリ、両方とりあえずディレクトリの状態(変更された箇所や、新たに追加されたファイルなどがあるか)を保存する場所なんでしょ?どうして2つも保存する場所が必要なの?リモートリポジトリって何に使うの?と思う方もいると思います。開発者が1人だけしかいない場合は、ローカルリポジトリだけでOKです。
なぜなら、変更するのも削除するのも追加するのも自分だけなんですから、他の人との作業がかぶることは無いはずです。

しかし、複数人で作業している場合、他の人と変更箇所がかぶってしまうことが起こりえます。
そんな時にリモートリポジトリの出番です!

f:id:chivsp:20200903204843p:plain
Aさんが作業し終えた時に、Aさんはまずローカルリポジトリに変更履歴を保存します。
その後、みんなに作業報告をするためにリモートリポジトリに変更履歴をアップロードします。

また、Bさんは自分の作業を 終えた時に、同じくローカルリポジトリに変更履歴を保存します。
その後、リモートリポジトリに変更履歴をアップします。

ここで、Aさんが作業した内容とBさんが作業した内容がかぶっていた場合にリモートリポジトリは「変更箇所かぶってるけど大丈夫?」と警告をしてくれるわけです。

ローカルリポジトリは自分の変更履歴を保存する自分のPCにあるもの。
リモートリポジトリはみんなの変更履歴を保存する遠い場所にあるもの。

ということが分かればOKです。

いかかでしょうか。ちょっとした言葉の知識ですが、これを理解しておかないと、この先の説明がチンプンカンプンになるので、しっかり押さえておきましょう。
ちなみに図の「push」や「pull」はのちに説明します。

変更の記録「コミット」

いよいよgitでの操作をするために必要なことを説明します。まずはコミットです。
f:id:chivsp:20200903205149p:plain
コミットとは作業が完了した時や、ひと段落ついた時に行う操作です。
このコミットをすることで、リポジトリに変更履歴を保存することができます。

このコミットという作業を忘れてしまうと変更履歴が保存されないので、必要な時に前の状態に戻すことができません。
必ず小まめに行いましょう!

マナーとして、1作業ごと(例えば1つのバグが治った時や、1つの機能を追加した時)に行うことを心がけてください。

また、このコミットにはもう1つ機能があります。
それは「コメント機能」です。

コミットをする場合はこのコメント機能を使う必要があります。
コミットする時に「〇〇を修正しました。バグ直ってます。」「△△機能を追加しました。」などコメントをつけます。
そうすることで、どのタイミングで何を行なったのかを誰がみても理解しやすくなります。

実際にコミットするには?

実際の操作でコミットするには1つ準備が必要です。それはコミットの前にアッド(add)してあげること。

下記の図を見てください。
f:id:chivsp:20200903205245p:plain
ここでもたくさんの知らない単語が出てきましたね。

ワークツリー

ワークツリーとは今自分が作業しているディレクトリのことです。ディレクトリが何かは説明したので、理解していただいたと思います。

インデックス

インデックスはコミットを準備する場所です。

なぜインデックスが必要なのか説明します。
というのも「いきなりコミットすればいいじゃん?」と思う方もいると思うので・・・

インデックスが必要な理由はファイルごとにコミットしたいときに困るからです。
例えば、HTMLファイルとCSSファイルを両方変更したとします。
けど、コミットは別々にしたいって時があるんですよ。

そういう時に、まずHTMLだけインデックスにアップして、コミット。
次に、CSSだけインデックスにアップして、コミットということができます。

メリットとしては別々にコミットできるので、コメントも別々に残すことができます。

HTMLをコミットする場合は「バグ修正しました。」
CSSをコミットする場合は「新機能を追加しました。」という風に。

この「コミットを実際にするには?」では、コミットする前にアッド(add)する必要があるということを押さえておきましょう。

次はリポジトリの共有(push、pull、clone)のお話です。

リポジトリ間のやり取り

ローカルリポジトリとリモートリポジトリの違いについては先ほど説明しました。
そのリポジトリ間でどのようにやり取りをして共有をするのか説明をします。
f:id:chivsp:20200903205458p:plain

リポジトリ間のやり取りを行う操作は3つです。

  • push
  • pull
  • clone

順番に説明していきます。

push(ローカルリポジトリ→リモートリポジトリ)

“push”という操作はローカルで保存した変更履歴をリモートリポジトリにアップロードする操作です。
f:id:chivsp:20200903205620p:plain

Aさんが自分のPCで変更を行い、コミットした変更履歴はローカルリポジトリに保存されています。

その変更履歴を、今度はみんなが見ることができるリモートリポジトリに保存しなくてはなりません。そうしないと、Aさんが行った変更は誰にも共有されることがなく、個人で作業しているだけということになってしまいます。

pull(リモートリポジトリ→ローカルリポジトリ

次はpullです。
f:id:chivsp:20200903205908p:plain
pull操作はリモートリポジトリに保存してある変更履歴をローカルリポジトリにダウンロードする操作です。

リモートリポジトリには、Aさん以外の人が変更した履歴が保存されている可能性があります。
他の人が変更した履歴をAさんのローカルリポジトリに保存したい場合、このpull操作を行います。

clone(リモートリポジトリ→新規ローカルリポジトリ

最後に、clone操作です。
f:id:chivsp:20200903210048p:plain
clone操作を行う場面は、例えば新しくBさんという人がプロジェクトに配属されたとなった時、BさんのPCにはまだ何もない状態ですよね。

そういったときにclone操作を行うと、リモートリポジトリのデータをそのままローカルリポジトリにダウンロードできます。
f:id:chivsp:20200903210103p:plain



gitを使うためには この3つの操作(push・pull・clone) の違いは必ず説明できるようになる必要があります。

しっかり頭に入れておきましょう。

次に説明するのは衝突(コンフリクト)の回避です。
コンフリクトとは、「 変更箇所かぶってますよ! 」状態のことです。
そういったときにどうすればよいのか、見ていきましょう!

変更履歴の統合(merge)

自分のPCで作業を続けて、「さあ!リモートリポジトリに変更履歴をアップロードするぞ」となったときにする操作は何だったか覚えていますか?

そうです、push操作です。
そのpush操作をすると、下記の図のような状態になることがあります。
f:id:chivsp:20200903210334p:plain

リモートもローカルも変更履歴"B"までは同じ内容だったのに、ローカルで“X”という変更を行ってる間に、他の人がリモートに“C”という変更履歴を保存しちゃいました。このままpush操作を行ってしまうと、他の人が行った“C”という変更箇所がなくなってしまいます。
それは困りますよね?そこで、“merge”という操作を行います。

もちろん、この状態でpush操作を行うと、gitさんは丁寧に「リモート更新されてるけど、マージしなくて大丈夫?」と警告を出してくれますので、安心してください。

警告されれば、mergeしなくちゃぐらいの感覚で大丈夫です。
それでは、mergeするとどうなるのか説明しましょう。
f:id:chivsp:20200903210421p:plain
merge操作を行うと、リモートの変更履歴を一旦ローカルにダウンロードできます。
ここで、「あれ?それってpull操作じゃないの??」と思った人、いると思います。
pull操作との違いは、自分のローカルの変更履歴に追加して、リモートの変更履歴がダウンロードできることです。

pull操作はリモートでは変更履歴が保存されていて、ローカルの内容が変わってないときに行う操作です。
merge操作はリモートもローカルも内容が変更されていて、それぞれ違う履歴が保存されているときに行う操作です。

mergeした後は、ローカルの内容はリモートで更新されている内容と、ローカルで更新されている内容が両方とも反映された状態になります。

その時に発生してしまうのが、衝突(コンフリクト)です。

衝突(コンフリクト)

複数人で作業をしていて様々なファイルを編集していると、必ず誰かと同じ場所を変更してしまう可能性が出てきます。
そのような現象を衝突(コンフリクト)と呼ばれています。
f:id:chivsp:20200903210555p:plain
コンフリクトは、先ほど説明したmergeの後にローカルリポジトリで出ます。

コンフリクトが起きると、gitは「ここが重なっている場所です!」と場所の特定まではしてくれますが、自動で修正はしてくれません。
機械にはどちらが正しい内容か理解できないので・・・

ここだけは我々人間が手作業で治すしかないのです。
コンフリクトが起きた場合は、誰と修正箇所が重なっているか確かめ、どちらが正しい内容か実際に相談して、決定し、修正を行ってください。



以上で、gitの基本の基本を説明しました。
個人でgitを使う場合には、ここまでの説明で十分扱うことができると思いますが、チームで開発となった場合、ブランチという考えを理解しておく必要があります。

後編では、ブランチについて説明します。
また、最後に実際に例を出して説明しますので、さらに理解を深めていきましょう!

在宅勤務の必需品

シベスピの研修を気に上京し、気づけば入社から激動の1年が経ちました、K端です。

去年の今頃はコロナウイルスも存在していなかったんだと思うと、なんとも言えない気持ちになりますね…


まさか自宅で仕事をすることが当たり前の生活になるとは夢にも思っていませんでしたが、私の現場では今でも在宅勤務が続いています。

今回は、在宅勤務のときに自分にとって欠かせないものをご紹介します!

 

在宅勤務の必需品 

 ①ベーグルクッション

広げて美尻、閉じてリラックス。」と謳われていますが、美しいお尻に近づいている実感はまったくありません…

それでも、このクッションを使うと骨盤が安定し、座卓で一日中座りっぱなしでも腰が辛くならないので必要不可欠な存在です!


②マッサージピロー

前職から転職するときに友人からプレゼントしてもらったNAIPOのマッサージピローなんですが、今になって大活躍してます。

手ごろな値段ながらも強い力で揉み込んでくれて、ヒーターの温熱が心地いいです。

仕事が終わったら、このマッサージピローを使って疲れた体を労るのが日課です。


③3時のおやつ

仕事中の気分転換に手作りおやつを食べています。

最近は「家事ヤロウ!!!」というテレビ番組で紹介されているレシピを試すのにハマっているんですが、その中でも美容家のIKKOさんが紹介していた「おかえりマンゴー」をよく作っています。


「おかえりマンゴー」の作り方

①一口大に切ったドライマンゴーをプレーンヨーグルトに混ぜ込んで一晩漬けるだけ☆


めちゃくちゃ手軽 & おいしい & 体にいいのでおすすめです!

ドライいちじくでもおいしくなったので、ドライフルーツ全般に合うと思います。

 

最後に

2020年、こんなはずじゃなかった…と思わせられることも多いですが、なんだかんだで新しい日常を受け入れて生活できている気もします。

皆さんの自宅で仕事をするときにおすすめのグッズ、気分転換の方法があれば是非とも教えてください!