gitの良さがいまだに分からない - 負け犬プログラマーの歩み
ここ2年ぐらいで俺が働いた現場はみんなgitを採用している。就職エージェントと面談するときもgit経験の有無をよく訊かれるし、今ではVSSやCVSどころか、SVNですら時代遅れになってきて、SVNを使っている現場は「レベルが低い」「保守的・旧態依然」という雰囲気すら感じる。 俺としては4-5年前からgit(GitHub)を使っているし、gitを使うこと自体に抵抗はない。一通りの基本操作はできるし、人並みにはできると言っても差し支えはない。 …が、正直gitの良さがあまり見えてこない。 もし俺が中規模以上のプロジェクトのリリースを本格的に管理する側であれば全然違った感想を持ったかもしれない。でも一人の開発者として、せいぜい10人程度のプロジェクトで利用する限り、「gitで良かった」という状況があまり思い当たらない。 ではgitの何が気に食わないのか書いていきたい。 ①gitは馬鹿には難しい
GitHub おじさん スターターキット - Qiita
この記事はGit Advent Calendar 2015の16日目の記事です。 はじめに この記事を読むと、GitHub と Git を人に紹介する時や、GitHub 導入後に注意すること、GitHub 普及の際のメンタルついて知識が得られます。 ある程度、Git, GitHub の知識があり、これから現場に GitHub を普及させたい方に有用な記事かもしれません。技術的な Tips は少なめです。 目次 どうも、GitHub おじさん、または 一度死んだおじさん こと沖縄の金城です。GitHubについてと人に説明する機会や導入する機会が多いので、その経験から、どんなことに注意しながら進めていけばいいか書いてみます。 記事は 「紹介編」,「導入後編」,「おじさん編」の３つの編から構成されています。 紹介編 Git はバージョン管理ツール、 GitHub は Git のホスティングサービ
Gitはじめの一歩
SlideShare上の本資料は現在メンテされていません。 ↓↓↓SpeakerDeck版をご覧ください！（時々アプデしてます）↓↓↓ https://speakerdeck.com/ihcomega56/githazimefalse-bu
etckeeperで設定ファイルのバージョン管理を始めよう
斎藤です。こんにちは。 今日は、etckeeperを用いて、設定ファイルをバージョン管理する方法を説明します。設定ファイルの書き換えで辛い目に遭う前に、どうぞお試しください。 ※CentOS 6.4, Ubuntu 12.04 LTS, etckeepr 1.7を基準に説明します etckeeperとは etckeeperは主に/etc配下をVCS(Version Control Systems)を用いてバージョン管理します。実態は、gitやmercurialのwrapperとなっています。 設定ファイルの書き換えの際に、ファイル名に日付をつけてバックアップしたりする手間を省いたり、誤って書き換えてしまったときのための 保険 として利用する事ができます。 インストール方法 はじめに 先程も述べました通り、etckeeperはVCSのwrapperとして動きます。そのため、インストール時には
subversionでのブランチマネジメント | Webシステム開発／教育ソリューションのタイムインターメディア
分散バージョン管理システムつかってますか？ 世の中ではgitやhgなどの分散型のバージョン管理システムが流行していて、「もうsvnなんて、、、」「まだsvnつかっているの、、、」という風潮になっています。 弊社内でもgitのレポジトリが立ったり、svnのプロジェクトでも自分の環境だけはgit-svnで分散バージョン管理を使う人が増えています。 「自分の環境だけはgit-svnで」。そう、社内ではまだまだsvnを使っているプロジェクトが多いのです。「日本語のファイル名が使えない」「デザイナーさんに使ってもらうためのわかりやすいクライアントが無い」「svnからなかなか移行するコストが、、」などの理由でsvnを使い続けているプロジェクトも多いと思います。 というわけで、分散バーション管理システムではなく社内で運用されているsvnでのブランチマネジメントについて、備忘録もかねて説明します。 前提
良いPull Requestのための10のTips読んだ時のメモ - 気の向くままに書き綴る
この記事を先週読んでセコセコ、メモしていたら、日本語の翻訳が出てた。 せっかくの機会なのでGistに貼っていたのもをブログに上げる。 原文 10 tips for better Pull Requests Yakst - より良いプルリクエストのための10のヒント 良いPull Requestのための10のTips 良いPull Requestを作ることは良いコードを書くこと以上を伴うもの Pull Requestモデルは、チームで開発する素晴らしい方法であることが判明している(特に分散しているチーム) もちろんこのモデルはOSS開発だけじゃなくても、エンタープライズでも言える。 2010年位から私は、自身のOSS、顧客のいくつか、また内部のクローズド開発でもPull Requestモデルを行ってきた。 当時、私は多くの偉大なPull Requestを見てきた。 そして、いくつか改善が必要
安全なMergeを行う開発フロー | DevelopersIO
渡辺です。 スノーボードでのスピン（回転）では、フロントサイド（前回り）は視界に向けて回るので比較的に簡単です。 ところが、バックサイド（背中周り）は非常に難しいと感じます。 これは見えない方向への回転なので見えないためであり、恐怖心が原因です。 解らないのは怖いことです。 解ってしまえば意外と簡単だったりします。 「幽霊の正体見たり枯れ尾花」とは良く言ったものですね。 Git（バージョン管理）のMergeも同様です。 Mergeの正体を理解し、恐怖心をなくしましょう。 最後の最後は気合いで手動Merge はじめにお断りしますが、Mergeを理解したとしても、手動でMergeする作業がなくなるわけではありません。 そして、手動でMergeするときは、最終的に気合いでMergeする以外の方法はありません（笑） しかし、Mergeを理解しConflict（競合）が発生しにくい運用を行うことで、
Gitのコミットメッセージの書き方 - Qiita
Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 （2014年12月17日追記） 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど！と思ったコメントをもとに少し修正・加筆してみました。 （2022年1月4日追記） 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目：変更内容の要約（タイトル、概要） 2行目 ：空行 3行目以降：変更した理由（内容、詳細） 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 （多すぎても悩むので
リポジトリの作成と基本的なバージョン管理――SourceTreeで始めるGitバージョン管理入門 第1回 | OSDN Magazine
本記事では、GUIで操作できるGitクライアントであるSourceTreeを使用し、バージョン管理を行う際に必要なリポジトリの作成やリポジトリへのファイルの追加/削除、コミットといった基本的な作業について説明します。 【連載】SourceTreeで始めるGitバージョン管理入門 第1回：リポジトリの作成と基本的なバージョン管理 第2回：タグとブランチ 第3回：国産のGitリポジトリサービス「SourceForge.JP」 本記事について 本記事は、2014年10月22日にソフトバンク クリエイティブより発売された書籍「デザイナーからプログラマーまで 絶対わかるGitバージョン管理」から、「第2章 バージョン管理はじめの一歩」の一部を抜き出し再構成したものです。 なお、本書の解説ではMac OS X版のSourceTreeを使用していますが、Windows版の場合でも同じ操作で作業を行うこと
Review Boardならコードレビューを効率良くできる！
Review Boardならコードレビューを効率良くできる！：ユカイ、ツーカイ、カイハツ環境！（19）（1/3 ページ） “コードレビュー”やってますか？ “コードレビュー”は、ソフトウェア開発の重要なプロセスですが、往々にしておざなりにされがちです。 しかし、きちんとコードをレビューすることで、品質向上や、早期のバグ発見による後工程でのコスト削減につながります。また、病気や事故、他のプロジェクトへの突発的な火消し（！）などによる、開発メンバーの長期離脱時のリスク削減にもつながります。さらには、他の開発者が書いたコードを読んで学習することにより、コーディングスキルの向上にも役に立ちます。 今回は、「そうはいっても、現実的にコードレビューなんて無理……」という方のために、コードレビューを効率化する「Review Board」というツールを紹介します。 Review Boardの主な特徴5つ
Meld
Meld Visual diff and merge tool Meld helps you compare files, directories, and version controlled projects. It provides two- and three-way comparison of both files and directories, and has support for many popular version control systems. Meld helps you review code changes and understand patches. It might even help you to figure out what's going on in that merge you keep avoiding. File comparison
ノンプログラマでも今日から使える「Git」でバージョン管理
※ 本スライドの内容を解説した、電子書籍を販売中です。 <a>http://p.booklog.jp/book/86773</a> 「Git（ギット）」や「バージョン管理」という言葉は聞いたことはあっても、なんだか難しそうなイメージを持っているかも知れません。 特に、プログラマーやエンジニアのツールであって、デザイナー・マークアップエンジニア・ディレクターの方は「自分には無縁」と思っているのではないでしょうか。 しかし、Gitはプロジェクトに関わるすべての方が使えると、コミュニケーションツールとしての役割も果たし、非常にスムーズにプロジェクトを進行させることができます。 このイベントでは「ノンプログラマの方」を対象に、Gitのよく使う部分だけをピックアップしてわかりやすく紹介、今日から使えるテクニックや便利なポイントを紹介していきます。Read less
Githubでカンバンが使えるようになるZenHubが素晴らしすぎる - たけぞう瀕死ブログ
GithubのIssueはワークフロー制御ができない、優先度順でソートできないなど、仕事で使うにはやや機能が貧弱なところです（個人的にはそのシンプルなところがOSSプロジェクトで使うのにはあっていると思いますが）。特にIssueだけを見ているとプロジェクト全体の状況がわかりにくいというのはよく言われるところです。そこで同僚に教えてもらったのがZenHubというサービスです。 日本語の記事もありました。この記事を読めばZenHubがどんなものかは大体わかると思います。 http://blog.isao.co.jp/post/87265630773/github-issue-zenhub 今までもGithubのIssueをカンバン化するツールやサービスはあったのですが、ZenHubが面白いのはChromeエクステンションとして提供することで、あたかもGithubの1機能であるかのようにカンバン
提言: コミットメッセージの一行目には要求仕様を書け - Qiita
これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情
Web制作者のための実践Git | 第1回 適切な履歴の作り方
上記の例の場合、変更した箇所が近いため同じhunk（変更の塊）として表示されています。ですので、hunkをさらに分割する必要があります。そのためにはsを選択します。そうすると次のような表示になります。 Split into 2 hunks. @@ -1,5 +1,5 @@ <ul> <li><a href="/">Home</a></li> - <li><a href="/about.html">About</a> + <li><a href="/about.html">About</a></li> <li><a href="/help.html">Help</a></li> </ul> Stage this hunk [y,n,q,a,d,/,j,J,g,e,?]? 変更が分割されて閉じタグ忘れだけの変更が表示されています。ここでyを押してこの変更をステージングします。すると次は以下の表
分散バージョン管理入門 (イラスト入り) - tcha.org
Kalid Azad、 2007 年 10 月 15 日、 原文 (original post) 従来のバージョン管理は、ファイルをバックアップ・追跡・同期するのに役立った。 分散バージョン管理を使うと、変更内容を共有するのが楽になる。 さぁ、両方の長所を活かすんだ。簡単なマージと一括管理されたリリースを。 分散だって? これまでのバージョン管理で何がまずいの? 別に…。 さっ、気を取り戻したければ、 バージョン管理へのビジュアルガイド(英語) を読んで。 もちろん、「古くさい」システムを使っているとバカにする人もいるだろう。 けれど、私はそれで全然かまわないと思う。 どんなバージョン管理システム(VCS)を使うにしても、プロジェクトにとっては前向きな一歩なんだから。 集中型バージョン管理システムは 1970 年頃に現れた。 その頃プログラマーには、シンクライアントと “big iron”
デザイナーでも使うと便利なバージョン管理システムGitの勉強会に参加しました ｜https://wp.yat-net.com/name
2013年 02月 05日 デザイナーでも使うと便利なバージョン管理システムGitの勉強会に参加しました カテゴリ： Git タグ：Git この週末にGitの勉強会を開いてもらって基礎的なところから教えてもらいました。これまで興味はあったけど全く何も知らなかったので、いろいろ詳しく教えて頂きました。 1.Gitとは？ 2.用語解説 3.実際に使ってみる。msysgit 4.参考文献 Gitとは？ 分散型バージョン管理システムの一つです。ファイルの更新状態を好きなタイミングで保存しておくことが出来、好きなタイミングで保存している状態へ戻したり、編集した箇所の差分を表示したりする事が出来ます。 また、プロジェクトを複数人で進行している場合に起こりうる、古いファイルでの最新ファイルの上書きといったトラブルについても、Gitを利用すればエラーが帰ってくるため避けやすくなります。 尚、Gitと聞くと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
一人でもはじめるGitでバージョン管理
日本語版 : IBM Bluemix
http://www.crystal-creation.com/software/technical-information/tool/version-control/visual-svn/