Git の GUI クライアントにはずっと SourceTree を使っていましたが、Windows 版で見過ごせないひどい有様があらわになったのを見て、よさそうなのを他に2つ試してみた記録です。 書くのは SourceTree Fork GitKraken の3つです。Git を GUI クライアントで使用している人のほとんどはこの 3 つのうちのどれかに落ち着いているんじゃないでしょうか。 あとずっと気になってたんだけど、Git ってみんなどう使ってるのか全然知らない。エンジニアならみんな興味ありそうなネタなのにそういう記事とか特集も読んだことないのよなー。普通にターミナルからコマンド打つ人、VS Code 内蔵(かもしくは関連する拡張機能)のやつ、あとは GUI クライアントって感じですかね。この 3 つはどういう比率になるんだろう。 結果的には Fork が最高ということでその後ず
MIXI(旧社名ミクシィ)は5月8日、同社の新入社員向け技術研修で使用した資料を無償公開した。分散型バージョン管理システム「Git」とテスト・設計研修の資料をスライド共有サービス「Speaker Deck」で公開中。動画も後ほど公開するという。 Gitの研修資料は約470ページあり、Gitを使ったチーム開発の進め方やGitの内部構造などを記載している。テスト・設計研修の資料は約40ページ構成で、テスト技法やコードレビューのコツなどを紹介。いずれの資料も同社の社員が作成した。 同社は2021年から新入社員向け研修の資料を一般公開しており、22年はUnityでのゲーム開発やAI、セキュリティ研修など全12種類の資料を自社ブログに掲載していた。同社の公式Twitter(@mixi_engineers)は「今後も随時資料や動画を公開していく」としている。 関連記事 ミクシィ、技術カンファレンスを初
エンジニア未経験のわたしがGitを学ぶ上で、この流れで記事を読むべきだったと思ったことを記載する。 完全に初学者意見のため、疑いながら読んでください。 私は下記の流れで学習することによって、理解をしやすいように感じた。 ① Gitで何をしているかのイメージを掴む(コマンドなし) ② Gitのイメージを、コマンドで実現している記事をみる ③ 実際にGitのコマンドを打ちながら、出力と、頭の中のイメージのすり合わせ Gitで何をしているかのイメージを掴む(コマンドなし) こちらの記事は、Gitのイメージをコマンドなしで、わかりやすく図で示してくださっています。 記事にも記載されていますが、 ・重要なのは 「何」から「何」へ・「どんな作業」を行う のかを追う ・操作前と操作後でどんなことが起こっているのかをイメージする 上記の内容が、すごく同意で、重要だと感じている。いきなりコマンドを打ちながら
プログラマー育成を支援するInitial Commitが、ローカルリポジトリにおけるGitの動作をシミュレート可能なコマンドラインツール「git-sim」を2023年1月22日にリリースしました。git-simを使うことで、Gitコマンドがリポジトリに及ぼす影響を視覚化した画像やアニメーションを生成できます。 git-sim - Visually simulate Git operations in your own repos with a single terminal command. https://initialcommit.com/tools/git-sim GitHub - initialcommit-com/git-sim: Visually simulate Git operations in your own repos with a single terminal c
はじめに 都内でひっそり見習いエンジニアをしている@noshishiです。 addしてcommitするプログラムの作成を通じて、Gitを内部から理解しようという記事です。 前書き 昨年末、Gitの記事を書いて、理解できたなら作れるのではと思いったったのがこの記事の出発点です。 これを機に新しいプログラミング言語にも触れてみて、いろいろ学べたらと思いRustで今回挑戦しました。 (この時は、新たなことを同時に取り組み絶望すること知る由もない著者でした。軽い気持ちで手を伸ばした自分をしばきたいです。。。) 実際に作成した(継続開発中ですが)リポジトリは、こちらです。 ※一応ローカルでの一直線の開発はできそうな程度までは作成できました。コードのしょぼさはご容赦ください。 この記事だけでは説明しきれない部分があることをご容赦ください。 もちろん、間違い等あれば、ぜひコメントいただけると幸いです。
git-simは、Pythonで記述されたコマンドラインツールで、gitコマンドがローカルリポジトリに与える影響を示す画像(またはアニメーション)を、すばやく簡単に生成できる。 同ツールの利用によって、実際にコマンドを実行する前に、ユーザーがコマンドの処理内容を確認することが可能になり、リセット/マージがローカルリポジトリにどのように影響するかが、確実にわかるようになる。なお、動作のビジュアル化はJPEG形式の静止画のほか、MP4形式の動画としても出力できる。 同ツールのおもな目標は、開発者ワークフローの中断を最小限に抑えつつ、gitコマンドの効果をすばやく簡単に作成して視覚化することであり、今後の機能強化としては、 コマンドラインインターフェイスを提供して、開発者がローカルGitリポジトリ内のターミナルで直接git-simを実行可能にする gitコマンド(サブコマンドおよびオプション/フ
はじめに 皆さんVisual Studio Code(以下VSCode)使ってますか? 私はメインで使っているのですが、自分なりにしっくりくる設定や拡張機能がある程度揃ってきたので公開しちゃいます。 おすすめ設定だけではなく、おすすめの機能もできる限り紹介したいと思いますので、最後までぜひお付き合いください。 ※プログラミング言語固有の設定の解説は軽めですのでご了承ください。 GIF画像が小さい場合は、クリックして頂けると拡大して表示が可能です デフォルト機能編 Local History機能 Gitは非常に便利なので、皆さん使われていると思います。 Gitはコミット単位で履歴が管理できますが、保存単位で履歴が見れると嬉しいな、保存単位で復元できると嬉しいな、と思うことはないでしょうか。 私はVSCodeは自動保存をオフにして、手動で保存するので、保存単位で履歴が見れると嬉しいなと思うこと
こんにちは、@yoheiMuneです。 Gitを使って開発をしていると、時々自分だけgitignoreにしたいファイルができます(例えばエディタのメタファイルとか)。そのようなファイルを、自分の環境からバージョン管理から外す方法をブログに書きたいと思います。 特定のプロジェクトにある指定したファイルを、自分だけgitignoreしたい 掲題のような場合には、.git/info/excludeのファイルにバージョン管理外にしたいファイルを指定します。 # .git/info/exclude my-gitignore-target.txt すると、ファイルをGitレポジトリ上に追加しても、バージョン管理対象外になります。 # ファイルを追加する $ touch my-gitignore-target.txt # しかし、バージョン管理対象に入らない $ git status # On bran
The entire Pro Git book, written by Scott Chacon and Ben Straub and published by Apress, is available here. All content is licensed under the Creative Commons Attribution Non Commercial Share Alike 3.0 license. Print versions of the book are available on Amazon.com. The version found here has been updated with corrections and additions from hundreds of contributors. If you see an error or have a s
EngineeringGit clone: a data-driven study on cloning behaviors@derrickstolee recently discussed several different git clone options, but how do those options actually affect your Git performance? Which option is fastest for your client experience? Which option is fastest for your build machines?… @derrickstolee recently discussed several different git clone options, but how do those options actual
(訳注: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
この記事は、Chris BeamsのHow to Write a Git Commit Messageブログの内容を簡単にまとめた資料で、翻訳・編集して、役に立つ内容を追加したものです。 Gitのコミットメッセージをうまく作成すべき理由 なぜコミットメッセージをうまく書く必要があるのか?理由は色々ありますが、うまく書かれたコミットメッセージが有益であるという事実は、多くのプログラマが同意することでしょう。そのうち代表的な3つの例を挙げてみます。 コミットログの読みやすさ より良いコラボレーションとレビュープロセス コード保守の容易さ 「良いコミットメッセージについて考えることは素晴らしいアイデアだと思う。しかし、良いメッセージの正解があるかは分からない。個人によって良いコミットメッセージと捉える基準が異なるためだ。多くの人々が共感できる良いコミットメッセージをうまく作るためのルールはないだ
これをみるとinputやfalseはLF -> CRLFの自動変換を行わないので、これらを選んでしまいそうですが、 大規模開発で多数の開発者がtrueでインストールしてしまった場合、わざわざ変更をしてもらうまでの悪影響があるのか?がわからなかったので、それについて調べた結果を記載しようかと思います。また、これを書くきっかけとなった私のチームではまった落とし穴について書こうと思います。 core.autocrlfをtrueに設定をした場合 core.autocrlfをtrueに設定をした場合について整理します。 チェックアウトやコミットした場合の動きや、開発者がCRLFでファイルを作成した場合の動きは以下のようになります。 上記の図から確かにwroking directory上ではCRLFとLFが混在してしまう可能性がありますが、 repository上のファイルがLFである以上、core.
WindowsとLinuxとでは、ファイルといったリソースを保護する仕組みが異なっている。Windowsではアクセス制御リストという方式が、Linuxでは保護ドメインという方式が使われている。Windowsでは具体的にはアクセス許可、Linuxではパーミッションという言葉が使われているのだが、今回はLinuxでこのパー... こちらのページを見ても分かるように Macでは ReadWrite eXec についてを誰につけるかを決めるに対して、 Windowsでは フルコントロール、変更、読み取りと実行、…を付けていく形式です。 この権限の違いを共通化することは難しいため、Gitを扱う時、以下のような状態になります。 GitはUNIX系のファイルパーミッションで管理されています。 Git上ではMacのパーミッションを正しく保存するため、Git上では755になっています。 しかし、Window
今回はちょっと技術よりのお話を。 ホームページの画面はHTMLやCSSといったテキストファイルというファイルを作成します。これはシステム開発でプログラムを書くときのソースプログラムも同じです。 ですので、アズシエルのスタッフの多くは日夜テキストファイルと格闘することが多いわけです。 テキストファイルは行の区切り、改行のことろで改行コード・行末コードという、文字ではない制御コードというものが使われます。 これが、古くからWindowsではCR+LF2のつ、macOSではCR、LinuxのようなUINX系ではLFと、OSによって違う、などと言われています。 とはいえ、最近はMacもすっかりUNIX系のOSになりまして、macOSの改行コードもLFだって言っていいんじゃない?というところはあります。 そして、Windows 10も次の大型アップデートでは「メモ帳」で、UNIX風のLFだけが改行コ
世の中の主なOS、Unix系、Windows系、Mac系ではそれぞれ改行コードが違っています。 LinuxなどUnix系の改行コードは「LF」で、Windowsは「CRLF」、Macは「CR」(昔のOS9の頃まで。今のOSXはUnix系なので「LF」)となぜかそれぞれ別になってしまっています。 自分はWindowsではSourceTreeでgitを使っているのですが、Linux上のスクリプト言語のソースは改行コードは普通LFにする必要があるため、SourceTreeのデフォルトのgitの設定では、commitする時に「CRLF」→「LF」に自動変換され、checkoutする時には逆に「LF」→「CRLF」に変換されるようになっています。 でもこれだと、なにも触ってないのに修正されているファイルとして上がってきてしまうことがあって、そしてしかたないからcommitしようとすると、変更されてな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く