מבוא להנדסת תוכנה - תשפ"ה - בוחן 4
- 26 שאלות
- -- תגובות
- 0% הושלמו
- equalizer סטטיסטיקות
- share שתף
Discuss, Learn and be Happy דיון בשאלות
help
brightness_4
brightness_7
format_textdirection_r_to_l
format_textdirection_l_to_r
באמצעות אילו פקודות גיט ניתן ליצור מאגר (repository) מקומי?
1
| done | ||
הסבר: הפקודה "git init" מייצרת מאגר חדש מקומי, והפקודה "git clone" יוצרת עותק של מאגר קיים, כך ששתי האפשרויות מאפשרות יצירת מאגר מקומי.
מיין לפי
איזה רצף מעברי מצב מתאר נכון את מחזור החיים של רכיב במאגר גיט (git) מקומי (רצף מעברים חלקי)?
1
| done | ||
הסבר: לאחר ביצוע commit (שמציב את הקובץ כ-staged ולבסוף כ-unmodified), כל שינוי חדש מקדם את הקובץ למצב modified. הרצף "staged -> unmodified -> modified" מתאר את המעבר לאחר שמירת commit ומעבר לשינויים עתידיים.
מיין לפי
מה היא טענה נכונה לגבי branching ו-merging?
1
| done | ||
הסבר: תהליך ה-branching יוצר קו פיתוח חדש (codeline) המגזר את עצמו מהקו הקיים, כך שניתן לבצע שינויים באופן עצמאי לפני שמיזוגם חוזר לקו הראשי.
הטענה האחרונה לא נכונה כי merging אינו מתבצע על גרסאות נפרדות בתוך אותו codeline, אלא על שני codelines שונים (למשל, על ה-branch שהתפצל מה-main ועל ה-main עצמו).
כאשר עושים merge, למעשה מביאים שינויים מ-branch אחד לתוך branch אחר, וכך נוצרת גרסה חדשה המשלבת את השינויים. אם היינו ממזגים גרסאות שונות בתוך אותו codeline, זה היה בעצם רק עדכון של גרסה אחת ולא תהליך של מיזוג בין התפתחויות מקבילות של הקוד.
מיין לפי
מה טענה נכונה בהקשר של פרוטוקול גיט (git) ופקודותיו?
1
| done | ||
הסבר: כדי להתחיל לעבוד על ענף חדש, עלינו קודם ליצור אותו (branch), לעבור אליו (checkout) ולאחר מכן לבצע את השינויים ולשמור אותם עם commit. זו הדרך התקנית להפרדת פיתוח.
מיין לפי
מה איננה טענה נכונה לגבי פקודת שמירת תמונת מצב (commit) בגיט (git)?
1
| done |
הסבר: ב-Git, למרות שהאובייקטים נשמרים כ-snapshots מלאים, ניתן לומר שהטענה הזו אינה נכונה – Git אינו שומר commit כ"אוסף דלתאות" במובן המסורתי, אלא שומר תמונה מלאה (עם אופטימיזציות פנימיות). לכן, זו הטענה הלא נכונה ביחס לשאר הטענות.
מיין לפי
מהו ההבדל בין שתי הפקודות: checkout HEAD^^ ו-checkout HEAD~2?
1
| done | ||
הסבר: בשיטת הסימון של Git, גם הסימון HEAD^^ וגם HEAD~2 מתייחסים ל"two commits before HEAD", ולכן תוצאות שתי הפקודות זהות.
מיין לפי
(git) פרוטוקול גיט מאפשר בניית מערכת ניהול גרסאות מבוזרת (distributed).
1
| mood | ||
הסבר: Git תוכנן להיות מערכת ניהול גרסאות מבוזרת, בה כל משתתף מחזיק עותק מלא של המאגר.
מיין לפי
נתונה מערכת גיט מבוזרת עם מאגר מרכזי משותף. מתכנת צריך להכניס תיקון ל-codeline שאינו בהכרח עמו קודם, מבלי להפריע לאחרים. מהו רצף הפקודות שעליו לבצע (משמאל לימין)?
1
| done | ||
הסבר: הרצף הנכון מתחיל בסנכרון עם המאגר המרכזי (pull), יצירת ענף חדש (branch), מעבר אליו (checkout), ביצוע השינויים (add ו-commit), מיזוג השינויים חזרה ל-codeline (merge) ולבסוף העברת העדכונים למאגר המרכזי (push). כך נמנעת הפרעה למפתחים אחרים.
מיין לפי
פעולת check-in\checkin\ci הינה פעולה המחזירה רכיב למאגר לאחר השינויים שנעשו בו.
1
| done | ||
הסבר: במערכות ניהול גרסאות מסוימות (ובעיקר בסביבות ששימושן מונחה בתהליכים של check-in/check-out) פעולת check-in אכן מתייחסת להחזרת רכיב למאגר לאחר עריכה.
מיין לפי
פקודת commit של גיט (git) מייצרת בפועל baseline חדש עבור גרסת מערכת גם כאשר מדובר בגרסת ביניים.
1
| done | ||
הסבר: כל commit ב-Git יוצר תמונת מצב מלאה של הפרויקט, אשר יכולה לשמש כ-baseline עבור גרסת ביניים, גם אם אינה גרסת שחרור רשמית.
מיין לפי