oh the Irony (קצת ארוך

[bismark1]

תראה

1. לירות לעצמך ברגל אפשר עם כל מערכת. אני לא בטוח שהבנתי עד הסוף את הדוגמא שלך - נו אז יש קונפליקט, מה הבעיה? מישהו עשה push, נתקלת בקונפליקט לוקאלית כשעשית pull, אתה מתקן, דוחף בחזרה וכולם שמחים. מה שאני זוכר מ-SVN זה איך כולם מפחדים לעשות קומיט כי לך תדע מה יקרה לריפוסיטורי ומה תשבור אז כולם צוברים המון שינויים לוקאליים ובסוף יש מסכן שעושה merge אחרון וצריך לאכול את כל הקונפליקטים של כולם. לי נשמע כאילו אתם עובדים עם git בדיוק כמו שעבדתם עם SVN וזה לא רעיון טוב.

2. לגבי כלים - בתור משתמש git פשוט אני די מרוצה מ-gitkraken, הוא crossplatform ומאפשר לבנות workflow פשוט בלי להתעסק עם מיליון פקודות ב-command line

3. לצוות קטן עם מוד עבודה די מוגדר הייתי הולך על hg במקום על git - הוא גם מבוזר ככה שאתה מקבל הרבה מאותם ייתרונות של git והרבה יותר פשוט ככה שהחיים יותר קלים למי ש git זה אוברקיל בשבילו (כשהייתי צריך לבחור כלי לצוות שלי - 3 מפתחים - לפני שלוש שנים העדפתי את hg על פני git, למרות מקדם ההייפ ואני מברך על ההחלטה הזו עד היום).

 

[user32]

כי גיט לא מסוגל לקבל את הרעיון של להתחרט

עשיתי שינוי, לא רוצה לעשות merge. במקום זה מחקתי את הקובץ מהדיסק כי ככה התחשק לי ועכשיו אני רוצה שגיט ידרוס את הקובץ (שכבר לא קיים יותר) בעותק שלו. נסה לעשות את זה.

והבנת נכון: אנחנו משתמשים בגיט בתור SVN אבל זה בעיקר כי תהליך העבודה שלנו לא מתאים לrepository מבוזר כי אין לנו ביזור ועבודה מקבילית על דברים נפרדים.

לא שמעתי על hg. מכיר את מרקוריאל. נשמע מעניין במידה ויש לזה קהילה מספיק גדולה כדי למצוא מענה לבעיות ברמה של חיפוש בגוגל.

 

[bismark1]

hg==mercurial

hg זה קיצור (הסימון של כספית בטבלה המחזורית).

 

[user32]

תודה לך וליבגניי. אנסה

 

[יבגניי34]

git merge is transactional, like most git operatios

You can
git merge --abort

Or cherry-pick instead of merge

git merges well when careful devs are committed to the art of small commits.

If you have lots of conflicts to resolve on each merge, the #1 fix for you is to educate your dev team!

 

[TakeCtrl]

yea , it don't work , in our case..

יש לנו מפתחת שעושה Commit על איזה 100 קבצים בבת אחת, (כן בשביל feature אחד) אחרת זה לא מתקמפל בjenkins , אני יודע אפשר לעשות mock וכו'. אבל אנחנו לא עובדים ככה. וזו אחת הסיבות שאני חושב שgit לא מתאים כל כך עבורינו..

 

[BravoMan]

מה הבעיה לעשות git checkout לאותו קובץ שמחקת?

בין אם מחקת, ובין אם הקובץ עדיין שם ואתה רוצה לדרוס אותו, לעשות git checkout filename יעשה בדיוק את מה שביקשת.

 

[יבגניי34]

דוגמה יפה ל general ux wtfness המפורסם של גיט

git rm your.file

> enter the git command to get your.file back without googling in 15 seconds. go!

 

[user32]

כי זה אף פעם לא עובד

אני מבין שזה לא עובד כי אני לא מפעיל את זה נכון. אבל לשם הניסוי:

מחקתי קובץ עם rm (רגיל, לא של גיט).

עשיתי git checkout
והוא אכן כתב לי משהו כמו:
D folder/myfile.txt
שזה כנראה אומר שהוא זיהה שהוא מחוק. עד כאן יפה.

עשיתי
git checkout myfile.txt וקיבלתי:
error: pathspec 'myfile.txt' did not match any file(s) known to git

ניסיתי אותו דבר עם קופי פייסט של השורה מgit checkout (עם הpath) וקיבלתי אותה שגיאה. עכשיו זה כמובן לחפש בגוגל.

עכשיו אני יכול לנחש שכדי שזה יעבוד אני צריך לעשות git add או אפילו commit. אלה הדברים הקטנים שמשגעים את המשתמש הקטן.
כיוון שכן באתי מחברות גדולות ואפילו ענקיות אני בהחלט מבין את הצורך בגיט אז אני לא מאלה שאומרים שזה מוצר דפוק וכו'.

אגב, חיפוש בגוגל אומר להשתמש בgit fetch

אז בשביל למשוך קבצים יש:
pull, checkout, fetch, clone, remote add

ובדרך חזרה יש את הבלבול שלא מספיק שם הbranch יש גם את הorigin שבהרבה מקומות זה נגמר במייל תחנונים של המתכנת לDevOps ישלח לו מה הוא צריך לרשום כדי שזה יעשה push.

וכמות האנשים שלא יודעים את ההבדל בין remote add לבין clone למשל. אני רואה המון שמשתמשים בגיט בלי לגמרי להבין מה הם עושים. אני לפחות משתדל להיות מודע לעצמי...

 

[BravoMan]

אתה לא מקשיב, ואז מתלונן שזה לא עובד...

לא אמרתי לך לעשות checkout פעמיים, ופעם ראשונה בלי פרמטרים.

החלטת לסבך את עצמך סתם.
https://git-scm.com/docs/git-checkout

checkout בלי פרמטרים מתנהג שונה.

אם היית עושה ישר רק את הפעולה השנייה - checkout עם שם הקובץ, היית מקבל את התוצאה הרצויה.

אבל, נניח שכבר עשית סתם checkout וקלקלת קצת - לא נוראה!
פשוט תעשה:
git checkout -- myfile.txt

כדי להבהיר ל-git שאתה רוצה לשחזר קובץ.
כן - שים לב למינוס הכפול. זה מבהיר שמדובר בשם קובץ ולא בשם של branch חדש שאתה רוצה ליצור.

למעשה, כדאי להוסיף את המינוס הכפול תמיד, ליתר בטחון ואולי זו טעות שלי שהשמטתי את הנקודה הזו בפעם הראשונה שלם פשטות.

(נבדק על git 2.7.4 אבל זה לא אמור לשנות)

 

[user32]

אז זהו, אתה מבין

שאם מחקתי 2-3 קבצים אני צריך לזכור בעל פה ובמדוייק את השם של כל אחד מהם (שכבר לא קיימים יותר, כן?) כדי להביא אותם.

ניסיתי הcheckout עם ה-- ועדיין מחזיר לי אותה הודעת שגיאה ואני ב2.9.3 מסתבר.

אבל כדי שלא תגיד שאני לא מקשיב להוראות: יש מצב שעשיתי add באחד הנסיונות אבל commit בוודאות לא עשיתי. תן לי לנחש: זה לגמרי משנה את המצב, נכון?

כשאני עושה git status הוא מראה שהוא deleted.

 

[BravoMan]

תראה, אומנם נשמעתי מקודם כאילו באתי לריב

אבל זה לא המצב.
אני באמת רוצה להבין מה הבעיה, ולראות אם אני מכיר פתרון טוב.

קודם כל, הבנתי למה קיבלת את השגיאה.

זה לא היה קשור ל-checkout הנוסף, פשוט פספסתי משהו קטן בהודעה שלך:
git אצלך רואה את הקובץ בתוך ספריה, ככה הוא רשם אותו כשהרצת checkout בלי פרמטרים.

אז, אם אתה רוצה להחזיר אותו, אתה צריך לתת את הנתיב המלא מבחינת git, במקרה שלך:
folder/myfile.txt

דבר שני, אם עשית add זה אכן משנה:
אומנם תוכל עדיין למשוך את הקובץ עם אותה פקודה בדיוק, אבל תקבל גרסה שלו עם השינויים שהיו בו לפני ה-add כי ברירת מחדל הוא ישחזר מה-staging.

אם אתה רוצה גרסה ללא שינויים, תגיד לו לקחת מ-HEAD:
git checkout HEAD -- folder/myfile.txt

ואם אתה לא זוכר אם עשית add או לא, אז תמיד תבקש מה-HEAD ליתר בטחון, במקום לשבור את הראש.

ולבסוף:
שאלת מה קורה אם עשית את זה לכמה קבצים.
אז תרשה לי לשאול: איך היית מתמודד עם המצב ב-svn?

האם אתה מבקש לדרוס את כל הספרייה מתוך הנחה שאין שם שינויים שאתה כן רוצה לשמור?

או שאתה רוצה שהכלי ייצר לך רשימה של חוסרים אוטומטית וימשוך אותם, תוך שימור שינויים בקבצים אחרים שתרם נכנסו ב-commit?

אין לי בעיה שאתה רוצה להקשות על המטלה המקורית, רק בוא תסביר מה בדיוק אתה מבקש לעשות.

 

[user32]

אני דווקא מעריך את הסבלנות שלך ולדיון הזה יש פואנטה

הפואנטה מבחינתי היא להראות את החולשות של גיט ומבחינתך אולי להפך.

ניסיתי את מה שאמרת גם מקודם. אני לא עד כדי כך פעור וניסיתי עם ובלי הpath. העתקתי בדיוק את מה שgit checkout כותב לי והוא עדיין לא מכיר את הקובץ. ניסיתי גם עם ובלי HEAD. הוא פשוט לא יודע על מה אני מדבר.
הדבר היחיד שעזר היה לתת לו path אבסלוטי (לקובץ שבכלל מחוק). משהו כמו
git checkout -- /home/me/code/folder/myfile.txt
זה עבד...

למה? לאלוהי הגיט הפתרונים. אבל הנה דוגמא לפעולה פשוטה יחסית ותראה כמה מסובך היה להביא את הקובץ הזה.
כמובן שזו אשמתי כי מי האידיוט שמוחק קובץ אבל לפעמים צריך למחוק קובץ ואחר כך מתחרטים וסורס קונטרולים מסורתיים מאפשרים לך להתחרט על המחיקה ולהביא אותו מחדש או להעלות את השינוי שלך ושיימחק גם בשרת.
לא רוצה לחשוב בכלל על הזזת קבצים וספריות כמו במקרה של rename לpackages ואם מישהו עשה שינוי באחד הקבצים זה בכלל פסיכי. גם SVN לא היה טוב בזה במיוחד וזה מצב שאין לו מענה מושלם בהגדרה אבל לתחושתי רק מומחה גיט יידע לצאת ממצב כזה.

עכשיו צחוק הגורל שאני לא זוכר איך SVN מתנהג במקרה הזה כי עברו שנתיים מאז שעבדתי איתו. ממה שזכור לי הוא היה הרבה פחות טרנזקציוני ולכן היה מוריד את הקבצים שבהם אין קונפליקט, אולי היה איזה force שהיה צריך להוסיף לו לפקודה או משהו כזה. במצב הזה של מחיקת קבצים הוא פשוט היה מביא את הקבצים החסרים בלי להטריד אותך.

 

[BravoMan]

כל אחד מוחק קבצים לפעמים...

לי זה קרה כמה פעמים עוד בתקופה שהייתי במקום בלי SC בכלל, ופעם אחת היה צריך ללכת כל הדרך לקלטת גיבוי (כן, ממש קלטת, אם כי לא כזו של טייפ רגיל

) כדי להביא גרסה של הקובץ החסר.
&nbsp
טעויות קורות, ואני לא טוען שהדרישה שלך מוגזמת.
&nbsp
אבל לפני שכתבתי לך, בדקתי את כל הסיפור על repo קטן עם 2 קבצים שהקמתי במיוחד לזה.
והכל עבד חלק. בלי path אבסולוטי כל הדרך ל-home שלי.
&nbsp
מעניין למה...
&nbsp
אני לא יודע מה אם בכלל הן הנקודות החזקות של git, אני רק יודע שלי הוא אף פעם לא עשה צרות, למרות, או אולי דווקא בגלל, שאני עושה בו את השימוש הכי פשוט שיש בלי לדעת יותר מידי על הפקודות המורכבות יותר.
&nbsp
מה הייתי עושה אם הייתי מגיע לריפוזיטורי מבולגן אם חוסרים?
כנראה יוצר עתק, עושה git reset --hard ואז דורס עם העותק שעשיתי (אולי בלי תתי ספריות של ה-git עצמו).
&nbsp
כל הקבצים המחוקים מן הסתם לא יידרסו, כל השאר כן.
&nbsp
לא בדיוק פתרון "לפי הספר", אבל לדעתי יביא לאותה תוצאה שתיארת עם svn.

 

[user32]

זה שימוש יותר תמים ממה שתיארת

מתכנת מתחיל בטעות עשה add וקומיט להרבה קבצים והכניס קובץ לוג לrepo. מובן שהוא לא אמור להיות שם אז הוא מחק אותו. זה הcase פחות או יותר. עכשיו תכפיל במקרים של קבצי קונפיגורציה של IDE, איזה קובץ טסט שבטעות יצרת, gitignore ועוד ועוד שבטעות מועלים, או חצי מועלים (רק add או רק commit וכו') ועכשיו לך נסה להפטר מהם. ובמקרה הגרוע שיש קונפליקטים אז בכלל זה סוף הדרך.

לתחושתי git מעולה לתרחיש שבמסגרתו נוצר: פיתוח פרוייקט בסדר גודל ובאופי של לינוקס קרנל. שם באמת לא יודע איך היו מסתדרים בלעדיו.
אבל שני אנשים שעובדים על כמה קבצים משותפים אוכלים יותר מדי קש עם זה לטעמי.

מה שכן, אני אף פעם לא אהיה חזק בגיט אם לא אקח פרוייקט במסגרתו אני יושב בצוות במקום מסודר. לא עשיתי את זה 4 שנים, אולי הגיע הזמן. גיט זה לא כמו שפת תוכנה או פריימוורק שאפשר ללמוד מדוגמאות קוד ועד שלא עובדים עם עוד אנשים, גרסאות, שחרורים, branches וכו' לא חושב שאפשר לדעת לעבוד איתו כמו שצריך. נראה אם יהיה לי כוח לזה

 

[BravoMan]

סורי, עדיין לא מבין.

אם רק עשית add, מחק staging וכל ה-add נעלם כלא היה.
&nbsp
אולי אני לא מכיר מספיק יכולות של svn ודומיו כי כמעת לא עבדתי איתם (התנסיתי בעצמי מקומית לפני הרבה זמן, מעולם לא בסביבה ארגונית מסודרת), אבל למיטב הבנתי, שם אם עשית commit למשהו שלא צריך, זו עדיין די חתונה קתולית.
&nbsp
ואין לך את שלב ה-add לפני שבו עוד תוכל להבין שאתה בדרך לאסון.
&nbsp
בעצם, כל cvs, נועד למנוע שינויי היסטוריה.
&nbsp
לפחות ב-git, בד"כ יש לך עוד עותק של repo איפשהו, שתרם הספקת ללכלך, אז יש דרכים לא דרכים לשחזר.
&nbsp
כאמור, מעולם לא עבדתי עם git בצוות, לא קטן ולא גדול.
לעבודות של מפתח אחד, הוא גם מעולם. הרבה יותר נוח מ-svn זה בטוח.
&nbsp
והזכרת לי עכשיו משהו:
לפני זמן מה נתקלתי במצב של repo עבור אפליקצייה לנייד שתפח למעל 700 מגה, רק ה-repo, לא הפרויקט עצמו.
&nbsp
ניסיתי להבין מה קרה, שכן מדובר באפליקציה קטנה למדי, שלא עברה הרבה שינויים גרפיים, ושינויים בקוד git דוחס טוב טוב.
&nbsp
מסתבר, שכמו שתיארת, הבחור שפתח את ה-repo לא ממש ידע להסתדר עם git, ועשה לשם commit של כל התוצרים הבינאריים, כולל קבצי ביניים של הקומפיילר.
&nbsp
(אם נדייק, הוא עבד דרך הפלאגין של ה-IDE, וזה לא ידע לייצר gitignore תקין)
&nbsp
מה הפלא שהדבר תפח.
&nbsp
בהתחלה חשבנו שזהו - נצטרך להחיות עם זה או לאבד את ההיסטוריה של הפרויקט, אבל אחרי חצי שעה של google מצאתי שבתהליך של 5 -6 שלבים, ניתן לאתר את הזבל הבינארי, ולמחוק אותו רטרואקטיבית מכל ההיסטוריה.
&nbsp
והפלא ופלא - הצלחתי להוריד את ה-repo לגודל שפוי בלי לאבד שום דבר חשוב.

 

[יבגניי34]

svn has no staging, and that's *awesome* ! hg is same

אני לא צריך staging area. זה סתם מפריע לי לעבוד. 95% מהמפתחים לא צריכים staging והיו מוותרים עליו בכיף אם רק היו יודעים שאפשר אחרת...

95% מה״בעיות״ בגיט מסתכמות ב״אנשים לא מבינים מה זה staging״

 

[BravoMan]

מה כ"כ נהדר בזה?

אני יודע שאין staging ב-svn, ולדעתי זה דווקא מקשה על שמירת ניקיון ה-repository.
&nbsp
אם אתה אומר שזה שם אותי ב-5% מכלל מפתחים - לבריאות!
staging נותן לי לראות מה אני הולך לעשות ל-repo שלי לפני שאני עושה זאת, ונותן לי הזדמנות להתחרט בקלות ובנוחות.
&nbsp
מה רע?

 

[ipv6]

אני לא בטוח שגם אני מבין

אבל, מפריע לך מצב שבו יש לך הרבה שינויים כשאת חלקם אתה רוצה ב-commit שלך ואת חלקם לא (נניח קבצים שהרסת)?
אם זה המצב, זה בדיוק הנקודה שבה ה-staging של git מציל אותך ומאפשר לעשות commit שמכיל רק חלק מהשינויים שלך.

נסה את git cola. מאפשר לך להסתכל בצורה נוחה על ה-repo שלך וליצור commit-חלקי.
git status -s יציג לך את הקבצים שנגעת בהם ותראה בדיוק מה הרסת.
להחזיר חזרה אפשר או את כל ה-repo שלך עם git checkout או git reset (אם אחרי שהרסת חצי מה-repo עוד עשית לזה commit).

אם רב השינויים שלך הם רעים, הייתי עושה מהשינויים ה"טובים" commit מרוורט את ה-repo שלי לגרסה נקייה (נניח מתחיל branch חדש שיוצא מbranch תקין) ולוקח את הcommit התקין עם cherry-pick.

אני לא יודע אם זאת הדרך הכי יפה \ יעילה אבל זה יעבוד.

 

[choo]

מתכנת מתחיל צריך לעבור הדרכה על שטאנץ העבודה אצלכם

&nbsp
כדי שהשימוש בגיט יהיה יעיל ועם מעט מעצורים - צריך לבחור שטאנץ עבודה קבוע ולדבוק בו.
&nbsp
בסופו של דבר, כמות פקודות הגיט השונות שצריך לעבודה באופן קבוע - היא די נמוכה (בסביבות 15 פקודות, להערכתי).
&nbsp
כשיש לך שטאנץ, קל להראות למפתחיל מתחילים מהו שהטאנץ, ולאמר להם שיעבדו רק ככה, ואם אם צריכים מתישהו משהו אחר - שיתייעצו עם "מומחה הגיט" המקומי (זה שמכיר עוד 15 פקודות
&nbsp
תביא אליכם פעם אחת מישהו שעבד עם גיט בצורה רצינית במקום עבודה כלשהו ומבין איך זה עבד להם, שבו איתו כמה שעות שיעזור לכם לתכנן את השטאנץ המקומי שלכם, ייתן לכם קצת הדרכה על הדרכים לצאת מטעויות - ותחסוך לעצמך את כאב הראש שאתה נמצא בו כבר שנתיים, על פי דברייך.