Git Version Control System Part 2

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

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

۱۳۹۶/۲/۳۱
3
) ‫گرافیکی‬ ‫های‬‫محیط‬ ‫در‬ ‫گیت‬۱(

۱۳۹۶/۲/۳۱
4
) ‫گرافیکی‬ ‫های‬‫محیط‬ ‫در‬ ‫گیت‬۲(

۱۳۹۶/۲/۳۱
5
) ‫گرافیکی‬ ‫های‬‫محیط‬ ‫در‬ ‫گیت‬۳(

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

۱۳۹۶/۲/۳۱
7
‫پیشنهاد‬git-flow‫ها‬‫برنچ‬ ‫مدیریت‬ ‫برای‬

۱۳۹۶/۲/۳۱
8
‫با‬ ‫کار‬remote

۱۳۹۶/۲/۳۱
9
Deploy On Push

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
۱۳۹۶/۲/۳۱
 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
۱۳۹۶/۲/۳۱
 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
۱۳۹۶/۲/۳۱
 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
۱۳۹۶/۲/۳۱
 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
۱۳۹۶/۲/۳۱
 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
۱۳۹۶/۲/۳۱
Good Commit Message (1)

17
۱۳۹۶/۲/۳۱
 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
۱۳۹۶/۲/۳۱
 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
۱۳۹۶/۲/۳۱
 Limit the subject line to 50 characters
 Strive for atomic commits
 72 is the hard limit

20
۱۳۹۶/۲/۳۱
 Capitalize the subject line
 For example:
• Accelerate to 88 miles per hour
 Instead of:
• accelerate to 88 miles per hour

21
۱۳۹۶/۲/۳۱
 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
۱۳۹۶/۲/۳۱
 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
۱۳۹۶/۲/۳۱
 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
۱۳۹۶/۲/۳۱
 Wrap the body at 72 characters

25
۱۳۹۶/۲/۳۱
 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

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

Git Version Control System Part 2

More Related Content

Similar to Git Version Control System Part 2 (20)

More from Masoud Sadrnezhaad (20)

Recently uploaded (20)

Git Version Control System Part 2