Gitバージョン管理において履歴を分岐させるブランチと呼ばれる機能、分岐した履歴を統合するマージと呼ばれる機能について、GitクライアントのSourceTreeを使った方法についてお伝えしていきます。 ブランチを切ってバージョンを分岐させる方法、そして分岐させたブランチをマージして統合する方法についてお伝えしました。 こうすることで、複数人での並行作業や、別々のバージョンを試してみる、また最終版を安定確保しておく、などの作業の進め方が実現できますので、非常に便利です。 しかしながら、分岐があることにより困ったことが発生する場合があります。 特に複数人で作業する際には十分に起き得るのですが、 同じ箇所を 別々のブランチで 別々の変更をかけてしまっているのに マージする この場合、二つの分岐で不整合が起きてしまい、履歴としてその状態から進ませることができなくなります。 これを「衝突」または「コ

Git はコードのマージを非常に得意としています。マージとはローカルで高速、そして柔軟に行えるものです。当然のことですが、異なるブランチから誰かがコンテンツをマージするたびにコンフリクトが発生します。コンフリクトを解決するには、主な変更点を把握して見抜かなければなりません。コンフリクトの解決は、時には多くの作業が必要になります。 開発者にはそれぞれ好みのコンフリクト解決方法があります。そのため同僚ライターのダン・スティーブンが以前、Questions for Confluence を使用して社内の人に質問していました。 返ってきた回答と洞察はアトラシアン社員だけではなく、もっと多くの人に役立つものでした。そこで私たちが Git コンフリクトを解決するさまざまな方法を以下に詳しく注釈付きで紹介します。皆さまの毎日のコーディング作業に役立つアイデアや方法がここで得られることを願います。 セット

私が Git リリース ノートをレビューしてからしばらく経ちましたが 、だからといって私が最新のノートを熱心に読んでおらず、毎日の作業に新たな優れモノを取り入れていなかった訳ではありません。自分の誕生日 (拍手！) と、先日の Bitbucket Server のリリースを祝うため、本日は私が Git 2.x シリーズ (2.6 まで) で気に入っているフィーチャーを全てご紹介します。どれか役に立つようなことがあれば、是非ご一報ください。 リベース前に変更内容をスタッシュ Git 2.6 では、rebase コマンドが皆さんから良い意味での注目を浴びました。以下にご紹介するのは、より興味深い新しいフラグの1つです : git rebase --autostash これからは、rebase 操作の開始時に未コミットの変更内容を一時的にスタッシュするか、操作を失敗させるかを指定できます。この行

オプション -n を使えば良い。 $ git log -n 1 (1コミット分だけ表示) $ git log -n 2 (2コミット分だけ表示) $ git log -n 3 (3コミット分だけ表示) もう一声 ハイフンの後に直接、数字を打っても良い。 $ git log -1 $ git log -2 $ git log -3 ( @tsuyoshi_cho さん情報 ) 環境 git version 2.3.8 (Apple Git-58) チャットメンバー募集 何か質問、悩み事、相談などあればLINEオープンチャットもご利用ください。 メンター受付 Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read b

git stash drop や clear の間違いを戻します。 最近、まじめに branch をまたぎながら開発を進めていて、git stash を使うようになりました。 Git – 作業を隠すgit stash すると、変更内容がスタックに保存されます。 作業完了後、git stash drop などで削除します。 ここで間違った場合の復旧方法。 スタック削除の手順スタックを確認。 % git stash list stash@{0}: WIP on feature/issue#2: 3232ce5 fix: install bug stash@{1}: WIP on feature/issue#2: 4364647 update: config files

Go 1.5からVendoring機能が使えるようになったので外部パッケージをgit subtreeで管理してみた。 以下のコマンドで対象のリポジトリにパッケージを追加することができる。 ※ --squashをつけると取り込むパッケージのコミットを一つにまとめることができる # usage: git subtree add --prefix=<prefix> <repository> <ref> $ git subtree add --prefix=vendor/github.com/zenazn/goji https://github.com/zenazn/goji v0.8.3 --squash GO15VENDOREXPERIMENTはデフォルトでは無効なのでビルドするときに有効にする必要がある。 $ GO15VENDOREXPERIMENT=1 go build パッケージを更新す

gitのalias 各所で提案されているaliasを収集、一部修正やら改良やらしたもの。 公開して更新を維持する方法がなかった(プライベートリポジトリでの運用のため)ので、適当なタイミングで公開することにする なお、個別のファイルにしてあって、.gitconfigのinclude設定で取得するようにしている。 pecoを利用するaliasは、引数があれば短縮ワードとして、そうじゃないなら、pecoでの選択になるようにしてある。 fzfにも対応(Windowsでwinptyなしのインタラクティブ動作が安定したこともあり) あと、その選択もローカルのブランチだけ、とか追跡ブランチも込みとか、ログからのハッシュ選択とかある。 改良が必要な箇所としては、elifにしてあるのはelseでもいいんじゃないか(pecoがないなら常に短縮動作)とか考えてますが、まだ未着手。 alias定義 # -*- c

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

Git や GitHub にまつわるツールは gitconfig に値を格納することにしておくのがユーザにも便利で、よく使っているし広く使われているとおもう。いっぽう YAML とか JSON とか設定ファイルによく使われるフォーマットは構造体に値をまとめて読みこむのが普通でもある。そういうわけで表題のようなものを書いた。以下の例を見れば分かるとおり gitconfig ファイルを自力で解析してすべての値を読みこむようなものではないです。 README より GoDoc のほうが詳しいです。 使い方 gitconfig フィールドタグを使います。 import "github.com/motemen/go-gitconfig" type C struct { UserEmail string `gitconfig:"user.email"` PullRebase bool `gitconf

GitHubにはコードの断片を管理したり人に見せたりブログに貼付けたりするのに便利なGistってのがあります。 通常の使い方では、ブラウザで貼付けたりとかすると思うのですが、GistもGitのリモートリポジトリなので、クライアントから使う事も出来ます。 ……ってのはGistにも普通に書いてるんですけどね。 Gist is a simple way to share snippets and pastes with others. All gists are git repositories, so they are automatically versioned, forkable and usable as a git repository. とりあえずやってみます。 色々やってみる まず適当に作ります。 GitHubはお金払わないとプライベートなリポジトリは作れないのですが、Gistだ

~/repo1/subdir に ~/repo2 を入れる あるリポジトリのサブディレクトリに別のリポジトリの中身を入れたいとき。たとえば、あるリポジトリのサブディレクトリを切り出して別のリポジトリとして管理しているものを、元のリポジトリに合流させたいとき。 cd ~/repo1 git remote add repo2 ~/repo2 git fetch repo2 # サブディレクトリの内容に repo2 の内容をマージする # （repo2 と内容が似ているサブディレクトリを自動で判別） git merge -s subtree repo2/master # ↑でうまくいかないときにはパスを指定する↓ git merge -X subtree=subdir repo2/master # そもそも ~/repo1/subdir が存在しないときには↓ git read-tree --p

git reset がわからないので図をかいた 以前のコミットへ戻るとき 現在の HEAD へ戻るとき 現在の HEAD へ戻る という日本語はおかしかった。 reset は HEAD の位置を変更する。 オプションとしてステージ上、ワーキングツリーのファイルを削除したり残したりできる。 HEAD へ reset するということは HEAD の位置がかわらない reset --soft はステージにもワーキングツリーにもなにもしない、のでなにもおこらない reset はステージ上からファイルを降ろすので、add の取り消しになる reset --hard はワーキングツリーへの変更も削除してしまう。コミットしていない作業は消える。 メモ ステージ と index は同じもの unstage はステージから削除されるということ HEAD^ は HEAD の一つ前のコミット ローカルファイルを

近藤です。こんにちは。Gitは様々な利用の仕方ができますが、その基盤となるモデルは8個だけの簡単なモデルです。これらのモデルを理解していない状態でGitを利用すると、あたかもリポジトリが壊れたように見えてしまいます。Gitは難しいと言われますが、そういう感想を持つ人はGitのモデルを理解していない事が多いようです。 今回はGitを構成する中心モデルと、基本的なコマンドを実行した時のオブジェクト関係を解説します。 基本概念 Gitの基本概念は大きく2つにわかれます。 GitObject Reference GitObjectはGitで管理するオブジェクトです。CommitなどがGitObjectです。Gitリポジトリである.gitを開くとobjects配下にあるファイルがGitObjectです。GitObjectはそのコンテンツをハッシュ化した文字列を元に、先頭2文字で配置フォルダ、残りの文

branch コマンドの contains オプションは、指定したコミットを含むブランチのみを表示する。 コミット指定を省略すると HEAD が指定されたとみなすので、以下でも上記コマンドと同じ意味になる。 Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up

半分自分用のメモですが、Gitを使って開発してる場合によくあることを簡単にまとめました。 特に使い始めの頃とか初心者の人が困ったときの手助けになれば。 なお、自己責任でお願いします。 ※間違いあったら指摘してください 変更確認系 1. 変更箇所を直前のコミットタイミングと比較したい git diff HEAD~1 2. 差分のサマリを見たい git diff --stat <source> <target> 3. スペースの変更を無視してdiffしたい これをしないと全体をインデントしたときとかに悲惨です。 git diff --ignore-space-change <source> <target> 4. 自分のリポジトリをフォークして作られた他人のリポジトリを比較 git remote add <name> <フォーク元もしくは比較したいリポジトリ> git fetch <name>

新サービスが続々登場してアツい！ 「GitHub」とは 皆さんは「GitHub」を活用しているでしょうか？ 「GitHub」（ギットハブ）はソースコード管理用の分散型バージョン管理システム「Git」を使ったホスティングサービスです。 Gitの特徴は、作業用として自分のコンピュータ上にあるローカルリポジトリがあれば、ネットワークに接続できない状態だったとしても、ソースコードの更新や、履歴を調べたりできる点にあります。その特徴はGitHubにも生かされていて、オープンソースとして公開中の既存のコードを分岐（fork）して、新しいプロジェクトとして開発できます。 また、自分が手元のローカル環境でバグ修正したり、拡張したソースコードを本家のオープンソースプロジェクトに取り込んで（pull）もらうことも手軽にお願いできます。 さらに、READMEテキストファイル（README.md）などを独特のマー

#!/bin/sh rm -fr .git *.txt .gitignore git init echo init.sh>.gitignore && git add .gitignore && git commit -m "Initial Commit" echo b>b.txt && git add b.txt && git commit -m "master 1" git branch other echo c>c.txt && git add c.txt && git commit -m "master 2" echo d>d.txt && git add d.txt && git commit -m "master 3" git checkout other echo e>e.txt && git add e.txt && git commit -m "other 1" echo