10分で自分のGitHubプロフィールをカッコ良くする - Qiita自分の username/README.md を作る 何はともあれ、自分の README.md を作りましょう。 自分と同じ名前のリポジトリを作成しようとすると、かわいい注意書きが出ます。 「Public にして README を作成すると、 GitHub プロフィールを作れるよ〜」と書いてあります。 画像のように Public と Add a README file にチェックを入れて作成します。 GitHub Profile Summary Cards を使う 続きはこちらに移動しました。
GitでUnityプロジェクトを管理する - KAYAC engineers' blog
はじめに カヤックのソーシャルゲーム事業部で働いているUnityエンジニアのmadaです。 カヤックでは、Unityのプロジェクトのバージョン管理にGit、ホスティングサービスにGithubを利用しています。 今日はGitでUnityプロジェクトを管理する方法について紹介します。 この記事はカヤックUnityアドベントカレンダー2016の22日目の記事です。 UnityプロジェクトのGit管理について プロジェクトをGitで管理する際、AssetsとProjectSettingsディレクトリを含める必要があります。LibraryとTempディレクトリは含めなくても動作に影響はありません。 Gitの管理対象から外したいディレクトリやファイルは.gitignoreに記述します。 .gitignoreの例を紹介します。 Library Temp *.bat *.csproj *.csproj.u
Gitを使って差分ファイルと差分情報を簡単に納品するコマンドのメモ - Qiita
納品を行った後、修正依頼が来て修正対応後 納品する際に「差分ファイルと差分情報が欲しい」と言われることも多々あると思います。 この場合に手動でチマチマやっていると時間がかかりますが、Gitだと簡単に情報がまとめられるとのことなのでそれらの情報をメモしてみます。 やりたいことの流れ 初回納品 納品バージョンのタグを付ける 全てのファイルをZIPにする 修正依頼が来てファイルを修正する 修正バージョンのタグを付ける 差分ファイルをZIPにする 差分情報をメモする 初回納品/全てのファイルをZIPにする まずは納品したいブランチでタグを付ける。納品用ブランチを作っておくとよいと思う。 例としてtag名はv1.0 注釈付きタグ名付与
GitHub Pages
Websites for you and your projects. Hosted directly from your GitHub repository. Just edit, push, and your changes are live. Pages Help Ready to get started? Build your own site from scratch or generate one for your project. You get one site per GitHub account and organization, and unlimited project sites. Let‘s get started. User or organization site Project site Create a repository Head over to G
git を https 経由で使うときのパスワードを保存する - Qiita
git を https 経由で使う場合、pull や push のたびに毎回パスワードを聞かれてしまいます。 これを改善するには git-credential を使うと良いです。 git-credential は git 1.7.9 以降で使用可能です。 なお、古いやり方としては .netrc を使う方法もありますが、パスワードを平文でファイルに保存するので、やらないほうがいいと思います。 使用可能な管理方式 git-credential では、以下のような方法でユーザ名とパスワードを管理できます。 git-credential-store : ファイルに保存します。ただし、パスワードが平文が保存されます。 git-credential-cache : 常駐プロセスに記憶させます。 git-credential-osxkeychain : Mac OS X のパスワード管理を使います。 G
Fork - a fast and friendly git client for Mac and Windows
Fork is getting better and better day after day and we are happy to share our results with you.
Upgrade Git to 2.5.2 in CentOS 6.4 through yum (Example)
I found it is impossible to find lastest Git in yum repo. Fortunately, the Git source base has provided make rule to build RPM package. Note you have to build the rpm from the source code repo. Building rpm from source tarball is not supported. yum install curl-devel expat-devel xmlto asciidoc git clone https://github.com/git/git.git cd git make rpm Find the rpms in ~/rpmbuild/RPMS/x86_64 Install
Git Cheat Sheet and Best Practices | JRebel by Perforce
In this post, we’re looking at one of the most successful source code management tools available today, Git. With every great tool, there is a CLI which compliments all the great features and options, which leads to a vast number of things you need to remember and be expected to recall within a keystrokes notice. Enter: the Git cheat sheet. Looking for a different Java cheat sheet? Be sure to chec
git commit時に英語でメッセージ書くためのヒントを表示する - Qiita
はじめに 英語力をあげるために、コミットメッセージを英語で書こうとしても実践するのはなかなか難しいものです。 GitHubで使われている実用英語コメント集 - Qiita のような記事を読んでもコミットするときには忘れています。 そこで、git commit時に表示されるコメントに、英語でメッセージを書くためのヒントを表示してみました。 完成イメージ やり方 ~/.gitmessage.txt を作成 # fix, add, changeといった事実ではなく、このcommitで実現する要件や仕様を書きましょう。（リファクタなどは除く） # # 例文） # - Fix typo in docs # - Remove unused code # - Remove use of deprecated method # - Update Modernizr to v1.6 # - Make it
It's Magit! A Git Porcelain inside Emacs
Magit is a complete text-based user interface to Git. It fills the glaring gap between the Git command-line interface and various GUIs, letting you perform trivial as well as elaborate version control tasks with just a couple of mnemonic key presses. Magit looks like a prettified version of what you get after running a few Git commands but in Magit every bit of visible information is also actionab
Gitter — Where developers come to talk.
Gitter is a chat and networking platform that helps to manage, grow and connect communities through messaging, content and discovery. Built on Matrix Matrix.org is an open network for secure, decentralized communication. There is a variety of clients are available. Learn more Simple to start Sign-in with GitHub/GitLab/Twitter and start chatting, with End-to-End Encrypted messaging. Markdown and La
git-svnを使った開発の手順
未だにSubversionの案件があって泣きそうです。 もうコマンド覚えていないのでgit-svnで対応しますが、流れを決めておかないと大変なので自分の作業をまとめときます チェックアウト ~~~ git svn clone -s –prefix svn/ [svnリポジトリのURL] [作成したいGitリポジトリのPATH] ~~~ ただしsvnをちゃんと使ってない案件、trunkがない場合など・・の場合はこのコマンドでは対応できない。。。。 ~~~ git svn clone –trunk= –branches=branches –prefix=svn/ [svnリポジトリのURL] ~~~ するとcheckoutができる ~~~ $ git branch * master $ git branch -r svn/trunk svn/foo-x svn/foo-y svn/bar-ne
SubversionのリポジトリをGitで扱う - Rewish
svnコマンドはログが見づらいし、コミットしたらリモートにソッコーで飛んで行くし、Gitに慣れた僕には凄く扱いづらい。てことでgit-svnネタです。 一年くらい前からずっと下書き状態だったのを思い出したので公開。他にもコレ系の記事は沢山あるけど自分用のメモとして。ね。 svnリポジトリからチェックアウト いつものcloneコマンドにsvnを付けるだけ。 git svn clone -s http://svn.example.com/Project_Name/ -sオプションを付けると、svnリポジトリが trunk 、 branches 、 tags のような、お馴染みの構造だよって言うのをgitに教えられる。教えておくと、ブランチやタグがgitのリモートブランチとして扱えるようになるので便利。 また、 trunk 、 branches 、 tags の名称が一般的なモノとは異なる場合は
Git超絶まとめ - Qiita
ファイル保存領域 ワーク（ワーキング）ツリー インデックス（ステージング） リポジトリ ワーク（ワーキング）ツリー ユーザーが作業しているディレクトリ領域 インデックス（ステージング） ワークツリーとリポジトリの中間領域（一時領域） コミット対象のファイルを登録する領域 リポジトリ ファイルやディレクトリの状態を管理する領域 ブランチ 履歴の流れを分岐して保存していくための機能 - masterブランチ - 追跡ブランチ - HEAD masterブランチ gitリポジトリに最初にコミットすると作成されるブランチ 追跡ブランチ リモートブランチの状態を監視するためのブランチでローカルブランチの一種 git branch -a * master //作業ブランチ remotes/origin/HEAD -> origin/master //HEADの位置 remotes/origin/mas
GitHubでの開発の流れ
github_development.md GitHubでの開発の流れ 1. issue をたてる 不具合修正などは issue に詳しい内容を書く 2. ローカルで master からブランチを作る git checkout -b ブランチ名 3. コミットをする git commit -am 'コミットメッセージ' 4. push する git push origin ブランチ名 5. pull request を作る pull request のタイトル、説明欄に含める内容 issue の番号を先頭に#を付けて記述 (例: #123) fix #123 のように fix を付けるとマージされたときに対象の issue が自動的に close されます。 見てほしい人のアカウントIDを先頭に@を付けて記述 (例: @github) この pull request によって何が変わるのか
Ruby on RailsによるWebアプリ開発記(03) - メモ置き場
Ruby on RailsによるWebアプリ開発記(03) 前回 Ruby on RailsによるWebアプリ開発記(01) - メモ置き場 Ruby on RailsによるWebアプリ開発記(02) - メモ置き場 ルールは決まったけど、やっぱりちょっとやりにくい これまで、「作業が完了したらPull Requestを作成してコードレビュー」という方針で実施してきたが、下記の問題が多々発生した。 Pull Requestが作成されるまでは、各自の作業状況が把握しにくい commitログを見ればどんな変更を行っているかは一応把握できるが、全作業の何%が終わっているのかがわからない。 意識相違やミスがキャッチできない Pull Requestでのソースレビュー時に「ここはこういう書き方にすべき」などの指摘が入った場合、大きな手戻りが発生してしまう。 (その機能実装についての)悩みや疑問がうま
git commit --allow-empty を使った WIP PR ワークフロー - Qiita
先日とある方と開発ワークフローについてお話していて初めて知ったのですがgit-commitには--allow-emptyという空の（親コミットと差分がない）コミットを作成できるらしいですね。 僕が今関わっているプロジェクトでは WIP PR を用いたワークフローを取り入れているのですが、このgit commit --allow-emptyを用いるともう一段階快適なワークフローになるかと思ったのでメモがてら書き留めておきます。 WIP PR って何？ Work In Progress Pull Request の略です。 Github に Pull Request （以下、PR と表記）という機能があるのは皆さんご存知だと思います（知らない方はググってください）し、業務で取り入れている方も多いと思いますが、それを作業途中の状態で出すことを WIP PR と呼びます。 作業途中のトピックブラン
WIP新しい開発手法 - Qiita
WIPで新しい開発手法 WIP(Work-in-progress)：仕掛り作業という意味 WIPという文字が付いていると、その作業はまだ終了しておらず、作業中であるとわかる。 一つの作業においても作業が様々あるので、それを細分化して書いておく。 例）進行中のチケットの状態 【WIP】#12345 ○○機能の新規追加 [✔] ○○.php にformを作成する [✔] ○○テーブルを作成する [ ] formをカスタマイズする [ ] formの挙動を確認する [ ] CSSの適応 [ ] テスト レビューワー（コードチェック）はWIPの状態を見ることで、その作業がどこまで進行しているかがわかり、タイトルの【WIP】が外れていたらその作業は完了（レビュー待ち）というように一目でわかるようになる。 プロジェクト管理において、今あるチケットがどういう状態なのか「見える化」することができるようにな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitFinder - git client with Finder integration
Gitでやらかした時に使える19個の奥義 - Qiita
