私は github を使用していませんが、自分のシステムでこの種のことを行っています。それを処理するためのさまざまな方法がたくさんあります。
ラップトップとデスクトップがあり、両方を使用しているとします。あなたはできる:
laptop$ git remote add desktop ssh://desktop.host.name/...
と:
desktop$ git remote add laptop ssh://laptop.host.name/...
いずれかのシステム (裸のリポジトリを使用) で、必要に応じてgit fetch laptop
、またはgit fetch desktop
必要に応じて実行できます。場合によっては、簡単に編集できるように、一方から他方へ ssh し、git commit
work-dir の作業を保存する必要があります。fetch
つまり、デスクトップにいて、まだラップトップから作業を行っていないことに気付きます。 ssh laptop
必要に応じてコミットし、次にgit fetch laptop
. 今、あなたはlaptop/branch
デスクトップ上にあり、やりたいことは何でもできますgit merge
。git cherry-pick
(最初にラップトップの電源を入れる必要があるかもしれません。:-))
または、 という名前のリモートの裸の「共有」リポジトリorigin
があり、デスクトップにいて、ラップトップからプッシュするのを忘れたことに気付いたとします。ラップトップに SSH 接続し、必要に応じてリポジトリにコミットgit push
し、デスクトップから "git fetch" して元に戻します。もう少し往復っぽいですが、結果は同じorigin/branch
ですlaptop/branch
。
編集:ここにいくつかの一般的なシナリオがあります(その場で作成されたので、それほど複雑ではありません)。「lola」(以下に繰り返し表示されます) は別名です。
$ git config --get alias.lola
log --graph --decorate --oneline --all
(また、ここではデスクトップ システムとラップトップ システムを相互に「追跡」ブランチとして設定していないことにも注意してください。すべてを「完全手動モード」で行っています。ラップトップでも同じですが、ビーイングについては自動化できますが、少なくともこの記事では、基本的なメカニズムを示したいので、ここでは自動化は必要ありません.)branch.master.remote laptop
branch.master.merge refs/heads/master
remote
desktop
あなたはデスクトップにいてcd project
、作業を開始し、探し始めて気づきました。ああ、待って、ここに置きたいラップトップで何かをコミットしました。私はブランチに取り組んでいますmaster
(これは新しいプロジェクトで、まだ他のブランチはありません)。
そう:
desktop$ git fetch laptop
remote: Counting objects: 4, done.
[snip]
desktop$ git lola
* d824ebf (laptop/master) work done on laptop
* 176af7a (HEAD, master) initial
ここlaptop
には、私が行っていないコミットが 1 つあります。保存したい作業が少しある場合は、おそらく使用するだけですgit stash
(他のオプションもありますが)。この場合、foo.py が欠落していることに気付いたので、まだ作業を開始していません。
desktop$ git merge laptop/master
Updating 176af7a..d824ebf
Fast-forward
foo.py | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 foo.py
これで、ラップトップとデスクトップが同期されました (ただし、マシンの「ラップトップ」はそれを認識していません!)。foo.py と commit にもう少し取り組み、desktop
先に進みます。
その後、ラップトップに戻って、次のことを行います。
laptop$ git fetch desktop
remote: Counting objects ...[snip]
$ git lola
* 968cf90 (desktop/master) main: fix stupid bug
* b8a9735 add main
* 6289ce6 fix up foo
* d824ebf (HEAD, master) work done on laptop
* 176af7a initial
これgit merge desktop/master
で、ラップトップでより多くの作業を行う準備が整いました。
laptop$ git merge desktop/master
Updating d824ebf..968cf90
Fast-forward
foo.py | 8 +++++++-
main.py | 21 +++++++++++++++++++++
2 files changed, 28 insertions(+), 1 deletion(-)
create mode 100644 main.py
ラップトップとデスクトップの両方で作業を行っていて、マージまたはリベースする必要がある場合は、少し面倒です。私はおそらくリベースします.私はそれらを得ることができるとき、私は私の線形コミット履歴が好きです:-):
desktop$ ... work, commit, etc
# oops, I forgot to bring over stuff from laptop!
desktop$ git fetch laptop
remote: Counting objects [snip]
desktop$ git lola
* 8f95602 (HEAD, master) describe
| * bd5d378 (laptop/master) hook up function
|/
* 968cf90 main: fix stupid bug
* b8a9735 add main
* 6289ce6 fix up foo
* d824ebf work done on laptop
* 176af7a initial
desktop$ git rebase laptop/master
First, rewinding head to replay your work on top of it...
Applying: describe
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging main.py
desktop$ git lola
* dba0f92 (HEAD, master) describe
* bd5d378 (laptop/master) hook up function
* 968cf90 main: fix stupid bug
* b8a9735 add main
* 6289ce6 fix up foo
* d824ebf work done on laptop
* 176af7a initial
ほら、リベースしたときにgitは正しいことをすることができました(マージの競合などはなく、結果は機能します)。線形シーケンスに戻りました。
より複雑なプロジェクトでは、ある時点で一連のコミットを再構築して少し混乱させることを決定するかもしれませんgit reset --hard
。しかし、その後、自分が何をしているのか、どのマシンにどのコミットがあるのかを正確に知る必要があります。どこで作業していても(デスクトップ、ラップトップなど)fetch
、他のすべての作業サイトを編集し、すべての「必要な」コミットを組み込んだことを確認する必要があります。再構築 (コミットのマージ、「修正」の適用rebase -i
など) は、最初にすべてのコミットを引き継ぐのを忘れると、自分にとって困難になります。
これに取り組んでいるのは私だけ (そして 2 つまたは 3 つのシステムを使用しているだけ) だとしても、それほど悪くはありません。しかし、それが共有プロジェクトである場合は、他の人のために物事を台無しにしないようにする必要があります。特に、レポを使用してオブジェクトを転送している場合や、「転送」レポのブランチをpush
故意に書き直している場合は特にそうです。push -f