Introduction to GIT

1. GIT is a free and opensource distributed version control system.
2. A version control system is a tool that lets you track the history and attribution of your project files over time.
3. This helps the developers in the team to work together.
4. Each developer has his own sandbox,preventing their work in progress from conflicting.
5. A mechanism is provided to merge the changes and synchronize work.
6. Each developer has his own copy of project history, a clone of repository.
7. Nearly all operations are performed locally and are flexible.
8. Repository's meant for development also provide a separate working area(a Work Tree) with project files for each developer.
9. Branching model used by GIT enables local branching and flexible branch publishing allowing to use branches for context switching and for sand boxing different work in progress.
10. Allows long term undo,rewinding back to last working version.
11. Ownership tracking makes it possible to find out who was responsible for any given area of code.
12. Compare different revisions go back to revision and debug the same.
13. Find out which revision introduced a regression bug.
14. GIT maintains a ref log for each and every change.
15. GIT is distributed version control system.

Distributed Vs Centralized Repositories

1. Centralized models require a network connection to a centralized server.
1. You make a change to your project and then commit that change which is sent to centralized server to track.
2. Other developers can immediately access the changes.
2. In Distributed model we commit the code to our local private repository without having to talk to centralized server,removing the need to be connected to a network to make a change.

Private Vs Public Repositories

1. Each developer has 2 repositories a private and a public repository.
2. Private repository exist on our computer that we make commit too.
3. Public repositories are those where we share our changes with other developers.
4. Multiple developers may push changes to same public repository or each developer may have his own public repository.
5. One can push and pull from multiple repositories.

Commit ID's vs Revision Numbers

1. Centralized Version Control Systems has the benefit of having one system that  provides revision numbers.
1. Since everyone shares code in same repository.The repository can control what number it assigns to a particular commit.
2. In a Decentralized system we use commit ID's that are SHA-1 hashes.
1. The hash is based on the code what came before it, who made the commit when they made it and some more meta data.
2. This lowers the chances of repeated commit ID's.

Forking

1. Forking is a process where a concerned part of Project is separated and provided to developer to work upon and then later merge the same back to original Project. 
2. GIT uses super merging capabilities, rooted in its distributed nature makes merging changes in a forked repository easy.
3. A user may fork a repository, commit changes and ask the original developer to pull your changes through a pull request.
4. The more the forks are the more active is the community working on a project.

GIT Work Flow

1. A GIT user fetches code from all the other developers and commits the changes it has made to the code.
2. Break out GIT's patch mode,stage and finally commit each set of changes separately.
3. Once a feature is complete combine the commits that are logically related and push them to the public repository for rest of the team to pull.

Small Teams with Shared Repository

1. Each team member makes changes in its private repository.
2. The member can then share the changes with other developers by pushing them back to the public repository shared by all.
3. Here no forking is there so we can use GIT as a traditional version control system as well.
4. If someone else has shared changes in shared repository that one is not updated with it will give an error during pushing changes.
5. One must first update the changes from the shared repository and integrate them into your private repository via process called merging.
1. Once the changes are merged one can push changes to share with rest of the team.

Repository Layouts

Public repositories can be managed in 2 ways

1. In a distributed model each developer has his own public repository that the developer uses to publish their changes too.
1. All the other developers can pull changes from everyone else's repositories to keep current.
2. There is a lead developer who is responsible for making sure all changes are integrated.Thus limiting the number of repositories one has to pull from.
3. Only one person can push changes to main repository.He/She is responsible for merging changes from all contributors into the main repository.
4. Many encourage forking out the project.So that other members can review their changes.If accepted one of the main contributors merges them back to the project's repository.
2. In a shared repository model all developers can push to a shared repository.This resembles the shared centralized model.
1. Many Projects have main repository open for all other committers.
3. A mix of both of these where each developer maintains their own public repository for sharing code that is still a Work in Progress.There is also a shared repository for all the code that's ready for production.

Distributed Repository

Shared Repository