タグ

Gitに関するhohoho_ho2005のブックマーク (400)

  • レビューしやすいPRの作り方 - 大きいPRを複数に分割する - - Qiita

    こんにちは、freeeエンジニアをしている @nasa4w です。 この記事は freee Engineers Advent Calendar の10日目です。 今回は大きな機能を複数のPRに分割する話をします。 freeeでも絶賛模索中の取り組みなので現在進行形の話ですm(_ _)m まとめ - 今回作ったブランチとPR - 長くなってしまったので結論をさきに置いておきます。PRを複数に分割する場合のゴールはこんな感じ。 Why?(なぜこうしたか) こうすることで、常に work ブランチを使って動作確認ができる レビューする PR を2つに分割できる view の PR と logic の PR レビュー指摘の反映は、topic_view, topic_logic ブランチに commit すればOK work ブランチにはこの2つのブランチを merge しなおすだけでOK PR

    レビューしやすいPRの作り方 - 大きいPRを複数に分割する - - Qiita
  • レビューしやすいコミット履歴でバグ削減 - Money Forward Developers Blog

    こんにちは。 アグリゲーション開発担当の中川です。 今回は、みんなが大好きな構成管理ツール「Git」について話したいと思います。 私は Git を使い始めてから、バグの発生数が激減しました。 Git を使ったとある手法によってレビューが充実し、バグの少ないコードを書くようになったと考えています。 では、今回はその手法について紹介したいと思います。 ※ 稿は Git 以外の第三世代構成管理ツール(Hg、Bzr など)にも適用するかと思いますが、Git の用語とコマンドを使って紹介していくため Git の基知識が必要となります。ご了承ください。 レビューしやすいコミット履歴と、開発の流れで自然にできるコミット履歴の乖離 以下のようなコミット履歴があるとします。 1. wip: 仕様変更○○を行い始めた 2. wip: 仕様変更○○の続き 3. wip: ちょっと設計を変更、それと過去のバグ

    レビューしやすいコミット履歴でバグ削減 - Money Forward Developers Blog
  • Payforward

    English

    Payforward
  • git challenge 開催しました - 若くない何かの悩み

    git challenge というイベントを開きました。 いよいよ、git challengeの第0問といいますか、チュートリアルが始まりました。スコアボード、実際には強烈なCircleCI画面が会場に映写されはじめています。#mixi_git pic.twitter.com/TiWcqqlk0q— mixi engineers (@mixi_engineers) November 15, 2015 alpha.mixi.co.jp 私は、企画、問題作成、インフラ構築、微妙にPM、みたいな感じで全般的に担当しています。 問題は全部で20問弱用意しているのですが、このうちの11問を作成しています。 これらの雑感を残しておきます。 企画について 私は Scrap Challenge というセキュリティのイベントがきっかけでミクシィに入社したので、challenge 系のイベントには思い入れがあ

    git challenge 開催しました - 若くない何かの悩み
  • 株式会社ジェネレーション :: GitからSlackに通知

    Gitをファイル管理ツールとして使用していると、 『リモートリポジトリの更新時に通知を受けたい』 と思う事があります。 そんな時、Gitにはhookという機能が用意されているので、 そのhookを持ちいてSlackのChannelに更新を通知する方法を記載します。1.Slack側でIncoming WebHookを用意する Slackのメニューから、「Configure Integrations」を選択し、Integrationの中から「Incoming WebHooks」を選択します。 どのチャネルでメッセージを受けるか?botのアイコンはどんなアイコンを使うか?などの設定画面が現れます。 ここで、payloadの使い方などの説明を読んでおいて下さい。

    株式会社ジェネレーション :: GitからSlackに通知
  • Gitlab + Gitlab CI をためす - LGTM

    Gitlab + Jenkins があまりグッとこなかったので,Gitlab + Gitlab CI をためしてみた.結論から言えば,Gitlab + Jenkins より良いと思う. Docker 上に準備 やることは Gitlab コンテナを動かす Gitlab CI コンテナを動かす Gitlab Runner コンテナを動かす OSX 環境でためしたので, $ docker-machine ip default 192.168.99.100 文中の192.168.99.100 とポートは適宜読み替えてください. 1. Gitlab コンテナを動かす $ curl https://raw.githubusercontent.com/sameersbn/docker-gitlab/master/docker-compose.yml > gitlab.yml $ docker-compo

    Gitlab + Gitlab CI をためす - LGTM
  • gitとプルリクエストに関して思うことまとめ - Qiita

    ※この記事は元々「Gitのこれやめて!リスト」として2015年11月に投稿したものを改訂したものです。 この記事について 私が個人的にgitとプルリクエストについて、「こうして欲しい」とか「これはやらないで!!」とか思っていることをまとめたものです。 元々は2015年に私がコードレビューをしてる時に気になったことを、あまり推敲もせず思うがままに書いた記事でした。今改めて読み返すと稚拙な文章なのと、他に思うところとがあったりしたので、改めて書き直しました。いいね貰ってるのに書き直すのに若干後ろめたさがあるのですが、よりいい内容にできればと思います。 コミットログがきれいだとレビューしやすい 一人で開発するときはgit使っててもブランチ切らないし、プルリクもださないしで、コミットログも"First Commit"の次が"Second Commit"とかでも支障はないです。しかし、チームで開発す

    gitとプルリクエストに関して思うことまとめ - Qiita
  • アプリ開発にはGitlab flowが合うと思います - Shoichi Matsuda's diary

    はじめに みなさまのプロジェクトではどのようにバージョン管理を行っているでしょうか。 ここでのバージョン管理とは具体的にはどのようなブランチを作ってどこにマージするか、リリースはどのように進めるかといった事柄を指しています。 今日は数あるバージョン管理戦略の中で比較的新しく提唱されたGitlab flowというフローを中心にして話していきたいと思います。 最近アプリの開発においてこのGitlab flowが個人的には一番しっくり来ているのでオススメしたいです。 有名なフロー gitは分散型のバージョン管理システムとして一世を風靡しており、いまや事実上のデファクトスタンダートです。 名前のとおり分散している(ローカル・リモートが明確に分かれている)ことやブランチ・コミットの編集も非常に容易で柔軟性が非常に高いです。 一方でその柔軟さゆえにルールをきちんと決めなければ各個人のフローが大きく異な

    アプリ開発にはGitlab flowが合うと思います - Shoichi Matsuda's diary
  • 新入社員による新入社員のためのGit - Qiita

    今年の4月インターンから晴れて株式会社ユニキャストに入社して、Gitを研修でやったので、勉強がてらまとめてみました。 以前こんな記事を書きましたがもうちょっと詳しく書いてます。 1. Gitの基 Gitとは分散型のバージョン管理システムです。Gitを使うことで、ファイルの状態を好きな時に更新履歴として保存しておくことができます。そのため、一度編集したファイルを過去の状態に戻したり、編集箇所の差分を表示することができます。 1-1. バージョン管理システム バージョン管理システムとは、ファイルに対して「いつ」「誰が」「何を変更したか」といった情報を記録することで、過去のある時点の状態を復元したり変更内容の差分を表示できるようにするシステムのことです。バージョン管理システムは大きく「集中型バージョン管理システム」と「分散型バージョン管理システム」に分けることが出来ます。 1-2. 集中型バー

    新入社員による新入社員のためのGit - Qiita
  • 今さら勉強したGitのこと | Nyahoon Games Pte. Ltd.

    今まで何となく使っていたGitだけど、自分でリポジトリを作ろうとしてハマったので今さらながら勉強してみた。 まず何にハマったかと言えば、ローカルでコミットした内容をサーバー側にプッシュしようとしたときに次のようなエラーが出て、何のことだかサッパリわからなかったということ。 remote: error: refusing to update checked out branch: refs/heads/master remote: error: By default, updating the current branch in a non-bare repository remote: error: is denied, because it will make the index and work tree inconsistent remote: error: with what yo

  • Git - Book

    The entire Pro Git book, written by Scott Chacon and Ben Straub and published by Apress, is available here. All content is licensed under the Creative Commons Attribution Non Commercial Share Alike 3.0 license. Print versions of the book are available on Amazon.com. The version found here has been updated with corrections and additions from hundreds of contributors. If you see an error or have a s

  • Gitのコミットメッセージの書き方 | POSTD

    (訳注:2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注:2015/11/1、いただいた翻訳フィードバックを元に記事を再修正いたしました。) 訳: プロジェクトが長引くほど、私のGitのコミットメッセージは情報が薄くなっていく。 イントロダクション | 7つのルール | ヒント イントロダクション:なぜ良いコミットメッセージを書くことが重要か Gitのリボジトリのログをランダムに閲覧すると、ひどいコミットメッセージを目にすることがあります。例として、私が昔書いたSpringにコミットした これらのgem を見てみましょう。 $ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009" e5f4b49 Re-adding ConfigurationPostProcessorTest

    Gitのコミットメッセージの書き方 | POSTD
  • git-style-guide/README.md at main · objectx/git-style-guide

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    git-style-guide/README.md at main · objectx/git-style-guide
  • Gitを学んでいて「なるほど!」となる瞬間 | POSTD

    Gitは速く柔軟性がありますが、理解に時間のかかる分散型バージョン管理システムです。Gitを始める前に次を理解しておきましょう。 通常のバージョン管理 分散型バージョン管理 や 学習書 、 指南書 はGitを理解するのに役に立ちました。しかし、その他にもGitの理解に至ったきっかけがありますのでご紹介します。 ステージング・エリアがある Gitにはステージング・エリアがあります。繰り返しますが、 ステージング・エリアがあるのです 。 これには混乱しました。リポジトリ(「オブジェクトデータベース」)とステージング・エリア(「インデックス」と呼ばれる)の両方がGitにはあります。チェックインには2段階あります。 git add foo.txt インデックスにfoo.txtを追加します。これだけでは、チェックインは完了していません。 git commit -m "message" リポジトリ

    Gitを学んでいて「なるほど!」となる瞬間 | POSTD
  • Gitのおさらい – Webサプリ

    コミットの修正 直前のコミットの修正 特定のコミットを取り消す 変更をなかったことにする 直前のコミットの修正 直前のコミットを訂正する場合は、ファイルを修正し変更をステージして、コミットするときに –amend オプションをつける。 $ git commit -a --amend コミットメッセージを変更せずに –amend オプションを使うには $ git commit -C HEAD -a --amend 特定のコミットを取り消す コミットをなかったことにしたいときには、 revertコマンド を使う。 $ git revert [コミットハッシュ] パタメータに与えたコミットハッシュに対応するコミットが取り消されて、その取り消したというコミットが作成される。 すぐにコミットされてほしくないときや、revertコマンドをコミットせずに連続して行いたい場合は、 -n オプションをつける

    Gitのおさらい – Webサプリ
  • もうGitは怖くない: 自信を持って使いたいあなたへ - 檜山正幸のキマイラ飼育記 (はてなBlog)

    2014初頭に書いた「WindowsにおけるGit利用環境は整った: Git for Windows と SourceTree for Windows」の最後の文: ブランチは、Gitのなかで最も重要でありながら最も分かりにくい概念でしょう。表面的な言葉に騙されず、先入観を持たず、SourceTreeの視覚的表示(樹形図)の力を借りながら学習するのが、理解への一番の近道です。 そんへんの詳しいことはまたの機会に述べるかも知れません。 1年半以上たってしまいましたが、「またの機会」がやって来ましたよ。ええ、Gitの説明をします、ブランチを中心に詳しく。 「基礎編」と「ブランチ編」で2回に分けようかと思ったけど、長大な記事として一挙公開。これからGitを使う人が対象ではありません。Gitが何をやっているのか、自分が何をやっているのかイマイチ自信が持てない方向けです。 ブランチやマージって、なん

    もうGitは怖くない: 自信を持って使いたいあなたへ - 檜山正幸のキマイラ飼育記 (はてなBlog)
  • Git Cheat Sheets JP

    設定 基ランチ リモート・リポジトリ git-stash git-svn 参考 修正履歴 設定 Git には様々なオプション設定がある。中には挙動を大きく変えるものもあるので注意が必要である。 設定をすべて表示する $ git config --list システム (/etc/gitconfig) の設定 $ git config --system --list や、ユーザーごと (~/.gitconfig) の設定 $ git config --global --list など表示する対象を絞ることもできる。 ユーザ名とメール・アドレスを設定する $ git config --global user.name "John Doe" $ git config --global user.email "john.doe@example.com" コミットする時に記録されるユーザー名とメ

  • GitHub GITチートシート

  • μ’sと学ぶバージョン管理システム入門 – ラブライブ!で学ぶソフトウェア開発入門

    もGit”love”で接近中! Gitによるバージョン管理の基礎を学びます。 ことり「みんなで歌を作る?」 穂乃果「そう!9人で1つの歌を作るんだよ!」 海未「あの・・・そういう企画、これまでにも何回か」 凛「既出も甚だしいにゃ」 穂乃果「いいのっ!なんか共同作業をしなきゃいけないって声が聞こえるの!」 にこ「ちょっと!穂乃果まで希みたいなこと言い出したわよ!?」 穂乃果「とにかく!全員に担当箇所割り振るから、考えてきてっ!」 穂乃果「で、毎日みんなで見せ合って調整!ってことで、よろしく!」 ただいま連載中!

  • Change the World!

    Visual Studio Team Services から Azure DevOps にリブランディング Sep 11, 2018 BLOG このブログをご覧のみなさん、こんにちは。 Microsoft が 提供する DevOps ツールとして、オンプレミスでは Team Foundation Server(略称TFS) 、クラウドでは Visual Studio Team Ser

    Change the World!