1. Version Control with git

2. Version Control
Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. Version control is like a big undo button for your project. It allows you to revert files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also generally means that if you screw things up or lose files, you can easily recover.
Version control or Revision control
When using a version control system you take snapshots of the state of your project (commits) at regular intervals. If you make a mistake you can easily go back to a previous snapshot.

3. Version Control can be used to:
Identify the person that changed a file.
Identify the changes made to a file over time
Work on new features but still be able to go back and fix a bug in the released version of the software.

4. Examples
Version control is most commonly realized with stand-alone applications such as git or svn but is also embedded in various types of software such as Google docs and Wikipedia (page history).
Version control systems (VCS) most commonly run as stand-alone applications, but revision control is also embedded in various types of software such as word processors and spreadsheets, e.g., Google Docs and in various content management systems, e.g., Wikipedia's Page history.

5. Development and Maintenance Use Cases
Version control is essential when you have multiple developers working on the same code base. Version control is essential when you are supporting multiple versions of a software system over time. When a bug is reported in one version of the product you have to rebuild that version of the product, fix the bug and ship an updated version.

6. Categories of Version Control Systems
The two main categories of version control systems are centralized (e.g. subversion or svn) and decentralized or distributed (e.g. git). With a centralized system the repository is located in one place. With a distributed system each user has a copy of the repository.
Centralized - single server that contains all the versioned files, and a number of clients that check out files from that central place. Disadvantage: single point of failure. If the centralized repository is down, no one can do work that requires version control.
Distributed - clients don’t just check out the latest snapshot of the files: they fully mirror the repository. No single point of failure. Can commit changes when off-line.
Centralized
Distributed

7. Version Control Collaboration Models
The main function of a version control system is to allow collaborative editing and sharing of data.
There are two main strategies for enabling this:
Lock-Modify-Unlock (aka reserved checkout)
Copy-Modify-Merge (aka unreserved checkout or optimistic checkout)
While the lock-modify-unlock model is considered generally harmful to collaboration, sometimes locking is appropriate.
The copy-modify-merge model is based on the assumption that files are contextually mergeable—that is, that the majority of the files in the repository are line-based text files (such as program source code). But for files with binary formats, such as artwork or sound, it's often impossible to merge conflicting changes. In these situations, it really is necessary for users to take strict turns when changing the file.

8. Lock-Modify-Unlock

9. Copy-Modify-Merge
Most version control systems support automatic merging when the changes are in different areas of the document.

10. git
Git is a fast, open source, distributed version control system. Git was initially designed and developed by Linus Torvalds for Linux kernel development in 2005, and has since become the most widely adopted version control system for software development. Git is a simple command line tool for keeping a history on the state of project source code and documents. You tell it to track files in your project and periodically commit the state of the project when you want a saved point. Then you can share that history with other developers for collaboration, merge between their work and yours, and compare or revert to previous versions of the project or individual files.

11. git vs. github git != github git is a version control system.
github.com is a web site where you can publish git repositories.
Typical workflow: use git locally to manage a set of files. Push or publish to github to backup your work and share it with others.

12. git
git has changed the way developers think of branching and merging. Branching and merging tends to be a big scary event with centralized repositories. Branching and merging are part of the daily workflow of developers using git. git supports non-linear development.
Non-linear development example: create a branch to work on a new feature. Get a call reporting a bug with existing released version (maybe in a file you are right in the middle of editing). No problem. Switch back to the master branch and change the file, commit changes and build and test and release fix. Switch back to branch you made earlier and continue working on new features. You can merge the state of the files you are working on with the existing files later.)

13. git  

14. Three main sections of a git project
Files tracked by git are in one of three states: committed, modified, or staged. This leads us to the three main sections of a Git project: the .git directory, the working directory, and the staging area.
Snapshots of each commit are stored in the .git directory.
The working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the .git directory and placed on disk for you to use or modify.
The staging area stores information about what will go into your next commit. (The staging area in contained in the .git directory.)
These concepts help to explain what you can and can’t do with git. For example, if you have modified files in your working directory, you can’t check out a version of the project from the .git directory. If you did, you would loose your changes as the file was overwritten by the previous version. There would be no way to recover your changes because they haven’t been committed yet.

15. git file stages Untracked Tracked
Each file in your working directory can be in one of two states: tracked or untracked. Tracked files are files that are recognized by git. They are under version control. Some files such as the binary files that are output from your build process, are untracked. You don’t need to keep track of them in your version control system.
Tracked files can be unmodified, modified, or staged. Once files are staged, they can be committed. Committing a file creates a snapshot that can be recovered at any time in the future. Once a file is committed it goes back to the unmodified state.
When you first clone a repository, all of your files will be tracked and unmodified because you just checked them out and haven’t edited anything.
git command for determine the state of the files in your working directory:
$ git status
Untracked
Tracked

16. SHA-1 checksums in git
git stores data in one big hash table or key-value data store. The keys are SHA-1 checksums. You see these checksums everywhere. For example, if you run git log --oneline you will see something like: $ git log --oneline b add readme file f118e0e update license text 6beda33 fixed issue 123 The hex values above are abbreviated SHA-1 checksum values or keys that point to commits.

17. SHA-1 checksums in git
The image above shows two branches (master and testing) and 4 commits. The current branch (indicated by HEAD pointer) is testing.

18. git command line
I will be demonstrating git using a command line interface. There are GUI options for using git. These usually support only a subset of the commands available from the command line. The command line is the only place you can run all Git commands. git GUI’s come and go. If you know how to use git from the command line, you can probably also figure out how to use git from any of the GUI options, while the opposite is not necessarily true. Also, while your choice of graphical client is a matter of personal taste, all users will have the command-line tools installed and available.
Here is a command line version of git you can run from a campus lab:
After installing, run the following. You only need to do this once:
$ git config --global user.name "John Doe“
$ git config --global user.
You can check all your configuration settings with:
$ git config --list

19. Contributing to a github project
Unless you are part of the core development team for a project, you probably won’t have write access to the repository for the project. The standard procedure for contributing to a github project to which you don’t have write or push access is:
Find the project on github and select “Fork”. You now have a copy of the project in your own github workspace.
Create a topic branch for the changes you plan to make.
Make your changes (one or more: git add <filename> followed by git commit –m ‘message’).
Push your topic branch back to your repository.
Open a pull request from github
Discuss and optionally commit additional changes to your branch.
When ready, the product owner will merge your pull request.
You will need an account on github to fork a project.
Note, before pushing your changes to github, you probably want to do a pull request on the branch you branched. This will bring in any changes to the branch since you made your topic branch. This will make it easier to merge your changes.

20. Git Workflows
There are many different version control workflows to choose from. A workflow is simply the procedures your team will follow when collaborating on development through your version control system. Popular options are:
Centralized workflow
Feature branch workflow
Gitflow workflow
Another: Not as robust as git-flow but easier to understand and use.
A workflow is a process. As with any process selection or definition, it is wise to resist the temptation to overcomplicate it. Begin with the simplest possible system that will work and add additional complexity only when it is absolutely needed and then add only what is needed to solve the immediate problem.

21. Centralized Workflow
Git is a distributed version control system but you can use it like a centralized version control system (i.e. subversion).
With the Centralized Workflow only the master branch is needed.
Step-by-step:
Create a centralized repository on github or other git hosting server.
Each developers clones the centralized repository.
Developers work locally committing changes ever so often.
The first developer, say John, does a git push origin master to merge his changes with the central repository. There are no conflicts because it is a simple fast-forward merge.
A second developer, say Mary, attempts a git push origin master, but she gets an error message because her local copy is behind the remote copy. She must do a git pull origin master ( or git pull --rebase origin master) to merge John’s changes before she can push her changes. This may require manual merge resolution. After merging, Mary can retry the git push origin master.
For more info see:

22. Feature Branch Workflow
The core idea behind the Feature Branch Workflow is that all feature development should take place in a dedicated branch instead of the master branch.
With feature branches you can also use pull requests to initiate discussions around a branch before it gets integrated.
Developers create a new branch every time they start work on a new feature.
Feature branches can (and should) be pushed to the central repository. Provides a mechanism for sharing work and also serves as a backup for local commits.
For more info see:
Benefits of feature branch over Centralized Workflow:
Master is more stable. You can establish the convention that master is always releasable.
Developers can push their branches thus backing up their changes.
Feature branches can be merged back into master using pull requests. This provides a process for discussing changes before they are merged into master (main line code).
If pull request can’t be merged automatically, you need to synchronize your local master with the upstream master. Then, you merge the feature branch into master and push the updated master back to the central repository.

23. Gitflow Workflow .
More advanced workflow called git-flow:
Also described here:

24. Nice explanation at: https://www. thinkup