Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
配信動画はこちら https://www.youtube.com/watch?v=qerW4vBftNA もし良かったらムーザルちゃんねるのチャンネル登録お願いします！ https://www.youtube.com/channel/UCLPHXwLp90A5R69Eltxo-sg Tw…
皆さん、今日もローカルにコミットしてますか？（言いたかっただけ） この連載は（中略）文章を扱う全ての人を対象にしています。 なんとなくで Git を覚えてしまっている人にもたぶん役立ちます。 シリーズ記事一覧 1-1「Git と GitHub を使うメリット」 1-2「コミットを積み上げる」 1-3「コミットを理解して活用する」 1. 今回のゴール コミットってなに？ コミットを書き換えたことにする 過去のコミットの内容を復元する 編集中の内容やステージを取り消す 便利な比較差分ツールの紹介 今回はちょっとしたお勉強と、使えるようになると捗る Tips の紹介です。 Tips はけっこうな頻度で使うので、実際に手を動かして覚えてくださいね。 2. コミットってなに？ 今後、高度な Git 操作を行ううえでは、 Git の仕組みを理解しておくことが何より重要です。 Git の仕組みを理解して
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? おことわり この記事はプログラミング＆業務未経験の新入社員に、Gitについて1時間程度で説明した内容をもとに作ったものです。自分がもし誰かにGitについて教えて貰える立場にいたら、最初にこれを教えて貰いたかったという気持ちで作りました。 とりあえず「1人のプロジェクト」で「1時間で」Gitをそこそこ知って使えるようになることを目的としています。実際のチーム開発ができる水準までこの記事だけで達することはできませんが、今後Gitを使う必要がある人にとって学習の足がかりになれば幸いです。 それと、新入社員に教えるという都合上、表現がやや正確で
「バージョン管理ツールのGitとは一体どういうものであるのか？」について簡単にまとめてみました。今回はGitの概念や考え方についてを中心にまとめており、「Gitが何なのかよく分からない」「実際のコードに触れてみたもののよく分からず使うのをやめてしまった……」といった人向けに記事を作成しています。 Git https://git-scm.com/ バージョン管理とは、要するに「ある時点でファイルを別に保存しておく」ということです。別のファイルに保存しておけば、またそこからやり直すことができます。これを直感的に行うと下図のような「手動ファイル名バージョニング」になりがちです。ただし、この「手動ファイル名バージョニング」は命名する時の思いつきで決めることが多く、後で見た時に「どれが本当の最新ファイルなのか分からない」となりがちなのが問題です。 これに対する一つの解決策が「プロジェクトフォルダに『
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 初めに LinusによるGitのinitial commitのREADMEの訳です。 社内のSVNからの移行を促すために資料を整備していたのですが、SVNでやっていたことを移し替えたりコマンドを覚えたりするより内部構造を知ったほうが早いことに気づきました。 それで、gitの内部構造についての解説資料を色々見ていたのですが、データ構造については原作者のこのREADMEに言い尽くされている気がします。のみならず、gitを使うものが抱くべき精神性のようなものが示されており、深い感銘を覚えました（ヒャッハー）。 README: ”GIT - 馬
「GitLab 9.2」リリース。1つのIssueに複数人をアサイン可能に、国際化対応を開始、Kubernetes環境へインストール対応など GitLab 9.2では、はじめて国際化対応のフレームワークが追加。有効性を確認するために一部のページのみスペイン語とドイツ語が用意されています。有効性が確認されれば、以降のバージョンからほかの言語も追加し、国際化を進めていくとのことです。国際化に協力するためのコントリビューションページも用意されました。 また、GitLabのインストール環境として正式にKubernetesがサポートされました。 インストールにはKubernetesのパッケージマネジメントツールである「Helm」を利用。Kubernetes環境によってスケーラビリティの実現が容易になっています。 有料版となるGitLab Enterprise Editionでは、1つのIssueに対
本連載「こっそり始めるGit／GitHub超入門」では、バージョン管理システム「Git」とGitのホスティングサービスの一つ「GitHub」を使うために必要な知識を基礎から解説していきます。具体的な操作を交えながら解説していきますので、本連載を最後まで読み終えるころには、GitやGitHubの基本的な操作が身に付いた状態になっていると思います。 連載第4回目の本稿のテーマは「コンフリクトが発生したときの対処方法」です。 前回の「Git初⼼者でも分かるGitブランチの作成、確認、切り替え、マージ、削除の⼿順」までで「ブランチ作成」から「マージ」までの一連の操作を行いました。前回行った一連の操作では片方の「second」ブランチだけで変更を進めたので、変更内容が複数ブランチ間で「コンフリクト（衝突、競合）」することなく簡単にマージできました。しかし、実際の開発では変更内容がコンフリクトしてしま
GitリポジトリとDockerイメージレジストリを統合した「GitLab 8.8」リリース。開発や継続的統合のワークフローがシンプルに GitLabは、Gitリポジトリを中心とした開発ツール「GitLab 8.8」をリリースしました。 GitLabはGitリポジトリ機能の機能に加え、Wikiやイシュートラッキング、コードレビュー、アクティビティフィード、そしてテストやビルド、デプロイなどの自動化を行うGitLab CI機能などが統合された開発ツールです。 GitLab 8.8ではパイプライン機能が強化。パイプラインの状態を画面で参照できるようになりました。 もう1つの大きな機能強化が、Dockerイメージレジストリ機能の統合です。 GitLab 8.8には最初からDockerイメージのレジストリ機能が組み込まれており、インストールするとすぐに使える状態になっています。GitLab CIによ
GitやGitHubの使い方を学習することができるデスクトップアプリ「Git-it」。Electronで作られていて、Mac / Windows / Linux用の実行ファイルをGitHubよりダウンロードすることができます。英語表記のみだけでなく、日本語に対応しているところもありがたいところです。 使用方法 Git-it自体は問題集のようなもので特別な仕掛けはありません。画面の指示に従いローカルの環境でGitを使いながら学習を進めていきます。Git-itではGitHub Desktopの使用を推奨していますが、実際の運用を考えてターミナルでGitを勉強してみるのも良いでしょう(Windowsの場合若干めんどくさいですが)。 Git-itでは、Gitのインストールから始まり、リポジトリの作成やコミット、GitHubの使い方、最終的にはプルリクエストの送信方法まで学ぶことができます。 プルリ
『エンジニアのためのGitの教科書』と『エンジニアのためのGitの教科書 上級編 Git内部の仕組みを理解する』の2冊が、2016年1月に翔泳社から刊行された。Gitはいまや、開発の現場において不可欠なツールになりつつある。新人エンジニアを始め、これまでSubversionを利用してきたもののGitを使ったことのなかった人もまた、Gitを覚えようと日々努力しているはずだ。そのようなGit初級者は、どのようにGitを学び、どういった機能に注目して使いこなしていくとよいのだろうか？ 本書の著者である株式会社リクルートテクノロジーズの河村聖悟氏と、太田智彬氏に話をうかがった。 新人エンジニアはまずGitの考え方を理解しよう ――新人エンジニアが覚えなければいけないことの一つにGitが挙げられるかと思います。しかしGitをまったく知らないと、戸惑うことも多いはずです。開発経験もなく、Gitも利用し
「Git 2.8.0」では、新機能としてsubmodulesの並列フェッチが可能になる。submodulesは、他のレポジトリをレポジトリのサブディレクトリのように使える機能で、プロジェクトへのライブラリや外部の依存関係の統合に便利。しかし、多数のsubmodulesがある場合フェッチに時間がかかるが、今回の新機能により実行時間が短縮される。 また、.gitconfigでユーザー名とメールアドレスを指定している場合、.gitconfigの指定と異なるユーザー名やメールアドレスでコミットした際に、警告は表示されるものの、コミット自体は実行されてしまうが、「Git 2.8.0」では異なるユーザー名やメールアドレスでのコミットを禁止する設定が追加された。 さらに、今回のリリースではGit for Windowsプロジェクトにおける成果の還元によって、プラットフォームにまたがる新機能の追加を行いや
最近、自分のGitのコミットログを読み返してみたら、すごく分かりづらかったので勉強も兼ねて、Gitのコミットログのプラクティスを勉強してみました！ 🐰 Gitのコミットメッセージの書き方次のサイトを参考にさせていただきつつ、簡単にまとめてみました！ Gitのコミットメッセージの書き方 | プログラミング | POSTD Gitのコミットメッセージの書き方 - Qiita 書き方を知ることのメリットGitのコミットメッセージをわかりやすく残すことで、その変更どんな目的で具体的にどんなことを修正したかを 次の変更を行う人に伝えることができ、次の人の修正する時間を節約できる。 具体的にどんなことを書くべきかどのように変更を行ったかは、コードを見れば分かる。もしわからないのなら、コードにコメントを書くべき。 変更した理由を明らかにすることに焦点を絞り、変更前がどうで、何が問題で、今はどのように機
を考えてみる。 Git Flow nvie.com やってみたことある。良いんだけど、僕の環境だと、もうちょっとシンプルにやれそうかなって思った。 Github Flow scottchacon.com これはシンプルだな。なんだけど、シンプルすぎてちょっと違うかな。 ということで、ちょうどいいくらいのを考えてみたい 今の僕の開発にとって、ちょうどいいくらいのを考えてみたいなーって。じゃあ、今の僕のやってる開発ってどんなん？ってところから。 チーム エンジニア5,6人くらい。 Feature, Story, Task Featureと呼ばれるものがあって、これは2,3ヶ月分の規模で。この単位でリリースする。 Featureは複数のStoryで構成されていて、Storyは4,5日くらいで完了する。から、1 Featureは10から15Storyくらいってことか。 Storyは複数のTaskを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
