Git

version control system

What is GIT

Manage versions and Distribute work:

Git is a type of source code management system called a distributed version control system.
Git is a tool to facilitate development work by recording and tracking the changelog (version) of files, comparing past and current files, and clarifying changes.
The system also allows multiple developers to edit files at once, so the work can be distributed.

Release versioning

For release versioning we recommend the Semantic Versioning system.

Given a version number MAJOR.MINOR.PATCH, increment the:
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.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

YouTube: Semantic Versioning

Try it with Github

try git with github

Git flow

git workflow

When working in a team, we recommend using the GitFlow branching model with a Git workflow using rebase.

YouTube: Gitflow: Introduction

YouTube: A Better Git Workflow with Rebase

Read this Blog: Git Rebase or Git Merge

Git Rebase vs Git Merge

Git Rebase and Git Merge are commands generally used to merge two branches. The difference here is the way they do this combination.

merge or rebase?

When we typed “git Rebase”, all the changes of the feature branch will be added to the master branch one by one. Here, if we search for a historical history, we will see only one history. Because when we typed “git rebase”, a single history will be created because all branches are collected on a single path.

Advantages of Git Rebase

Converts complex history into a single format
Simplifies DevOps work by reducing multiple comments to a single comment.

Advantages of Git Merge

Simple and clear
Preserves the history in chronological order
Protects branches

Which Should We Use?

If you are working with a single or small team, it will be more advantageous to use git rebase. But if you’re working with a big team, use git merge.

The seven rules of a great commit message

For writing good commit message on a commit, I recommend the seven rules.

1. Separate subject from body with a blank line

 Derezz the master control program

MCP turned out to be evil and had become intent on world domination.
This commit throws Tron's disc into MCP (causing its deresolution)
and turns it back into a chess game.

2. Limit the subject line to 50 characters

- 50 characters is not a hard limit, just a rule of thumb. Keeping subject lines at this length ensures that they are
  readable, and forces the author to think for a moment about the most concise way to explain what’s going on.

3. Capitalize the subject line

For example:

Accelerate to 88 miles per hour

Instead of:

~~accelerate to 88 miles per hour~~

4. Do not end the subject line with a period

For example:

  `Open the pod bay doors`

Instead of:

  ~~Open the pod bay doors.~~

5. Use the imperative mood in the subject line

Imperative mood just means “spoken or written as if giving a command or instruction”. A few examples:

Clean your room
Close the door
Take out the trash

6. Wrap the body at 72 characters

7. Use the body to explain what and why vs. how

commit eb0b56b19017ab5c16c745e6da39c53126924ed6
Author: Pieter Wuille <pieter.wuille@gmail.com>
Date:   Fri Aug 1 22:57:55 2014 +0200

 Simplify serialize.h's exception handling

  Remove the 'state' and 'exceptmask' from serialize.h's stream
implementations, as well as related methods.

  As exceptmask always included 'failbit', and setstate was always
called with bits = failbit, all it did was immediately raise an
exception. Get rid of those variables, and replace the setstate
with direct exception throwing (which also removes some dead
code).

  As a result, good() is never reached after a failure (there are
only 2 calls, one of which is in tests), and can just be replaced
by !eof().

  fail(), clear(n) and exceptions() are just never called. Delete
them.

Example

Summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.

Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain them.

Further paragraphs come after blank lines.

 - Bullet points are okay, too

 - Typically a hyphen or asterisk is used for the bullet, preceded
   by a single space, with blank lines in between, but conventions
   vary here

If you use an issue tracker, put references to them at the bottom,
like this:

Resolves: #123
See also: #456, #789

Recommended reading: Understanding GIT trough images

Using Git means

excerpt from understanding Git through images

Start daily exercises in the Code Gym

Start with: Start your journey to become a Java Developer

Continue with: Git repo setup

Git

Git