入門書を終えた人に捧げる、社会人のためのGit中級編 - Qiita
自分が実際に企業で働くうえでよく使ったコマンドや役に立った設定をまとめてみました。 Git入門系に関しては飽和していると思いますが、ちょっとした応用編としてご覧いただければ幸いです。 自分の環境 ファイルの数や行数が膨大 複数の案件が同時進行することが多く、質問などに答えたりするためにブランチ移動をすることが多い プロジェクト内に複数文字コードが混在している（Shift-JISとUTF-8） コマンド編 基本のコマンド書きなぐり $ git clone <ブランチ名> <ディレクトリ名> # clone先のディレクトリ名まで指定してcloneする $ git pull # pullする。必要に応じて -u や、 remote名、ブランチ名を打ち込む $ git diff # 差分見る $ git diff master HEAD # 現在の状態とmasterを比較する $ git chec
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
某プログラマが某有名ファミコンゲームのソースをgitに公開したの巻 | Colorful Pieces of Game
ツイッターでポロっとつぶやいたのだけど、ここでも記事をば。 某プログラマが34年前に発売された某有名ファミコンゲームのソースをgitに公開したので、以下にリンクを置いておく。 GitHub - omuanko/nnjhtrkn: Famous Ninja game for NESFamous Ninja game for NES. Contribute to omuanko/nnjhtrkn development by creating an account on GitHub. 某プログラマからの箴言は以下。 ■某プログラマ ちなみに びるど とおりますうご(www act65 を cpm86 エミュで 試してみた ソース見られるの恥ずかしい いまさらおそいか ちなみに act65は つけてないよ どっかで ひろってね ところで、イマドキな方には全く理解できないことがいろいろあるだろう
VS CodeによるPython開発環境のテンプレ - Qiita
0. はじめに sublime使いだった僕が（使い込んではいなかったけど）社内のPython開発環境を統一するためにVS Codeの色々を調べたので，そのまとめです． 以下ができるような開発環境の構築を目的としています． 複数人がローカルで開発する時に，環境を揃えたい． ローカルからリモートサーバーにアクセスして開発したい． プロジェクトごとに依存関係を整理したい． コーディングスタイルや型などのチェックを入れたい． Pythonの環境周りはPipenvで管理し，ローカルでdockerを立ち上げてその中で開発するためのテンプレです． 1. install Setting up Visual Studio Code 2. Extension 2.1. 必須 以下は必須． python Remote Development Remote SSH git lens 2.2. オプショナル その他
Markdown と GitHub で社内規程を便利に管理 - クックパッド開発者ブログ
VP of Technology の星 (@kani_b) です。技術基盤や研究開発領域などを担当しつつ、社内の色々なことを技術の力でいい感じにする仕事をしています。セキュリティや AWS の話が好きです。 さて、みなさんは、ご自身が勤務する会社の就業規則を読んだことはあるでしょうか。 エンジニアに限らず、会社の全スタッフが仕事をする上で関わってくるのが、就業規則や情報セキュリティドキュメントなど、会社のルールや規程を記す文書です。 特にセキュリティやインフラに携わるエンジニアは、その改訂も含め携わったことがある方もいるのではと思います。 よくある文書管理 こうした文書は、以下のように管理されていることが多いようです。 ベースドキュメントは Word 保存時は PDF で保存 版管理は Word の編集履歴 + PDF に保存する際のファイル名 編集は担当部門, 担当者のみが行う かつての
今さら聞けない人のためのGit超入門 OSC2018名古屋版
2. 自己紹介 • 本名：宮原 徹 • 1972年1月 神奈川県生まれ • 1994年3月 中央大学法学部法律学科卒業 • 1994年4月 日本オラクル株式会社入社 – PCサーバ向けRDBMS製品マーケティングに従事 – Linux版Oracle8の日本市場向け出荷に貢献 • 2000年3月 株式会社デジタルデザイン 東京支社長および株 式会社アクアリウムコンピューター 代表取締役社長に就任 – 2000年6月 （株）デジタルデザイン、ナスダック・ジャパン上場（4764） • 2001年1月 株式会社びぎねっと 設立 • 2006年12月 日本仮想化技術株式会社 設立 • 2008年10月 IPA「日本OSS貢献者賞」受賞 • 2009年10月 日中韓OSSアワード 「特別貢献賞」受賞 • ガンダム勉強会主宰・好きなモビルスーツはアッガイ 2 4. 日本仮想化技術株式会社 概要 • 社名
Gitのコミットメッセージの書き方 | POSTD
(訳注：2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注：2015/11/1、いただいた翻訳フィードバックを元に記事を再修正いたしました。) 訳： プロジェクトが長引くほど、私のGitのコミットメッセージは情報が薄くなっていく。 イントロダクション | 7つのルール | ヒント イントロダクション：なぜ良いコミットメッセージを書くことが重要か Gitのリボジトリのログをランダムに閲覧すると、ひどいコミットメッセージを目にすることがあります。例として、私が昔書いたSpringにコミットした これらのgem を見てみましょう。 $ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009" e5f4b49 Re-adding ConfigurationPostProcessorTest
Git中級者に送る便利なコマンド群 - カイワレの大冒険 Second
Gitを使っていて、ちょくちょく便利だなと思うコマンドに出会うので、メモ残しておきます。実際中級者の方には物足りないかもしれませんが、とりあえず。目次は以下。 自分がいじったファイルを一旦退避させたい ツリーが今どういう状態になっているか確認したい 今まで作業をやったことを振り返って、特定の過去に戻りたい リモートブランチをチェックアウトしたい コンフリクトがあったファイル一覧を表示したい 間違ってremote masterブランチにpushしてしまったので、取り消したい マージコミットを消したい 過去のまとまったコミットをまとめたい ここから載せるサンプルは、以下のフローが既に処理された前提で話します。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 # 適当にファイル作成、push $ touch sample.txt
開発フロー研修 @ Wantedly - Qiita
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、
Git入門：Git初学習者のための効率的な学習方法を考えてみた
本記事は，Git Advent Calendar 2014の13日目に投稿させて頂いた記事です． モチベーション 自分を成長させながらいかに効率的に技術を伝承するかが自分の中で課題になっており模索中なこの頃．試しに，社内でGitを使ったことのないエンジニアに1週間(合計7時間)で開発に必要なGitの知識を講義したので，その時に使用した教材や効率的な学習方法を初心者向けに共有する． 背景 一昔前はイケてるエンジニアはGitを使ってプログラムを管理してるみたいな感じだったが，今となってはGitはエンジニアにとって必要不可欠なツールになった．Gitがあるからコードの2重管理はなくなり，Gitがあるから継続的インテグレーションや継続的デリバリーが活きる，Gitがあるから変更に対してコメントを残せる．Gitが無いと開発が成り立たなくなって来ているのだ．特に，Githubのヒット以降，その流れは加速し
GitLab flowから学ぶワークフローの実践 | POSTD
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
【Git】サルでも分かるとか言われても分かんねーよって思ってたけど、少しだけGit使えるようになってきた話
Git使ってます？Git。 覚えなくちゃなあ…でもあれ正直よくわかんないんだよなあ…。そんなデザイナー結構いるんじゃないかと思いますが（いてくれ！）いかがでしょうか。 一応、ご存じない方のために概要を抜粋。 Git（ギットまたはジット）は、プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムである。もとはLinuxカーネルのソースコード管理に用いるためにリーナス・トーバルズによって開発され、それ以降ほかの多くのプロジェクトで採用されている。Linuxカーネルのような巨大プロジェクトにも対応できるように、動作速度に重点が置かれている。現在のメンテナンスは濱野純 (Junio C Hamano) が担当している。 Wikipediaより つまりGitとは、コードや画像の修正・変更ごとにファイルの状態を記録し、それぞれのバージョンを管理することができるシステム
「WordPressサイト制作におけるデプロイメントを考える」フォローアップ #wckansai | Waviaei
先の投稿でも書いたとおり、6月7〜8日開催されたWordCamp Kansai 2014に参加し、公募枠で登壇してきました。 セッションを聞いてくださった皆様、ありがとうございました。 セッションのタイトルは「WordPressサイト制作におけるデプロイメントを考える〜Gitとデプロイメントサービスの活用〜」です。概要はというと、WordCamp Kansaiのサイトからの引用になりますが： 現在WordPressサイトの構築や更新には、FTPもしくはSFTPソフトを利用したデプロイメントが主流です。サイト全体の引っ越しであれば、あるいはrsyncやscpといったコマンドを使う場合もあるでしょう。しかし手動で行う作業や、不慣れなコマンドを使うことにより、ミスしたり、時間が掛かったりしませんか？ 一方で、最近は開発にGitを用いたVCを実践している、あるいは検討、勉強しているという方も少しず
GitHub Kaigiで「はてなブログチームの開発フローとGitHub」という発表をしました - Hatena Developer Blog
こんにちは、id:shiba_yu36です。先日開催された「GitHub Kaigi」にて、はてなブログチームでのGitHubを利用した開発フローについて、「はてなブログチームの開発フローとGitHub」というタイトルで発表しました。 資料はこちらです。 はてなブログチームの開発フローとGitHub // Speaker Deck はてなブログチームでは日々開発効率が上がるよう、開発フローの改善をしています。そこで今回の発表では、はてなブログチームの開発フローで、「タスク管理」、「レビュー」、「リリース」の3つのトピックで、実際に起こった問題とそれをGitHubなどを利用してどのように解決してきたかについて具体的に紹介しました。 1つ目のタスク管理というトピックでは、Redmineなどのタスク管理ツールとGitHubを併用している時の問題や、GitHubのIssuesのみタスク管理に利用し
提言: コミットメッセージの一行目には要求仕様を書け - Qiita
これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情
Git を学ぶ - チュートリアル、ワークフローおよびコマンド | Atlassian
Git は、元々 Linus Torvalds によって 2005 年に作られた、無料でオープンソースのバージョン管理システムです。他の SVN や CVS といった中央バージョン管理システムと違って、Git は分散型で、すべての開発者がローカル環境で彼らのコードのリポジトリの完全な履歴を持っています。これは、最初のリポジトリのクローン作成に時間がかかりますが、commit、blame、diff、merge、log といったこれに続く作業を劇的にスピードアップします。 Git は多くの革新的で強力なワークフローやツールにつながる、リポジトリ履歴のブランチ、マージ、および書き換えに非常に役立ちます。プル リクエストは、チームが Git ブランチでコラボレーションを行い、他のコードを効果的に見直すことができる、非常に人気のツールです。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を押してこの変更をステージングします。すると次は以下の表
イケててヤバいGit入門 | GREE Engineering
この投稿はGREE Advent Calendar 2013 20日目の記事です。 プロデューサーの皆さん、みりっほー。進捗どうですか？私はダメです。ごめんなさい。（´・ω・｀） WG事業部の二宮です。今日はアイマス駆動開発の話をしようかと思ったのですが、急遽Gitの使い方の話に変更しました(Inspired by 堀口先生)。 アイマス駆動開発の話が気になる方は、是非一緒に飲みに行きましょうw ※この記事では、ツールにGitやGitHubを利用することを想定しております。 Gitをスマートに使いたい グリーでは、基本的にA successful Git branching model（有志の方による日本語訳）にのっとって開発しています。 Gitについて基本的な考え方の部分は堀口さんの記事で言及されているので、私は現場で具体的にどのような使い方をしているのかについて書きたいと思います。 と
git による分散作業パターン | GREE Engineering
分散バージョン管理を華麗に扱いたい堀口です。 GREE Advent calendar 2013 の 14 日目として参加させていただきます。 お二人に続き Haskell の話をしようかと思ったのですが、急遽無難な開発の話に変更しました :o Java や C++ には OOP の概念が必要であったように、分散作業の認識が薄いまま git や Mercurial を使うことは長期的に不幸をもたらします。 とあるプロジェクトにて、その一部を副産物のミドルウェアとして抽出すべく、アプリケーションと分離したい 不具合があったので原因を探りたいが、依存関係が複雑すぎるのでコードを読む量を減らしたい テストやレビュー、提案、リファクタの運用を強化したい よそのプロジェクトに迷惑を掛けないように、そこのツールを改良して使いたい。 いままで何気なく「こんなもんだろう」と思って手間をかけていませんでした
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
YAPC::Asia 2014 で「Git によるツール開発」というタイトルで話しました #yapcasia - 詩と創作・思索のひろば
