ローカルリポジトリのmasterブランチは別に無くても良い？ - Qiita
喧嘩を売るつもりはございません。 理由 Gitでブランチを作るのを忘れてmasterにコミットしてしまったときの対処法というQiita記事のコメント欄で ローカルのmasterブランチは別に持たなくても良い(むしろローカルにmasterがあるから表題のミスが起こる。) というコメントがあり、確かにな〜と共感したのが始まり。 masterで作業していることに気づかず、プッシュするときに「あぁ…」となる人も多いはず。 こういう悲しみが生まれること無く、皆が幸せになれるのではないでしょうか？ とりあえずmasterブランチを消そう git branch -D masterで削除。さよなら。 git fetchしましょう git pullを主に使用している人にはあまり馴染みのないコマンド（私もつい最近知った）。 git fetchの理解からgit mergeとpullの役割 ここに非常にわかりやす
gitとプルリクエストに関して思うことまとめ - Qiita
※この記事は元々「Gitのこれやめて！リスト」として2015年11月に投稿したものを改訂したものです。 この記事について 私が個人的にgitとプルリクエストについて、「こうして欲しい」とか「これはやらないで！！」とか思っていることをまとめたものです。 元々は2015年に私がコードレビューをしてる時に気になったことを、あまり推敲もせず思うがままに書いた記事でした。今改めて読み返すと稚拙な文章なのと、他に思うところとがあったりしたので、改めて書き直しました。いいね貰ってるのに書き直すのに若干後ろめたさがあるのですが、よりいい内容にできればと思います。 コミットログがきれいだとレビューしやすい 一人で開発するときはgit使っててもブランチ切らないし、プルリクもださないしで、コミットログも"First Commit"の次が"Second Commit"とかでも支障はないです。しかし、チームで開発す
gitを社内LANで運用しようと考えていますが、どんな方法がおすすめですか？…
gitを社内LANで運用しようと考えていますが、どんな方法がおすすめですか？ 目的はソースコードのバージョン管理ではなく、各部門のdocx,xlsx等のドキュメントのバージョン管理です。 仕事柄、各部門（多数）のマニュアルの変更が頻繁にあります。またこれらのマニュアルは監査等で第三者機関からチェックされるので、きちんと管理されるべきですが、現状きちんと管理されているとはいえません。 そこでバージョン管理システムの導入を考えています。 かといって私はまだgitに関する全体像を把握できていないため、このような場合にどんな環境構築を採用すべきかなどがよくわからない状態です。 求められる条件は下記のような感じだと思います。 ・クライアント環境はWindows7 ・gitサーバはWindows7あたりで（予備機が余っているので） ・社内のイントラネット環境 ・誰にでもできるようにGUI操作でクローン
俺のオレオレgit-flow | おそらくはそれさえも平凡な日々
背景 一昨年末くらいにgit-flowを採用していた 良いんだけど、結構めんどくさいなーと思うところがあった 去年頭の新規開発からはgithub-flowを採用(と言うかごく普通のGit運用) masterのテスト通ったらjenkinsさんが開発サーバー反映してくれて捗る ただ本番をそれで運用するわけにもいかない リリースタイミングとかある masterはデザイナーやME(=gitに不慣れな人たち)がカジュアルに画像やテンプレをpushできる(それで構わない) git-flowとgithub-flowの中間くらいのフローで運用することに git-flowの気に入ってる点とそうじゃない点 気に入っている点 並列ブランチを走らせるというのは良い(git-flowの場合、masterとdevelop) hotfixが便利 めんどくさい所 releaseブランチ毎回作る必要性をあまり感じない バー
Gitのコミットメッセージの書き方 - Qiita
Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 （2014年12月17日追記） 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど！と思ったコメントをもとに少し修正・加筆してみました。 （2022年1月4日追記） 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目：変更内容の要約（タイトル、概要） 2行目 ：空行 3行目以降：変更した理由（内容、詳細） 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 （多すぎても悩むので
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
