An interactive Git visualization tool to educate and challenge!
Learn Git Branching
An interactive Git visualization tool to educate and challenge!
Dotfiles Management - mitxela.com
19 Dec 2022 Progress: Complete Not much of a project, but this might be useful for some folks. Here's how I am currently keeping track of all the configuration for my laptop. The system I've settled on is copied from other people – tracking dotfiles as a git repo – but taken to its extreme where the entire root filesystem is trackable. Importantly, Any file on the machine can be added to the dotfi
SSH and Git, meet 1Password 🥰 | 1Password
1Password now includes full support for SSH keys, providing the easiest and most secure way for developers to manage SSH keys and use Git in their daily workflow. The magic of 1Password has always been making the secure thing to do the easy thing to do. Today I’m thrilled to announce that we’re bringing this magic to development teams everywhere with the all-new 1Password SSH Agent. 🦄 In today’s
Git はなぜ空のディレクトリを無視するのか？ - Qiita
LAPRAS アドベントカレンダー2021 の 17 日目の記事です。 概要 Git では空のディレクトリをそのままリポジトリに追加することはできません。 この問題は.gitkeep等を作成することで解決しますが、そのやり方を知ったとき 「なぜ普通のファイルと同じように追加できないのだろう？」 と疑問に思った方も多いのではないでしょうか。 というわけで本記事では、空ディレクトリを追加できない仕様になっている理由について調査してみました。 Gitが管理するのはファイルの内容 「空ディレクトリをaddできないのは何故か？」という疑問への答えとして、 「そもそもどんなディレクトリもaddはできないから」がまず挙げられるでしょう。 もちろんgit add directory/とコマンドを打つこと自体は可能です。 しかしこのとき実際にインデックスに追加されるのは、そのdirectory自身ではなく、
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
gitで2つのリポジトリを混ぜる戦略を考える - golden-luckyの日記
「2つのgitリポジトリがあって、その片方をもう一方に取り込みたい」という状況を考えます。依存ライブラリのソースを自分のプロジェクトで保持したい、といった状況が典型的でしょう。 この場合、通常は git submodule を使うと思います。 git submodule であれば、他のプロジェクトを履歴ごと自分のソースの一部として管理できて、かつ双方の履歴をきれいに分離できます。 Git - Submodules ただ、双方の履歴が分離できるということは、双方の履歴を混ぜられないということでもあります。そのため、 git submodule は、他のプロジェクトのソースに自プロジェクト独自の変更を加えて管理するといった用途には向かないように思います。ではどうすればいいだろうか、という試行錯誤の記録です。 git submodule で取り込む 「Aのcloneにおけるsubmoruleへの
文章に関わる全ての人のための Git & GitHub 入門 1-1「Git と GitHub を使うメリット」 - Qiita
この連載はこんな人に向けて書かれています。 小説作家さん 編集者さん 校正さん ライターさん 発注者さん つまり文章を書いたり修正したりする全ての人たちですね！ シリーズ記事一覧 1-1「Git と GitHub を使うメリット」 1-2「コミットを積み上げる」 1-3「コミットを理解して活用する」 0. この連載を始めたきっかけ 僕は片倉青一という筆名で小説を書いています。 小説だけではご飯を食べられないので、覆面ライターもやっています。せちがらい。 で、覆面ライターの案件で 「クライアントさん… Git と GitHub 使って仕事したいです…」 って言ったら、使っていいということになりました。やったぜ。 でもクライアントさんは Git と GitHub の使い方をあんまり知らないので、片倉が入門書を書くことになりました。なんてこった。 この連載は、片倉がこれからの仕事で楽をするために
CircleCIでgit-pr-releaseする | おそらくはそれさえも平凡な日々
git-pr-releaseそのものの説明に関してはninjinkunの以下のエントリを参照ください。 git-pr-releaseのすすめ さて、現職に入社したら、git-pr-releaseが使われていたのですが、リリース担当者が手元で実行するフローになっていました。しかし、git-pr-releaseの本場であり発祥の地でもある、はてな社では、git-pr-releaseはCIに作らせるものであったので、それに倣って、こちらも現職で利用しているCircleCIに作らせるようにしてみた。 手順 .git-pr-releaseをrepositoryに配置する GIT_PR_RELEASE_TOKEN をCircleCIに登録する .circleci/config.yml にjobを設定する おまけ machine accountを作るといいよ Triage(トリアージ)権限が便利 1.
git-pr-release を実行する GitHub Action をつくってみた - BAKUNOTE
先日、 Shinjuku.LT というイベントで話してきたのですが、資料をつくっていなかったため当日話したこと(+α)をここに残しておこうと思います。 話の流れはざっくりいうと、 GitHub Services を使って master マージ&自動デプロイしていたが、サービスが終了した 仕方なく手動デプロイしていたが、GitHub Actions で再び自動化できた せっかくなので、GitHub Action をつくって公開してみた という感じです。 作成した GitHub Action は Marketplace で公開されています 🎉 よかったら使ってみてください。 https://github.com/marketplace/actions/git-pr-release 以降は、 LT で話した流れに沿って内容を書きます。 GitHub Services の利用と終了 🐙 昨年つ
Gitで日本語長文のdiffをとる方法 - Qiita
（この記事はここからの転載です） 課題 日本語の長文をgitで管理していると、ほんのちょっとの変更でもdiffでは行丸ごと変更されたことになり、変更点がよくわからないことがある。 二泊三日で小説を書く過激なイベントNovelJam 2018参加作品である高橋文樹氏の「オートマティック クリミナル」は、GitHubを使って執筆されている。小説では、git diffの欠点がはっきりでる。高橋氏は参加レポートで、こう書いている。 あと、今回得た重要な知見なのですが、Githubではある程度以上テキストが長くなってくると、数文字の調整で全部差分として判定されたりするので、小説には向いてないかなーと思いました。小説は行の移動とかがよく発生するので、GithubじゃなくてGitとの相性かもしれません。 普通にdiffを取る 確かに、普通にdiffをとるとその通り。コマンドラインで「オートマティック ク
Macのコンテキストメニューから操作可能なFinder統合型Gitクライアント「GitFinder」が正式にリリース。
Macのコンテキストメニューから操作可能なFinder統合型Gitクライアント「GitFinder」が正式にリリースされたそうです。詳細は以下から。 GitFinderはオランダのZigZagが2017年から開発していたGitクライアントで、WindowsのTortoiseGitの様にファイラー(Finder)に統合され、コンテキストメニューからリポジトリの作成やクローン, コミットなどの操作が出来ますが、この「GitFinder」が2018年02月13日に正式リリースされたそうです。 Thank you so much for showing interest in GitFinder. I would like to inform you that GitFinder has been launched today (February 13), and it is available
最強のGitフロントエンドはForkかもしれない - たけぞう瀕死ブログ
昨日Macで使えるGitフロントエンドの紹介を書いたところ、友人のPishenさんからForkというツールもあることを教えていただきました。 How about https://t.co/fDZq7jzQoo ?— Pishen Tsai (@pishen) 2017年8月30日 Webサイトはこちら。現時点ではMac版（動作にはMacOS X 10.11以降が必要）のみですが、Windows版も提供予定のようです。 git-fork.com リリースノートを見ると昨年から開発されていたようですが、完全にノーマークだったので早速試してみました。 1ウィンドウで複数リポジトリをタブ切り替えで操作できる ブランチの状況も把握しやすい履歴ビュー（見た目的にはSourceTreeに近い） コミット時点のファイルツリーを確認できる 動作は軽快（ただし安定度についてはまだ不明） ターミナルから起動する
GitUp - Mac OSX用の軽量なGitクライアント
Gitは誕生して10年になろうとしているそうです。そして現在、GitHubを筆頭として多くのエンジニアがGitを使っています。しかしGitの使い方について、日々多くのエンジニアが悩んでいるのではないでしょうか。 そこで作られたのがGitUpです。分かりやすくGitを使えるようにしたいと考えているクライアントソフトウェアです。 GitUpの使い方 GitUpを立ち上げるとまず、リポジトリを選択するウィンドウが表示されます。 リポジトリを開くとグラフが表示されます。 ブランチなども見やすいです。 コミットメッセージも見られます。 修正した場所も分かります。ここからコミットもできます。 GitUpでは操作の殆どがundo/redo可能であり、タイムマシーンさながらに指定したリポジトリの状態に戻すのも簡単にできます。UIはとてもシンプルですが、GitUpを使うことで普段のGit運用がとても楽になる
Gitプッシュでブランチごとにステージング環境生成or本番反映させる - Qiita
概要 「masterをプッシュで本番反映」をやっている記事はいくつかあったものの、ブランチごとに自動でステージング（テスト環境）が作られるような仕組みは見当たらなかったので書いてみる。 マージ未定の実験的なブランチをWeb上で確認したり、ローカル環境のないディレクターやデザイナーに作業ブランチの内容を確認してもらう際に役に立つはず。 Gitフック経由のサイト更新はFTPもサーバーへのログインも必要なく、ただpushするだけなので非常に便利だと思う。 ※以下、ある程度のサーバーサイドの知識を要する説明になっているので注意 最終的に実装する機能 masterをリモートリポジトリにpushすると、masterの内容が本番サイトであるhttp://プロジェクト名.com/に取り込まれる。 hogeというブランチを切ってプッシュすると、http://hoge.プロジェクト名.com/というhogeブ
よりよいGitの設定 | Yakst
.gitconfigファイルに記入するオプションをカスタマイズすれば、Gitをより上手に、便利に使うことができる。著者のGit設定の紹介と、便利な設定の解説。 私はGitが大好きで、いつでもGitを使っています。私は時々、何かについて深く調べてみたり、ドキュメントを一通り読んでみたり、設定を見直してみたりするのですが、今回はGitについてそれをやってみました。私の書いた4番目の技術スタックの改善に関する記事にようこそ！ Gitのすべて 私がコーディングを始めたのは、ただのファイルシステム上でコピーしていたあの辛い日々、そしてチェックアウトに排他的ロックが必要だったVisual SourceSafeを使っていた時でした。それでもその時、ソース管理のコンセプトは私にとって素晴らしいものに思えましたし、家でコーディングする時にはそういったものにアクセスできたらな、と思っていました。 その後カリフ
最近のgitを使った開発フローについて - その手の平は尻もつかめるさ
最近のgitを使ったWebアプリケーションのプロジェクトの開発フロー (主にブランチ運用) について記すものです． なお前提としてGitHub Enterpriseを利用しています． git-flow 大上段に構えたもののあまり特殊なことはしていなくて，基本的にgit-flowをそのまま踏襲しています． git-flowについてはしっかりした解説記事がインターネット上に数多く存在しますからそれらを参考にしていただければと思いますが，ざっくり説明すると masterブランチ，developブランチ，releaseブランチ，featureブランチ及びhotfixブランチがある masterブランチは常にリリース可能な状態になっている (すなわち現在本番で稼働しているアプリケーションのコードと等しい) developブランチは開発中の状態で，ステージング環境等に上がっている releaseブラン
３年間でおこなった僕のチームの開発ルール制定と考え方inぐるなび - ぐるなびをちょっと良くするエンジニアブログ
こんにちは！ 季節が秋に突入し、次第にスノボ欲が高まってきた吉次です。 前回は勤怠連絡の出欠確認を自動化するという題材で記事を書かせていただきました。今回はもう少し開発の話題に寄せ、チームの開発ルールができるまでの話をしたいと思います。 はじめに みなさんは、「開発ルール」と聞いて何を思い浮かべますか？ 一口に開発ルールといっても、コーディング規約、Gitのブランチングルール、命名規則、開発におけるマインド、社内のローカルルールなどなど、枚挙にいとまがありません。今回の記事ではソース管理、タスク管理、リリースの3つに着目し、どのようにして開発ルールの効率化を図ったかを振り返ります。 ぐるなびにおけるソース管理の遍歴 Gitによるソース管理 ぐるなびにおけるGitの歴史はさほど長くありません。下記はぐるなびソースコード管理の略歴です。 時期 ツール 問題点など ～2012年7月 SVN or
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SIOS Tech. Lab - エンジニアのためになる技術トピックス
Loading...
Gitgraphのエディタ作った - Qiita
