コミットは作業ログではない！ - Qiita
いきなりだけど、こんなコミット、よく見ない？ （例１とする） 見た瞬間に腕まくりして修正依頼と理由を書き出したくなっちゃう感じ！ これが良くない理由を、持論だけど挙げてみるよ このコミットについて コミットは作業単位でするものではない プルリクエスト（以下 PR）をレビューする側に立って考えるとよくわかるのだけど、 PRレビューをする人が欲しているのは(= masterブランチが欲している、チームが欲していると言っても良い）作業者の作業ログではない。 レビューする人にとって、そのPR作成者が「どれくらいの時間をかけた」とか「休日もコミットを重ねてた」とか 「何ファイルも直さなくちゃあならなくて大変だった」とか「いつどこでブランチを切り換えて自分の出したPRを見てくれていた」とか、 そんなことはぶっちゃけ全く興味がないんだ。 欲しいのは「生成物と成果」であって、それを「どの様な作業工程」で作
MacとWindows混在でgit使ってる時の問題 - モーグルとカバとパウダーの日記
世の中の主なOS、Unix系、Windows系、Mac系ではそれぞれ改行コードが違っています。 LinuxなどUnix系の改行コードは「LF」で、Windowsは「CRLF」、Macは「CR」(昔のOS9の頃まで。今のOSXはUnix系なので「LF」)となぜかそれぞれ別になってしまっています。 自分はWindowsではSourceTreeでgitを使っているのですが、Linux上のスクリプト言語のソースは改行コードは普通LFにする必要があるため、SourceTreeのデフォルトのgitの設定では、commitする時に「CRLF」→「LF」に自動変換され、checkoutする時には逆に「LF」→「CRLF」に変換されるようになっています。 でもこれだと、なにも触ってないのに修正されているファイルとして上がってきてしまうことがあって、そしてしかたないからcommitしようとすると、変更されてな
windows環境の git で改行コードの自動変換に注意 - Qiita
windows環境で git を使っていて、改行コードが意図しないものになってしまっていたことがあり、git for windows には改行コードの自動変換というものの存在に気づきました。 git のインストーラーのデフォルト設定では、この自動変換がONになっているので、備忘録のためにおさらい。 git for windows（msysgit） のインストール 最新版のダウンロード ⇒ git for windows インストールの詳細については以下を参照。 ⇒ 私家版 Git For Windowsのインストール手順 ⇒ WindowsにGitをインストールする手順について このインストーラーでデフォルト設定でインストールしていくと、改行コードの自動変換がONになっているので注意！ (1) Select Components ⇒ デフォルトでOK (2) Adjusting your
GitHub Enterpriseがやってきた！～導入編～
どうもはじめまして。 シャノンで社内インフラを担当しているma2iです。 入社してからもうすぐ半年になるのですが、時間って本当に早いですね。 今回初のブログ当番という事で、今年買った輸入盤ベスト５でも紹介しようと 思ったのですが、技術ブログなのでそれはダメだそうです・・。 閑和休題。 何を書こうか迷ったのですが、先日社内に導入した「GitHub Enterprise」（以下GHE）に ついて書いてみたいと思います。GitHubについては様々な情報があるのですが、GHEに 関しては日本語の情報がまだ少ない気がします。今回の作業の経緯をまとめることで、 GHE導入を躊躇している管理者の方々の参考になればよいかと思います。 ■GitHub Enterpriseとは？（一応説明しておきます） GitHubをクローズドな環境で使うために、GitHub社が提供しているソフトウェアです。 機能やインタフ
git push --force でなく git push --force-with-lease を使う - valid,invalid
前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある git push --force でなく、最後に fetch したタイミング以降に他人が push していたら失敗する git push --force-with-lease を使う方が良い。 --force considered harmful; understanding git's --force-with-lease - Atlassian Developers Quipper では GitHub flow のような開発フローを採用している。 各開発者が feature branch を作成し、master / develop branch へ pull request を作る流れだ。 他人と修正箇所が重なってコンフリクトした際には rebase が必要で、 rebase 後の内容を push する際には
僕のチームの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を
サイバーエージェントのGitHub活用 ～ 導入から運用体制、開発フロー、勉強会による現場への普及活動まで
また、Organization[1]の数も360を超え[2]、リポジトリ数もOrganizationのものだけでも2000近く作られています[3]。 新規のプロジェクトは基本的にGitを利用しており、既存プロジェクトもほとんどがSubversion（以下SVN）などからGitに移行しました。 本記事では、Ameba事業本部がどのようにGitを組織内に普及させていったか、その運用体制、現場でどのように利用されているのかをご紹介します。 [1] 複数アカウントをまとめるグループ機能です。リポジトリは個人単位だけでなく、Organization単位で作ることもできます。 [2] プロジェクト単位で1つのOrganizationを用意しています。 [3] 個人アカウントで作成したり、他からforkしたリポジトリは除いた数です。 GitHub Enterprise導入への道のり GHE導入以前の標準
Gitマージの基本 マージ・競合・競合解決・マージしなおし - Qiita
オライリー・ジャパン『実用Git』を最近読み終えたので、 マージについて、実用的な部分をつらつらとまとめておく。 時間があればマージだけでなく、コミットの変更方法についても後日書くかも。 マージ方法 マージするにはマージされる（他ブランチのコードを取り込む）側のブランチをチェックアウトして、 マージ対象（他のブランチにコードを取り込まれる）ブランチを指定して実行。 マージする時には余計なトラブルを避ける為に、未コミットのものがある状態でのマージは避ける。 # topic1,topic2のブランチがmasterにないコミットを含んでいる事を確認 $ git show-branch * [master] a ! [topic1] b ! [topic2] c --- + [topic2] c + [topic1] b *++ [master] a #マージ実行 $ git merge topi
Git submodule の基礎 - Qiita
この記事は Git Advent Calendar 6日目の記事です！ Git submodule って最初わかりにくいと思うので、基本的な説明をしようと思います。 git submodule とは git submodule は、外部の git リポジトリを、自分の git リポジトリのサブディレクトリとして登録し、特定の commit を参照する仕組みです。 Subversion でいうところの、external と似ています。 さて、解説のため、手元に、リポジトリA (/path/to/a) とAの submodule として、よく使う例として Bootstrap (元Twitter Bootstrap) を登録してみます。 git submodule を理解するうえで重要なのは、 リポジトリAが指し示すsubmoduleとしてのBootstrapのcommit 現在のBootstr
GitHubへのアクセスはSSHよりHTTPSがお勧めらしいので切り替えてみた - Qiita
はじめに Set Up Git · GitHub HelpのNext steps: Authenticating with GitHub from Gitによると、GitHubへのアクセスはSSHよりHTTPSがお勧めらしいです。 OSXのキーチェーンにgitで使用するパスワード/アクセストークンを保存する設定 Caching your GitHub password in Git · GitHub Help 私はHomebrewでgitをインストールしているのでgit-credential-osxkeychainはインストール済みでした。 ということで、設定は以下のコマンドを実行するだけです。 この設定をしておくと、GitHubからgit cloneするときにユーザ名(メールアドレス)とパスワードを聞かれて、入力するとキーチェーンに保存されます。以降はパスワードの入力は不要になります。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gistnote
Gitを一度はあきらめた人のためのわかりやすいスライド９選
GitHub Status
GitLab