oh the Irony
(קצת ארוך:)

selalerer

New member
יש דבר אחד נורא ב-git: התיעוד.

במקום להסביר לך את השימוש בכלי במובנים של מה אתה רוצה לעשות הוא מסביר לך מה הכלי עושה פנימית, אלגוריתמים ומתמטיקה. מגוחך.
&nbsp
מצד שני, google פתוח ותשובות לרוב ב-stack overflow דיי מסדרות אותך. עם הנסיון גם לומדים לסנן את התשובות של כל הנודניקים שמדברים באותה השפה של התיעוד ולהשתמש רק בפעולות פשוטות שעובדות.
&nbsp
באמת תמיד השתמשתי ב-command line ואישית אני מעדיף את זה. אני אף לא סומך על pluginים של IDE שלא יפשלו. גם ב-svn לא הייתי מתקין plugin ל-IDE ובד"כ משתמש ב-tortoise (שאני מניח שזה כמו ה-command line של Windows
) ולפעמים גם ב-command line.
&nbsp
דבר אחד שצריך להתרגל אליו זה באמת שאתה אדמיניסטרטור של רפוזיטורי לוקאלי והאינטראקציה שלך החוצה היא רק עם clone, pull ו-push.
&nbsp
בסה"כ אין תחרות למהירות של הכלי הזה וזה מאוד חשוב. כשמשהו לוקח לך הרבה זמן (למשל commit) אתה נמנע מלעשות אותו הרבה וכך גם מאבד את היתרונות שבו.
 

choo

Active member
יש למבנה התעוד סיבה טובה - הבנה של האינטרנלז תעזור לך להשתמש

&nbsp
כדי להגיע לשליטה בכלי, צריך להבין את הצורה הפנימית שבה הוא עובד. ה-man pages נועדו בדיוק לזה. הם לא מדריך למשתמש - הם רפרנס מלא. רוצה מדריך למשתמש? קרא מדריך למשתמש.
 

selalerer

New member
לא רוצה מדריך למשתמש, רוצה user friendly reference

ואת זה כרגע יש רק בעזרת חיפוש בגוגל שמוצאות בד"כ תשובות ב-SO.
&nbsp
כל פעם שאני צריך עזרה אני רוצה לדעת איך לעשות פעולה אחת פשוטה מוגדרת בשפה פשוטה שכל מתכנת יכול לבטא.
 

יבגניי34

New member
סליחה ידידי למה לא פשוט לאמר שלגיט יש api גרוע?

ה"וויכוח" הזה משול לדיון האם השמש זורחת במערב אם לאו.
לגיט יש api נוראי, לא קונסיסטנטי, שלא תוכנן לעולם המודרני. והתיעוד שלו - גרוע.

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

hg כן תוכנן לעולם המודרני, ולכן לכל צוות שאין לו סיבה מהותית לעבוד עם גיט, אני תמיד אמליץ לעבוד עם hg.
 

TakeCtrl

New member
מה שמצחיק זה כלי שנוצר לאחרונה לכן זה עוד יותר גרוע

שזה "לא תוכנן" לעולם המודרני ..
 

ipv6

Member
קישרת לשאלות ה&חדשות& ביותר ב3 הנושאים.

בהודעה הקודמת דיברת על הנפוצות.
ואשמח אם תסביר מה הראת בדיוק עם הלינקים וה-diffים שלך.
שהשאלות על Git הרבה יותר פשוט מהשאלות על HG\פיית'ון? זה לא ממש נראה ככה.
השאלות על HG ו-GIT יחסית דומות במורכבות.
אחת התשובות הכי נפוצות על HG היא מדריך מפורט למתחיל. לשיטתך, אם HG כל כך פשוטה, למה צריך הודעה כל ארוכה ב-SO שתסביר איך להשתשמש?

אני מסכים שאיתך שהתיעוד הוא רע אבל לא חושב שSO שכמות שאלות ב-SO זה מדד כלשהוא.
 

user32

Well-known member
מנהל
גיט זה כלי עזר. אמצעי, לא מטרה

שאני לא אשמע כמו המתכנת השטחי הזה שלא מתעמק בעבודה שלו, אבל עם כל הכבוד, גיט נועד לעזור לי לנהל גרסאות ולסנכרן בין המפתחים. אני לא רוצה ללמוד את הinternals שלו כמו שאני לא לומד את הקוד של הIDE שאני משתמש בו, ולא את המימושים של npm, maven, ואפילו וירטואליזציה של מכונות אני יודע מאוד במעורפל איך זה עובד מאחורי הקלעים.

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

TakeCtrl

New member
git זה כלי מחורבן , נקודה...

הבנתי את זה עוד מהתיאור הראשוני שלו ולכן לא רציתי להכנס אליו ...
&nbsp
השימוש דומה לשימוש של אדמינים של linux (ורואים מאיפה זה מגיע) כיום git מונע מאיתנו לשחרר גרסה בגלל שקובץ אחד יש בupper lower case,ולא חשוב כמה תתאמץ הקובץ הזה נשאר, וrebase נופל, ועכשיו אתה צריך לחפור ולהבין איך את עושה rebase בלי commit אחד (שבכלל מוחק לך קובץ) ועוד יותר גרוע שאתה מתקשה להסביר לאחרים מה הבעיה.
 

יבגניי34

New member
לא. זה כלי מעולה שאף אחד בחברה שלך לא טרח ללמוד ולחשוב עליו

לדוגמה, בעבודה משותפת על fs שיש להן גישה שונה ל case sensitivity, אפשר לשקול לשים core.ignorecase=true ב gitattributes.

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

TakeCtrl

New member
לא, זה כלי עבודה מחורבן... בשבילנו
(פשרה)..

מה נראה לך שאין בעיות של case senstive בsvn? שם לפחות קל לפתור... ב.git יש לי commit מחורבן שתקוע לי כמו עצם בגרון שאני צריך לחפור בSO כדי להבין איך אני מדלג מעליו... עם Reset או rebase אינטרקטיבי... לפחות עכשיו שלב אחד השולם בmerge.. עכשיו הcommit הנ"ל תקוע בbranch המקומי.. וצריך לדגל מעליו כדי להעביר אותו לbranch ..
&nbsp
וכן, אתה צודק בקשר לחשיבה מראש..
&nbsp
ותודה שהזכרת לי אני צריך לשנות את ignore case חזרה לברירת מחדל שלו בתחנה שעבדתי עליה קודם
 

ipv6

Member
אתה צודק

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

אולי לא תבין את כל מה שקורה מתחת לרגליים אבל זה לא באמת נדרש..
 

user32

Well-known member
מנהל
מסכים

התחלתי כבר להתלבש על הנושא יותר ברצינות.

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

TakeCtrl

New member
*בדיוק* מה שקורה אצלי עכשיו..


אתמול טחנתי עם המתכנתת על למה git מסרב לעשות rebase בגלל אותו קובץ דפוק. (עד שהצלחתי לגרום לו לדלג על הזבל, והיום יש לי מסע הרפתקאות על עושים rebase בvisual studio 2013 כי, אעפס הגרסה הזו לא תומכת...
&nbsp
בגדול הנוהל שהמלצתי לעשות עם git
1. ליצור branch לכל feature (כולל remote, כי יכולים לעבוד על זה חודשים)
2. לעשות fetch, ולאחר מכן מכן rebase עם הmaster בremote
3. אחרי שהעסק עובד לעשות checkout לorigin/master
4. לעשות הפעם merge עם הbranch המרוחק
5. לוודא שוב שזה עובד ואז push
&nbsp
מלבד העובדה שrebase יכול להיות בעייתי עם הbranch משותף, קרוב לוודאי שיש ויהיו הרבה בעיות עם מה שאמרתי ...בגדול הלכתי חלקית לפי זה..
(https://www.derekgourlay.com/blog/git-when-to-merge-vs-when-to-rebase/)
&nbsp
אבל אין לי זמן להתעמק עם זה, אני צריך לתלוש מהפרוייקט שלנו איזה embedded tomcat מעצבן ולהשתמש במקומו בwebserver של com.sun, זה + jax annotation צריך לספק כל מה שצריכים(רעיון שלי) , נמאס לי שמקבלים תלונות על בעיות security רק בגלל שסורקים את tomcat ונכנסים ללחץ מבעיות גרסה שלו (משהו לגבי Protocol ejp שבכלל לא מופעל אצלנו) . וגם בגדול זה overkill למשהו שסה"כ צריך לספק העברת קבצים בhttp
 

ipv6

Member
הצעדים שכתבת זאת דרך יחסית מקובלת לעבוד

אני אישית עובד טיפ טיפה שונה.
כשאני מסיים פיצ'ר אני עושה rebase -i מעל הברנץ' שאני הולך לדחוף אליו ומקבץ את כל הקומיטים שלי לקומיט בודד (על ידי fixup בזמן ה-rebase)
אחר כך אני דוחף את הקומיט הבודד הזה הזה לברנץ' המרוחק.

git fetch origin
git rebase -i origin/ipv6-branch
git push origin HEAD:ipv6-branch

ipv6-branch is my remote branch. Obviously it can be "master" branch.
 
למעלה