Git kesinleşmedi ancak bu makinede devam edemiyor


11

Bazen bir taahhüt için hazır olmayan, ancak farklı bir iş istasyonunda veya dizüstü bilgisayarda tamamlanması gereken bir iş istasyonunda taahhüt edilmeyen kodlara sahip olma sorunuyla karşılaşıyorum.

Herkes bu sorun için "yumuşak bir taahhüt" veya başka bir yerde üzerinde çalışmak için değişiklikleri başka bir makineye aktarmanın başka bir yolu gibi bir çözümü var mı?

Düzgün uygulanmayan değişiklikleri yapmaya ve zorlamaya zorlanmamayı tercih ederim.


2
bu yazıyı okumak oldukça zor (metnin duvarı). Sakıncası var düzenleyebilir daha iyi bir şekle ing?
gnat

..kine benziyorsun git stash...?
Simon Whitehead

@SimonWhitehead evet ama git zulası başka bir makineye kolayca taşıyabilir miyim?
csteifel

Tüm Git taahhütleri "yumuşak taahhütler" dir.
user253751

Gerçekten bir kopya değil, çünkü soruna başka bir şekilde yaklaşıyor, ancak ilgili: Git stash'ı projemin devam eden değişikliklerini kaydetmek ve diğer bilgisayarlara erişmek için github'a itmeli miyim?
try-catch-nihayet

Yanıtlar:


12

Aşağıda, yerel repo'nuzun başka bir sunucudaki repo klonu olduğu varsayılmaktadır, örneğin github; ve akış yukarı sunucuda değişiklik yapma haklarına sahip olduğunuzu. Örneğimde, bu akış yukarı repoyu "orijin" olarak adlandırdım. git remote showDiğer depoları listelemek için çalıştırın , bu size adının ne olduğuna dair bir ipucu verebilir.

Bir şube yapmayı öneririm, o zaman başka bir makinede şubeyi kontrol edebilirsiniz. Aslında, işe başlar başlamaz bir dal yaparsanız, istikrarlı bir kod kümesine sahip olmak zorunda kalmadan dalınıza "taahhüt" edebilir, çalışmanızın izini ve yedeğini alabilirsiniz. Çalışmanızdan memnun olduğunuzda, onu "usta" dalınıza geri birleştirebilirsiniz.

  • Repo'nuzu dallamak için: git checkout -b MyNewBranch
  • Yeni şubenizin taahhüt edilen değişikliklerini zorlamak için: git push origin MyNewBranch
  • Başka bir makinedeki bir dalı kontrol etmek için: git checkout MyNewBranch
  • Başka bir şubeye geçmek için (örn. "Master"): git checkout master
  • Masterdayken, MyNewBranch'ı tekrar birleştirmek için: git merge MyNewBranch
  • Dalları listelemek için: git branch

3
Evet, her zaman kendi özel şubenizde çalışmak bu sorunu çözer. Başkasını etkilemeden istediğiniz sıklıkta işlem yapabilirsiniz. Daha da iyisi, her yeni özellik üzerinde çalışmaya başladığınızda veya yeni bir kusuru düzeltmeye başladığınızda yeni bir şube oluşturmaktır. Bu, kod tabanları arasında ileri ve geri atlamayı çok kolaylaştırır.
Robotu

Ayrıca ve bunu yapmamın nedeni: Eğer yarıda bir hata yaparsanız, mevcut dalda önceki taahhütlere gidebilirsiniz. Veya geri atlayın, bir parçasını alın, ileri atlayın ve uygulayın.
AMADANON Inc.

1
Bu yöntem, birleştirilen ana dalda eksik taahhütleri de içermez mi?
eimrek

Evet, ve (bence) bu muhtemelen kötü bir şey değil. Bunu istemiyorsanız, yukarıdakileri yapın, sonra kodunuzu yerine koymak yerine, bir fark yaratın (tüm dosya değişikliklerini içerir, ancak taahhüt yok), dalın yeni bir kopyasına uygulayın, ardından itin.
AMADANON Inc.

2
"hakkındaki yapmak başka bir şubeye geçmek içingit branch -d master ben kafam karıştı," e git istemediğine dikkat silmek ana şube ?? (yine de git şube kılavuzunu okumaktan aldığım izlenim)
Tasos Papastylianou

2

Sen kullanabilirsiniz git diffbir yama oluşturmak ve daha sonra diğer makinede uygulamak için. Veya geçici bir taahhüt oluşturabilir, ardından başka bir makineden çekebilirsiniz. Başka bir makinede geçici bir dal bile oluşturabilir, geçici taahhüdünüzü oraya itebilir ve ardından dalı silebilirsiniz.

En sevdiğim yöntem ikincisidir: geçici bir taahhüt oluşturmak, daha sonra başka bir makineye gitmek ve böyle bir şey yapmak:

$ git fetch ssh://first_machine/path/to/repo whatever_branch_i_was_working_on
$ git reset --hard FETCH_HEAD
$ git reset HEAD^

Neden bu kadar karmaşık ve sadece kullanmak değil git format-patch?
try-catch-nihayet

Gerçekten farklı değil git diff. Kaçırdığım bir şey var mı?
aragaer

1
git format-patch deadbee..badcab1e- .patchKorunmuş güzel isim ve taahhüt mesajı ile ayrı ayrı her taahhüt için dosyalar oluşturur .
try-catch-nihayet

Ayrıca henüz yapılmayan değişiklikler için bir yama yaratıyor mu? Mevcut dizini ve henüz sahnelenmemiş olanları ayırıyor mu? Görünmüyor gibi.
aragaer

Hayır, taahhüt edilmemiş / değiştirilmemiş değişiklikler için değil. Ancak, bir taahhüt, itmediğiniz sürece kimseye zarar vermediğinden, taahhütte bulunmanız uygun olmalıdır ("Devam Eden Çalışma" yazan net bir mesajla - devam etmekte olan çalışma).
try-catch-nihayet

2

Ben taahhüt ederim . Ben itmek için kişisel dalı diğer tarafta kontrol etmek ve değiştirmek. Ve bittiğinde kişisel şubeyi silin.

Tabii ki doğrudan depolar arasında itebilir, demet veya format-patch/ kullanabilirsiniz am, ancak kişisel bir şube açık ara en kolay çözümdür. Ve yeniden yazma tarihi, paylaşılan bir şubeye itilmediği sürece büyük bir mesele değildir. Birçok projede, insanların inceleme için daha kolay anlaşılabilmeleri için özellik dallarını geri sarmaları beklenir .


0

Kolay yaklaşım, tanımladığınız yaklaşımdır: .gitgizli dizini ve proje dosyalarını, taahhütte bulunabileceğiniz ve tamamlayabileceğiniz veya çalışmaya devam edebileceğiniz başka bir makineye kopyalayın .

.gitDizini git geçmişi tutulur nerede olduğundan gerçek dosyalarla birlikte bu koruyarak tüm proje geçmişi bütünlüğünü korur olduğunu.

Orijinal makineyi kalıcı olarak yapmayı bitirdiyseniz, muhtemelen bu yaklaşımı öneririm.


0

Diğerlerinin yanıtladığı gibi, Git ile kişisel şubelerinizdeki bitmemiş kodu önemsememelisiniz. Ancak, bir sebepten dolayı, tamamlanmamış çalışmanızın ana repoya dokunmasını gerçekten istemiyorsanız, Git'in dağıtılmış doğasını kullanabilirsiniz!

git bundleMerkezi bir depo olmadan değişiklikleri kolayca iletmenize yardımcı olabilecek basit bir araç var . İlk olarak, repoyu klonlayın:

git clone https://github.com/octocat/Spoon-Knife.git working_copy_1
cd working_copy_1

bazı değişiklikler yapın ve geçici bir şubeye gönderin:

git checkout -b tmp_branch
git commit -a -m "temporary changes"

Şimdi, değişiklikleri paketleyin:

git bundle create ../tmp.bundle tmp_branch

Artık yeni makinenize gönderebileceğiniz bir paket dosyanız var. Orada nasıl kullanıyorsunuz? Yeni bir çalışan kopya oluşturalım:

cd ..
git clone https://github.com/octocat/Spoon-Knife.git working_copy_2
cd working_copy_2

paketimize başka bir uzaktan kumanda gibi davranmamız gerekiyor, böylece değişiklikleri ondan alabiliriz

git remote add tmp ../tmp.bundle
git fetch tmp

tüm mesele değişiklikleri bir iz bırakmadan aktarmak olacaktı, geçici taahhüdü kaybetmek için bunları çalışma kopyasına sıkıştırmak isteyeceğiz:

git merge tmp/tmp_branch --squash

ve geriye kalan tek şey geçici uzaktan kumandayı kaldırmaktır:

git remote remove tmp

VİYOLA! Değişiklikler ne şube ne de taahhütten ayrılmadan yeni çalışma kopyasına aktarıldı!

Ama gerçekten - bu süreç oldukça uzun ve hantaldır. Bu Git, SVN değil - kişisel şubenizi merkezi repoya itmemek için hiçbir sebep olmamalı.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.