GitHub実践入門読んだ - karaage. [からあげ]
GitHub実践入門買いました Gitおじさんになると下記記事で宣言していたので、本1冊くらい買っておくかということで、一番有名っぽいGitHub実践入門買ってみました。 GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus) 作者: 大塚弘記出版社/メーカー: 技術評論社発売日: 2014/03/20メディア: 単行本（ソフトカバー）この商品を含むブログ (23件) を見る これな やはり本1冊読んでみると、いろいろな気づきがあったり、実は全然分かってなかったことに今更気付いたりしました。ネットでも情報豊富ですが、たまには本で通しで読んでみるのもよいですね。基本的には宇宙語が続くので、気になる方だけ続きをよんでみてください。 本読んで初めて知ったことメモ いろいろ気づいたことのメモです。完全に自分用。 WindowsのGitはmsysGi
![GitHub実践入門読んだ - karaage. [からあげ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/debe96adca991ca81ef7c95ec883354892f2786c/height=288;version=1;width=512/http%3A%2F%2Fecx.images-amazon.com%2Fimages%2FI%2F51PjpAUHZBL.jpg)
Gitコミットメッセージの7大原則 - rochefort's blog
タイトルは大げさです。割と当たり前の話です。 ハードディスクの整理中にRailscastsのメモが出てきまして 懐かしいなぁ、 Ryan Bates(@rbates)さん 元気かなぁと Twitterを覗いてみたところ How to write a Git commit message: http://t.co/D31dVh1lks— Ryan Bates (@rbates) 2015, 7月 28 なかなか興味深い記事をtweetされていました。 Git の commit messageに 規律をもたらそうぜ、ってのは どうやら日本人だけじゃないようです。 元記事( How to Write a Git Commit Message ) Introduction 著者の過去と現在のcommit logを対比しています。 一貫して、この緑と赤の対比が見やすいので、記事も読みやすいです。 ま
これが大規模SIerな弊社のデファクトスタンダードな開発スタイルだ！！ - そこに仁義はあるのか(仮)
受託開発やっている、いまの開発スタイルを書く。 この前のブログはわりとフォーカスをしぼったはなしだったので、今回は簡単に全体のはなし。（書く順番が逆っぽい） 今回のプロジェクトではアーキテクトとして、この↓開発スタイルの構築と運用をしていて学び多い。 バージョン管理はGit プロジェクト用サーバーにGitBucketをたててソースコードを管理している。 オフショアと仕事をするなど、開発拠点がわかれることが多い。 ソースコードに対してロックをとったりしちゃうと、他の人が開発すすめられなくなるし、拠点別れて並行開発する大規模案件だからこそ、Gitを使う必要がある。 各開発者がブランチをきって開発をして、プルリクでレビュー依頼、からのマージをすることで、レビューが済んでいるソースしかmasterブランチに取り込まれない、というのもイイ。 弊社の”エンジニア”はみんな当たり前のようにGitを使って
A successful Git branching modelから重要なとこを抽出 - Qiita
Git使うなら絶対に一度は読んだ方がいい良エントリ A successful Git branching model 日本語訳 理屈は本文読めということで、ルール的な箇所を抽出 ブランチの種類 メインブランチ サポートブランチ サポートブランチはさらに3種類に分類される メインブランチ メインブランチはmasterとdevelopの二つ この二つは常に存在するし、削除しない masterでの開発は一切しない developで開発してmasterにマージするのが大きな流れ サポートブランチ フィーチャーブランチ リリースブランチ ホットフィックスブランチ 用が済めば削除される フィーチャーブランチ developから分岐してdevelopにマージされる 命名規則は特に無し（他の種類のブランチと区別がつくように） 個々の機能を実装する originにはpushしない フィーチャーブランチの一生
ネイティブと働いて分かった英語コミットメッセージの頻出動詞10つ
ウッ ここで詰まる事は往々にしてあります. 特に急いでる時の煩わしさは甚だしいです. どうせならそれっぽい英語を使いたいのでOSSや同僚のコミットメージの語彙の出現確率を調べてみましたら、 もちろんfeatureによってコミットメッセージの付け方など数多あるものの、一定の頻出パターンは見い出せたので筆を取りました. （英語勉強しないと..） 方法 github.com/rails/railsのコミットメッセージ内における各動詞の出現確率を求め、 またOSSと仕事でのコミットメッセージの趣向も変わってくる事も勘案するため、 （仕事でDeprecateとか滅多に使わんし） 同僚に聞きつつ10つあげてみた. 以下列挙 （例は実際の同僚やOSS上でのコミットメッセージです.） Add *A to *B AをBに加える
初心者がプルリクまでに覚えるべきたった 9つの厳選 Gitコマンド - akiyoko blog
この投稿は 「Git Advent Calendar 2014 - Qiita」 の 2日目の記事です。 2年前の 「Git Advent Calendar 2012 - Qiita」 では、「Gitコマンド総選挙」と題して、本当に使える Git コマンドのベストテン発表というネタを書いたのですが、今振り返ってみても、Git コマンドって、よく使うものから普段あまり使わないものまで様々なコマンドが取り揃えられていて至れり尽くせり感がある一方で、Git 初心者が覚えるにはぶっちゃけ 数が多過ぎて辛い ですよね。 そこで今回は、Git 初心者がプルリクできる ようになるまでに覚えるべきコマンドを絞りに絞って、9つだけ紹介したいと思います（9つでも多いよ！というツッコミは受け付けません！）。 【コマンド その１】 git clone 【コマンド その２】 git log 【コマンド その３】 g
現場で使うGitのテクニック - Qiita
お疲れさまです、trebyです。 もうだいぶ日付が変わりそうな勢いですが、Git Advent Calendar 2014の23日目を担当させていただきます。 Gitを業務で使い始めて早2年、だいぶ慣れてきた感じがありますが、それをアウトプットする機会があるかといえばなかなかありません。せいぜいたまに同僚に聞かれるくらいでなんかもったいない感じがあります。 そこで今日は私個人がgitを使って仕事をする上でどういうフローしているかなーということを改めて文字にアウトプットしてみたいと思います。ご参考にしていただくなり、ツッコミしていただくなりしていただけますと幸いです。 なお、本投稿において想定するツールはGit、ホスティングサービスはGitHubですが、多分その他のサービスでもいけるのではないかと思います。 開発準備 「新しくチームに配属された！」等のシチュエーションを想定しています。 開発
A successful Git branching model » nvie.com
Note of reflection (March 5, 2020) This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea. Du
Non-Fast-Forward Push の解決 - Linux 入門
他の開発者とともに同じリモートリポジトリ (depot リポジトリ) を利用していれば、しばしば発生するのが Non-Fast-Forward Push 問題です。 Non-Fast-Forward とは何かということを説明するために、そもそも Fast-Forward とは何かということを説明します。 Fast Forward とは？ ある時点で master ブランチからブランチ A ができたとします。その後、ブランチ A にてコミットします。 その間、master ブランチでは全くコミットが行われていないとします。 この状態ではブランチ A はブランチ master に安全にマージ可能ですよね。ブランチ A に対して行ったコミットを master にも行えば良いだけですから。 ただ、実際に Fast Forward マージは同じ変更をせっせと再生するのではなく、単に master ブ
gitでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
めんどくせーので個人用Gitメモ晒す - Qiita
Gitメモ 基本的に-nか--dry-runで何をするか確認できる 色々ありすぎて理解しきれない→本買うよりここ http://git-scm.com/book/ja zshあればbranchとか補完してくれて便利 よくまとまってる http://transitive.info/article/git/ システムの人はこれ見た方が早い http://keijinsonyaban.blogspot.jp/2011/05/git.html?m=1 gitのversionはできるだけ新しいものを使いたい（1.7.1だとorphenとかsingle-branchとか無い） クローン git clone ssh or http repo ブランチ指定クローン git clone -b branch git@... ミラー git clone --mirror repo ブランチだけクローン（1.7.
[ポエム][社内実習向けメモ書き]git rebase道場 - Qiita
非常に個人的なことですが、最近チーム内でrebaseの必要性が増しています。 なのでチーム内講習のためのプロットとしてここに説明することをまとめます。 主目的はチーム内での説明なので、記述にはチーム固有の事情やチームメンバーへの説明を前提としたものなどが一部あります。 なんのためのrebase rebaseをする理由・メリットはいろいろありますがうちのチームに限定すれば目的はほぼ一つです。 その目的はpull requestによるレビューをしやすくすること。 pull requestによるレビューはその性質上レビューによる指摘点を追加のコミットで行うことが多いですが、 この追加コミットは本来それまでにレビューしてもらったコミットへ含めるべきものであることが多いです。 例えば 適切でない変数名 よりベターなロジック記述の仕方 コメント中の誤字・脱字修正 などはすべてそれまでに見てもらったコミ
![[ポエム][社内実習向けメモ書き]git rebase道場 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/85e1708aa5cd52fbc9f3679547920cd3f4681d27/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCJUUzJTgzJTlEJUUzJTgyJUE4JUUzJTgzJUEwJTVEJTVCJUU3JUE0JUJFJUU1JTg2JTg1JUU1JUFFJTlGJUU3JUJGJTkyJUU1JTkwJTkxJUUzJTgxJTkxJUUzJTgzJUExJUUzJTgzJUEyJUU2JTlCJUI4JUUzJTgxJThEJTVEZ2l0JTIwcmViYXNlJUU5JTgxJTkzJUU1JUEwJUI0JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1jZjIxNWEyMDlmZWFlNDMyZWQxNTU4MWQ2NDEwZTM0Yg%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwYmlnd2hlZWwmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTFhMThjODE1N2QxNWNhNzg5MGE1ZmQ5MmE5YjJiYmE1%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D46b7278c21b8e50fd41bf8566f5f063f)
Git入門：Git初学習者のための効率的な学習方法を考えてみた
本記事は，Git Advent Calendar 2014の13日目に投稿させて頂いた記事です． モチベーション 自分を成長させながらいかに効率的に技術を伝承するかが自分の中で課題になっており模索中なこの頃．試しに，社内でGitを使ったことのないエンジニアに1週間(合計7時間)で開発に必要なGitの知識を講義したので，その時に使用した教材や効率的な学習方法を初心者向けに共有する． 背景 一昔前はイケてるエンジニアはGitを使ってプログラムを管理してるみたいな感じだったが，今となってはGitはエンジニアにとって必要不可欠なツールになった．Gitがあるからコードの2重管理はなくなり，Gitがあるから継続的インテグレーションや継続的デリバリーが活きる，Gitがあるから変更に対してコメントを残せる．Gitが無いと開発が成り立たなくなって来ているのだ．特に，Githubのヒット以降，その流れは加速し
コードレビューをし合える文化がチームを強くする - ppworks.jp
コードレビューしてますか？ 「コードレビューをしよう - pblog」でも触れたのですが、 今回はコードレビューの話です。 コードレビューって何からして良いか分からなかったり、レビューアーに負担なんじゃないか、、、って尻込みしがちですが、レビューしてもらう前に気を付けること、なにをレビューしてもらうのか、そして逆にレビューするのか、そして何が起きるのかあたりを考えていきましょう。 レビューして貰う前に気を付けること レビュアーの負担を減らすのは大事です。 コーディング規約に沿っているか？といった簡単なレビューは、犬にやらせるという方法もありますが、そもそもgit-pushする前に、ローカルのgit-commit時点で対処しておくというのもありです。 犬 is rubocopですし、 rubocopやjshintなどをgit-hookにまとめて設定できるpre-commit gemが便利そう
コミットメッセージのルール - Opacities
2014-11-22 コミットメッセージのルール 開発でGit(Github)を利用している時、コミットメッセージは後からログを見返すときにとても大切なものだけど、 普段適当に記述しているのもあって、改めてルールを書くことにした。 コミットの粒度 コミットの粒度では、何かしら一つの作業を終えたら・・・という粒度でコミットすることにする。 具体的には ある範囲のUIを実装した時 何かしらのコードを削除した時 バグを潰した時 など、比較的作業単位で細かくコミットするようにする・ コミットメッセージの内容 1行目 / 内容の要約 例 modify serarch button for product menu 2行目 / 空行 空行にする理由としては、可読性や要約と内容を分離するためにある。 3行目 / 本文 実際に何をやったのかを書く。長すぎるのもダメなのでだいたい60字ぐらいでまとめるよ
新卒研修でGitの話 - けんちゃんくんさんのWeb日記
新卒エンジニア向けの「座学」という枠で、1時間ほどGitについてお話させてもらった。資料はspeackerdeckに。 新卒sは、普段Gitは使っているものの、まだまだ実務で起きた問題を解決できるほどではないようなだった。そこで、自分がGitを理解できたなーと思えたきっかけである「全てはコミットである」を少しでもわかってもらえたらいいかなーと思ってそんな内容になっている。 資料はひたすらコマンドが並べられているだけなんだけど、これを打ってもらいなから結果を確認したり、コミットの繋りをホワイトボードに書いたりしていた。なので、この資料を眺めてもさっぱりかもしれないけど、わかる 人には言いたいことが伝わるんじゃないかと思う。(本当はremoteまで説明したかったんだけど、資料作成と実際の講義時間の問題で割愛している) ペパボでは1週間に2回ずつこういう時間があって、実は今は2週目なんだけど、そ
git 1.7.5で追加されたオプションを使ってgit on Dropboxの運用を見直す | uuu
git 1.7.5がリリースされました。変更点はいろいろありますが、なかでも今回initとcloneに追加された--separate-git-dirオプションに注目してみます。 git init --separate-git-dir=/path/to/repo git initすると普通はカレントディレクトリの下に.gitディレクトリが作られ、そこにリポジトリ情報が格納されます。ワークスペースとリポジトリが単一ディレクトリ下にあるわけですが、以下のような処理をしてリポジトリを破壊してしまった人も居ることでしょう。 $ find -print0 | xargs -0 sed -i 's/foo/bar/g' .. .git/objects/以下が壊滅 この事故はfind -print0ではなくgit ls-files -zを使うことで回避できますが、find以外にも色々と起こりえますし、そも
GitマスターサーバをAmazon Linuxにインストールしてみる - funasaki memo
Gitマスターサーバにgitをインストールする。 $ sudo yum install git git-all git-daemon $ git --version git version 1.7.4.5 xinetdを使ってgitサーバを起動する sudo /etc/init.d/xinetd start gitの設定ファイルでdisable = no に変更 sudo vi /etc/xinedt.d/git # default: off # description: The git damon allows git repositories to be exported using \ # the git:// protocol. service git { disable = no socket_type = stream wait = no user = nobody serve
Git入門 v1.1.0
Frontrend Vol.6 powered by CyberAgent, Inc. http://frontrend.doorkeeper.jp/events/6907 で発表したプレゼン資料です。 こういう資料に対する投げ銭的なのがどうなるのか気になっていたので、もしよろしければ・・・！15円からできるソーシャルカンパサービスだそうですm(_ _)m http://kampa.me/t/dev
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gitignore.io - Create useful .gitignore files for your project
