Ask questions, find answers and collaborate at work with Stack Overflow for Teams. Explore Teams Collectives™ on Stack Overflow Find centralized, trusted content and collaborate around the technologies you use most. Learn more about Collectives
チーム開発をしているプロダクトで タイポを修正しただけとか、コミットログが本当にただの履歴になっているままPRをだしたりしてmasterにマージされてしまうとmasterブランチに本質ではないコミットというノイズが混ざり、後から遡って見づらくなったりしてしまいます。 PRの際にブランチのコミットを整理するルールや方法はチームやプロダクトによって違うと思いますが、 PRを出してコードレビューで指摘を受けた箇所を直し、最終的に修正部分のコミットを元のコミットに結合してコミットログを修正する方法を例にメモ e.g. 例えば次のようなジャパリバスを直したPRのコミットログがあるとします $ git log --oneline ca284e8 (HEAD -> master) しうんてんをしたよ 30c99a8 バス的なものをボスとつないだよ bb971d8 いすを取り付けたよ 6d8ee79 ハン
オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。
どこもかしこも妙ちくりんな図で混乱させてくるのうざい 自分で書いてみる gitなんてクソ難しいんだから、きちんと概念を理解させようとかすんなよ なぜgitが必要かバージョン管理のために必要、と言うと意味わからんと思う プログラムみたいなのは少しずつ変更していくんだ だから細かに変更の差分を管理したり、変更を戻せたりしなきゃきつい なぜgitか？他のバージョン管理との違いうるせぇgit使え そんなの来年考えろ gitの基本要素、用語branch： いきなり説明が難しいが、branchがわかればどうにかなる。 例えば、今編集しているプログラムに対して、RPGのセーブデータがあると思ってほしい。 それぞれのセーブデータがそれぞれのブランチにあたる。 セーブデータが1枠しか無いと、難しいだろ？何があるかわからない、戻ったり、試したりしたいからな。 セーブデータと少し違うのは、1個のブランチでも過去
pick 8145f1c Fix screen rotation problem pick d90db4a v1.2.4 pick 646bf79 Fix screen rotation problem pick 71a6940 v1.2.4 # Rebase ed7420a..71a6940 onto ed7420a # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this c
No more digging through Dropbox and Google Drive. Always know where to find “the latest,” so you can stay in your design flow.
PWA-Editor(仮) デザインとかは適当なんだけど、コンセプト的にどこまで実装可能かの検証を一通り終えた。頑張れば本格的なものが作れそう、という手応えがある。 IndexedDB バックエンドに fs 動かして ismorphic-git を動かしている。 UIは全然足りないが、 ポテンシャル的には GitHub に push できることも検証済み。ServiceWorker でオフラインで動くようになっている。 デプロイ先は https://nervous-kilby-73c9b0.netlify.com/ 開発中のものなので、予告なく互換が壊れることがある。 動機 Chromebook 買ったんだけど、やはり開発機として使うには厳しい気持ちがあった。主にまっとうなエディタがないのが辛い。cloud9 とか試したけど、辛かった。 フロントエンドのツール周りはJSで完結して PWA
ディップ Advent Calendarの21日目です。 はじめに 現在、うちのチームではRuby on Railsで開発を進めており、 ソースコード管理にはGitHub Enterpriseを使っています。 精鋭たちが「えいやーっ！」と並行開発している状況なので、 気を付けないと意図せず開催されてしまうんです...コンフリクト祭りが。 そんなとき、普通はローカルで修正→PUSHで解決すると思います。こんな感じで。 ですが、人の手でやることなので、量が多いと面倒だし、ツラいし、ミスも発生しやすくなります。 うちのチームでも、プルリクエスト内で時折こんなコメントを見かけたりします。 コンフリクトマーカーが残ったままです！修正をお願いします！ ...これは、レビューする人も直す人もツラい。 なので、よりスマートにコンフリクトを解消する術を改めてまとめてみました。 片方のブランチの変更内容を採用
![[Git]コンフリクトをよりスマートに解消したい！ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/8077f4a0f39d83ba0d247605b02e004e15a5438d/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Fadvent-calendar-ogp-background-7940cd1c8db80a7ec40711d90f43539e.jpg%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCR2l0JTVEJUUzJTgyJUIzJUUzJTgzJUIzJUUzJTgzJTk1JUUzJTgzJUFBJUUzJTgyJUFGJUUzJTgzJTg4JUUzJTgyJTkyJUUzJTgyJTg4JUUzJTgyJThBJUUzJTgyJUI5JUUzJTgzJTlFJUUzJTgzJUJDJUUzJTgzJTg4JUUzJTgxJUFCJUU4JUE3JUEzJUU2JUI2JTg4JUUzJTgxJTk3JUUzJTgxJTlGJUUzJTgxJTg0JUVGJUJDJTgxJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMzQTNDM0MmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz1kMzI1NThkNjFmMDUwZTYxNzQ2ZTJhYzE1YTdmNjRiYQ%26mark-x%3D120%26mark-y%3D96%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9OTcyJnR4dD0lNDBtLXlhbWF6YWtpJnR4dC1jb2xvcj0lMjMzQTNDM0MmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz05NDhhNDg0ZWVmZjMzZDVkN2NlOWI3MDhkMzliMWQ5Zg%26blend-x%3D120%26blend-y%3D445%26blend-mode%3Dnormal%26txt64%3DaW4g44OH44Kj44OD44OX5qCq5byP5Lya56S-%26txt-width%3D972%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%25233A3C3C%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D134%26txt-y%3D546%26s%3D0d694c7c1659614bbdaaf111a2d21d4f)
git の submodule、便利ですが安定してない(変更の多い)リポジトリに使うと 地獄です。 Submodule Hellです。 やばいです。 開発で変更が入りまくるリポジトリをうっかりsubmoduleにしちゃった！ かなり開発して入り組んできたけどどうしよう…。 なぜsubmoduleが地獄になるのか？ 更新が多いリポジトリはコミットが2箇所になって地獄 しかも変更がsha-1形式でしか分からなくて地獄 submoduleのクラス名・メソッド名等をリネームすると、親側もリネームが必要になって無駄に2回のコミットをしなくちゃいけなくて地獄。 さらに、親のコミットはコードの修正＆submoduleの変更の取り込みも必要 submoduleの参照先同士が衝突した時、何が悪いのか探すのが大変すぎて地獄 いともたやすくsubmodule側が detached HEAD になって自分のコミッ
昨日Macで使えるGitフロントエンドの紹介を書いたところ、友人のPishenさんからForkというツールもあることを教えていただきました。 How about https://t.co/fDZq7jzQoo ?— Pishen Tsai (@pishen) 2017年8月30日 Webサイトはこちら。現時点ではMac版（動作にはMacOS X 10.11以降が必要）のみですが、Windows版も提供予定のようです。 git-fork.com リリースノートを見ると昨年から開発されていたようですが、完全にノーマークだったので早速試してみました。 1ウィンドウで複数リポジトリをタブ切り替えで操作できる ブランチの状況も把握しやすい履歴ビュー（見た目的にはSourceTreeに近い） コミット時点のファイルツリーを確認できる 動作は軽快（ただし安定度についてはまだ不明） ターミナルから起動する
.gitconfigファイルに記入するオプションをカスタマイズすれば、Gitをより上手に、便利に使うことができる。著者のGit設定の紹介と、便利な設定の解説。 私はGitが大好きで、いつでもGitを使っています。私は時々、何かについて深く調べてみたり、ドキュメントを一通り読んでみたり、設定を見直してみたりするのですが、今回はGitについてそれをやってみました。私の書いた4番目の技術スタックの改善に関する記事にようこそ！ Gitのすべて 私がコーディングを始めたのは、ただのファイルシステム上でコピーしていたあの辛い日々、そしてチェックアウトに排他的ロックが必要だったVisual SourceSafeを使っていた時でした。それでもその時、ソース管理のコンセプトは私にとって素晴らしいものに思えましたし、家でコーディングする時にはそういったものにアクセスできたらな、と思っていました。 その後カリフ
イラストの管理 自分はたまにイラストを描いたりするのですが、以前からその管理方法に苦労していました。 苦労していた点は主に次の 2 点です。 バックアップ 制作過程 Gif をつくるのが面倒くさい 強い人は、短時間でもさらっとイラストを描いてしまいますが、自分は時間をものすごく掛けないとまともなものが描けないので、バックアップは結構頻繁に取ります。 手動でバックアップしようとした場合は、ふつうにファイルを複製する感じになると思います。 ただ、普段からコードを書いていて VCS を利用している身だと、どうしても原始時代かと錯覚してしまいます。 さらに、PhotoShop の psd 形式や CLIP STUDIO PAINT の標準である clip 形式はいろんなデータが詰め込んであるので 1 ファイル当たり平気で 50 MB くらい持って行かれます。これも結構厳しいところです。 VCS を
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
Git 2.9 has been released https://github.com/blog/2188-git-2-9-has-been-released 昨日キレイなDIFFが出せるgit2.9がリリースされました。 homebrewで brew upgrade git な感じでアップグレードすれば2.9は入るのですが、 このキレイなDIFFは標準では有効になってないので、記事にあるとおりに設定を行いましょう。 だいたい以下のような感じのコマンドうてばいいと思います。 下準備：diff-highlightにPATHを通す まぁ通さずに直接読んでもいいんですが、通しておきましょう。 homebrewでいれるとdiff-highlightさんは↓あたりにいるのでPATHを通しておきましょう。 export PATH=$PATH:/usr/local/Cellar/git/2.9.0/s
動機 ExcelファイルをGitで管理しているときに、差分を見られると嬉しい。Git for Windows (msysgit)は、WordファイルやPDFファイルは差分を見られるように設定済で配布されているが、Excelファイルについては未対応。 できたこと git diffでExcelファイルに加えた変更を確認してからgit commitできる もちろん過去の履歴の差分も見られる 行頭にシート名が含まれていて複数シートにも対応している CUIでのExcelファイルの差分表示例 GUI (Git Extensions)でのExcelファイルの差分表示例 超便利！！！ 使ったもの Git for Windows (msysgit) version 1.8.4.msysgit.0 Go 1.4.2 git-xlsx-textconv ab71fc84ecd7ae97b19305ba05159
私の独断と偏見によるGit for Windowsのインストール手順です。 最終更新 2022/06/07 Downloadをクリックし、インストーラーのダウンロードを開始します。 ファイルをダブルクリックしてインストーラーを起動します。 ライセンスを確認して、Nextをクリック。 Only show new optionのチェックは、アップグレード時に新規に設定する項目のみを表示させるためのオプションです。 インストール先ディレクトリを確認されるので、Gitをクライアントとしてのみ使う場合にはできるだけこのままで進めます。ただ、オープンソースのTracのようなITS/BTSと組み合わせる場合や、SSHを使ってサーバー公開をする場合などは、C:\Gitのように短めで、間にスペースが入らないディレクトリに設定してインストールをします。 VSのGit拡張や、その他Git関連ツールと組み合わせる
「Git 2.8.0」では、新機能としてsubmodulesの並列フェッチが可能になる。submodulesは、他のレポジトリをレポジトリのサブディレクトリのように使える機能で、プロジェクトへのライブラリや外部の依存関係の統合に便利。しかし、多数のsubmodulesがある場合フェッチに時間がかかるが、今回の新機能により実行時間が短縮される。 また、.gitconfigでユーザー名とメールアドレスを指定している場合、.gitconfigの指定と異なるユーザー名やメールアドレスでコミットした際に、警告は表示されるものの、コミット自体は実行されてしまうが、「Git 2.8.0」では異なるユーザー名やメールアドレスでのコミットを禁止する設定が追加された。 さらに、今回のリリースではGit for Windowsプロジェクトにおける成果の還元によって、プラットフォームにまたがる新機能の追加を行いや
最近、自分のGitのコミットログを読み返してみたら、すごく分かりづらかったので勉強も兼ねて、Gitのコミットログのプラクティスを勉強してみました！ 🐰 Gitのコミットメッセージの書き方次のサイトを参考にさせていただきつつ、簡単にまとめてみました！ Gitのコミットメッセージの書き方 | プログラミング | POSTD Gitのコミットメッセージの書き方 - Qiita 書き方を知ることのメリットGitのコミットメッセージをわかりやすく残すことで、その変更どんな目的で具体的にどんなことを修正したかを 次の変更を行う人に伝えることができ、次の人の修正する時間を節約できる。 具体的にどんなことを書くべきかどのように変更を行ったかは、コードを見れば分かる。もしわからないのなら、コードにコメントを書くべき。 変更した理由を明らかにすることに焦点を絞り、変更前がどうで、何が問題で、今はどのように機
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
