Github上にローカル環境からTerminalなどのコマンドラインを使ってPush,PullRequestを作成する流れをまとめてみました。 大まかな流れ ①Github上からローカルにファイルをclone(保存)する ②GithubへPullRequest用のBranchをローカルで作成する ③データを更新編集し、ローカルに add, commitする ④Githubにpushする ⑤GithubにPullRequestする ※⑥PullRequestをMergeする 用語の整理 ①Github…オンライン上にレポジトリーを保管し、複数人で共有・編集できる ②ローカル…自分のPC ③clone...Githubなどオンライン上のリポジトリーをローカルにコピー保存すること ④Branch...１つのレポジトリに複数のBranchを作ることで同時に複数のバージョンでレポジトリを管理すること

.gitconfigファイルに記入するオプションをカスタマイズすれば、Gitをより上手に、便利に使うことができる。著者のGit設定の紹介と、便利な設定の解説。 私はGitが大好きで、いつでもGitを使っています。私は時々、何かについて深く調べてみたり、ドキュメントを一通り読んでみたり、設定を見直してみたりするのですが、今回はGitについてそれをやってみました。私の書いた4番目の技術スタックの改善に関する記事にようこそ！ Gitのすべて 私がコーディングを始めたのは、ただのファイルシステム上でコピーしていたあの辛い日々、そしてチェックアウトに排他的ロックが必要だったVisual SourceSafeを使っていた時でした。それでもその時、ソース管理のコンセプトは私にとって素晴らしいものに思えましたし、家でコーディングする時にはそういったものにアクセスできたらな、と思っていました。 その後カリフ

An open source Git extension for versioning large files Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server like GitHub.com or GitHub Enterprise. Getting Started Download and install the Git command line extension. Once downloaded and installed, set up Git LFS for y

最近のgitを使ったWebアプリケーションのプロジェクトの開発フロー (主にブランチ運用) について記すものです． なお前提としてGitHub Enterpriseを利用しています． git-flow 大上段に構えたもののあまり特殊なことはしていなくて，基本的にgit-flowをそのまま踏襲しています． git-flowについてはしっかりした解説記事がインターネット上に数多く存在しますからそれらを参考にしていただければと思いますが，ざっくり説明すると masterブランチ，developブランチ，releaseブランチ，featureブランチ及びhotfixブランチがある masterブランチは常にリリース可能な状態になっている (すなわち現在本番で稼働しているアプリケーションのコードと等しい) developブランチは開発中の状態で，ステージング環境等に上がっている releaseブラン

ありがちなgitの失敗とその修正コマンドをまとめました。(´﹃｀) masterブランチで作業を始めてしまった！　Σ(llﾟ艸ﾟll) git stash をすると、stashリストに書きかけのソースが退避して登録される。 なので、git statusとしても"nothing got commit"となり、変更が隠される。 ちなみにstashはこっそりしまう、という意味。 git stash list　とすると、退避されているソースのリストが表示される。 コードを持っていきたいブランチに切り替えて、 git stash apply とすると、最後にstashされたものがそのブランチで反映される。 直前のソースではなく、特定のstashしたソースを指定したい場合は、 git stash apply stash@{[git stash listで確認した番号]}とすると、適用できる。 べつにm

AWS のクレデンシャルを GitHub に載せてしまう事故 相変わらず続いてますが、以下秘密情報の公開を防ぐ方法。 （ AWS の Glacier とか GCP の BigQuery とか 課金の仕組み系も気をつけないとですね・・） AWS が公開しているツール。パスワードなどの秘密情報を 誤って git リポジトリに commit する ことを防いでくれます。 https://github.com/awslabs/git-secrets 設定手順 1. インストール ツールを置いておくためのフォルダを作り、 あとはそこにソースを落としてきて make install するだけ。

新しくgitのアカウントを作り、ローカルでゴニョゴニョして、addしてcommitしてpushしたら↓のようなエラーが・・ $ git push origin master error: The requested URL returned error: 403 Forbidden while accessing https://github.com/hogehoge/rss.git/info/refs fatal: HTTP request failed ここまでどうやったか 一応手順が間違ってなかったことを確認するために、 ここまでどうやって来たかをまとめて起きます。 A. githubでリポジトリ作成 最初にgithubでリポジトリを作りました。 B. ユーザ名登録

変更のdiffを見ながらコミットメッセージを書く 教えてもらってから活用してる。見ながら書いたほうが具体的に書けるような気がする。 ```diff:余談...diffのシンタックスハイライト初めて使ったけど良い感じですね $ git commit -v 変更のdiffを見ながらコミットメッセージを編集できます Please enter the commit message for your changes. Lines starting with '#' will be ignored, and an empty message aborts the commit. On branch commit-v You are currently bisecting, started from branch 'test-git-bisect'. Changes to be committed: #

私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ

社内やオープンソースのプロジェクトに並行して参加していると、gitconfig の user.name や user.email をリポジトリごとに切り替えたくなることがある。リポジトリを作るたびに git config user.name "My Name" すればいいのだが、 user.name が存在しないか空文字列だと環境変数 NAME の値を暗黙的に使う仕様になっているため、設定をうっかり忘れてしまうとなかなか気づけない。名前やメールアドレスを間違えたまま何度もコミットしてしまうと修正が厄介である。 Git 2.8以上 最近の Git で設定忘れを未然に防ぐには git config --global user.useConfigOnly true を実行する。これを設定するとユーザー情報について環境変数を暗黙に参照することがなくなる。グローバルな gitconfig で use

背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること

社内のライトニングトーク用に Qiita:Team に書こうとしていたものですが、誰かの参考になればと思い、こちらにアップします。対象は 「エンタープライズ系ではない」「スクリプト言語系の」WEB系エンジニア/プログラマ です。 流行り廃り、好みがあると思いますが、これらは実際に、私が試してよかったものです。サービスであったりライブラリであったり粒度がバラバラではありますが、参考まで^^; 「最近の」というタイトルですが、私的に最近、活用しているという意味で、サービス自体は昔からあるものもあります。 ① Heroku Heroku を利用すると、Ruby(on Rails)、PHP、Node.js、Python 等のサーバ側アプリケーションをホスティングすることが出来ます。デプロイ方法は Git で push するだけ です。 商用でちゃんと使おうとすると、無料枠の構成では難しいですが、デ

GitやGitHubの使い方を学習することができるデスクトップアプリ「Git-it」。Electronで作られていて、Mac / Windows / Linux用の実行ファイルをGitHubよりダウンロードすることができます。英語表記のみだけでなく、日本語に対応しているところもありがたいところです。 使用方法 Git-it自体は問題集のようなもので特別な仕掛けはありません。画面の指示に従いローカルの環境でGitを使いながら学習を進めていきます。Git-itではGitHub Desktopの使用を推奨していますが、実際の運用を考えてターミナルでGitを勉強してみるのも良いでしょう(Windowsの場合若干めんどくさいですが)。 Git-itでは、Gitのインストールから始まり、リポジトリの作成やコミット、GitHubの使い方、最終的にはプルリクエストの送信方法まで学ぶことができます。 プルリ

GitHub Pagesは、GitHubでHTMLなどを配置してWebサイトを公開することができる機能です。PHPなどのスクリプトは動作しませんが、Jekyllなどと組み合わせることで、Blogサイトを公開することもできます。 アカウントを作る もし、まだGitHubにアカウントを作っていない場合は、以下のサイトでアカウントを作ります。フリープランでも利用できます。 GitHub リポジトリを作る 新しいリポジトリを作ります。この時、名前は必ず次のようにします。 [アカウント名].github.com ファイルをプッシュする GitHubのクライアントソフトなどを使ってクローンを作り、ファイルを作成してプッシュします。 ※ 画面は、Tower URLにアクセスする 後は、次のURLにアクセスすれば閲覧することができます。 http://[アカウント名].github.com 独自ドメインを

GitHubとは GitHubとは、ソフトウェア開発プロジェクトのためのソースコード管理サービスです。 ソースコードを更新したバージョンの管理や閲覧、バグ追跡機能、SNSの機能を備えており、開発者にとってなくてはならないサービスです。 また、GitHubを使ってソースコードの管理を行っている企業も多数あります。 GitHubが人気な理由と類似サービスとの違い GitHub は、Git を使用したソフトウェア開発とバージョン管理のための人気のあるプラットフォームおよびクラウドベースのサービスです。コードを効率的に保存、管理、共同作業するために必要なツールを開発者に提供します。ユーザーフレンドリーなインターフェースと豊富な機能を備えた GitHub は、世界中の開発者にとって不可欠なツールとなっています。 GitHub はテクノロジー業界では有名な名前かもしれませんが、ライブカジノへのユニーク

動機 他人の出しているPull Requestについて、自分のブランチとして実験・修正したい、ということがありました。具体的には下記のような状況です。 本体GitHubリポジトリ Aさんがforkしたリポジトリ Pull Requestが出ているブランチ（←これを自分のリポジトリに取り込みたい！） 自分がforkしたリポジトリ 自分が本体からforkしていない状態であれば、単にAさんのリポジトリをforkするだけで問題のブランチも手に入りますが、残念ながら自分は既にfork済みで、かつ何度かPull Requestを送っているので自分のリポジトリを消すわけにもいきません。 また、問題のブランチがTravis CIでのテストに通るかどうかに興味があったので、手元にPull Requestのコピーを作るだけでなく、自分のブランチとしてGitHubにpushして、自分のTravis CIアカウン

GitHub 上のプロジェクトへプルリクエストをしてみます。 複数人数でのチーム開発に加わった場合も、初回の手順はこんなフローになりそうなイメージ。 お手本を参考に進めます。 GitHubへpull requestする際のベストプラクティス – hnwの日記Github で Fork してから Pull Request をするまでの流れ | けーこ in サンフランシスコ プロジェクトファイルを取得するGitHub にあるプロジェクトのファイルをローカルに落とします。 Fork するGitHub のプロジェクトをブラウザで開き、Fork します。 今回は、cask を追加することにします。 caskroom/homebrew-versionsgit clone するFork したプロジェクトをローカルに git clone します。 % git clone git@github.com:D

git-flowとは、プラグイン(ツール)のことです。。 Vincent Driessen氏がブログに書いた"A successful Git branching model" というブランチモデルの導入を簡単にする git プラグインである。 参考資料： ・　http://hm-solution.jp/lifehack/post2475.html ・　http://d.hatena.ne.jp/Yamashiro0217/20120903/1346640190 #Git-flowイメージと各ブランチの役割 ####master: プロダクトとしてリリースするためのブランチ。リリースしたらタグ付けする。 ####develop: 開発ブランチ。コードが安定し、リリース準備ができたら master へマージする。リリース前はこのブランチが最新バージョンとなる。 ####feature bra

8. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) 例: 受け取ったパッチを取り込んだ人 ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー（説明は省略） 1つ前のコミットのリビジョン 例: 4717e3cf182610e9e82940ac45abb0d422a76d77 9. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Co

FINDJOB! 終了のお知らせ 2023年9月29日にFINDJOB!を終了いたしました。 これまでFINDJOB!をご利用いただいた企業様、求職者様、様々なご関係者様。 大変長らくFINDJOB!をご愛顧いただき、誠にありがとうございました。 IT/Web系の仕事や求人がまだ広く普及していない頃にFind Job!をリリースしてから 約26年間、多くの方々に支えていただき、運営を続けてまいりました。 転職成功のお声、採用成功のお声など、嬉しい言葉もたくさんいただきました。 またFINDJOB!経由で入社された方が人事担当になり、 FINDJOB!を通じて、新たな人材に出会うことができたなど、 たくさんのご縁をつくることができたのではないかと思っております。 2023年9月29日をもって、FINDJOB!はその歴史の幕を下ろすこととなりましたが、 今後も、IT/Web業界やクリエイティブ