Perforce उपयोगकर्ताओं के लिए Git

Question

मैं कई वर्षों से Perforce का उपयोग कर रहा हूं। मैं अपने व्यक्तिगत कोड के लिए git का उपयोग करने के लिए स्विच करना चाहूंगा, लेकिन उन सभी git ट्यूटोरियल्स के बारे में जिन्हें मैंने देखा है कि या तो यह मान लें कि आप एक पूर्ण स्रोत नियंत्रण n00b (जो उन्हें अविश्वसनीय रूप से थकाऊ बनाता है) या जिसका आप उपयोग कर रहे हैं svn (जो मैं नहीं हूं)।

मुझे पता है कि पी 4, और मैं एक वितरित स्रोत नियंत्रण प्रणाली के पीछे के विचार को भी समझता हूं (इसलिए मुझे बिक्री पिच की आवश्यकता नहीं है, धन्यवाद)। मुझे जो पसंद है वह p4 कमांड से बराबर git कमांड में ट्रांसलेशन टेबल है, साथ ही "बिना नहीं रह सकता है" कमांड के साथ कोई भी 4 समतुल्य नहीं है।

चूँकि मुझे संदेह है कि प्रत्येक p4 उपयोगकर्ता p4 के एक अलग उपसमूह का उपयोग करता है, यहाँ कुछ चीजें हैं जो मैं नियमित रूप से p4 में करता हूं जो मैं git में करने में सक्षम होना चाहता हूं जो मैंने जिस डॉक्स को देखा है उससे तुरंत स्पष्ट नहीं हैं :

1. एक ही क्लाइंट में कई लंबित चेंजेलिस्ट बनाएँ। ( p4 change)
2. एक लंबित चेंजेलिस्ट को संपादित करें। (भी p4 change)
3. मेरे सभी लंबित पत्रकारों की सूची देखें ( p4 changes -s pending)
4. मेरे क्लाइंट में सभी परिवर्तित फ़ाइलों की सूची ( p4 opened) या एक लंबित चेंजलिस्ट में ( p4 describe)
5. पेंडिंग चेंजलिस्ट का एक अंतर देखें (मैं इसके लिए एक रैपर स्क्रिप्ट का उपयोग करता हूं जो उपयोग करता है p4 diffऔर p4 describe)
6. किसी दिए गए फ़ाइल के लिए, देखें कि किन चेंजलिस्टों ने प्रभावित किया है कि कौन सी लाइनें ( p4 annotate)
7. किसी दिए गए फ़ाइल के लिए, फ़ाइल को प्रभावित करने वाले चेंजेलिस्ट के विवरणों की एक सूची देखें ( p4 log)
8. लंबित चेंजलिस्ट ( p4 submit -c) जमा करें
9. एक लंबित चेंजलिस्ट को गर्भपात कराएं ( p4 revert)

इनमें से बहुत सारे "चैंजिस्ट" के आसपास घूमते हैं। "चैंजिस्ट" पी 4 शब्दावली है। Git समतुल्य शब्द क्या है?

ऐसा लगता है कि शाखाएं क्या हो सकती हैं जो g4 उपयोगकर्ताओं के स्थान पर git उपयोगकर्ताओं का उपयोग करती हैं। थोड़ा भ्रामक है, क्योंकि पी 4 में भी कुछ शाखा होती है, हालांकि वे केवल संबंधित अवधारणाएं लगती हैं। (हालांकि मुझे हमेशा लगता था कि पी 4 की एक शाखा की अवधारणा बहुत अजीब थी लेकिन यह एक शाखा के क्लासिक आरसीएस अवधारणा से फिर भी अलग है।)

वैसे भी ... मुझे यकीन नहीं है कि मैं g4 की शाखाओं के साथ पी 4 चेंजलगिस्ट में सामान्य रूप से क्या करूं। P4 में मैं ऐसा कुछ कर सकता हूं:

$ p4 edit a.txt
$ p4 change a.txt
Change 12345 created.

इस बिंदु पर मेरे पास एक चेंजलिस्ट है, जिसमें a.txt है। मैं विवरण को संपादित कर सकता हूं और चेंजलिस्ट को प्रस्तुत किए बिना काम करना जारी रख सकता हूं। इसके अलावा, अगर यह पता चला है कि मुझे कुछ अन्य फ़ाइलों में कुछ बदलाव करने की आवश्यकता है, जैसे कि कोड की किसी अन्य परत में बगफिक्स कहते हैं, तो मैं उसी क्लाइंट में कर सकता हूं:

$ p4 edit z.txt
$ p4 change z.txt
Change 12346 created.

अब मेरे पास एक ही क्लाइंट में दो अलग-अलग चैनल हैं। मैं इन समवर्ती पर काम कर सकते हैं, और मुझे उन्हें "बीच स्विच" करने के लिए कुछ भी करने की आवश्यकता नहीं है। जब यह करने का समय आएगा, मैं उन्हें अलग से प्रस्तुत कर सकता हूं:

$ p4 submit -c 12346  # this will submit the changes to z.txt
$ p4 submit -c 12345  # this will submit the changes to a.txt

मैं समझ नहीं पा रहा हूँ कि इसे कैसे दोहराया जा सकता है। मेरे प्रयोगों से, यह प्रकट नहीं होता है कि git addवर्तमान शाखा के साथ जुड़ा हुआ है। जहां तक ​​मैं बता सकता हूं, जब मैं git commitयह करने के लिए सभी फाइलें करने जा रहा हूं कि उस समय मैं git addकिस शाखा में था, कोई फर्क नहीं पड़ता:

$ git init
Initialized empty Git repository in /home/laurence/git-playground/.git/
$ ls
a.txt  w.txt  z.txt
$ git add -A .
$ git commit
 Initial commit.
 3 files changed, 3 insertions(+), 0 deletions(-)
 create mode 100644 a.txt
 create mode 100644 w.txt
 create mode 100644 z.txt
$ vi a.txt z.txt 
2 files to edit
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   a.txt
#   modified:   z.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git branch aardvark
$ git checkout aardvark
M   a.txt
M   z.txt
Switched to branch 'aardvark'
$ git add a.txt 
$ git checkout master
M   a.txt
M   z.txt
Switched to branch 'master'
$ git branch zebra
$ git checkout zebra
M   a.txt
M   z.txt
Switched to branch 'zebra'
$ git add z.txt 
$ git status
# On branch zebra
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   a.txt
#   modified:   z.txt
#
$ git checkout aardvark
M   a.txt
M   z.txt
Switched to branch 'aardvark'
$ git status
# On branch aardvark
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   a.txt
#   modified:   z.txt

इस उदाहरण में, aardvark और ज़ेबरा शाखाओं में ठीक उसी परिवर्तन के सेट को सम्‍मिलित किया गया है, और इसके आउटपुट के आधार पर git statusऐसा प्रतीत होता है कि दोनों में एक ही कार्य करने का एक ही प्रभाव होगा। क्या मुझसे कुछ ग़लत हो रहा है?

Comments

आप बस अपने निजी कोड के लिए पर्फेक्ट का उपयोग कर सकते हैं।

— लोगन कैपल्डो

यही मैं कर रहा हूं, लेकिन मैं कुछ ऐसा करना चाहता हूं जो ओपन-सोर्स हो और ओपन-सोर्स प्रोजेक्ट्स द्वारा भी उपयोग किया जाता हो। मैं git और Mercurial दोनों पर विचार कर रहा हूं। मैं गित की ओर झुक गया हूं क्योंकि ऐसा लगता है कि अधिक गति है।

— लॉरेंस गोंसाल्वेस

आप खरोंच से गिट सीखना बेहतर होगा। Git द्वारा निर्धारित वर्कफ़्लो Perforce द्वारा निर्धारित वर्कफ़्लो के लिए बहुत अलग है। अनुवादित वर्कफ़्लोज़ अजीब होंगे, और सुविधाओं को समान करने की कोशिश आपकी समझ को भ्रमित करेगी। सौभाग्य से, Git समुदाय शुरुआती लोगों के लिए प्रलेखन का एक धन प्रदान करता है, जैसे। git-scm.com/book

— कर्नल पैनिक

@ColonelPanic मैं आपकी बात देख सकता हूं, लेकिन इस तरह के दस्तावेज़ीकरण के साथ समस्या यह है कि यह उन चीजों को बुनियादी चीजों की व्याख्या करने में समय बर्बाद करता है, जो प्रत्येक Perforce उपयोगकर्ता पहले से ही जानता होगा। इस तरह के प्रलेखन को पढ़ना एक अन्य प्रोग्रामिंग भाषा पर एक ट्यूटोरियल को पढ़ने की कोशिश करने के लिए उतना ही कष्टप्रद है जितना कि एक चर को व्याख्यायित करने वाला अध्याय।

— लॉरेंस गोंसाल्वेस

@ColonelPanic ने कहा कि, मैंने कुछ अन्य git डॉक्यूमेंट को पढ़ा है, जिसमें Git फ्रॉम द बॉटम अप और Git फॉर कंप्यूटर साइंटिस्ट शामिल हैं जो वास्तव में काफी उपयोगी थे। मैं अब कुछ वर्षों के लिए Git का उपयोग कर रहा हूं (ध्यान दें कि जब यह प्रश्न मूल रूप से पूछा गया था), और मुझे लगता है कि git सीखने में मुख्य समस्याएं दस्तावेज़ीकरण की कमी नहीं हैं, लेकिन खराब नामकरण, आंतरिक असंगति, बुरी तरह से अतिभारित आदेश और कुछ निश्चित हैं अधूरे हिस्से जो वास्तविक उपयोग के लिए तैयार नहीं हैं। काश कोई ऐसा होता जो किसी की भी सफाई कर देता, लेकिन यह सब उन पर गुस्सा करता।

— लॉरेंस गोंसाल्वेस

Answer 1

मैंने बहुत अधिक उपयोग नहीं किया है इसलिए यह ठीक 1: 1 अनुवाद नहीं हो सकता है। फिर git और मर्क्यूरियल जैसे डिस्ट्रीब्यूटेड सोर्स कंट्रोल सिस्टम का वैसे भी एक अलग वर्कफ़्लो होता है इसलिए वास्तव में ऐसा नहीं होता (और वहाँ नहीं होना चाहिए) 1 - 1 अनुवाद। वैसे भी, यहाँ जाता है:

• कई लंबित चेंजेलिस्ट बनाएं -> इसके बजाय शाखाओं का उपयोग करें। Git में शाखाएँ हल्की और तेज होती हैं, बनाने में एक सेकंड से भी कम समय लगता है और आमतौर पर विलय होने में दो सेकंड से भी कम समय लगता है। अक्सर ब्रांचिंग और रिबेस से न डरें।

  git branch new-branch-name
  git checkout new-branch-name
  

  या यह सब एक पंक्ति में करें:

  git checkout -b new-branch-name
  

• सभी लंबित चेंजेलिस्ट की सूची देखें -> चूंकि कई लंबित चेंजलगिस्ट के बराबर कई शाखाएं हैं, बस शाखाएं देखें:

  git branch
  

  यदि आप दूरस्थ शाखाओं को भी देखना चाहते हैं:

  git branch -a
  

  एक सफल मर्ज के बाद तुरंत एक शाखा को हटाने के लिए अच्छा अभ्यास माना जाता है ताकि आपको इस बात का ध्यान न रखना पड़े कि किस शाखा को विलय करने के लिए लंबित है और जिसे पहले ही विलय कर दिया गया है।

• सभी परिवर्तित फ़ाइलों की सूची बनाएं -> एक विशिष्ट शाखा में लंबित "चेंजलगिस्ट" के लिए सूचकांक या कैश की अवधारणा है। एक परिवर्तन करने के लिए आपको पहले इस सूचकांक में फाइलें मिलानी चाहिए। यह आपको मैन्युअल रूप से चयन करने की अनुमति देता है कि फाइलों का कौन सा समूह एकल परिवर्तन का प्रतिनिधित्व करता है या अप्रासंगिक फाइलों की उपेक्षा करता है। इस इंडेक्स को देखने के लिए कि कौन सी फाइलें जोड़ी गई हैं, या नहीं।

  git status
  

• पेंडिंग चेंजलिस्ट का एक अंतर देखें -> इसके दो भाग हैं। कार्य निर्देशिका और सूचकांक के बीच अंतर देखने के लिए सबसे पहले:

  git diff
  

  लेकिन अगर आप इस बात को जानना चाहते हैं कि आप अभी और आखिरी कमिटमेंट के बीच क्या अंतर कर रहे हैं, तो आप वास्तव में वर्किंग डायरेक्टरी + इंडेक्स और हेड के बीच अंतर पूछ रहे हैं:

  git diff HEAD
  

• किसी दिए गए फ़ाइल के लिए, देखें कि किन चेंजलिस्टों ने प्रभावित किया है कि कौन सी लाइनें -> यह आसान है:

  git blame filename
  

  या इससे भी बेहतर, अगर आप एक खिड़की वाले माहौल में हैं:

  git gui blame filename
  

  Git gui फ़ाइल को पार्स करने में अधिक समय लेता है (यह C के बजाय tcl में लिखा गया था) लेकिन इसमें बहुत सारी नीट विशेषताएं हैं जिनमें कमिट आईडी पर क्लिक करके अतीत में "टाइम ट्रैवल" करने की क्षमता शामिल है। मैं केवल यह चाहता हूं कि वे भविष्य के लिए "टाइम ट्रेवल" करने के लिए एक सुविधा लागू करें ताकि मैं यह पता लगा सकूं कि किसी दिए गए बग को आखिरकार कैसे बनाया जाएगा; ;-)

• किसी दिए गए फ़ाइल के लिए, उन चेंजेलिस्ट्स के विवरणों की एक सूची देखें जो फ़ाइल को प्रभावित करते हैं -> यह भी आसान है:

  git log filename
  

  लेकिन git log इस से कहीं अधिक शक्तिशाली उपकरण है। वास्तव में मेरी व्यक्तिगत लिपियों में से अधिकांश गुल्लक ऑफ-द-गिट लॉग इन द रिपॉजिटरी को पढ़ने के लिए। मैन पेज पढ़ें।

• लंबित चेंजलीस्ट प्रस्तुत करें -> आसान भी:

  git commit
  

मेरे पिछले git वर्कफ़्लो को देखने के लिए पिछले प्रश्न का उत्तर देखें: Learning Git। यह जानने की जरूरत है कि क्या मैं सही रास्ते पर हूं

यदि आप मेरे द्वारा बताए गए वर्कफ़्लो का अनुसरण करते हैं, तो आपको गीक जैसे टूल बहुत अधिक मूल्यवान लगेंगे क्योंकि यह आपको परिवर्तनों के समूहों को स्पष्ट रूप से देखने की अनुमति देता है।

---

अतिरिक्त उत्तर:

गिट बहुत लचीला है और आपके द्वारा वर्णित कई तरीके हैं। याद रखने वाली बात यह है कि आप जिस भी फीचर पर काम कर रहे हैं, उसके लिए हमेशा एक नई ब्रांच शुरू करें। इसका मतलब यह है कि मास्टर शाखा को छुआ नहीं गया है ताकि आप बग फिक्स करने के लिए हमेशा उस पर वापस जा सकें। Git में काम करना लगभग हमेशा से शुरू होना चाहिए:

git checkout -b new-feature-a

अब आप फ़ाइल a.txt को संपादित कर सकते हैं। दूसरे फीचर पर समवर्ती रूप से काम करने के लिए:

git checkout master
git checkout -b new-feature-z

अब आप file z.txt को एडिट कर सकते हैं। A.txt पर वापस जाने के लिए:

git checkout new-feature-a

लेकिन रुकिए, नए-फीचर-जेड में परिवर्तन हैं और गिट आपको शाखाओं को स्विच नहीं करने देंगे। इस बिंदु पर आपके पास दो विकल्प हैं। पहला सबसे सरल है, वर्तमान शाखा में सभी परिवर्तन करें:

git add .
git commit
git checkout new-feature-a

यह वही है जो मैं सुझाऊँगा। लेकिन अगर आप वास्तव में कोड के लिए तैयार नहीं हैं, तो आप इसे अस्थायी रूप से रोक सकते हैं:

git stash

अब आप ब्रांच न्यू-फीचर-ए पर स्विच कर सकते हैं। उस कोड पर वापस जाने के लिए, जिस पर आप काम कर रहे थे बस स्टैश पॉप करें:

git checkout new-feature-z
git stash pop

जब सब किया जाता है तो सभी परिवर्तन वापस स्वामी में कर दिए जाते हैं:

git merge --no-ff new-feature-a
git merge --no-ff new-feature-z

क्योंकि मर्ज इतने त्वरित और आसान (आसान हैं क्योंकि संघर्ष इतने दुर्लभ और संघर्षपूर्ण संकल्प हैं, जब कोई भी होता है, बहुत कठिन नहीं होता है) हम सब कुछ के लिए गिट में शाखाओं का उपयोग करते हैं।

यहाँ git में शाखाओं के सामान्य उपयोग का एक और उदाहरण है जिसे आप अन्य स्रोत नियंत्रण टूल में नहीं देखते हैं (शायद व्यापारिक को छोड़कर):

अपने देव वातावरण को दर्शाने के लिए अपनी कॉन्फिग फाइलों को बदलते रहना चाहिए? फिर एक शाखा का उपयोग करें:

git checkout -b dev-config

अब अपने पसंदीदा संपादक में अपनी कॉन्फ़िगर फ़ाइलों को संपादित करें फिर परिवर्तन करें:

git add .
git commit

अब हर नई शाखा मास्टर के बजाय देव-विन्यास शाखा से शुरू हो सकती है:

git checkout dev-config
git checkout -b new-feature-branch

एक बार जब आप इंटरैक्टिव रिबास का उपयोग करके नई-सुविधा-शाखा से देव-विन्यास में संपादन हटा दें:

git rebase -i master

उन कमिटों को हटाएं जिन्हें आप नहीं चाहते हैं फिर सहेजें। अब आपके पास कस्टम कॉन्फ़िगरेशन संपादन के बिना एक साफ शाखा है। मास्टर में वापस आने का समय:

git checkout master
git merge --no-ff new-feature-branch
# because master have changed, it's a good idea to rebase dev-config:
git checkout dev-config
git rebase master

यह ध्यान दिया जाना चाहिए कि git rebase -iजब एक ही फ़ाइल में सभी परिवर्तन होते हैं, तब भी संपादन हटाने से काम चल जाता है। Git में परिवर्तन याद रहता है, न कि सामग्री दर्ज करें *।

* नोट: वास्तव में, तकनीकी रूप से पूरी तरह से सच नहीं है, लेकिन एक उपयोगकर्ता के रूप में यह ऐसा लगता है

---

अधिक अतिरिक्त उत्तर:

इसलिए, आपकी टिप्पणियों से ऐसा लगता है कि आप दो शाखाओं को एक साथ रखना चाहते हैं ताकि आप यह जांच सकें कि संयुक्त कोड कैसे काम करता है। खैर, यह शाखाओं की शक्ति और लचीलेपन को चित्रित करने का एक अच्छा तरीका है।

सबसे पहले, अपने वर्कफ़्लो पर सस्ते ब्रांचिंग और परिवर्तनीय इतिहास के निहितार्थ पर एक शब्द। जब मैं सीवीएस और एसवीएन का उपयोग कर रहा था तो मैं हमेशा थोड़ा सा अनिच्छुक था। ऐसा इसलिए है क्योंकि अस्थिर कोड को कम करना अनिवार्य रूप से अन्य लोगों के कामकाजी कोड को च ** में ले जाएगा। लेकिन git के साथ मैंने वह डर खो दिया। ऐसा इसलिए है क्योंकि अन्य लोगों में मेरे परिवर्तन तब तक नहीं होंगे जब तक कि मैं उन्हें मास्टर में विलय नहीं कर देता। इसलिए अब मैं अपने आप को अपने द्वारा लिखी गई प्रत्येक 5 पंक्तियों के लिए प्रतिबद्ध करता हूं। आपको सही दूरदर्शिता की आवश्यकता नहीं है। आपको बस अपनी मानसिकता बदलने की आवश्यकता है: प्रतिबद्ध-से-शाखा == ऐड-टू-चेंजसेट, मर्ज-टू-मास्टर == कमिट-चेंज।

इसलिए, उदाहरणों पर वापस जाएं। यहां बताया गया है कि मैं यह कैसे करूंगा। कहते हैं कि आपके पास एक शाखा है new-feature-zऔर आप इसका परीक्षण करना चाहते हैं new-feature-a। मैं इसका परीक्षण करने के लिए एक नई शाखा बनाऊंगा:

# assume we are currently in branch new-feature-z
# branch off this branch for testing
git checkout -b feature-z-and-feature-a
# now temporarily merge new-feature-a
git merge --no-ff new-feature-a

अब आप परीक्षण कर सकते हैं। यदि आपको सुविधा-ए के साथ फीचर-जेड कार्य करने के लिए कुछ संशोधित करने की आवश्यकता है, तो ऐसा करें। यदि ऐसा है तो आप संबंधित शाखा में परिवर्तनों को वापस मर्ज कर सकते हैं। git rebase -iमर्ज से अप्रासंगिक परिवर्तनों को हटाने के लिए उपयोग करें ।

वैकल्पिक रूप से, आप नई सुविधा-बिंदु को इंगित करने के लिए अस्थायी रूप से नए-फीचर-z के आधार को बदलने के लिए git rebase का भी उपयोग कर सकते हैं:

# assume we are currently in branch new-feature-z
git rebase new-feature-a

अब शाखा इतिहास को संशोधित किया गया है ताकि नया फीचर-जेड, मास्टर के बजाय नई-फीचर-आधारित हो जाएगा। अब आप परीक्षण कर सकते हैं। इस शाखा में किए गए कोई भी परिवर्तन शाखा नई-फीचर-जेड के होंगे। यदि आपको नई-सुविधा को संशोधित करने की आवश्यकता है-तो इसे वापस लाने के लिए और नए परिवर्तन प्राप्त करने के लिए रिबास:

git checkout new-feature-a
# edit code, add, commit etc..
git checkout new-feature-z
git rebase new-feature-a
# now new-feature-z will contain new changes from new-feature-a

जब आप पूरा कर लें, तो नए-फीचर-ए से परिवर्तन हटाने के लिए बस मास्टर को वापस रिबास करें:

# assume we are currently in branch new-feature-z
git rebase master

एक नई शाखा शुरू करने से डरो मत। एक भगोड़ा शाखा शुरू करने से डरो मत। शाखाओं को फेंकने से डरो मत। और चूंकि मर्ज == सबमिट करें और प्रतिबद्ध == ऐड-टू-चेंजसेट अक्सर कमिट करने से डरते नहीं हैं। याद रखें, कमिट एक डेवलपर का अंतिम पूर्ववत उपकरण है।

ओह, और एक और बात, गिट हटाई गई शाखाओं में अभी भी आपके भंडार में मौजूद हैं। इसलिए यदि आपने गलती से कुछ नष्ट कर दिया है जो आपको बाद में पता चलता है कि आखिरकार आप इतिहास को खोजकर उसे हमेशा वापस पा सकते हैं। इसलिए शाखाओं को फेंकने से डरो मत।

Comments

क्या प्रत्येक शाखा का अपना "सूचकांक" होता है, या क्या शाखाओं के बीच एक एकल सूचकांक साझा होता है? मेरा प्रयोग उत्तरार्द्ध का सुझाव देता प्रतीत होता है, लेकिन आप कहते हैं कि "एक विशिष्ट शाखा git में सूचकांक या कैश की अवधारणा है" जो पूर्व का सुझाव देता है।

— लॉरेंस गोंसाल्विस

यह एक अलग उपकरण है। आपको एक अलग वर्कफ़्लो चाहिए और उसके साथ एक अलग मानसिकता और आदत। कोई भी गिट आपके बताए तरीके से काम नहीं करता है। यह शाखाएं हैं और कुछ नहीं। लेकिन बहुत शक्तिशाली शाखा हेरफेर उपकरण हैं। मेरा सुझाव है कि आप अपने आप को एक नौसिखिया मानते हैं जो स्रोत नियंत्रण के बारे में कुछ नहीं जानते हैं और बुनियादी ट्यूटोरियल पढ़ते हैं। अपनी वर्तमान मानसिकता "खराब निवास" पर विचार करें कि आपको गिट-लैंड के खिलाफ फिर से शिक्षित होना होगा। क्षमा करें ..

— 21 मई को स्लीपबेटमैन

तो आप क्या करते हैं जब आप दो चीजें प्राप्त करते हैं जो आप समवर्ती (और एक ही स्थान पर करना चाहते हैं, तो आप एक दूसरे के खिलाफ असम्बद्ध परिवर्तनों का परीक्षण कर सकते हैं), लेकिन आप उन्हें अलग से करना चाहते हैं? इसके अलावा, आप एक प्रदर्शन करने से पहले एक प्रतिबद्ध संदेश को कैसे संपादित कर सकते हैं? मैं स्वीकार कर सकता हूँ कि वर्कफ़्लो अलग है, लेकिन आपने यह नहीं बताया है कि git-तुल्य वर्कफ़्लो क्या है। यह कहते हुए कि बुरी आदतें एक भयानक बात है जैसे एक बग को एक सुविधा के रूप में पारित करने की कोशिश करना।

— लॉरेंस गोंसाल्विस 21

पढ़ें मेरा अपडेटेड जवाब जब आप अनर्जित शाखाओं के बारे में सोच रहे होंगे, तब भी आप अनकहे परिवर्तनों के संदर्भ में सोच रहे होंगे।

— स्लीपबेटमैन

बहुत व्यापक जवाब। इसे किस बिंदु पर विकीफाई किया जाना चाहिए?

— टिम क्लेम्सन

Answer 2

मेरे पास वास्तविक चीट शीट का उत्पादन करने के लिए पर्याप्त पी 4 अनुभव नहीं है, लेकिन वापस गिरने के लिए कम से कम कुछ समानताएं हैं। एक पी 4 "बदलाव" एक "कमिट" है।

आपके स्थानीय कार्य स्थान में परिवर्तन के साथ "इंडेक्स" जुड़ जाता है git add, और इंडेक्स बाद में प्रतिबद्ध हो जाता है git commit। इसलिए इंडेक्स आपका लंबित चेंजलिस्ट है, सभी इरादों और उद्देश्यों के लिए।

आप परिवर्तनों के साथ git diffऔर git status, जहां git diffआमतौर पर कार्यक्षेत्र और सूचकांक के git diff --cachedबीच परिवर्तन दिखाते हैं , लेकिन सूचकांक और भंडार (= आपके लंबित चैनल) के बीच परिवर्तन दिखाता है।

अधिक जानकारी के लिए, मैं http://progit.org/book/ की सलाह देता हूं । चूँकि आप सामान्य रूप से संस्करण नियंत्रण जानते हैं, आप शायद इसे बहुत कम कर सकते हैं और git-specific जानकारी निकाल सकते हैं ...

Comments

मैं असहमत हूं कि "एक पी 4 बदलाव एक कमिट कमिट" है; वे सबसे समतुल्य समतुल्य हैं, सच है, लेकिन एक पी 4 बदलाव गेट कमिट के सेट के बहुत करीब है। एक पी 4 चेंजसेट एक विशेषता का प्रतिनिधित्व करता है, जबकि एक गिट शाखा एक विशेषता का प्रतिनिधित्व करती है।

— RJFalconer

@RJFalconer एर्म। एक "शाखा", पर्फेक्ट में भी एक शाखा है, नहीं? और एक "बदलाव" एक या एक से अधिक फ़ाइलों के परिवर्तनों का एक परमाणु संग्रह है, बहुत कमिट जैसा? यदि नहीं, तो आप क्या कहेंगे कि पी 4 कमिट के बराबर है?

— जैकब बोर्ग

मैं कहूंगा कि पी 4 का कोई समकक्ष नहीं है, केवल इसलिए कि परमाणु की डिग्री समान नहीं है; git में मैं किसी दिए गए फ़ाइल में कई बदलाव कर सकता हूं, फिर उन्हें अलग-अलग कमिट (git ऐड -p) में कर सकता हूं, इस प्रकार इतिहास में रीफैक्टरिंग / क्लीनअप को फीचर / बग फिक्स से अलग कर सकता हूं। अगर मैं पी 4 में ऐसा करता तो मुझे दोनों को अलग-अलग विकसित करना होता। फिर भी मेरे कमिट निरंतर नहीं हो सकते क्योंकि अन्य डेवलपर्स उनके बीच में जमा कर सकते हैं (जब तक कि मैं निजी शाखा न हो, जिसमें डिस्क पर बार-बार अव्यवस्थित दोहराव शामिल हो)।

— RJFalconer

अस्वीकरण: मैंने कुछ महीनों के लिए केवल पी 4 का उपयोग किया है और यह काफी संभव है कि इसकी कुछ विशेषता है जो इसे पूरा करती है कि मैं अभी तक नहीं आया हूं।

— RJFalconer

पी 4 चैंजिस्ट और पी 4 शाखाएं तार्किक रूप से गिट कमिट्स और गिट शाखाओं के समान हैं। p4 शेल्वे गिट स्टैश के बराबर है। जहां वे भिन्न होते हैं कार्यान्वयन में (यानी वितरित बनाम क्लाइंट-सर्वर) और उस अंतर के परिणामस्वरूप पी 4 चेक के बराबर होता है जिसमें कई चरणों और काफी समय शामिल होता है। ओवरहेड ऐसा है कि कई शाखाओं को आमतौर पर डिस्क चेक के बराबर करने के बजाय डिस्क पर स्थानीय रूप से संरक्षित किया जाता है। पी 4 अलमारियों को स्थानीय रेपो में सर्वर पर संग्रहीत किया जाता है।

— जोश हेत्ज़मैन

Answer 3

मैं आप की तरह "चैंजिस्ट" अवधारणा की कमी से पीड़ित हूं जो वास्तव में गिट शाखाओं के समान नहीं है।

मैं एक छोटी सी स्क्रिप्ट लिखूंगा जो उस चैंजिस्ट में फाइलों की सूची के साथ एक चैंजिस्ट फाइल बनाएगी।

एक और आदेश केवल git प्रतिबद्ध -a @ change_list_contents.txt और फिर "जीएसटी प्रतिबद्ध" कहकर एक निश्चित चेंजलिस्ट प्रस्तुत करने के लिए

आशा है कि मदद करता है, एलियास

Comments

हां, मैंने वास्तव में ऐसा कुछ करने पर विचार किया है, हालांकि उस समय मैंने यह प्रश्न पूछा था कि मैं नया था और इसलिए मैं "मूल" समाधान जानना चाहता था। अब मुझे लगता है कि मुझे याद आती है मुख्य बात यह है कि वास्तव में प्रतिबद्ध किए बिना एक प्रतिबद्ध संदेश पर काम करने की क्षमता है। इस प्रकार "लंबित प्रतिबद्ध संदेश" को रखने के लिए एक फ़ाइल होने से हल किया जा सकता है, और शायद कुछ जादू एक प्रतिबद्ध संदेश लिखते समय इसे स्वचालित रूप से पढ़ने के लिए।

— लॉरेंस गोंसाल्वेस

@ लॉरेंसगॉन्स्लेव्स, मेरे द्वारा उपयोग किए जाने वाले वर्कफ़्लो का उपयोग अपूर्ण प्रतिबद्ध संदेश (या यहां तक ​​कि "WIP") करने के लिए है जब मैं काम पर ध्यान केंद्रित कर रहा हूं, तो बाद में मेरे विद्रोह के दौरान फिर संशोधन करें। जैसा कि कमिट विशुद्ध रूप से स्थानीय होते हैं, उन्हें तब तक अंतिम होने की आवश्यकता नहीं होती है जब तक आप अपनी शाखा को उपलब्ध नहीं कराते हैं (अपने रिमोट या समान के लिए इसे धक्का देकर)।

— RJFalconer

Answer 4

Git में अधिक हल्का विकल्प है जो आपके वर्कफ़्लो का हिस्सा बन सकता है; गेट स्टेजिंग क्षेत्र का उपयोग करना।

मैं अक्सर सिर्फ बदलाव करता हूं, फिर कई कमिट जमा करता हूं (जैसे डिबग स्टेटमेंट, रिफलेक्टर, वास्तव में बग फिक्स करना)। अपने पेरिफेरल चेंजलिस्ट्स को स्थापित करने के बजाय, फिर बदलाव करें, फिर सबमिट करें, आप बस अपने बदलाव कर सकते हैं फिर उन्हें कैसे सबमिट करें (वैकल्पिक रूप से गिट स्टेजिंग क्षेत्र का उपयोग करके)।

आप कमांड लाइन से विशेष फाइल के साथ कर सकते हैं:

git commit a.txt
git commit z.txt

या पहले फ़ाइलों को स्पष्ट रूप से मंचित करना:

git add a.txt
git commit
git add z.txt
git commit

git gui आपको स्टेजिंग एरिया में कमिट बनाने के लिए फाइल्स के भीतर से लाइनों या हॉक का चयन करने देगा। यह बहुत उपयोगी है यदि आपके पास एक फ़ाइल में परिवर्तन है जो आप अलग-अलग तरीकों से करना चाहते हैं। Git से perforce में स्थानांतरित होने और यह एक ऐसी चीज़ है जो मुझे वास्तव में याद आती है।

इस वर्कफ़्लो के साथ ध्यान में रखने के लिए एक छोटा सा चेतावनी है। यदि आप किसी फ़ाइल में A और B में परिवर्तन करते हैं, तो फ़ाइल का परीक्षण करें, फिर A करें, फिर आपने उस कमिट (B के स्वतंत्र रूप से) का परीक्षण नहीं किया है।

Comments

यह निश्चित रूप से सही है कि git आपको perforce (यानी: लाइनों और हंक) की तुलना में महीन दाने वाले काम करने देता है। मैं (अभी भी) याद आती है perforce से यह याद रखने की क्षमता है कि मैं वर्तमान में क्या काम कर रहा हूं, इसके लिए परिवर्तन विवरण (उर्फ कमिट मैसेज) का ध्यान रखें। उदाहरण के लिए, जब मैं बग को ठीक करने जा रहा हूं # 12345 मैं एक चेंजलिस्ट को यह कहकर क्रिएट करूंगा कि मैं ऐसा कर रहा था (लेकिन उर्फ ​​कमिट इट सबमिट नहीं करता)। फिर जैसा कि मैंने इस पर काम किया था, मैं जो कुछ भी किया था, उसे इंगित करने के लिए परिवर्तन विवरण को अपडेट करूंगा। अंत में, जब मैं कर रहा हूँ, तो मैं चैंज करने वाला हूँ।

— लॉरेंस गोन्साल्वेस

Git में ऐसा लगता है कि लगभग बराबर उन छोटे (अक्सर गैर-काम कर रहे) बिट्स को एक देव शाखा में करने के लिए है, और फिर एक बार परिवर्तनों को मर्ज करने के लिए सब कुछ ठीक है। यह अभी भी मुझे बहुत अधिक थकाऊ और भद्दा लगता है। इसके अलावा, मैं अभी भी वास्तव में कोड के विचार के लिए इस्तेमाल नहीं किया है जो संकलन भी नहीं करता है।

— लॉरेंस गोन्साल्व्स

@ लॉरेंसगॉन्सलव्स उत्सुक अगर आपको इस बीच इसकी आदत हो गई। मैं Git से Perforce में आ रहा हूं और मुझे याद है कि मैं हर 15 मिनट में कमिटमेंट कर सकता हूं, फिर जब मैं तैयार होऊंगा तो धक्का दूंगा।

— डेमियन

Answer 5

यह विशेष रूप से आपके प्रश्न का उत्तर नहीं देता है, लेकिन मुझे नहीं पता कि क्या आप जानते हैं कि एक 2 उपयोगकर्ता, 5 कार्यबल का कार्यक्षेत्र संस्करण perforce वेबसाइट से डाउनलोड और उपयोग करने के लिए स्वतंत्र है ।

इस तरह से आप अपनी व्यक्तिगत परियोजनाओं के लिए घर पर पर्फेक्ट का उपयोग कर सकते हैं। एक झुंझलाहट 5 कार्यक्षेत्र है, जो थोड़ा सीमित हो सकता है, लेकिन घर के उपयोग के लिए उपलब्ध लागू करने के लिए इसकी बहुत अविश्वसनीय है।

Comments

यही मैं कर रहा हूं, लेकिन मैं कुछ ऐसा करना चाहता हूं जो ओपन-सोर्स हो और ओपन-सोर्स प्रोजेक्ट्स द्वारा भी उपयोग किया जाता हो।

— लॉरेंस गोंसाल्वेस

Answer 6

Perforce और git दोनों का बड़े पैमाने पर उपयोग करने के बाद, Git के साथ Perforce चैंजिस्ट के पास कहीं भी पहुंचने के लिए केवल एक ही रास्ता है।

समझने वाली पहली बात यह है कि इस कार्यक्षमता को सही ढंग से इस तरह से लागू करने के लिए कि यह एक पूर्ण कलुग नहीं है, जैसे कि इसे शाखाओं में बदलने की कोशिश करना, निम्नलिखित परिवर्तन की आवश्यकता होगी: git को एक एकल शाखा के लिए कई स्टेजिंग क्षेत्रों की आवश्यकता होगी ।

पेरफोर्स चेंजेलिस्ट एक वर्कफ़्लो की अनुमति देते हैं जिसमें बस गिट के बराबर नहीं होता है। निम्नलिखित वर्कफ़्लो पर विचार करें:

Check out a branch
Modify file A and add it to changelist 1
Modify file B and add it to changelist 2

आप इस शाखाओं का उपयोग कर Git में आप दो शाखाएं, जिनमें से एक फ़ाइल में परिवर्तन के साथ हवा जाएगा करने की कोशिश करते हैं A, अन्य फ़ाइल में परिवर्तन है B, लेकिन कोई जगह है जहाँ आप दोनों फ़ाइलों में परिवर्तन देख सकते हैं Aऔर Bपर उसी समय।

निकटतम सन्निकटन मैं देख सकता हूँ उपयोग करने के लिए है git add . -pऔर फिर 'a'और 'd'चयन या पूरे फ़ाइलों को अस्वीकार करने के उप आदेशों। हालाँकि यह बिल्कुल समान नहीं है, और यहाँ अंतर दो प्रणालियों के सामान्य तौर-तरीकों में बुनियादी असमानता से उपजा है।

Git (और तोड़फोड़, इस चर्चा के लिए यह मायने नहीं रखता है) किसी फ़ाइल को समय से पहले किसी को बताए बिना बदलने की अनुमति देता है। आप बस एक फ़ाइल को बदलते हैं, और फिर जब आप परिवर्तन करते हैं तो इसे सभी को छाँटने देते हैं। बदलावों की अनुमति देने से पहले Perforce को आपको सक्रिय रूप से एक फ़ाइल की जांच करने की आवश्यकता होती है, और यह इस कारण से है कि चेंजेलिस्टों का अस्तित्व है। संक्षेप में, Perforce को इसे बदलने से पहले आपको एक फ़ाइल को अनुक्रमणिका में जोड़ना होगा। इसलिए पेरफोर्स में कई चेंजलगिस्ट की आवश्यकता है, और यह भी कारण है कि git का कोई समकक्ष नहीं है। यह बस उन्हें जरूरत नहीं है

Answer 7

Git 2.27 (Q2 2020) के साथ, " git p4" चार नए हुक सीखे और " --no-verify" विकल्प उन्हें बायपास करने के लिए (और मौजूदा " p4-pre-submit" हुक)।

देखें 1ec4a0a प्रतिबद्ध , 38ecf75 प्रतिबद्ध , प्रतिबद्ध cd1e0dc (14 फरवरी 2020), और 4935c45 प्रतिबद्ध , aa8b766 प्रतिबद्ध , 9f59ca4 प्रतिबद्ध , प्रतिबद्ध 6b602a2 द्वारा (11 फ़र, 2020) बेन कीन ( seraphire) ।
^{(द्वारा विलय Junio सी Hamano - gitster- में प्रतिबद्ध 5f2ec21 , 22 अप्रैल 2020)}

git-p4: p4 सबमिट हुक जोड़ें

^{साइन-ऑफ-बाय: बेन कीने}

Git कमांड " commit" कई हुक का समर्थन करता है जो कमिट कमांड के व्यवहार को बदलने का समर्थन करता है।

git-p4.pyकार्यक्रम केवल एक मौजूदा हुक है, " p4-pre-submit"।

यह आदेश प्रक्रिया में जल्दी होता है।

P4 चैंजिस्ट पाठ को प्रोग्रामेटिक रूप से संशोधित करने के लिए प्रक्रिया प्रवाह में कोई हुक नहीं हैं।

git-p4.pyसबमिट विकल्प पर 3 नए हुक जोड़ता है ।

नए हुक हैं:

• p4-prepare-changelist- चैंजिस्ट फाइल बनने के बाद इस हुक को एक्सेक्यूट करें। विकल्प सेट
  होने पर भी हुक निष्पादित किया जाएगा --prepare-p4-only।
  यह हुक --no-verifyमौजूदा व्यवहार को ध्यान में रखते हुए विकल्प की अनदेखी करता है git commit।

• p4-changelist- उपयोगकर्ता द्वारा चैंजिस्ट को संपादित करने के बाद इस हुक को निष्पादित करें।
  यदि उपयोगकर्ता ने --prepare-p4-onlyविकल्प चुना है तो इस हुक को निष्पादित न करें ।
  यह हुक सम्मान करेगा --no-verify, निम्नलिखित सम्मेलनों का git commit।

• p4-post-changelist- P4 सबमिशन प्रक्रिया सफलतापूर्वक पूरी होने के बाद इस हुक को निष्पादित करें।
  यह हुक कोई पैरामीटर नहीं लेता है और --no-verifyविकल्प की परवाह किए बिना निष्पादित किया जाता है।

यह वापसी मूल्य की जाँच नहीं की जाएगी।

नई हुक करने के लिए कॉल: p4-prepare-changelist, p4-changelist, और p4-post-changelistसब कोशिश अंत में ब्लॉक के अंदर बुलाया जाना चाहिए।

---

Git 2.28 (Q3 2020) से पहले, " --prepare-p4-only" विकल्प को एक बदलाव को दोहराने के बाद बंद करने वाला है, लेकिन गलती से रखा गया है?)

बेन केने ( ) द्वारा प्रतिबद्ध 2dfdd70 (12 मई 2020) देखें । ^{( जूनियो सी हमानो द्वारा विलय - - 7a8fec9 में प्रतिबद्ध , 02 जून 2020)}seraphire
gitster

git-p4.py: --prepare-p4-onlyकई कमिट्स के साथ त्रुटि को ठीक करें

^{साइन-ऑफ-बाय: बेन कीने}

विकल्प के git p4 submitसाथ उपयोग करते --prepare-p4-onlyसमय, प्रोग्राम को एक एकल पी 4 चैंजिस्ट तैयार करना चाहिए और उपयोगकर्ता को सूचित करना चाहिए कि अधिक हिट लंबित हैं और फिर प्रसंस्करण बंद कर दें।

p4-changelistहुक फीचर द्वारा एक बग पेश किया गया है , जिसके कारण कार्यक्रम एक ही समय में सभी लंबित चेंजलगिस्ट की कोशिश और प्रक्रिया जारी रखता है।

फ़ंक्शन लागू होता applyCommitहै Trueजब कमिट लागू होता है और कार्यक्रम जारी रहना चाहिए।
हालाँकि, जब वैकल्पिक ध्वज --prepare-p4-onlyसेट किया जाता है, तो पहले अनुप्रयोग के बाद प्रोग्राम बंद हो जाना चाहिए।

--prepare-p4-onlyसफलतापूर्वक applyCommitविधि पूर्ण करने के बाद ध्वज की जाँच करने के लिए P4Submit के लिए रन विधि में तर्क बदलें ।

यदि 1 से अधिक प्रतिबद्ध पी 4 के लिए लंबित है, तो विधि पी 4 चेंजलिस्ट को ठीक से तैयार करेगी, हालांकि यह अभी भी 1 के एक्ज़िटकोड के साथ आवेदन से बाहर निकल जाएगा।

वर्तमान प्रलेखन परिभाषित नहीं करता है क्या बाहर निकलने के कोड को इस हालत में होना चाहिए।