サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
文章でリストを表示（少し詳細あり） fix: バグ修正 既存の機能の問題を修正する場合に使用します。 hotfix: 緊急対応 稼働中のシステムのバグ修正など、緊急性が高い修正を行う場合に使用します。 add: ファイルや機能の追加 新しいファイルや機能を追加する場合に使用します。 feat: 新機能・新規ファイル追加 新しい機能やファイルを追加する場合に使用します。 update: 機能修正 既存の機能に問題がなく、ただし修正を加えたい場合に使用します。 change: 仕様変更による機能修正 仕様変更により、既存の機能に修正を加えた場合に使用します。 clean・refactor: リファクタリング コードを修正し、改善する場合に使用します。 improve: コードの改善 コードの改善をする場合に使用します。 disable: 機能の無効化 機能を一時的に無効にする場合に使用します。
cloc countsblanklines, commentlines, and physicallines of source code in manyprogramming languages. - AlDanial/cloc 基本的な使い方 基本的な使い方は引数でファイルもしくはディレクトリを指定するだけです。下記では例として ccache というソフトのコードのステップ数を調べています。各言語ごとにステップ数が集計されて表示されます。 $ git clone https://github.com/ccache/ccache.git $ cd ccache $ cloc . 366text files. 365 unique files. 21 files ignored.github.com/AlDanial/cloc v 1.82 T=0.47 s (736.4 f
Conventional Commits 人間と機械が読みやすく、意味のあるコミットメッセージにするための仕様 Conventional Commits 1.0.0 概要 Conventional Commits の仕様はコミットメッセージのための軽量の規約です。 明示的なコミット履歴を作成するための簡単なルールを提供します。この規則に従うことで自動化ツールの導入を簡単にします。 コミットメッセージで機能追加・修正・破壊的変更などを説明することで、この規約は SemVer と協調動作します。 コミットメッセージは次のような形にする必要があります: 原文： <type>[optional scope]: <description> [optional body] [optional footer(s)] 訳： <型>[任意 スコープ]: <タイトル> [任意本文] [任意 フッター] あな
バグがどこで混入したのか調べたい時など、一時的に過去のコミットに戻って作業したい場合があります。 その場合は次の gitswitch コマンドを使います。 一時的に過去のコミットに戻る: gitswitch -d <コミット> ※ -d オプションは移動後の HEAD を「detached HEAD」という使い捨ての HEAD にするという意味 ところが、このコマンドはワーキングツリーとインデックスと HEAD の内容が一致していないとエラーが出て実行出来ない事があります。 そういう場合は次の様に stash 機能を使ってワーキングツリーとインデックスの内容を一時的に保存してから gitswitch を実行します。
git pull して、リモートブランチの最新に合わせようとしたら・・、あれ？コンフリクト・・？なにこれ、うまくいかない！「git push -f origin masterして強制Pushはできたのに。git pull -f origin master的な強制コマンドはないの？！」 とにかくリモートに合わせたい。そんなあなたのための、解決方法と解説です。 「git pull --force」は存在しない・・。 「git push --force」というコマンドがあるので、そこから連想してしまいますが、「git pull --force」というオプションは存在しません。 git pull の強制的に実行するには、別のコマンドが必要になりますので、見ていきましょう。 git pull で、ローカルを強制上書きする方法 ローカルのmasterを、強制的にリモートのmasterに合わせる //
コードレビューでよく見るけど、これってどういう意味だっけ..IMO..芋..？ そんな略語たちをまとめました。 他にもこんなのあるよ！と言うのがあれば教えてください〜 「LooksGood To Me」 = 良いと思います WIP 「Work In Progress」 = 対応中 FYI 「For Your Information」 = 参考までに must 「must」 = 必須 want 「want」 = できれば imo 「in my opinion」 = 私の意見では imho 「in my humble opinion」 = 私のつたない意見では（控えめな意見・謙虚な意見） imnsho 「in my no so humble opinion」 = ハッキリ言わせていただくと imao 「in my arrogant opinion」 = 私の大胆な意見（ぶっちゃけ） nits
git rebase とgit mergeの違い 両方とも、異なるブランチの変更を統合するためのコマンドですが、統合の方針に違いがあります。 今回、masterブランチの過去のコミットから派生した機能開発用のブランチ「topic-branch」の変更を、「master」に取り込む、という状況で、２つの方法を比較してみます。 「git merge」を用いて統合する さて、ブランチtopic-branchで機能を開発する間に、他のチームメンバーによってmasterがいつくか先にすすんでしまいました。このままmaterにtopicをマージすると、コンフリクト（競合、衝突）が発生してしまう事がわかっています。 masterブランチ上でコンフリクトを解決するのは好ましくありません。解決の結果がうまくいったかどうか、テストする必要があるからです。テストされていない機能をmasterに入れてしまっては、
git-flow is 🤔 Vincent Driessen さんがブログで公開した A successful Git branching model のこと 元記事：A successful Git branching model 日本語訳： A successful Git branching model を翻訳しました または、A successful Git branching modelを補助するためのツールの名称git-flow cheatsheet ブランチの運用ルール、命名規則を設けることで、 複数人開発時も各ブランチをわかりやすい状態に保つことができるようになる もっとシンプルなルールにしたものに、GitHubFlowがある 元記事：GitHub Flow 日本語訳：github-flow.ja.md 小さなサイクルでデプロイするケース向き この記事では、A succ
Webサービスやアプリ開発の現場では必須のバージョン管理システム「Git（ギット）」。Gitは、専用のソフトを使えばクリックで直感的に操作することもできますが、いざというときにコマンドが使えると便利です。 前回の 第6話 では、特定の時点までファイルを巻き戻す「リセット」を学びました。 ・特定の時点までファイルを巻き戻す $ git reset 今回の第7話では、間違えてリセットしてしまっても元に戻せる「リフログ」を学びます。一体どのようなコマンドなのでしょうか。このマンガを通して、わかばちゃんと一緒に知識を身につけていきましょう！ 【筆者】湊川 あいさんフリーランスのWebデザイナー・漫画家・イラストレーター。マンガと図解で、技術をわかりやすく伝えることが好き。 著書『わかばちゃんと学ぶ Git使い方入門』『わかばちゃんと学ぶGoogleアナリティクス』『わかばちゃんと学ぶ Webサ
Webサービスやアプリ開発の現場では必須のバージョン管理システム「Git（ギット）」。Gitは、専用のソフトを使えばクリックで直感的に操作することもできますが、いざというときにコマンドが使えると便利です。 前回の第16話では、複数のGitアカウントを使い分ける方法について学びました。 ・メインで使うアカウントを設定する（グローバル設定） $ git config --global user.name "wakaba" $ git config --global user.email. "wakaba@example.com" ・サブで使うアカウントを設定する（リポジトリごとの設定） $ git config user.name "wakaba2" $ git config user.email "wakaba2@example.com" 今回の第17話では、すでに消されたリモートリポジトリ
cd ~/projext_X cat .gitmodules # 結果 [submodule "lib/ethnam"] path = lib/ethnam url = git://github.com/DQNEO/ethnam.git # サブモジュールの中身をのぞいてみる ls lib/ethnam #(ちゃんと中身が見える!) ここまでは問題なし。 この後、プロジェクトXをcloneしたプロジェクトYに移動すると、 cd ~/projext_Y lib/ethnam #(中身が空) あ、あれ・・・？ 原因と対処法 原因は、projext_Y側で "git submodule init"をしてなかったことでした。 cd ~/project_Y git submodule init git submodule update # サブモジュールの中身を確認 ls lib/ethnam #(
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
git commit により、すでに作成したコミットのコメント（コミットメッセージ）を修正する方法についてです。 直前のコミットコメントの修正「git commit --amend」 Git で、コミットログ（コミットメッセージ、コミットログとも言います）を修正したいときは、非常にシンプルです。 git commit の「--amend」オプションを使います。 // 直前のコミットコメントを修正する $ git commit --amend 実際は、--amend オプションは直前のコミットを「置き換える」コマンドです。コマンド実行時インデックスに変更が含まれていれば、新しいコミットにその変更を取り込み、直前のコミットを置き換えます。 git commit の詳しい仕様は、こちらの記事も合わせてご覧ください。 git commit �の仕様と、主要オプションのまとめ 過去のコミットコメント
Gitでよく使用するコマンドが何を行っているかをGIFアニメで解説した記事を紹介します。 Gitのマージ、リベース、リセット、チェリーピック、フェッチ、プル、リフログなど、コマンドを実行した時にブランチはどのように相互作用し、履歴にどのような影響を与えるのか視覚的に学べます。 🌳🚀 CS Visualized: Useful Git Commands by Lydia Hallie 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに Gitのマージ（fast-forward, no-fast-forward） Gitのリベース（rebase） Gitのリセット（reset, revert） Gitのチェリーピック（cherry-pick） Gitのフェッチ（fetch） Gitのプル（pull） Gitのリフログ（re
分散型のバージョン管理ツール「Git」。 今や開発者ならば避けて通れないメジャーなツールですが、多機能なだけに複雑で、使いこなすには十分な知識と経験が必要となります。本日紹介する「lazygit」はそのGitを使いやすくする専用クライアントの一つです。ターミナル上で動作するため、オリジナルのGitコマンドは使いたくないけれども、起動に時間がかかるGUIクライアントを使うのも気が進まないという方におすすめのツールです。 以下使用方法を説明します。 lazygitならば画面上で確認しながら操作できる lazygitはmacOSやLinux、Windows、FreeBSDなどで動作します。macOSの場合HomebrewやMacPortsを利用してインストール可能です。 brew install lazygit # Homebrewの場合sudo port install lazygit #
忘れがちなのでメモです。 直前のコミット日時を修正現状のコミット日時を確認します。 $ gitlog --pretty=fuller commit 62c6282c9b6a3f20659559a5d975dc16a33cb7cd (HEAD -> master) Author: zzzmisa <__@mail.com> AuthorDate: Sat Sep 21 14:04:18 2019 Commit: zzzmisa <__@mail.com> CommitDate: Sat Sep 21 14:04:18 2019 ... コミット時間を 15:00 へ修正することにします。 まずは、AuthorDate を修正します。 $ git commit --amend --date="Sat Sep 21 15:00:00 2019 +0900" エディタが立ち上がるので保存して終了
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
