脱ブランチファースト - 日々常々
あるいは「プルリクエストをやめてみた」 チーム構成とかにもよるんだろうけど。Gitかつフォークされないプロダクトでの話です。OSSとかは全然話は変わります。 問題とアプローチ (2019-10-25T15:20 追加) 表出している問題と、ここでのアプローチを書いておきます。 ブランチファースト（造語） 「ブランチファースト」はこのエントリでの造語です。コードベースに変更を加える際に「まずブランチを作成する」から始めることを指します。 作業単位でブランチを作成、ブランチでコードを変更してプルリクエスト、レビューを経てメインライン（ master ブランチ）に反映までがブランチファーストのスコープになります。 よくあるスタイルだと思いますし、ブランチだけ作成して変更せずプルリクエストを作成する拡張もありますね。 プルリクエストを挟まずにメインラインにマージするものは含みません。 ……名前微妙
git blameでプルリクエストの番号を表示する
GitHubでプルリクエスト前提の開発をしていると、git blameで「なぜ、このコードがこうなっているのか」調べる際に、commit idではなくプルリクエストの番号を表示してほしくなります。 というわけで書いたのが git-blame-pr.pl。 以下のような感じで表示されるので、調査がはかどります。 $ git-blame-pr.pl lib/core/request.c (中略) PR #446 PR #606 h2o_iovec_t h2o_get_redirect_method(h2o_iovec_t method, int status) PR #606 { PR #606 if (h2o_memis(method.base, method.len, H2O_STRLIT("POST")) && !(status == 307 || status == 308)) PR
Git を少しでも高速、安全に使う方法を紹介 - アジャイルSEの憂鬱
はてブを眺めてたら、なんか Git の記事がバズってたので、便乗して Git の話を書いてみた。 Oh, shit, git! http://ohshitgit.com/ 「Oh shit, git!」を簡単に和訳してみた。(追記あり) - Qiita https://qiita.com/KaminoHiroki/items/391fb421e94e82c00128 基礎知識 git-reset は危ない git reset --hard は作業ディレクトリにコミットしていない変更があった場合、全てを吹き飛ばしてしまう可能性があります。 使う前に必ず git status を実行して、作業ディレクトリの状態を確認をした方が良いです。 git-checkout は遅い checkout コマンドは作業ディレクトリの状態を変更します。このとき ファイルアクセスが発生するため遅い です。 git
Is it possible for git-merge to ignore line-ending differences?
Is it possible for git merge to ignore line-ending differences? Maybe I'm asking the wrong question ... but: I tried uisng config.crlf input but things got a bit messy and out of control, specially when I applied it after the fact. For one thing, applying this config after the fact doesn't seem to affect files that were committed to the repository before applying this option. Another thing is that
First commit が git rebase -i できない問題 → git rebase -i --root でできる - 納豆には卵を入れる派です。
git init してから一番最初のcommit内容を、2番目のcommitと一緒にまとめたい、と後で思った。 よーし、git rebase -i HEAD~~からのfixupで… $ git rebase -i HEAD~~ fatal: Needed a single revision invalid upstream head~~えっ・・・(ΦωΦ) 一番最初のcommitはgit rebase -i HEADほにゃららでは遡れないのか・・・一番最初のcommitはgit rebase -i できないのか・・・？— TAE ✅ (@ken_c_lo) April 21, 2013 @ken_c_lo それ方法あったら知りたいですねー。調べた限りでは無さそうなのもあって、自分でリポジトリ作る時はgit flow initを使って最初に空のInitial commitを作るようにしてます
How do you merge two Git repositories?
Consider the following scenario: I have developed a small experimental project A in its own Git repo. It has now matured, and I'd like A to be part of larger project B, which has its own big repository. I'd now like to add A as a subdirectory of B. How do I merge A into B, without losing history on any side?
git commit --fixup とは何か - 詩と創作・思索のひろば
git commit --fixup というオプションの存在を最近知って調べた。 ヘルプとリリースノートより "git commit" learned the --fixup and --squash options to help later invocation of interactive rebase. Git v1.7.4 Release Notes --fixup=<commit> Construct a commit message for use with rebase --autosquash. The commit message will be the subject line from the specified commit with a prefix of "fixup! ". See git-rebase(1) for details. 1.7.4 から入って
rsyncをGit for Windowsに混ぜる
Windowsでrsyncをインストールする方法はいくつかあって、一番簡単なのはmingw-getでパッケージとして導入する方法。またはrsyncは諦めてChococaltely経由でcwRsyncパッケージをインストールするのが簡単。両者ともrsyncのためだけに入れるには大仰なので、既に導入されているGit for WindowsにMinGWパッケージと手作業で混ぜてインストールするのも悪くない。 必要な物は以下の4つの実行ファイルとDLLファイル。 rsync.exe(rsync-*-bin.tar.lzma より) msys-iconv-2.dll (libiconv-*-dll-2.tar.lzma) msys-intl-8.dll (libintl-*-dll-8.tar.lzma) msys-popt-0.dll (libpopt-*-dll-0.tar.lzma) それぞれ
gitにおけるコミットログ/メッセージ例文集100
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
gitのpush.defaultに関するノウハウ - Qiita
gitのpush.defaultの設定に関して、他人のを設定してあげることもあり、毎回迷うのでまとめました。 push.defaultは、今まではmatchingというのがデフォルトでしたが、Git2.0からsimpleっていうのがデフォルトになります。なので、何らかの設定をしないと、以下の様な警告が出たりします。 warning: push.default is unset; its implicit value is changing in Git 2.0 from 'matching' to 'simple'. To squelch this message and maintain the current behavior after the default changes, use: git config --global push.default matching To squ
Mac で使える git mergetool をいろいろ試してみる - 準備編 | そんなこと覚えてない
この記事は すごい広島 #6 での活動の一部です。 Git で branch をマージしたときにコンフリクトが起きると、これを解消する必要があります。テキストエディタでがんばるのはつらいこともありますよね。 そんなとき、マージするためのツールを使いたい場合もあります。 Git に git mergetool というコマンドがあって、設定しておいたツールを起動することができます。 同様に 差分を見るのにGUIツールを使いたい場合などには git difftoolというコマンドもあります。 基本的には Mac で使えるものを紹介しますが、マルチプラットフォームのもあるので、別の環境でも使えるものもあります。 試したツール opendiff - 無料 Xcode に添付されている p4merge - 無料 Qt ediff(emacs) - 無料 Kaleidoscope - 有料 - Coco
Git（GitHub）の運用で気をつけていること - えいのうにっき
ある日、 PR の内容を見ずにマージすることを岡島（ピッチャーの）というらしい 笑った— いのうえ (@a_know) 2015, 9月 10 ということで、脳天気に笑っていたら、 @a_know むしろイキナリmasterリポジトリに直接pushするパターンですね！— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 という話になり、そしてなぜだか、 @a_know push -fと同様、Gitの運用アンチパターンとかどこかに纏めがほしいですねー。 #ブログ待ってます— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 というはなしになったので、本当に必要として頂いているのかどうかはともかく、 Git / GitHub でぼくやぼくの職場で気をつけていそうなことをまとめてみる。 もくじ もくじ GitHub Flow に沿って開発する 基本
これが大規模SIerな弊社のデファクトスタンダードな開発スタイルだ！！ - そこに仁義はあるのか(仮)
受託開発やっている、いまの開発スタイルを書く。 この前のブログはわりとフォーカスをしぼったはなしだったので、今回は簡単に全体のはなし。（書く順番が逆っぽい） 今回のプロジェクトではアーキテクトとして、この↓開発スタイルの構築と運用をしていて学び多い。 バージョン管理はGit プロジェクト用サーバーにGitBucketをたててソースコードを管理している。 オフショアと仕事をするなど、開発拠点がわかれることが多い。 ソースコードに対してロックをとったりしちゃうと、他の人が開発すすめられなくなるし、拠点別れて並行開発する大規模案件だからこそ、Gitを使う必要がある。 各開発者がブランチをきって開発をして、プルリクでレビュー依頼、からのマージをすることで、レビューが済んでいるソースしかmasterブランチに取り込まれない、というのもイイ。 弊社の”エンジニア”はみんな当たり前のようにGitを使って
Advantages of monorepos
Here's a conversation I keep having: Someone: Did you hear that Facebook/Google uses a giant monorepo? WTF! Me: Yeah! It's really convenient, don't you think? Someone: That's THE MOST RIDICULOUS THING I've ever heard. Don't FB and Google know what a terrible idea it is to put all your code in a single repo? Me: I think engineers at FB and Google are probably familiar with using smaller repos (does
Gregory Szorc's Digital Home | On Monolithic Repositories
When companies or organizations deploy version control, they have to make many choices. One of them is how many repositories to create. Your choices are essentially a) a single, monolithic repository that holds everything b) many separate, smaller repositories that hold all the individual parts c) something in between. The prevailing convention today (especially in the open source realm) is to cre
受託開発でGitとmavenを使って開発をしている - そこに仁義はあるのか(仮)
会社で受託開発していて、gitを使った開発フローを考えることになった。 ニアショアに開発をお願いしていて、ニアショアからの受け入れタイミングが何回かあるから、それにあわせてブランチをわけている。 どういうフローで進めているかと、一番最後にやってみて思ったことを書いた。 どういうフローでやっているか リポジトリの構成 下記モジュールを用意した。 parent core entity common web batch tools ニアショアにて開発するモジュールは『common』、『web』、『batch』で、 アーキにて開発するモジュールは『parent』、『core』、『entity』。 ブランチ ブランチはこんな感じで分けている。 ちなみに、ソース管理はgitBucketを使った。 masterブランチ … リリース可能な状態の資源のみを管理する。結合テスト実施時は、本ブランチから資源を
Home
SCM-ManagerThe easiest way to share and manage your Git, Mercurial and Subversion repositoriesGetting started SourceCode ManagementSCM-Manager comes out of the box with support for Git, Mercurial and Subversion. All three types can be managed the same way over one interface. Easy InstallationSCM-Manager can be easily installed on the platform of your choice. We are trying to make the installation
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Git でマージ済みのブランチを一括削除する - Qiita
「Gitによるバージョン管理」の執筆者によるGit勉強会か講演会 / git bundle
GitHub - azu/awesome-commit-english: コミット英語についての記事まとめ
