質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Ruby

Rubyはプログラミング言語のひとつで、オープンソース、オブジェクト指向のプログラミング開発に対応しています。

Node.js

Node.jsとはGoogleのV8 JavaScriptエンジンを使用しているサーバーサイドのイベント駆動型プログラムです。

Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

JavaScript

JavaScriptは、プログラミング言語のひとつです。ネットスケープコミュニケーションズで開発されました。 開発当初はLiveScriptと呼ばれていましたが、業務提携していたサン・マイクロシステムズが開発したJavaが脚光を浴びていたことから、JavaScriptと改名されました。 動きのあるWebページを作ることを目的に開発されたもので、主要なWebブラウザのほとんどに搭載されています。

Q&A

4回答

2602閲覧

コード整形コマンドの実行はgitログに悪影響ですか?

退会済みユーザー

退会済みユーザー

総合スコア0

Ruby

Rubyはプログラミング言語のひとつで、オープンソース、オブジェクト指向のプログラミング開発に対応しています。

Node.js

Node.jsとはGoogleのV8 JavaScriptエンジンを使用しているサーバーサイドのイベント駆動型プログラムです。

Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

JavaScript

JavaScriptは、プログラミング言語のひとつです。ネットスケープコミュニケーションズで開発されました。 開発当初はLiveScriptと呼ばれていましたが、業務提携していたサン・マイクロシステムズが開発したJavaが脚光を浴びていたことから、JavaScriptと改名されました。 動きのあるWebページを作ることを目的に開発されたもので、主要なWebブラウザのほとんどに搭載されています。

0グッド

1クリップ

投稿2017/10/19 05:27

javascriptでprettierというコードを整形してくれるライブラリをつかってます。これを実行すると対象ディレクトリのコード全体が綺麗にフォーマットされるのですが、gitを他の人と共有して使う際に迷惑になりますか?

どうすればよいでしょう。

マスターブランチにマージするときだけ、コードの整形を走らせるとかにすれば良いのでしょうか?

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答4

0

あなたのプロジェクトの中に「オレオレフォーマット」を書いている人が居ると、その人に迷惑がかかるでしょう。

といっても、そういった「一人のわがまま」を取るより「その他全員の幸福」を取るべきだと私は思います。「すべてのコードが統一のフォーマットで書かれている」というのはとてもメリットのあることで、コードを追う際の効率に関わります。ですので、全員が共通のコード整形ツールを使うことを呼びかけるのが一番よいです。保存時に自動でコード整形ツールが走るようになっていれば整形漏れもなくなるのでなおよいです。

投稿2017/10/19 05:34

編集2017/10/19 05:36
masaya_ohashi

総合スコア9206

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2017/10/19 10:03

gitのログがおいづらくなるのが心配で
masaya_ohashi

2017/10/19 15:39

確かにフォーマットをかける前、後で追いづらくなるのは事実です。しかし、きちんと順を追っていけば追えないこともないです。 私の経験談ですが、はっきり言ってログをそこまで遡って追うことはほぼ発生しないですし、そのためにフォーマットをしないことの方がよほど作業効率に支障が出ます。一度フォーマットをかけて、以後フォーマットを自動でかけることを徹底すればそこからのログはきれいなものです。なので、ちゃんとみんなが一斉にフォーマットを導入すれば、ログを追いづらくなる壁は一度しか発生しません。
guest

0

もし以前からあるコードに対して整形を掛けていくのであれば、コンフリクトの解消やコミットログの連続性の消失という痛みが伴います
ほかにも、そのツールの導入・共通化の時間や労力が必要になるでしょう(一人が使うだけでは効果的ではありません)

そこで、たとえば GitHub + SideCI の組み合わせが考えられるかもしれません

「コードの整形ができていない場合、それが出来るまでこのブランチはマージできません」といった判定を新たに設けることができます
(書いたコードに対するテストコードの通過失敗と同じくらいの意味合い)

このワークフローや類似のものを確立できれば、各編集者にその作業が必要であることを機械的に通知することができます

コンフリクトの解消を低頻度長期的に実施しつつ、新たに書かれるコードはCI によるチェックが入った整形済みのものがコミットされる、そういった環境にしていけると思います

何か参考になれば幸いです

Links

投稿2017/10/19 14:32

gouf

総合スコア2321

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

javascriptでprettierというコードを整形してくれるライブラリをつかってます。

プロジェクトの決定は法律と同じで、悪法もまた法なり
これは個人の思想がどんな優れていても同じ

もしこれがプロジェクトの決定ならば、
「ツールで整形せずにコミットした奴は説教」レベルの命令違反だね。

gitを他の人と共有して使う際に迷惑になりますか?

でもこの1文がなんか怖いんだよねぇ…
もしprettierを使おうとしているのがhayatomoさんの独断なら
「お前何勝手なことしてコンフリクト作りまくってるんだ」と叱られる側になっちゃうよ!

使うなら使うで皆に合意を取ってプロジェクトの決定にするべき。
ツールで整形すること自体は良い事だから、頑張ってプロジェクトの決定まで持っていって欲しい。

投稿2017/10/19 15:06

miyabi-sun

総合スコア21158

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2017/10/22 06:17

> ツールで整形すること自体は良い事だから、頑張ってプロジェクトの決定まで持っていって欲しい。 そうしてみます!!!ありがとうございました!
guest

0

整形による編集と、整形前のコードに対して行われた編集が高い確率でコンフリクトしますので、ローカルのリポジトリにあるまだpushしていない編集と、別ブランチから/へのマージがほぼもれなくコンフリクトします。

コードを共有している場合、関係者全員が困ることになります。

また、たいていの場合ファイル全体にわたって編集が行われるため、あるコードが以前に編集されたのはいつか、という情報がほぼリセットされます。したがってコードの連続性を追跡するのが難しくなります。

これはコードを共有していなくても発生します。

--
基本的には既に存在するコードベースに整形ツールを掛けるのはなかなか難しいです。ローカルの修正はpush/pullしてもらえばいいとして(それも難しい、という状況もあり得ますが)、ブランチが問題になります。

例えばmasterと以前のリリースのメンテナンスブランチがあるような時に、どちらか一方だけ整形すると、どちらにも必要な修正を行うのに苦労します。両方整形すると、メンテナンスブランチに大規模な変更を突っ込んでしまうことになります。

現実的には

  • デメリットは甘受して整形ツール掛けてしまう
  • 既存コードへの全面適用は諦め、新規のコードや変更箇所のみ整形ツールを掛けるようにする

を状況によって判断することになるかとおもいます。

履歴の断絶について、例えば「ある部分に見つかったバグはどのcommitによるものか」という調査がログからはできないことになります。リポジトリが存在する限り永遠につきまとうことになります。

投稿2017/10/19 07:19

編集2017/10/21 02:50
suzukis

総合スコア1449

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2017/10/19 10:03

やっぱそうですよね。整形を実行して良いタイミングってチーム開発において何かありますか?何かのタイミングにhookさせるとか。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

まだベストアンサーが選ばれていません

会員登録して回答してみよう

アカウントをお持ちの方は

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問