Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? いろんなサイトを見てもピンとこなかったので、検証して自分なりにまとめてみました。 間違いなどあればご指摘いただけるとありがたいです。 サブモジュールとは? **「特定のリポジトリ」の「特定のコミット」**をリポジトリ内の特定のディレクトリに紐付ける仕組みです。 そのため、以下のように普段のリポジトリ操作の挙動とは異なる点が多々あります。 サブモジュール内は独立したリポジトリになっている。 サブモジュールを更新するとバージョン管理外のファイルが全て消えてしまう。 サブモジュール更新直後はブランチがない状態(no branch)になる。 サ
みなさんgitのsubmoduleって理解して使ってますか? 親プロジェクトをpullしたら、submoduleがmodifiedになって混乱してgit addして...あばばばば。みたいな事ないですか? 私はsubmoduleがなかなか理解できずに結構苦労しました。^^; ブランチ単位で管理する通常のリポジトリと違い、submoduleはCommitID単位で管理するというのが一番理解しにくい部分だと思います。 今回は、プロジェクトにsubmoduleを追加、更新、削除の動きを更新を掛ける側のプロジェクトと更新を受け入れる側のプロジェクトの2つの視点から追いながら、CommitIDで管理するとはどういう事なのかを解説していきます。 (結論だけ見たい人は末尾のまとめへ) 準備 「submoduleを開発する役割のプロジェクト test_app_A」と「submoduleを取り入れる役割のプ
gitコマンドって実務でどう使うんだろう? 独学の git コマンドを実務で使いまくり、最近やっとうまく運用できているように感じます。 そのうえで、git コマンドを勉強し始めた頃、「コマンドの説明はいっぱいあるけど、実務でどうコマンドを使うんだろう?」 と感じていたのを思い出しました。 そんな想いから、よく使う git コマンドを実務テイストで振り返ってみました。 本記事に書いていないもの 実務では使うのですが、諸事情により以下は省いています。 submodule 本当はこの記事に含めようかと思ったのですが、長くなりすぎてしまったので、需要がありそうだったら次回作に書こうかと思います。 プルリク コマンドの説明をしたいため、省きます。 Git Flow やら GitHub Flow やらの Flow 系の考え 説明がややこしくなってしまうので省きます。 developブランチ、maste
はじまり ある日 「…今日も作業が終わったし、進んだ分をCommitしよか」 「お、ランキングに面白い記事があがっとるし、休憩がてら見てみよか」 私が(iOS エンジニアの)採用でコードチェックする時何を見ているのか 「ほえー」 「gitのcommit粒度もチームで開発していく上で重要なんやな…」 リポジトリを見てみると… 「せや、さっきcommitしたgitの履歴見てみよか」 「gitていうたけどgithubの履歴なんは勘弁な」 … …… ……… 「なんやこれ、ざっくりしすぎや」 「何してるかは辛うじて読み取れるけども、内容に関して直感的に読み取ることができないやないか…」 「このままじゃあかん…なんとかせな…」 ルールを考える 「とはいえどうしたらええんやろか…」 「ワイにはハスケル子ちゃんはおらんしな…自分で考えるしか道はないんや…」 「ただ単にルールを決めても、区別がつかんとあかん
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 branches: 機能の追加。
はじめに 5日目は、スマートテック・ベンチャーズの奥寺(@okuderap )が担当いたします。 今回はGitのブランチモデルについてです。 私はGitを使い始めたばかりの頃、masterブランチ1本で開発進めてしまったり どのようにブランチを使い分ければ良いのか全然わかりませんでした。 私が経験した好ましくないケースをいくつか挙げて 最後に、それらの問題点を解消したブランチモデルをご紹介いたします。 ※iOS開発において、Gitを使った経験を記載します。 製品やサービスの開発に利用する場合は通じることがあると思いますが、 プロジェクトによって変わる部分もございます。 Case1: masterブランチ1本 私がGitを触り始めたばかりの頃はこの使い方でした。 【開発作業の流れ】 なんでもかんでもmasterブランチにコミットする 【登場するブランチ】 master: 開発を進めたら全てこ
おことわり この記事はプログラミング&業務未経験の新入社員に、Gitについて1時間程度で説明した内容をもとに作ったものです。自分がもし誰かにGitについて教えて貰える立場にいたら、最初にこれを教えて貰いたかったという気持ちで作りました。 とりあえず「1人のプロジェクト」で「1時間で」Gitをそこそこ知って使えるようになることを目的としています。実際のチーム開発ができる水準までこの記事だけで達することはできませんが、今後Gitを使う必要がある人にとって学習の足がかりになれば幸いです。 それと、新入社員に教えるという都合上、表現がやや正確でなくざっくりしたところがあるかもしれませんが、質の悪い誤解を招くようなものでなければご容赦下さい。 全体像 まずはGitとは何かをざっくり分かって貰った後で、VSCode上での操作を行って頂きます。 Windowsでの説明を行いますが、Macの方は適宜読み替
はじめに 一年前に新人研修でGitを担当してTigの記事を書いたのですが,今年も同じくGitの研修を担当することになりました.新人さんたちにとってはターミナル環境はとっつきにくい人も多いようで,短い研修期間では操作自体に苦戦してしまい,Gitそのものを理解するというところに力を割けない人も少なくありませんでした. それを踏まえて今回はGUIで操作しやすい環境を検討したのですが,以下のポイントを踏まえてVSCodeを使うことに決めました. マルチプラットフォームで使える.(研修はWindows環境で行いますが,業務ではLinuxデスクトップ環境も使うので) Gitの基本的な内容はVSCode上でGUI操作が可能. Gitの内容とあわせて,プログラミング用のテキストエディタの一例として,導入しやすそうなVSCodeを紹介. VSCodeを使ったGitの基本的な操作を一通りまとめていきます. イ
という形式のコミットメッセージを生成するようにしました。(もちろん絵文字もない、コミット内容の具体的な理由もない要約だけのコミットメッセージもここでは作れます) 要約については、Githubのファイル欄に表示されたりするためここは日本語英語が入り混じっていると汚いなと思ったので英語統一にしました コミット内容の具体的な理由については英語が望ましいですが、 具体的な理由を書く必要がある (要約より、英語力が必要であり内容が様々であるためテンプレートもあまり機能しない) Githubのファイル欄や、git log --onelineコマンドで表示されない 以上の理由から日本語でも問題ないのかなと思います。 具体的な使い方 基本的には上記のgifのように実際に使っていただければわかると思います。 まずフォームについて簡単に説明すると Emoji: コミットカテゴリを絵文字で表したもの Verb:
本題のチートシートはこちら PNG SVG https://d.kuku.lu/6b5cc7b0a9 から DL できます 作った理由 git って他人に概念を説明するのって難しいし、自身も何度も反復させないと定着しなかったなあという感覚を持っていたので作ってみました 所感 こちらの Git チートシートですが、この中に盛り込めなかった内容で 第2段 を作成しようか考え中です 皆さまのオススメの便利コマンドとか、この内容は必須だろ!的なものがあればをご教示いただければ幸いです もし誤りがあれば、作者の心が折れない程度にご指摘いただければ幸いです あとがき ここまで反響を頂けるとは思っておらず、嬉しい限りです・・・本当にありがとうございます・・・!! また、図は全て自作です。図における言語は英語、説明は日本語、と言う形に統一しました。(吹き出し部分だけ日本語になっていたのでこちらは修正しまし
フォークとは GitHubのヘルプページには、こうある。 フォークは、リポジトリのコピーです。 リポジトリをフォークすると、元のプロジェクトに影響を与えずに自由に変更を試すことができます。 最も一般的には、フォークは他人のプロジェクトへの変更を提案するか、 他人のプロジェクトを自分のアイデアの出発点として使用するために使用されます。 ↓を見ると、もう少しざっくりとイメージすることができるかも。 https://qiita.com/matsubox/items/09904e4c51e6bc267990 お断り GitHubを使っていることが前提の話です。 あくまで自分の経験でのやり方に尽きるので、これやって現場で怒られても責任は持てません。。 通常Git初心者は(他の人から勧められて)GUIツールを使うと思いますが、この記事では基本的にコマンドでの説明になるのでTortoiseGitの使い方
Windows 各ToolのProxy設定 社内からgit/nodejs/sourcetree/atom等を使う際、proxyで接続できないので以下の設定を行う ※ httpsでアクセスするbitbucketがNGだったので、https proxyの設定を少し変える必要があるかも。 git:git for windows CUIベース CUIからgit使用するため。これを実施しておくとjulialangのPackageもInstallできる。 ※juliaにもgitが内蔵されているので、juliaのgitに設定すれば不要かも。 sourcetree : Git GUI Tool GUIでGitを使うため。 nodejs npm(node package manager)を使うため atom editor apm(atom package manager)を使うため 0. 社内Proxy 社
cherry-pickコマンドを使った経緯 本番へのリリースにあたり、リリース用のブランチに変更をコミットしようとしたところ、 過去の改修が含まれていたことに気付き、「特定のコミットだけ反映したいな」と思って調べたのがきっかけです。 cherry-pickコマンドとは? まさに上記ような状況にぴったりのコマンドで、他ブランチの特定コミットのみを反映されることができるコマンドです。 使い方 cherry-pick コミットIDでそのコミットを反映させることができます。 例 developブランチのコミットをstrawberryブランチにcherry-pickする場合 git checkout develop git log commit f77d749550d38df8b2a11cc3d5c16cd1f26fc025 staging環境ホスト名変更 commit 7c83ae675baf01
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 みなさん、Git使ってますか? もしくは、使いこなしていますか? 独習Gitを読んで、思いの外Gitコマンドが多かったので、 タイトルの通り、Gitコマンドで100本ノックをまとめてみました。 Gitの環境構築が終わっている状態からを想定しています。 git initでローカルにリポジトリを用意してください。 問題に対して、直後に回答を載せる形式にしています。 Git初心者の方も、目を通して知らないオプションをググれば勉強になると思います。 参考文献 独習Git 100本ノック Gitに馴染む 1. メールアドレスをGitのグロー
社内に新人が増えてきたので、弊社のWeb開発でのGitのゆるーい利用方針をまとめます。 本当はネガティブなことばかり書かずに、「覚えて欲しいコマンド、使ってほしくないコマンド」というタイトルにしたかったのですが、予想以上に長くなりそうなので分けます。 (追記:第二弾できました) → [社内新人向け]Gitで絶対にオススメなプラグインや設定3つ 社内環境 Web系開発がほぼ100% ブランチワークはGitflowをベースにしたプルリク駆動開発 少人数チームなので、エンジニアは全員LinuxのCUI操作をできて欲しい(vagrantや開発サーバ上の操作など) GitのGUIクライアントは、SourceTreeとGithub公式を試しましたが、初学者が使うと却って危ない挙動をしてしまうケースがあったので、全員CUI操作をしてもらうことにしました CIツールはまだ導入できず。各サーバーへのデプロイ
Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 (2014年12月17日追記) 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど!と思ったコメントをもとに少し修正・加筆してみました。 (2022年1月4日追記) 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目:変更内容の要約(タイトル、概要) 2行目 :空行 3行目以降:変更した理由(内容、詳細) 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 (多すぎても悩むので
インストール方法から参考リンクまで。 自分の勉強ついでに、Tigについて基本の すべてをまとめてみました。 合わせて読みたい 【おすすめ】MacのFinderをカスタマイズする魔法のコマンドたち 【おすすめ】これからWebする人はここ読んどけ(HTML/CSS/JS/Ps/Ai.etc) 【おすすめ】Qiitaを使い倒す方法一覧 Tigとは 定義 Tig is an ncurses-based text-mode interface for git. It functions mainly as a Git repository browser, but can also assist in staging changes for commit at chunk level and act as a pager for output from various Git commands. 要
Gitチートシート 用語 リポジトリ バージョン管理システムにおいて,プログラムやファイルを蓄積しておく場所. Gitではローカルリポジトリとリモートリポジトリの二種類のリポジトリを扱える. ローカルリポジトリ 現在作業中のリポジトリ.主に自分のPCや開発サーバーなどで作業する場合はローカルリポジトリとなる. また,リモートリポジトリからリポジトリをクローンして,自分のPC上やサーバー上に環境を構築することもできる. リモートリポジトリ 外部にあるリポジトリ.リモートリポジトリはローカルリポジトリを通じて作業を行う. 複数人での作業やインターネットに公開する場合に利用できる. ワーキングツリー ユーザーが編集したり新しいファイルを作成したりする場所. インデックス ワーキングツリーでの編集後,リポジトリへのコミットの前に次のコミットの対象となる状態を保持している場所. ブランチ 履歴の流れ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く