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

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

ただいまの
回答率

90.60%

  • Git

    1238questions

    Gitはオープンソースの分散バージョン管理システム(DVCS)です。

  • Subversion

    50questions

    Subversionは、使い方はCVSによく似た、CVS(Concurrent Versions System)を改良したバージョン管理ツールです。

  • Mercurial

    9questions

    Mercurialとはオープンソースの分散型バージョン管理システムです

コミットログを書く文化がないチーム

受付中

回答 15

投稿

  • 評価
  • クリップ 18
  • VIEW 8,122

matobaa

score 1875

ログみると真っ白で、なんで変更したのか、さっぱりわかりません🗿

どうしたらいいですかねー。
  • 気になる質問をクリップする

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

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

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 15

+29

「文化」って、根付かせるには時間が掛かるものだから、まず第一に「諦めない」こと。
価値や必要性を理解してもらうのも重要だけど、習慣化させるための最初のステップは、何をどのように書くかべきかという「ポリシー」を明文化すること。
ポリシーが決まったら、解りやすいテンプレートを作成すること。
何らかの方法で課題管理(バクトラッキング、変更管理など)を実施しているはずなので、その「管理番号」の記入方法(フォーマット)を明確に決めることは特に重要。
その上で、フックスクリプト等を利用して、所定フォーマットのコメント記入がなければコミットできないようにすれば、いずれ定着するはずだと思います。
それから、コミットの『種類』を意識させることも重要だと思います。
たとえば、バグフィックスなのか機能追加なのか、それともリファクタリングなのか、あるいは作業の完了なのか、それとも途中経過(特定の工程が完了)なのか、などなど。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/07/10 07:46

    勇気をもらえました。ありがとうございます。

    - ポリシーを明文化し
    - テンプレートを作り
    - トレーサビリティを確保し
    - フックスクリプトで型にはめる
    ですね。やってみます!

    よく引き合いに出される、山本五十六の言葉を思い出しました。
    やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ。
    話し合い、耳を傾け、承認し、任せてやらねば、人は育たず。
    やっている、姿を感謝で見守って、信頼せねば、人は実らず。

    キャンセル

+6

サーバーの設定でコミトログの記述を強制することができます。
Subversion pre-commitを用いたhookでコミット時メッセージを必須+日本語でのエラー表示を行うの巻

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/07/10 00:54

    やー、コミットログの価値を理解してもらいたいんだ

    キャンセル

  • 2015/07/10 01:33

    強制でも書き始めれば慣れてきたり、価値を理解するきっかけになると思います。

    キャンセル

  • 2015/07/10 15:11

    コミットログって管理者、チームリーダーにとっては大変大きなメリットです。ただチームメンバーにとってコミットログが書かれていることってメリットを感じにくいんですよね。実際コミットログがなくても困らないんです。「価値を理解」は難しいんじゃないですかね…

    キャンセル

  • 2015/07/10 15:21

    過去の改修内容をコミットログを手がかりに探すことがたまにありますがコメント書いてなくて後悔する事ありますし、コメント書いていてよかったと感じること有りますよ。
    直近のものだと確かにメンバはメリット感じにくいかもしれませんね。

    キャンセル

  • 2015/07/10 16:32 編集

    メリットがないというのはありません。書かない人にとってはやはりメリットを感じていないからということです。書くことを当たり前の習慣にするには、強制するのが一番簡単な方法だと思ってます。

    メンバーにとって、良かったと思うのはコミットログよりソース中のコメントの方が役に立つし、特定のコミットでどのファイルが編集されたかより、特定のファイルがどのコミットで編集され、誰が編集したかは使う場面がありますが、svn log で特定ファイルの編集履歴が追跡できてしまいますよね。「コミットメッセージを手掛かりにする」という場面があまりないんですよね。特に「やらされている意識」でやっているメンバーにとっては…

    「仕事なんだからやれよ。」って話なんですけどね。

    メッセージをだらだら書かせるより、Redmine のチケット番号の入力だけを強制する方が運用は楽だと思ってます。ex) refs #1234

    キャンセル

+3

- 目の前の現実を変えるために必要な「7つの知性 http://globis.tv/movie/?e=1714

目の前の現実を変えるための「戦略」は、まずは自分がコミットログを書くことかもしれません。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+3

文化がないのであれば、まずかんたんなところからはじめて、
しだいに発展させていく(イテレータを回す的な)のが良いと思います。

たとえばコミット種別の例として、「バグ修正、致命的なバグ修正、新規機能追加、機能修正(非バグ)、仕様変更、リファクタリング、コメントアウトなどの無効化、削除、バージョンアップ、変更取り消し」などがあります。(これをこのまま採用しろ、というわけではなく、あくまでイメージするための例です)

最初はこういうのをコピペするだけでもいいと思います。

いや導入側としては、「もっと高度に使ってほしいんだけど……」という感じでしょう。文章のテンプレートやフォーマットとか、(日本の場合は少ないがOSSの場合)英語で書くとか、フックスクリプトでチケットナンバーのような数字を自動的に入れるとか、流儀や作法はいくらでもあります。

でも受け入れ側は、「やらされている」と感じがちです。今の仕事にさらに積むから、あれもこれも要求されると感じて、人間の心理としてうんざりするのです。

たいてい導入側はよそのビルを見て「うちもこうしよう!」と思うわけですが、
いきなり更地にビルを建てようとするより、小屋を建てるほうがかんたんです。

そこで、「抵抗できないほどかんたんなことを、すぐにやり始める」のが良いと思います。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+2

普通に


コメント分かりづらいです、書いて下さい。


っと直接言っていいと思います。
それが言いづらいのであれば、コメントに


多分前回の変更から”ここ”と”ここ”を変更した。
履歴のコメントを見てもわからないので悪しからず。。。

とでも書いておいてはいかがですか?

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/07/10 00:55

    チームリーダーにお願いするのがいいのかなあ……書かない筆頭なんですけど

    キャンセル

  • 2015/07/10 01:36

    「書かない筆頭」と諦めたらそこで終わりです。
    正しいことを正しいと言えないことがあるのであればそこは変えなければいけません。

    本当にそれが正しいのであればどんな立場の人間にも言うべきです。
    たとえそれが自分の会社の社長であったとしても。

    間違ったことを続けるのが社の長なのであればそれに付き合って社が潰れるのを待つ必要はありません。
    あくまで自分が考えた結果の人生ですから、悔いのないようにしなければ。

    チームリーダーがコメントを書かないのであれば、その上(バージョン管理を導入した本人)へ訴えてはいかがですか?

    キャンセル

  • 2015/07/10 07:57

    「バージョン管理を導入した本人」がすなわち私なので、悩んでいます。

    仰るとおり、安西先生がいうところの
    最後まで…希望をすてちゃいかん。
    あきらめたらそこで、試合終了だよ。
    ということですね。
    しゃーない、やるかあー

    背中を押していただき、ありがとうございます。

    キャンセル

  • 2015/07/12 01:01

    変更点そのものは、バージョン管理が教えてくれるので、なんて書いたらいいのかわからないんだとおもいます。


    なので、”書いて下さい”ではなく、”この変更は何の変更なのですか”と聴いた上で”この場合はXXXというコミットログを書いてくれると変更内容がすぐに分かります。”と一家ずつ説明して回るのが良いと思います。

    キャンセル

  • 2015/07/12 01:36

    わからなくても白紙はね・・・
    わからないなりに頑張って書いてみるとかが無い時点で論点が違うと思います。

    変更点を確認すらしているのかわからないですが、コメントを書かない人が変更点を確認してコミットしているのですかね?

    キャンセル

  • 2015/07/12 13:43

    わからないなりに頑張るのは、書くことで確実にメリットがあることを信じている場合だと思います。バージョン管理に馴染みがなく、コミットログから変更点を探したことがないのなら、メリットを信じられないと思います。(ホントは”んなもん、ちっと考えりゃあ、わかる!”という意見にも同意したい。)

    逆に、何を書いたらよいかわからない状態で無理に書かせると”変更点をコミット”とか”[filename]を変更”とか”バグを修正”とか書くことになります。これでは、書くだけ無駄かなと・・・

    キャンセル

  • 2015/07/12 19:11

    いえ、わからなくても書いた内容が間違っているのならばそこを指摘し発展していけると思います。

    メリットについてはぶっちゃけ話した上での導入じゃないんですかね?
    そうでないなら
    ”なんとなくバージョン管理システム導入したので使ってねー(*´ω`*)”
    って言ってもちゃんと使ってはくれないですよね、その場合はもう一度導入の説明からやり直しですかね。

    キャンセル

  • 2015/07/13 01:12

    書いてるなら指摘出来るという意見、とてもわかるんですが、ホントに”変更点をコミット”とか書く人だと暖簾に腕押しというか・・・愚痴ですね、すみません。

    どのような方法にせよ根付かせるには、地道に話を重ねるしかないってことですよね。

    キャンセル

  • 2015/08/31 11:17

    もう一度導入の説明からやり直します。がんばります。

    キャンセル

+2

ないよりはあった方が良いのはわかっている。
だけど面倒だと思う人がいるかもしれない。
という事ですかね。

まずひとつは。
こういうのは個々でばらばらに始めるものでもないので、(その後どうなるかは別として)まずは全員で「やりましょう」という意思統一することですよね。それには、しっかり目的を伝えて、提案することから始まると思います。
まずは全員がいる場で議題として提示することじゃないですかね。
(チームで決めたことを破る奴は、ただそいつが悪いだけですから)

思うに、
バージョン管理の導入をしたということなので、他にもバージョン管理のルール的なものは、ある程度あるはずですよね。例えば、「こういう命名規則のブランチ名にしましょう」とか「こういうflowで運用します」とか「リリース後はタグを打ちましょう」とか。
そういうルールの中に、コミットログは何の目的で何を修正したのか完結に書きましょう的なルールが加わるだけじゃないかなと思います。

私が思うところのコミットログは、
私個人の作業としては不要ですが、チームというのはメンバーが変わりますし、過去の経緯を完全に覚えている人なんてごく稀ですし、自分のために書くのではなくて、その時のチームメンバーが誰であれ過去の修正経緯が分かるという点で必要かなと考えます。
逆に言えば、他の方がおっしゃってるように、タスク管理のツールと照合できたり、リリースノートが全て残っているとか、他で管理が出来るならそういう手段もあるのかなと。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+2

チャンスです!
ルールを整備して、一貫性があって、役に立つコミットログを目指しましょう。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/09/08 20:53

    ベストプラクティスを模索中です。
    http://rochefort.hatenablog.com/entry/2015/09/05/090000 の
    http://chris.beams.io/posts/git-commit/ とかとか。

    キャンセル

+2

commitログに限らず基本的にコメントってのは大事ですよね....
ソースコードを記述する際にも変数名などがわかりづらくなってしまう場合などにもコメントはできるだけ残すようにしていますが...

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+2

最初はコメントを書く習慣がありませんでした。
理由は作業の合間のバックアップとして都度コミットしていたからです。
なので関数を書きかけの状態でも構わずコミットしていました。

今はコメントの有無で状態を判断しています。
コメントのないコミットは作業バックアップとして扱い、
コメントのあるコミットは機能追加や修正などの成果を示すものとして扱っています。

管理側からすればコメントは入れて欲しいのですが、
開発側からすればコメントが書ける状態でないけどバックアップとしてのコミットが必要なこともあるので、
どういう状況でコメントが必要かルール決めしておけば良いと思います。

うちでは進捗とリスケの参考にするため都度バックアップ的なコミットは推奨しています。
特定の人物の進捗が遅れているけど日別のコミットを見てみると
バグにより巻き戻し作業が発生していたということも確認できて評価材料にもできますし。


投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/09/08 18:29

    うーん。やはりコメントを書かないというのはいかがなものかと思います。
    ソースを修正するのには理由があるはずなので、「XXXに関する作業」というポインタを入れてもらいたいです。別のチームでは、 refs #NNNN WIP と書いてます。

    キャンセル

  • 2015/09/08 19:30

    経験則になりますが、
    成果単位でなく作業バックアップのコミットを許容する運用の場合、
    似たようなコメントが連続することがあり成果コミットを見つける事が面倒な事がありました。
    コメントの書式ルールを決めて作業と成果を区別できるようにする事も検討しましたが、
    「XXXに関する作業」の「関する作業」についてコメントだけでは表現できないことやそのフォローも不足するので、
    成果以外のコミットに関しては業務日誌(Redmine)で管理するようになりました。

    キャンセル

  • 2015/09/08 20:52

    ソースのannotateとかblameとかから変更理由をたどりたいので、やはり refs #NNNN は書いてほしいです。gitだったらあとからコミットをまとめられるので、バックアップ目的などの一時的なコミットにメッセージを書かないのもアリだと思います。

    キャンセル

  • 2015/09/08 23:44

    コミットコメントの種類を設計項目から一覧化して、
    その1項目をコピペしてもらったら担当者はコメントを考える労力なく記入してくれるのではないでしょうか?
    または設計書の項目番号など。

    設計書に無い単語を用いられると後々確認にも時間がかかりますし、
    作業内容を誇張や過少、詐称や勘違いで書き込む余地を残さないことも大事だと思います。

    キャンセル

+1

(質問の意図を誤読した回答だったため、自主的に消去)

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/08/31 11:15

    もしや同じプロジェクトに居るのではないかと思うくらい、見透かされた気になりました。刺さりました。こういう指摘は大変ありがたいです。痛かったです。反省します。

    キャンセル

+1

私はいつも一人でやってしまうので、書かない人です。しかし、皆さんがおっしゃっているように過去の変更点を覚えているわけでもないので修正する場合は思い出すのに苦労します。(時には思い出さずに問題解決のサブルチーンを付け加えてしまいます。実に美しくないプログラムになりますが)
書こうとするのですが、意外とどう書けばよいかわからず、細かく書くとプログラムより長い文章になり、プログラムが読みにくくなるのでやはり書かなくなります。
私は独学でやってきたせいか、書きたくても書けないという悩みを持つ人間となってしまいました。。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+1

JIRAとStashを連携していて、Gitでコミットしてもマスターブランチには承認者がStashで承認しないとマージされないみたいな仕組みがあれば、コミットメッセージを書かないといけない状況になると思うんですがどうなんでしょうね?

前にいたチームでgitのコミットメッセージは必ず英語で書かないといけない。それがGitHubのルールだっ!といって、別に社内のGitのリポジトリなのにGitHubのルールを推し進めようとしていた人がいました。
日本人しかいないチームで「modified the ~」だけ書かれていてもわかんないですよね。
何のために書くのか、伝わらないのは伝える側のほうが悪いと思っています。

まずは緩いなりにちょっと書かないと制約が不便なくらいの縛りで進めてみてはと思います。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/09/10 13:04

    いいですね。ちょっと書かないと制約が不便。
    「もしある人物が問題に関係があって、しかもその問題を抱えていないなら、何かをやってそれをその人物の問題にしてしまおう」ってやつですね。やろうやろう

    キャンセル

+1

# 2か月ほど経ちましたが、いかがな状況でしょう...

すでに多くの方からコメントいただいているとおりですが、
書かない人は、なぜ、何のために必要なのかが理解できていないのですよね。
あまり良くないかも知れませんが、一度痛い目に遭わないと・・・
例えばコメントがないためにコードを頭っから読み解きなおすとか、
メンテナンスに想定以上の工数がかかって大赤字プロジェクトにしてしまったりとか...
果ては現場で徹夜とか...ね。
でも、そんなネガティブな対処を推奨するわけにはいかないかと思いますので、
とりあえずはここの回答の中からピックアップするなりして、こういうことが
あるので必要なことなんですといったようなアプローチで、地道な布教活動を
諦めずにしつこく行うことでしょうか。
確かに強制的に書かせるのもアリですが、なぜ、何のためにがわかってないと、
テキトーなコメントを書いてしまい、余計わからなくなることもままあります。
それに、内容とコメントが違う...なんてこともあるので、やはり理解した上で残すような
文化を作っていくしかないかと。
また、いくつかコメントのテンプレートを用意しておくというのも良いと思います。
(なんだかなぁと思いますが、極力手間を省いてあげる...)

私も過去似たような経験がありますので大変だということはわかります。
諦めずに継続を!

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2015/09/15 17:19

    「とりあえずコミットメッセージこんなふうに書いてね」というメールを送ったら、仲間が増えました!

    いまは歯抜けながら、変更理由を書き始めてくれています。近いうちに、変更箇所から変更理由を特定する (その過程の中でコミットメッセージを使う) というデモをしたいと思ってます。

    キャンセル

+1

emoji prefixを使ってコミットログを可愛くしましょう。可愛さが命です。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/07/08 13:59

    可愛さは悪ですか。

    キャンセル

  • 2016/07/13 17:37

    お、マイナス評価3くらい最初ついたのに持ち直したw

    キャンセル

+1

書く習慣を付ける様に提案したほうがいいと思います。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

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

  • ただいまの回答率 90.60%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

同じタグがついた質問を見る

  • Git

    1238questions

    Gitはオープンソースの分散バージョン管理システム(DVCS)です。

  • Subversion

    50questions

    Subversionは、使い方はCVSによく似た、CVS(Concurrent Versions System)を改良したバージョン管理ツールです。

  • Mercurial

    9questions

    Mercurialとはオープンソースの分散型バージョン管理システムです

閲覧数の多いGitの質問