コマンドを使わずに理解するGit - Qiita
この記事はNuco Advent Calendar 2022の7日目の記事です はじめに 株式会社Nucoでエンジニアをしている@noshishiです。 今回は、ついついその場限りのコマンド実行で乗り越えがちなGitを、コマンドを使わず理解するための記事を書こうと思います。 Gitとは バージョンを管理し、作業を分散する Gitは、分散型バージョン管理システムと呼ばれるソースコードの管理システムの1種です。 Gitは、ファイルの変更履歴（バージョン）を記録・追跡することで、過去と現在のファイルを比較し、変更点を明らかにすることで、円滑に開発作業を進めるためのツールです。 また、一度に複数の開発者がファイルを編集できるシステムなので、作業を分散して行うことができます。 Gitを使うということ まず、みんなで共有できる保存場所（以下、リモートリポジトリ）にあるファイルなどを、手元のパソコン（以
世の中の小説作家と編集者は今すぐ Word や G Suite を窓から投げ捨てて Git と GitHub の使い方を覚えるべきだ - Qiita
世の中の小説作家と編集者は今すぐ Word や G Suite を窓から投げ捨てて Git と GitHub の使い方を覚えるべきだGitGitHub小説 タイトルは釣りではありません。 最近、小説の執筆にあたって Git を導入して原稿の進捗履歴を管理しました。めちゃくちゃ便利でした。 GitHub を使って友人と一緒に校正校閲の作業をしました。めちゃくちゃ捗りました。 短編 SF 小説が短期間で完成しました。でも広告が目的ではないのでリンクは貼りません。 Git のことを何も知らない奴が Git と GitHub の使い方を覚えたら便利だったし捗ったので、記事にしてしまおうぜという試みです。 2019年1月4日 追記 本記事は「執筆」および「校正・校閲」の段階における Git と GitHub の有用性を主張する記事です。 「組版」や「デザイン」の段階における Git の有用性について
GitOpsとは - Qiita
GitOpsはWeaveworks社が提唱し始めたCDの手法です。 GitOpsについてGitLabの公式の記事では以下のように紹介されています。 GitOpsは、バージョン管理、コラボレーション、コンプライアンス、CI/CDなど、アプリケーション開発で使われているDevOpsのベストプラクティスを、インフラの自動化に適用した運用フレームワークです。 参照: https://www.gitlab.jp/blog/2020/09/03/is-gitops-the-next-big-thing-in-automation/ もう少し噛み砕くと、「インフラとアプリケーションの両方を含めたシステム全体のコードをGitを使って管理する」、この考え方や手法がGitOpsの本質です。 GitOpsではGitのバージョン管理システムを用いてインフラの設定ファイル(Infrastructure as Cod
リモートワークのいま学びたい、GitLab Handbookと徹底した文書化への狂気 - Qiita
1200人以上の全社員がリモートワーク。GitLabが公開する「リモートワークマニフェスト」は何を教えているか？ スケールする組織を支えるドキュメンテーションの技術を”GitLab Handbook”から学ぶ その コメント GitLab Handbookで面白かったもの@コミュニケーション編 GitLabのリモート統括責任者が語る 日本企業が「まずやるべきこと」 を読んだ。主題はGitLab社の https://about.gitlab.com/handbook/ である。 2022.02追記 GitLabで学んだ最高の働き方 Developers Summit 2022-02-18 2022.01追記 リモートワークのいま学びたい、GitLab Handbook非同期コミュニケーションのススメ - Qiita Handbook要点 「GitLab社ではリモートワークの中でも生産性高く働
GitHubの機能をフルに使って職務経歴書の継続的インテグレーションを実現する
GitHub で職務経歴書を公開 & 継続的に改善していく環境を作ったのでその紹介です。 リポジトリはこちらです。 kawamataryo/resume なぜ職務経歴書を？ 今のチームがとても好きなので転職の予定はないのですが、「安定しているときこそ職務経歴書をまとめておくべき。本当に職務経歴書が必要なときはメンタルが消耗していて書く余裕はない」という話を最近知り合いから聞き、それは確かにと思い書き初めました。どうせ書くなら何か面白いことをしたいなと GitHub に公開 & CI 環境の構築をやってみました。 機能紹介 🌐 GitHub Pages で Web ページとしての公開 Markdown + GitHub のファイルビューでも良いのですが、より見やすいほうが好ましいですよね。 GitHub の無料ホスティグ GitHub Pages を使って Web ページとして公開していま
Bridge Word
This shop will be powered by Are you the store owner? Log in here
devops - Pete HodgsonさんのFeature-togglesが面白かったので翻訳してみた - Qiita
Feature Toggles Pete HodgsonさんというThoughtWorksの方が書かれたFeature Togglesという記事が面白かったので翻訳してみました。 「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional SCRUM GATHERING Tokyo 2016の記事で取り上げていただいた通り、マイクロソフトの内部の開発では多くのフィーチャートグルが使われています。このことをより深く理解したいと思って個人的に翻訳したものを公開します。私的な自分が理解する用の翻訳でありますので、その辺はご考慮いただければと思います。Pull Requestは歓迎いたします！ 概要 フィーチャートグルズ(Feature Toggles)は、とてもパワフルなテクニックだ。チームがコードを変更することな
ssig33.com - Github Flow と組織
github という公的なインフラを使うために必要なこと - アンカテ を盛大に dis っとかなきゃなという気持ちになった。 Pull Request ベースの開発 階層型組織構造 は特に対立するものではないですし、階層型がいいのかフラットがいいのかは場合場合によるでしょう。階層型でばりばりに管理するような開発チームでも ディレクターが issue を起案する 開発リーダーとディレクターがプロダクトマネージャーなどを交えてスケジュールを決定する 開発リーダーがその issue を閉じる Pull Request を作る人とそれをレビューする人を決定しスケジュールを伝達する 所定のタイミングでリリース権限を持っている人がマージボタンを押す みたいなカチカチした運用でいろいろやっていけると思いますし、これでも Github Flow というか Pull Request ベースの開発の恩恵を十
君には1時間でGitについて知ってもらう(with VSCode) - Qiita
おことわり この記事はプログラミング＆業務未経験の新入社員に、Gitについて1時間くらいでバババッと説明した内容をもとに作ったものです。自分がもし誰かにGitについて教えて貰える立場にいたら、最初にこれを教えて貰いたかったという気持ちで作りました。 とりあえず「1人のプロジェクト」で「1時間で」Gitをそこそこ知って使えるようになることを目的としています。実際のチーム開発ができる水準までこの記事だけで達するのは無理ですが、今後Gitを使う必要がある人にとって学習の足がかりになればいいな、という内容です。 それと、新入社員に教えるという都合上、表現がやや正確でなくざっくりしたところがあるかもしれませんが、質の悪い誤解を招くようなものでなければご容赦下さい。 全体像 まずはGitとは何かをざっくり分かって貰った後で、VSCode上での操作を行って貰います。 Windowsでの説明を行いますが、
VSCodeでのGitの基本操作まとめ - Qiita
はじめに 一年前に新人研修でGitを担当してTigの記事を書いたのですが，今年も同じくGitの研修を担当することになりました．新人さんたちにとってはターミナル環境はとっつきにくい人も多いようで，短い研修期間では操作自体に苦戦してしまい，Gitそのものを理解するというところに力を割けない人も少なくありませんでした． それを踏まえて今回はGUIで操作しやすい環境を検討したのですが，以下のポイントを踏まえてVSCodeを使うことに決めました． マルチプラットフォームで使える．（研修はWindows環境で行いますが，業務ではLinuxデスクトップ環境も使うので） Gitの基本的な内容はVSCode上でGUI操作が可能． Gitの内容とあわせて，プログラミング用のテキストエディタの一例として，導入しやすそうなVSCodeを紹介． VSCodeを使ったGitの基本的な操作を一通りまとめていきます． イ
悪いコードを憎んで人を憎まず！ プルリク送付前に心がけたいコードレビューのコミュニケーション術 - エンジニアHub｜Webエンジニアのキャリアを考える！
悪いコードを憎んで人を憎まず！ プルリク送付前に心がけたいコードレビューのコミュニケーション術 コードレビューを円滑に進め、より学びを促進するために重要な「コードレビュー時のコミュニケーション」について、現役エンジニア・池田 惇さんの経験とともに考えてみます。 アプリエンジニアの池田 惇（いけだ・じゅん／@jun_ikd）です。 コードレビューとは、エンジニアにとって毎日発生する作業であり、「コードを書く」という行為と等しく重要なタスクの1つです。同時に、ただ漠然と「粗探し」をするだけがレビューの目的ではありません。特に若手のエンジニアにとっては、先達のエンジニアのコードにじっくりと触れ、学びを得て、さらにチームに自分の持つ知識・技術を還元する、大事な機会でもあるのです。 今回はコードレビューを円滑に進め、より学びを促進するために重要な「コードレビュー時のコミュニケーション」について、私自
ghq, peco, hubで快適Gitライフを手に入れよう！ - Qiita
はじめに peco, hubは前から使っててghqは存在は知りながらも「別にリポジトリ管理は必要ないかなー」と思ってたのですが、管理するリポジトリ数が増えてきて面倒になってきたので試しに入れてみたらかなり良かったので紹介したいと思います ghq, peco, hubとは？ ghqは上でも軽く書いたようにリポジトリ管理ツールになります。 例えばgit cloneの代わりにghq get <repository URL>とコマンドを打つとghqルートディレクトリ（デフォルトでは~/.ghq）以下にリポジトリがcloneされ、 ghq listでghqルートディレクトリ以下のGitリポジトリ一覧を表示、 ghq look <project>で指定したリポジトリに移動する、といったように使います。
tigでgitをもっと便利に！ addやcommitも - Qiita
皆さん、tigコマンドを活用していますか？ tigは、コンソール上で使えるgitブラウザです。実はずっと、ただのきれいなgit logだと思っていたのですが、本当はそんなことはありません。かなり使えるやつなのです。 インストール ソースコード: https://github.com/jonas/tig インストール方法: https://github.com/jonas/tig/blob/master/INSTALL.adoc この辺りを参考にしてみてください。詳細は割愛します。 基本の使い方 この状態の差分を扱っていきます。いつものこれだとこんな感じ。 git logが素敵にビジュアライズされてます。この画面をmain viewといいます。 ここでエンターを押すと、下半分に差分の詳細（diff view）が表示されます。 下矢印で、Unstaged changesの差分を見てみるとこんな
テクニカルライティングの将来 ー GitHub上のAsciidocで技術書Pro Gitを協働執筆 | POSTD
Pro Git第2版の驚くべき冒険と最終的なツールチェーン ほぼ6年前、私はApressから執筆が予定より遅れていたPro Gitと呼ばれる本の手伝いの誘いを受けました。結局原著者が書き続けないことを決めて、私が最初から書き直して2009年8月頃に最終的に出版されました。最初の3章あたりは、私はWordで本を書きました。そして編集者に文書を送って、しばらくして最終的な版を手にしました。 この3章のあとで、私たちが執筆と技術的な編集段階のためにMarkdownに切り替えて、同意された編集のためにだけWordへ戻るように提案したとき、私はやめようとしていました。一旦本が完成したら、私はすべての内容をMarkdownへ再び戻したので、それを私が作成したWebサイトにおいてオンラインで発表できました。幸運にも、原著者は著作をクリエイティブ・コモンズ・ライセンスとすることでApressと同意しました
【図解】git-flow、GitHub Flowを開発現場で使い始めるためにこれだけは覚えておこう
本連載「こっそり始めるGit／GitHub超入門」では、バージョン管理システム「Git」とGitのホスティングサービスの1つ「GitHub」を使うために必要な知識を基礎から解説していきます。具体的な操作を交えながら解説していきますので、本連載を最後まで読み終える頃には、GitやGitHubの基本的な操作が身に付いた状態になっていると思います。 前回記事「たった3つで共存できる、Git／GitHubとSubversion（SVN）の連携、移行に関する基本操作」では、Subversionとの連携や移行について解説しました。 本連載の最終回となる今回のテーマは「Git／GitHubのワークフロー」です。幾つか存在するバージョン管理のワークフローのうち「git-flow」「GitHub Flow」の概要を解説します。 git-flow 「git-flow」はVincent Driessen氏の「A
二カ月間ブランチを利用した開発フローを実践して感じたメリットとデメリット | DevelopersIO
本記事は当初SVNとGitの比較として「ブランチを用いた開発フロー」のメリット・デメリットについて記載していましたが、 「SVNでもブランチを利用できること」「分散型という言葉に対する記載の誤り」についてご指摘をいただきました。 そのため、ブランチを利用した開発フローに対して感じたことを焦点に記事を修正しております。誤った情報を記載していたこと、SVNに対して誤ったイメージをもつ可能性のある記載をしていたことに対し、深くお詫び申し上げます。 Gitをまともに使い始めて約二ヶ月がたちました。 特に、「ブランチをきる」「修正する」「レビューする」「マージする」という、おそらくGitで想定されている開発フローに沿っての開発はクラスメソッドに入社してからが初めてです。 6月に入社する以前は、開発用のソースコード管理には主にSVNを利用し、1つのバージョンの流れに全ての修正をコミットしていくフローで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
仕組みから理解する Git 入門 ~ ひとり開発でも便利 ~
GitBookによるドキュメント作成 - Qiita
「GitとGitHub用語」の可愛いイラストを使用した解説に対して圧倒的わかりやすさを感じる人たち
GitHub Flow (Japanese translation)
