【Git】同じコンフリクト解消を繰り返している人に教えたい「git rerere」 - Qiita
はじめに こんにちは、kenです。みなさんコンフリクト解消してますか！ チーム開発をしているとコンフリクトとは嫌でも向き合うことになりますが、コンフリクト解消って緊張感のある作業なのでやりたくないですよね。 そんなコンフリクト解消をちょっぴり楽にする(かもしれない)コマンドを最近知ったので今回はそれを紹介します、その名もgit rerereです。 git rerereとは Gitの公式ドキュメント（日本語版）には次のように記載されています。 git rerere コマンドはベールに包まれた機能といってもいいでしょう。これは “reuse recorded resolution” の略です。その名が示すとおり、このコマンドは、コンフリクトがどのように解消されたかを記録してくれます。 そして、同じコンフリクトに次に出くわしたときに、自動で解消してくれるのです。 ここに書かれているように、git
git worktreeを使ってプルリクレビューを効率化した話 - freee Developers Hub
共通マスタ基盤チームにおけるソフトウェアエンジニアのyugoです。 共通マスタ基盤チームは、従業員、商品、取引先といった製品横断で利用できるマスタデータを一元管理し、ユーザーにfreeeプロダクトにおける統合体験を提供できる基盤開発をミッションとしております。 そんな共通マスタ基盤チームチームですが、製品横断で利用されるとだけあり、日々の開発フローでPRレビューの割り込みが多いです。そんな中で、開発フローにgit worktreeを導入してみて、個人的にはPRレビューの割り込み作業時に割と使いやすかったので紹介します。 git worktreeを使うに至る背景 実はfreeeで働く以前、前職で先輩シニアエンジニアが「レビューするときにgitのstagingにあげていない自分の変更を、stashしたり、テキトーにcommitしてからrebaseするなりするの嫌だったら、worktree使った
gitbookで設計書を作成したら最高だった話 - フォトシンス エンジニアブログ
こんにちは。Akerunエンジニアの @ishturk です。 Akerun Advent Calendarの記事です。 今日は設計書の話です。 設計書をどんなツールで書くかは、僕らソフトウェアエンジニアの尽きない悩み（楽しみ）ですね。 最近はまったツールが最高に良かったので紹介させてください。 僕のツールに求める要件は以下です。 編集がカジュアルにできる UMLが書ける。あとから編集できる（画像での貼付けは編集できないのでNG） バージョンの管理ができる 好きになれる（重要） 変遷と pros/cons MS Word pros 良くも悪くもスタンダードなツールですね。 だれでも編集できるのが強みです。 Visioと組み合わせれば、UMLも後から編集可能です cons Visioは標準にするには少々値が張ります。 バイナリ形式なのでバージョン管理はしづらいです。 ページが増えたり画像を貼
JetBrains系IDEと各種ITSとGitを連携してスマートに作業する - mike-neckのブログ
JetBrainsユーザーグループにて「IntelliJとYouTrack」というタイトルにて発表してきましたが、グダグダな発表をしたのでちゃんとまとめた記事を書きます。 jbugj.connpass.com 要点 JetBrains系IDEでは、標準に付属しているツールを用いることで、スマートに作業ができます。(なお、一部のIDEについてはリポジトリーからインストールしないといけなさそうです(GoglandにはTaskManagementプラグインが付属していないようだった)) Task Management プラグイン ITS(イシュー管理システム)とIDEを連携させてTask と Context を管理できるプラグイン Task - イシュー管理システムのチケットに該当する、作業の単位をあらわす Context - 開いているファイルのカーソルの位置や、プロジェクトツリーの開いている
「速」を落とさないコードレビュー
Forkwell Meetup #3 https://forkwell.connpass.com/event/48147/Read less
GitLabの運用方法をドーンと公開！！ - pixiv inside [archive]
ピクシブ株式会社 Advent Calendar 2016の時間です。今回はピクシブ株式会社でエンジニアをしている @catatsuy が担当します。今回は意外と書いてなかったのでGitLabを社内でどう運用しているかの話を書こうと思います。 GitLabとGitHub ピクシブ社内では以下の2つの方法でソースコードを管理しています。 自社でホストしているGitLab GitHub Organization それぞれ以下の特徴があります。 GitLabのメリット 自社でホストしているため、アメリカにサーバーがあるGitHubよりもgit cloneでリポジトリをダウンロードする場合などは速い オープンソースのプロジェクトのため、社内のサーバーにインストールするだけで使える ソースコードを読めば内部でやっていることが分かる ユーザー数やリポジトリ数などで料金がかからないため、気軽に使える G
![GitLabの運用方法をドーンと公開！！ - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/8e3e8f846870fc5033b87b4b346a4f506eb82516/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F11696248318756278971%2F10328749687197154835%2F1481852582)
git blameによるSRP（単一責任原則）の定量化 - どこでも見れるメモ帳
はじめに ソースコードを静的解析することでSRP（単一責任原則）を定量的に算出します．*1 svn blameによるSRP算出*2を参考に、git blameによる算出をshで行ってみました． このSRP値が最大のモジュールが王様モジュールに相当します． # 単一責務性の違反指数（SRP） # SRP＝R＋U＋((L/100)－5) # R：修正リビジョンのユニーク数 # U：修正ユーザのユニーク数 # L：モジュールのライン数 function get_SRP() { local target_filepath=$1 echo $(( \ $(git --no-pager blame --line-porcelain $target_filepath | sed -n 's/^summary //p' | sort | uniq -c | sort -rn | wc -l) + \ $(
Git のコンフリクトを解決する 14 のヒントとツール | Atlassian Japan 公式ブログ | アトラシアン株式会社
Git はコードのマージを非常に得意としています。マージとはローカルで高速、そして柔軟に行えるものです。当然のことですが、異なるブランチから誰かがコンテンツをマージするたびにコンフリクトが発生します。コンフリクトを解決するには、主な変更点を把握して見抜かなければなりません。コンフリクトの解決は、時には多くの作業が必要になります。 開発者にはそれぞれ好みのコンフリクト解決方法があります。そのため同僚ライターのダン・スティーブンが以前、Questions for Confluence を使用して社内の人に質問していました。 返ってきた回答と洞察はアトラシアン社員だけではなく、もっと多くの人に役立つものでした。そこで私たちが Git コンフリクトを解決するさまざまな方法を以下に詳しく注釈付きで紹介します。皆さまの毎日のコーディング作業に役立つアイデアや方法がここで得られることを願います。 セット
僕のチームのGitの開発フロー - Mitsuyuki.Shiiba
を考えてみる。 Git Flow nvie.com やってみたことある。良いんだけど、僕の環境だと、もうちょっとシンプルにやれそうかなって思った。 Github Flow scottchacon.com これはシンプルだな。なんだけど、シンプルすぎてちょっと違うかな。 ということで、ちょうどいいくらいのを考えてみたい 今の僕の開発にとって、ちょうどいいくらいのを考えてみたいなーって。じゃあ、今の僕のやってる開発ってどんなん？ってところから。 チーム エンジニア5,6人くらい。 Feature, Story, Task Featureと呼ばれるものがあって、これは2,3ヶ月分の規模で。この単位でリリースする。 Featureは複数のStoryで構成されていて、Storyは4,5日くらいで完了する。から、1 Featureは10から15Storyくらいってことか。 Storyは複数のTaskを
Vimとgitで俺たちの開発速度はさらに加速した - pixiv inside [archive]
gitという、とっても便利なツールをご存知だろうか。 git とはソフトウェア開発に特化したバージョン管理ツールである。もはや、git 無しで僕らの開発は立ち行かないし、GitHubを中心としたエコシステムに僕らは支えられている。 日々の開発では、毎日数え切れないgitコマンドを打ち続けてプロダクトの歴史をアップデートしている。 この記事を見ているエンジニアの皆さんもきっとそうだろう。 いや？ ちょっと待ってくれ。 そういえば、僕はしばらくgitコマンドをコンソールで叩いた記憶がない。 そうだ！ vimをカスタマイズしてからというもの、gitを直接たたくより遥かに便利な開発環境になったんだった！ Vimmerはunite-gitiなしでは生きられない unite-gitiというプラグインがある。 これがすこぶる便利なのだ。 github.com サヨナラ git add git statu
![Vimとgitで俺たちの開発速度はさらに加速した - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/09f3a56ebac0b1da926a32768e8a295a6d5daa4e/height=288;version=1;width=512/https%3A%2F%2Fcloud.githubusercontent.com%2Fassets%2F1688137%2F11896630%2F8f08dc74-a5cb-11e5-8b1e-4b7433794387.gif)
Git-it - Gitの使い方を基礎から覚えるためのアプリ
Gitが開発現場におけるバージョン管理の軸になってきています。しかしGitには多くの機能があり、さらに他のバージョン管理に比べてローカルでできることが多いので、覚えるのが大変というイメージがあります。 そこで作られたのがGitの使い方を覚えるためのGit-itというソフトウェアです。Git-itを通してGitの使い方を学んでいけます。 Git-itの使い方 最初のページです。一番最初はGitのインストールからはじめます。 リポジトリを作ってみようのレッスンです。 コマンドも書かれていて、その結果をアプリ上から確認できるようになっています。 pullの方法。こうやって順番にすすめていくことでGitを使った開発の基本が抑えられるようになるでしょう。 Git-itの良いところはElectronアプリアプリなので、ローカルに作成したフォルダの状態などをチェックすることができるということです。コンテ
.gitattributesのeol=crlfは改行コードをCRLFに変換してチェックインするものではない - エンジニア的考察ブログ
https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html eol This attribute sets a specific line-ending style to be used in the working directory. It enables end-of-line normalization without any content checks, effectively setting the text attribute. Set to string value "crlf" This setting forces git to normalize line endings for this file on checkin and convert them to CRLF when the f
これからGit を始めてみようという人のための使い方と入門フロー
作成：2015/06/8 更新：2017/04/16 Web制作 > 使い方 Git（ギット） でどういったことができるか、メリットなどは結構知っている人が多いと思うので、ここでは「コマンドやGUIなどの初歩的な部分だけを１日で使える」ようになるためのフローをポイントだけメモしておきます。 内容は知っているけど実際に使っていない人、筆者のような超初心者、分厚い本を読むのが苦痛な人、すぐに使いたいのでポイントだけサクッと教えて欲しい人対象となります。 エンジニア速報は Twitter の@commteで配信しています。 もくじ 準備 準備する物３つ 予備知識 必須用語を「ひとこと」で解説 実践 ファイルの表示設定 git コマンドと便利なコマンド クライアントツールとリモート SourceTreeの使い方 Bitbucketの使い方 準備 準備する物３つ とりあえず、必要な物は以下の３つ。イ
Gitでやらかさないための事前予防策 - Qiita
Gitでやらかした時に使える19個の奥義を書いてやらかしたときになんとかリカバリできるようにした。 今回は、そもそもやらかさないようにしたいよねっていうお話。 コミット編 .gitignoreを細かく指定しておく .gitignoreを指定しておけば余計なファイルをコミットしちゃうことを予防できます 過去に似たようなプロジェクトがあるのならそれを流用しましょう。 ないのであれば.gitignore.ioで生成してそれをカスタムしましょう。 ワイルドカード指定やディレクトリまるごとの指定は副作用ある可能性があるので慎重に。 コミットメッセージのフォーマットを決めておく コミットメッセージのフォーマットを決めておけば書き直したいということも減ります コミットメッセージをやらかして直したいと思うことはよくあります。 そういうのって案外コミットメッセージが自由すぎることが問題だったりします。 ある
Git を学ぶ - チュートリアル、ワークフローおよびコマンド | Atlassian
Git は、元々 Linus Torvalds によって 2005 年に作られた、無料でオープンソースのバージョン管理システムです。他の SVN や CVS といった中央バージョン管理システムと違って、Git は分散型で、すべての開発者がローカル環境で彼らのコードのリポジトリの完全な履歴を持っています。これは、最初のリポジトリのクローン作成に時間がかかりますが、commit、blame、diff、merge、log といったこれに続く作業を劇的にスピードアップします。 Git は多くの革新的で強力なワークフローやツールにつながる、リポジトリ履歴のブランチ、マージ、および書き換えに非常に役立ちます。プル リクエストは、チームが Git ブランチでコラボレーションを行い、他のコードを効果的に見直すことができる、非常に人気のツールです。Git は現在世界で最も広く使用されているバージョン コント
JenkinsでGitHubのプッシュ時に自動デプロイする - sometimes I laugh
Gitでバージョン管理をしていると、本番サーバにデプロイする際に、クライアントでpush、そして本番サーバにログインしてgit pull、ってやるのは面倒臭いですよね。そんな不毛な操作は自動化するのがプログラマとしては当然です。 GitHub上のリポジトリで、デプロイの自動化をやるにはWebhookやTravis CI、JenkinsなどのCIツールとの連携を考えます。選択肢は多々あり、それぞれにメリット、デメリットはありますが、今回は後々、FuelPHPのユニットテスト自動化までを見据えて、Jenkinsによるデプロイ自動化を試してみようと思います。 サーバ構成イメージ 今回、Jenkinsを導入するにあたって、専用のEC2インスタンスを立ち上げます。このインスタンスをCIサーバとして利用していきます。 GitHubリポジトリへプッシュされたとき、GitHubはJenkinsサーバへ通知
GitHub「完璧なプルリクの書き方を教えるぜ」 - Qiita
はじめに この記事は How to write the perfect pull request - GitHub を和訳というか、意訳した記事です。 ご指摘などありましたら大歓迎です！ 良いプルリクエストを書くには (原題 : How to write the perfect pull request) 会社が成長していくと、人もプロジェクトも様変わりしていきます。GitHubの中に私達が望む文化を育んでいくためには、我々が何を自覚してコミュニケーションするべきなのか分かってきました。私達のチームが最強であり続けるために、最近以下のようなプルリクエストのガイドラインを導入しました。 プルリクへのコメント (原題 : Approach to writing a Pull Request) プルリクエストには目的を明記しましょう。たとえば… これは〜を調べてみるためのプロトタイプです これは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Git入門：Git初学習者のための効率的な学習方法を考えてみた
Gitでやらかした時に使える19個の奥義 - Qiita
コンセプトから理解するGitコマンド
