در این ارائه ابتدا به برخی مباحث پیشرفته‌تر دربارهٔ سیستم کنترل ورژن گیت پرداخته شده است. این ارائه در کلاس تحلیل و طراحی سیستم‌های دانشکده کامپیوتر دانشگاه صنعتی شریف در تاریخ ۳۱ اردیبهشت ۱۳۹۶ ارائه شده است.

1. (‫)تکمیلی‬ ‫گیت‬ ‫ورژن‬ ‫کنترل‬ ‫سامانه‬
‫شریف‬ ‫صنعتی‬ ‫دانشگاه‬ – ‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
– ‫صدرنژاد‬ ‫سیدمحمدمسعود‬۳۱‫اردیبهشت‬۱۳۹۶

2. ‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
2
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫کنترل‬‫سامانه‬ ‫کارگاه‬۲(
‫مطالب‬ ‫فهرست‬
۱‫گرافیکی‬‫های‬‫محیط‬ ‫در‬ ‫گیت‬ ‫از‬ ‫استفاده‬ ‫و‬ ‫نصب‬ .
۲.‫پیشنهاد‬git-flow‫ها‬‫برنچ‬ ‫مدیریت‬ ‫برای‬
۳‫روش‬ .semantic versioning‫و‬tag‫گذاری‬
۴‫یک‬ ‫های‬‫ویژگی‬ .commit message‫خوب‬

3. ‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
3
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫کنترل‬‫سامانه‬ ‫کارگاه‬۲(
) ‫گرافیکی‬ ‫های‬‫محیط‬ ‫در‬ ‫گیت‬۱(

4. ‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
4
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫کنترل‬‫سامانه‬ ‫کارگاه‬۲(
) ‫گرافیکی‬ ‫های‬‫محیط‬ ‫در‬ ‫گیت‬۲(

5. ‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
5
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫کنترل‬‫سامانه‬ ‫کارگاه‬۲(
) ‫گرافیکی‬ ‫های‬‫محیط‬ ‫در‬ ‫گیت‬۳(

6. 6
‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫ل‬‫ل‬‫کنتر‬‫سامانه‬ ‫کارگاه‬۲(
Workshop
Let's See in Action
Open Your Terminal

7. ‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
7
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫کنترل‬‫سامانه‬ ‫کارگاه‬۲(
‫پیشنهاد‬git-flow‫ها‬‫برنچ‬ ‫مدیریت‬ ‫برای‬

8. ‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
8
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫کنترل‬‫سامانه‬ ‫کارگاه‬۲(
‫با‬ ‫کار‬remote

9. ‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
9
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫کنترل‬‫سامانه‬ ‫کارگاه‬۲(
Deploy On Push

10. 10
‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫ل‬‫ل‬‫کنتر‬‫سامانه‬ ‫کارگاه‬۲(
Semantic Versioning (1)
 Problem
 In the world of software management there exists a
dread place called “dependency hell.”
 Many dependencies
 Version lock
• The inability to upgrade a package without having to
release new versions of every dependent package
 Prevent you
• from easily and safely moving your project forward

11. 11
‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫ل‬‫ل‬‫کنتر‬‫سامانه‬ ‫کارگاه‬۲(
Semantic Versioning (2)
 Solution
 Common practices
• in use in both closed and open-source software
 Consider a version format of X.Y.Z
(Major.Minor.Patch)
 Version numbers and the way they change
• convey meaning about the underlying code and what
has been modified from one version to the next

12. 12
‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫ل‬‫ل‬‫کنتر‬‫سامانه‬ ‫کارگاه‬۲(
Semantic Versioning (3)
 Semantic Versioning 2.0.0
 http://semver.org
 Given MAJOR.MINOR.PATCH increment
 MAJOR version
• when you make incompatible API changes,
 MINOR version
• when you add functionality in a backwards-compatible
manner, and
 PATCH version
• when you make backwards-compatible bug fixes.
 pre-release and build metadata

13. 13
‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫ل‬‫ل‬‫کنتر‬‫سامانه‬ ‫کارگاه‬۲(
Semantic Versioning (4)
 Semantic Versioning Specification (SemVer)
 Declare a public API.
• This API could be declared in the code itself or exist
strictly in documentation.
 A normal version number MUST take the form X.Y.Z
• Where X, Y, and Z are non-negative integers, and MUST
NOT contain leading zeroes.
• X is the major version, Y is the minor version, and Z is the
patch version.
• Each element MUST increase numerically. For instance:
1.9.0 -> 1.10.0 -> 1.11.0.
 Once a versioned package has been released,
• The contents of that version MUST NOT be modified.
• Any modifications MUST be released as a new version.

14. 14
‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫ل‬‫ل‬‫کنتر‬‫سامانه‬ ‫کارگاه‬۲(
Semantic Versioning (5)
 Semantic Versioning Specification (SemVer)
 Major version zero (0.y.z) is for initial development.
• The simplest thing to do is start your initial development
release at 0.1.0 and then incment the minor version for
each subsequent release.
 Version 1.0.0 defines the public API.
• The way in which the version number is incremented after
this release is dependent on this public API and how it
changes.
• If your software is being used in production, it should
probably already be 1.0.0.
• If you have a stable API on which users have come to
depend, you should be 1.0.0.
• If you’re worrying a lot about backwards compatibility,
you should probably already be 1.0.0.

15. 15
‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫ل‬‫ل‬‫کنتر‬‫سامانه‬ ‫کارگاه‬۲(
Semantic Versioning (6)
 Semantic Versioning Specification (SemVer)
 Patch version Z (x.y.Z | x > 0) MUST be incremented
if only backwards compatible bug fixes are introduced.
• A bug fix is defined as an internal change that fixes
incorrect behavior.
 Minor version Y (x.Y.z | x > 0) MUST be incremented
if new, backwards compatible functionality is
introduced to the public API.
• Patch version MUST be reset to 0 when minor version is
incremented.
 Major version X (X.y.z | X > 0) MUST be incremented
if any backwards incompatible changes are introduced to
the public API.
• It MAY include minor and patch level changes.
• Patch and minor version MUST be reset to 0 when major
version is incremented.

16. 16
‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫ل‬‫ل‬‫کنتر‬‫سامانه‬ ‫کارگاه‬۲(
Good Commit Message (1)

17. 17
‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫ل‬‫ل‬‫کنتر‬‫سامانه‬ ‫کارگاه‬۲(
Good Commit Message (2)
 Why good commit messages matter?
 Seven rules
 Separate subject from body with a blank line
 Limit the subject line to 50 characters
 Capitalize the subject line
 Do not end the subject line with a period
 Use the imperative mood in the subject line
 Wrap the body at 72 characters
 Use the body to explain what and why vs. how

18. 18
‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫ل‬‫ل‬‫کنتر‬‫سامانه‬ ‫کارگاه‬۲(
Good Commit Message (3)
 Separate subject from body with a blank line
 Begin the commit message with a single short (less
than 50 character) line summarizing the change,
 Followed by a blank line
 And then a more thorough description.
 The text up to the first blank line in a commit
message is treated as the commit title, and that
title is used throughout Git.
 For example, Git-format-patch(1) turns a commit
into email, and it uses the title on the Subject line and
the rest of the commit in the body.

19. 19
‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫ل‬‫ل‬‫کنتر‬‫سامانه‬ ‫کارگاه‬۲(
Good Commit Message (4)
 Limit the subject line to 50 characters
 Strive for atomic commits
 72 is the hard limit

20. 20
‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫ل‬‫ل‬‫کنتر‬‫سامانه‬ ‫کارگاه‬۲(
Good Commit Message (5)
 Capitalize the subject line
 For example:
• Accelerate to 88 miles per hour
 Instead of:
• accelerate to 88 miles per hour

21. 21
‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫ل‬‫ل‬‫کنتر‬‫سامانه‬ ‫کارگاه‬۲(
Good Commit Message (6)
 Do not end the subject line with a period
 Trailing punctuation is unnecessary in subject lines.
 Example:
• Open the pod bay doors
 Instead of:
• Open the pod bay doors.

22. 22
‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫ل‬‫ل‬‫کنتر‬‫سامانه‬ ‫کارگاه‬۲(
Good Commit Message (7)
 Spoken or written as if giving a command or
instruction
 Git itself uses the imperative whenever it creates a
commit on your behalf.
 For example:
• Refactor subsystem X for readability
• Update getting started documentation
• Remove deprecated methods
• Release version 1.0.0
 Instead of:
• Fixed bug with Y
• Changing behavior of X

23. 23
‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫ل‬‫ل‬‫کنتر‬‫سامانه‬ ‫کارگاه‬۲(
Good Commit Message (8)
 Spoken or written as if giving a command or
instruction
 A properly formed Git commit subject line should
always be able to complete the following sentence:
• If applied, this commit will your subject line here
 For example:
• If applied, this commit will refactor subsystem X for
readability
•If applied, this commit will update getting started
documentation
•If applied, this commit will remove deprecated methods
•If applied, this commit will release version 1.0.0
•If applied, this commit will merge pull request #123 from
user/branch

24. 24
‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫ل‬‫ل‬‫کنتر‬‫سامانه‬ ‫کارگاه‬۲(
Good Commit Message (9)
 Wrap the body at 72 characters

25. 25
‫ها‬‫سیستم‬ ‫طراحی‬ ‫و‬ ‫تحلیل‬
۱۳۹۶/۲/۳۱
‫صدرنژاد‬ ‫سیدمحمدمسعود‬) ‫گیت‬‫ورژن‬ ‫ل‬‫ل‬‫کنتر‬‫سامانه‬ ‫کارگاه‬۲(
Good Commit Message (10)
 Use the body to explain what and why vs. how
 Code is generally self-explanatory in this regard.
 Take a look at the full diff and just think how much
time the author is saving fellow and future committers by
taking the time to provide this context here and now.
 Just focus on making clear the reasons why you made
the change in the first place—the way things worked
before the change (and what was wrong with that), the
way they work now, and why you decided to solve it the
way you did.
 For example:
https://github.com/bitcoin/bitcoin/commit/eb0b56b190
17ab5c16c745e6da39c53126924ed6

26. ‫پاسخ‬ ‫و‬ ‫پرسش‬‫پاسخ‬ ‫و‬ ‫پرسش‬
‫وسیله‬ ‫به‬ ‫شده‬ ‫طراحی‬
twitter.com/smmsadrnezhtwitter.com/smmsadrnezh
‫صدرنژاد‬ ‫سیدمحمدمسعود‬