Git は、最も一般的に使用されるバージョン 管理システムです。 Git を使用すると、ファイルに加えた変更を追跡できるため、実行された内容を記録し、必要に応じて以前のバージョンのファイルに戻すことができます。 また、Git を使用するとコラボレーションが容易になり、複数のユーザーによる変更をすべて 1 つのソースにマージできます。 Git は Windows AND on WSL にインストールできます 重要な考慮事項: WSL を有効にして Linux ディストリビューションをインストールする場合は、コンピューター上の Windows NTFS C:\ ドライブから分離された新しいファイル システムをインストールします。 Linux では、ドライブに文字は与えまれません。 マウント ポイントが指定されます。 ファイル システム / のルートは、WSL の場合、ルート パーティションまた
今までdotfilesの類いをcodereposにコミットしていたのですが、codecheck.inにもコミットしたくなりました。でも複数svnレポジトリをトラックとかできんの？ということでとりあえずmanpageを見る事に。 man git-svn svn-remote Specify the [svn-remote ""] section to use, this allows SVN multiple repositories to be tracked. Default: "svn" git-svn(1) という事が書いてあったので、できそうな気がします。 git-svn initしてみる 何も考えずにgit svn initしてみよう。 git svn init http://hogehoge.com/ git svn init http://fugafuga.com/ --sv
こんにちは！テニスはじめました、小山です。開発部門でウエディンググループのリーダーをやっています。 今回は私が考えた新しいGitのブランチモデル「GitFeatureFlow」についてお伝えしたいと思います。 GitFeatureFlowとは Gitを使った開発をより快適にするため、GitFlow,GitHubFlow,GitLabFlowではない、新しいGitのブランチモデル「GitFeatureFlow」を考えました。 Gitを利用して開発を行う場合、Gitのブランチモデルをどうすべきか悩むことが多いかと思います。私自身もこの悩みに直面しました。既存のブランチモデルでは問題が解決できなかったので、GitFeatureFlowという新しいブランチモデルを考え、ウェディンググループに導入。今では快適にGit開発を行っています。 GitFeatureFlowで使う主なブランチはこの3つです。
今回のソリューション：【GitLab/ギットラボ】 〜ソースコードのバージョン管理をSVNからGitLabへ移行し、コードの品質向上、開発者のスキルアップに成功した事例〜 結婚式場の日本最大級のクチコミサイト「ウエディングパーク」を運営する株式会社ウエディングパーク。同社では何年も続いていたSVNでのソースコード管理を、Gitベースのレポジトリ管理ツール「GitLab（ギットラボ）」に移行した。 SVNでは並行開発が難しく、コードレビューもPCの画面を直接見てもらうような形式で行っていたことに課題を感じていたためだ。GitLabは自社のサーバー上に構築でき、OSSの開発で定番となった「GitHub」に近い機能やデザインを提供しているため、コードの共有やレビューが気軽に行える。 同社に新卒で入社した栗山 茜さんと小山 翔平さんは、何度も社内勉強会を開催し、ドキュメントを整備することでGitL
![SVNを捨てGitへ！「GitLab」を社内に浸透させた方法と、移行によるメリットとは？ | SELECK [セレック]](https://cdn-ak-scissors.b.st-hatena.com/image/square/c25c8bd91910b743594d4b66d3f09b0dfe41ce6c/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fproxy.goincop1.workers.dev%3A443%2Fhttps%2Fdpd29bjwmgbr8.cloudfront.net%2Fwp-content%2Fuploads%2F2016%2F03%2F16145412%2F54c1f922-5c4b-4414-bc11-03996fbfbf98.jpg)
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? まえがき 私はGit好きの人間です。 もっと言えば、Gitを愛している（Git Lover）と言ってもいいくらいです。 そんな私がなぜこんなタイトルの記事をいまさら書こうと思ったかというと、 いまだにGitの便利さを知らず、Subversionを強い理由もなく使い続ける開発者が多いからです。 そんなわけで 「会社にGit/GitHubを導入するための説得する」 という目的でこの記事を書こうと思います。 Gitの良さってなんだろう？ 実は私もこれまで強く意識して考えたことはありませんでした。 Gitを使い出したら、 それがあるのが当たり前
※本稿は諸事情により過去の投稿を再投稿したものです。 はじめに git-svn を使うと、素直な SVN リポジトリーなら簡単に移行できますが、実運用してきた SVN リポジトリーを移行する際はつまづくことも多々あります。 また Git リポジトリー化ができてもブランチやタグは手作業で作ることになります。 今回、たまたま移行を検討する機会があったので、その予行作業のなかで得た知識をメモしておきます。 作業を行ったクライアント環境は Ubuntu 14.04 / Git 1.9.3 です。 SVN リポジトリーは HTTPS でアクセスできる状態です。 移行の第一歩 まずは SVN リポジトリーからローカル環境に Git リポジトリーを作成します。 git svn clone または git svn init + git svn fetch を使います。 ヘルプや Book にも記載されてい
最近のgitを使ったWebアプリケーションのプロジェクトの開発フロー (主にブランチ運用) について記すものです． なお前提としてGitHub Enterpriseを利用しています． git-flow 大上段に構えたもののあまり特殊なことはしていなくて，基本的にgit-flowをそのまま踏襲しています． git-flowについてはしっかりした解説記事がインターネット上に数多く存在しますからそれらを参考にしていただければと思いますが，ざっくり説明すると masterブランチ，developブランチ，releaseブランチ，featureブランチ及びhotfixブランチがある masterブランチは常にリリース可能な状態になっている (すなわち現在本番で稼働しているアプリケーションのコードと等しい) developブランチは開発中の状態で，ステージング環境等に上がっている releaseブラン
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
案件で「作業の差分を納品してくれ」とか言われることってよくあります。 今までは手作業でディレクトリ作って、ファイルをコピーしてましたが、 もう、そんなうんざりする作業とはおさらばできそうです。 git archive と git diff の合わせ技で差分を出力できる事がわかったからです。 例えば、一個前のコミットから現在のコミットまでの差分を取り出したい時は、 まずは、git archive について。 --format=zip を付けるとzipで固めてくれます。 --prefix=root/ は抽出したファイルをrootディレクトリに入れた状態にしてくれます。 -o archive.zip で出力先と出力名を指定しています。 HEAD は抽出元のコミットで、 抽出したいファイルやディレクトリをgit diffを使って指定しています。 git diff は --name-only を付け
| 書籍紹介 | サイトの目的 | ダウンロード | 更新情報 | 謝辞 | お問い合わせ | 書籍紹介 Git は、 Linux カーネル開発のために Linus Torvalds さんが2005年に公開した分散型バージョン管理システムです。スタートアップのような小規模組織からGoogle、 IBM のような巨大企業で、また数多くのオープンソースプロジェクトで利用されています。現在の Git 開発は、濱野純さんを中心としたコミュニティによって非常に活発に行われています。 本書 Pro Git は、2009年に Apress から初版が、2014年に第2版が出版された、Git の解説書です。著者の Scott Chacon さんは、GitHub 社の CIO、Git のエバンジェリストであり、Git 公式サイトの管理者でもあります。 本書の内容は、出版以降も有志により頻繁に更新されており、
今は企業内においてもバージョン管理でGitを使う所が増えています。個人個人がリポジトリを持つことでオフラインでも開発がスムーズに進められたり、多数の関連ツールの登場によって生産性が向上しています。 GitHubやBitBucketのようなGitリポジトリサービスもありますが、企業内部でリポジトリを持ちたいというケースも多いでしょう。そこで使ってみたいのがGogsです。 Gogsの使い方 GogsはGitHubを強く意識したUIになっていますので、既にGitHubを使っている方であればすぐに使えるようになると思います。社内や自社サーバにGitリポジトリサーバを立てたい時に選択肢の一つに考えてみてください。 GogsはGo製、BSD Licenseのオープンソース・ソフトウェアです。 Gogs: Go Git Service - A self-hosted Git service writte
先日は既に公開されているWEBデータを元に、ローカル環境を作りました。 今回はその逆。ローカルで開発してきたデータを、サーバーに乗せて管理します。 ローカルリポジトリからリモートリポジトリを作るときの流れ 1・ローカルの開発中のフォルダをgit管理下におく （念のため…）まずは管理したいフォルダ（私の場合は、WPのthemesフォルダになります）の中で、gitを始めます。 [shell toolbar="true"] $ git init [/shell] git init というのは、リポジトリを初期化する＝新しくリポジトリを作成する、ということになります。 これで、管理したいフォルダ内に「.git」フォルダ（不過視フォルダ）が出来ます。 次に、最初のコミットをしておきます。 [shell toolbar="true"] $ git add . $ git commit [/shell]
git commitを行う際、任意の名前・メールアドレスで行いたい時、ありませんか？ だからといって、以下のように一時的に変更して元に戻すのも面倒ですよね。 そんな時にオススメしたい方法、あるんです。 グローバル設定を変更する ホームディレクトリ/.gitconfigで定義する情報を変更するコマンド $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com ローカルリポジトリ設定を変更する リポジトリ/.git/configで定義する情報を変更するコマンド $ git config user.name "John Doe" $ git config user.email johndoe@example.com ユースケース sudo git commit -
日々の出来事、メンバーの働く様子や声、未来への想いなど、Supershipの“BE SUPER”なストーリーをシェアしています。
分散バージョン管理システムの利用は拡大しています。そのなかでも最も人気のあるツールはGitでしょう。しかし、GitをWindowsで使うのはなかなか困難でした。 Windows向けのGitであるmsysGitは、bashのコンソールを出して、最小限のUnix風コマンドライン環境を提供するものです。これは使いやすくありません。もう一つの選択肢であるTortoise Gitは、Windowsのエクスプローラー（ファイルマネージャ）に統合されたGUIツールですが、僕は「なんか違うな」と感じてました -- これは個人の感性の問題ですが、ファイルマネージャに横付けすることが、分散バージョン管理システムへの良いUIを提供するようには思えないのです。 ところが、最近は事情が大きく変わっています。使いやすいGUIツールとして、2013年6月に正式公開されたSourceTree for Windowsが存在
認証が必要な Git リポジトリに TortoiseGit でアクセスすると毎回ユーザー名とパスワードを聞かれます。これを省略するには以下の方法があるようです。（私は後者の credential helper の方法しか試してません） ■ _netrc %USERPROFILE% ディレクトリー（Windows 7,8 だと ”C:\Users\ユーザー名”）に _netrc ファイルを置いて、中身を machine xxxx.visualstudio.com login ユーザー名 password パスワード machine github.com login ユーザー名 password パスワードのように書いておけばいいようです。 この方法だとパスワードをそのまんまテキストファイルに書いておかなくちゃいけなのでちょっとイヤンな感じです。 ■ credential helper Tor
(追記) この記事は公開から時間が経っており、内容が古くなっています。 本稿では、すでにプライベートなWebサーバを運用している人向けにGitサーバの構築方法を説明します。ひと手間をかけるだけでGitサーバを構成できます。Webサーバがない人はGitHubでプライベートリポジトリを作った方が早くて安くて旨いかもしれません。 要件 以下の要件を考えてみます。 SSHでGitリポジトリにアクセスしたい。 HTTPSでGitリポジトリにアクセスしたい。 Webブラウザでリポジトリを閲覧したい。 Gitリポジトリには機密性の高い情報を格納する可能性がある。 具体的には、 git clone git@git.example.com:/something.git とか、 git clone https://myname@git.example.com/something.git とかしたいです。 Gi
意外と面倒なGitサーバの構築 GithubやBitBucketといったサービスの登場もあり、GitやMercurialなどの分散型バージョン管理システムも一般的に利用されるようになってきた。しかし、自分でGitやMercurialを利用可能なサーバを構築しようとすると、さまざまな依存ソフトウェアのインストールや設定が必要で、意外と面倒だ。そのような場合におすすめしたいのが、今回紹介するGitblitだ。 GitblitはJavaで実装されたGitサーバで、Tomcatなどのサーブレットコンテナ上で動作する。内部的にはEclipse Foundationで開発されている「JGit」というGitのJava実装を使用しているため、warファイルをデプロイするだけで利用でき、プラットフォームも問わない。Javaさえインストールされていれば利用可能で、非常に手軽に導入することができるのだ。 Git
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: 実用Git: ジョン・ロリガ, 吉藤英明, 本間雅洋: 本
