[B! Git] haru135のブックマーク

Gitでやらかさないための事前予防策 - Qiita

Gitでやらかした時に使える19個の奥義を書いてやらかしたときになんとかリカバリできるようにした。今回は、そもそもやらかさないようにしたいよねっていうお話。コミット編 .gitignoreを細かく指定しておく .gitignoreを指定しておけば余計なファイルをコミットしちゃうことを予防できます過去に似たようなプロジェクトがあるのならそれを流用しましょう。ないのであれば.gitignore.ioで生成してそれをカスタムしましょう。ワイルドカード指定やディレクトリまるごとの指定は副作用ある可能性があるので慎重に。コミットメッセージのフォーマットを決めておくコミットメッセージのフォーマットを決めておけば書き直したいということも減りますコミットメッセージをやらかして直したいと思うことはよくあります。そういうのって案外コミットメッセージが自由すぎることが問題だったりします。ある

haru135 2015/04/14

Git

リンク

tande lab.

好奇心の赴くまま、夫婦で活動・制作したものを公開しています。

haru135 2014/07/23

github
Git

リンク

プロとしての行為 Act as Proffesional

Gitのブランチをどのタイミングで切って、マージしていくかなども非常に大切ですが、ブランチやマージをするよりも頻繁におこなうコミットについて、あらためて基本に立ち返ってみましょう。一つ一つのコミットを綺麗に積み重ねていくことは、ブランチを切るタイミングやマージ、歴史の改編などを容易にすることができます。コミットが綺麗に積み重ねられていないとマージや歴史改変で苦労するでしょう。 Gitのベストプラクティス（原文）に乗っかるためにもgit commitする前に以下のようなことをチェックしましょう。 Gitの操作に慣れている人はPushやMergeをする前に今回紹介するようなことを元にしてコミットの歴史を綺麗に整えましょう。 1コミットに1つの対応1コミットにはあれこれ詰め込めすぎるべきではありません。例えば以下のような2つのことがあったとします。 Aの機能を追加Bの機能のバグを修正2つの対応

haru135 2012/09/05

Git

リンク

ぼくが実際に運用していたGitブランチモデルについて

オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。見えないチカラ: A successful Git branching model を翻訳しました基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ

haru135 2012/09/03

git

リンク

死んで覚える本当のGitの使い方 - mizchi log

注意: バズってますが、これははてなダイアリーからはてなブログの自動マイグレーションに失敗してたものを復旧させたもので、書かれたのは2012年です。 - 最近流行っているGit初心者向け記事は、「僕らが本当に知りたかったこと」が欠けているようにしか思えません。そこで、本当のGitの使い方を僕が皆さんに伝授しようと思いました。なにはともかく使ってみよう前提として、皆様のお手元にはすでにGitがインストールされているものとします。今回はエディタとしてDungeonCrawl StoneSoupを使います。 Downloads « Dungeon Crawl Stone Soup http://crawl.develz.org/wordpress/downloads Dungeon Crwal Stone Soup は今一番ホットなオープンソースのローグライクです。風来のシレンやトルネコ

haru135 2012/07/31

Git

リンク

git - 簡単ガイド

アッド & コミット変更されたファイルを選択します。 git add <filename> git add * を実行するとIndexに追加されます。これは基本的な作業の一つです。変更を実際に適用するには git commit -m "Commit message" を実行します。変更がHEADに入りましたが、リモートリポジトリには未だ入っていません。変更のプッシュこの時点で、変更がローカルリポジトリのHEADに適用されました。この変更をリモートリポジトリに適用するには git push origin master を実行し、masterの代わりに適用のブランチ名を入れます。もし既存リポジトリをクローンせずに使用した場合 git remote add origin <server> を実行すると、リモートリポジトリを登録する事が可能です。これで変更を特定なリモートリポジト

haru135 2012/02/04

リンク

GitHubをもっとソーシャルに使いこなすための7つ道具

新サービスが続々登場してアツい！「GitHub」とは皆さんは「GitHub」を活用しているでしょうか？「GitHub」（ギットハブ）はソースコード管理用の分散型バージョン管理システム「Git」を使ったホスティングサービスです。 Gitの特徴は、作業用として自分のコンピュータ上にあるローカルリポジトリがあれば、ネットワークに接続できない状態だったとしても、ソースコードの更新や、履歴を調べたりできる点にあります。その特徴はGitHubにも生かされていて、オープンソースとして公開中の既存のコードを分岐（fork）して、新しいプロジェクトとして開発できます。また、自分が手元のローカル環境でバグ修正したり、拡張したソースコードを本家のオープンソースプロジェクトに取り込んで（pull）もらうことも手軽にお願いできます。さらに、READMEテキストファイル（README.md）などを独特のマー