タグ

gitに関するblue_goheimochiのブックマーク (5)

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

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

    レビューしやすいコミット履歴でバグ削減 - Money Forward Developers Blog
  • GitのRebaseによるBranchの運用 | DevelopersIO

    渡辺です。 東京では雪が降って騒ぎになっていますが、札幌では雨が降って騒ぎなっています。 これっていわゆる「北から目線」ですが、目線の違いってのは結構大切なことです。 はじめにお断りしておきますが、今回紹介する手法はひとつの運用方法です。 自分はこんなやり方が好きだ/嫌いだといったことを言われても、「そうっすかw」としか言えません。 特にGitを使うと様々なやり方があるでしょう。 それらを否定するつもりも、今回紹介する方法が完璧な方法だとも考えていません。 あくまでGit(バージョン管理)運用手法のひとつとしてご紹介いたします。 マサカリを投げるのは歓迎しますが、好みの押しつけはご遠慮ください(笑) メインBranchへのMerge 安全なMergeを行う開発フローでも解説しましたが、Gitでは各開発者がそれぞれ作成したBranchに変更をCommitし、最後にメインBranchへMerg

    GitのRebaseによるBranchの運用 | DevelopersIO
  • 【Git入門者向け】イメージで理解するGitコマンド事始め - きのこる庭

    ご無沙汰です。連載企画を書き進めると豪語しておきながら かなり経過してしまいました。連載企画の方は時間を見つけつつ少しずつ書き進めていければと思います、申し訳ございません。 さて、最近周囲の方にGitの解説をする機会が増えてきたため、今回はGitの基コマンドに関連する説明をします。 対象読者 ・何らかの理由でGitを使う事になったが、コマンドが多くてよくわからない方。 ・コマンドごとの意味は何となく理解しているけど、イマイチピンと来ない方。 (※「そもそも何故Gitを使う必要があるのか」「バージョン管理とは何か」といった点については ノンプログラマ向けの連載企画として後日記載させていただければ幸いです) 解説するコマンド git init, git add, git commit, git status, git log, git branch, git checkout, git me

    【Git入門者向け】イメージで理解するGitコマンド事始め - きのこる庭
  • Github で Fork してから Pull Request をするまでの流れ | けーこ in サンフランシスコ

    いつも忘れてしまうので、GithubであるプロジェクトをForkしてからPull Requestをするまでの流れをメモしたいと思います。今回、実際に私がこの流れを使っているCordova (PhoneGap) ドキュメントのプロジェクト、 https://github.com/apache/incubator-cordova-docs を例にやっていきたいと思います。 1. Fork する GithubでForkしたいプロジェクトまで行って、右上にあるForkボタンを押します。今回、 https://github.com/apache/incubator-cordova-docs をForkしたので、私のGithubアカウントkeiko713上では https://github.com/keiko713/incubator-cordova-docs というリポジトリが作成されます。 2.

  • Gitの運用ルール、フローを考えてみた

    徐々にGitに移行しつつあるのですが、複数人数(チーム)でGitを使った場合の運用ルール、ワークフローというものを考えてみました。 Git使い始めということもあり、不備は多々あると思います。アイディア等あれば是非教えて下さい! 原則 masterで作業しない。ブランチを作って作業する。 ブランチでは1機能もしくは1バグのみ作業する。 ワークフロー 準備 ローカルのmasterに移動する $ git checkout master ローカルのmasterをリモートと同期する $ git pull origin/master masterから、作業用のブランチを作成する。 $ git checkout -b branchname master ブランチ名は担当者名と作業名をスラッシュで結合したものとする。 例: taro/featurename, taro/bugname コーディング コード

  • 1