0

私は単一のリモートレポと、リモートから実行できるコンピューターをいくつか持っていpullますpushmaster2 つのボックスのバージョンは頻繁に相違します --これらのローカル バージョンとリモート/バージョンが相違する場合、ローカルの変更を にマージすることは可能masterでしょうか?

pushデスクトップにあるバージョンで作業を開始する前に、ラップトップからリモートに移動することを忘れることがよくあります。現在、これらの問題を消極的に解決しています。

git fetch --all
git reset --hard origin/master

そして、いくつかの切り取りと貼り付け (通常、編集が小さいときに発生するため、それほど負担にはなりません)。

私がやりたいのは、遅れているバージョンをリモートのバージョンとマージすることです。

これは可能だと確信していますが、理解できません (私が見つけたオンライン ヘルプでは、2 つの異なるバージョンと 1 つのリポジトリではなく、リポジトリにリンクされた単一のボックスがあると想定しています)。

前もって感謝します

4

1 に答える 1

1

私は 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 commitwork-dir の作業を保存する必要があります。fetchつまり、デスクトップにいて、まだラップトップから作業を行っていないことに気付きます。 ssh laptop必要に応じてコミットし、次にgit fetch laptop. 今、あなたはlaptop/branchデスクトップ上にあり、やりたいことは何でもできますgit mergegit 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 laptopbranch.master.merge refs/heads/masterremotedesktop

あなたはデスクトップにいて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

于 2013-11-09T09:36:34.373 に答える