Prep Git, GitHub & TFS Version Control

Microsoft source code management application that allows programmers to maintain a Master copy of the code they are working on as well as version control copies in a centralized, single location while also proving project management and control, automated builds, testing and release management capabilities.

Typically is run within Visual Studio but can be used on other IDE's as well. Since 2013, TFS has used Git as a source code repository behind the scenes with Microsoft UI and Visual Studio look and feel.

Background: Git history forms a directed acyclic graph (DAG) in which every commit has to reference a previous set of one or more parent commits. The original or first one being the Master.

A push is the process of taking the local code and the DAG and pushing it to the server so that it's available to all other developers while also making sure the DAG pointer is correctly incremented.

Background: Git history forms a directed acyclic graph (DAG) in which every commit has to reference a previous set of one or more parent commits.

When you are pulling, you are taking committed remote code on the server and downloading it and merging it along with its DAG pointer... these both are then located on your local machine so that you can manipulate it later.

• At the instance you modify this code on your local machine, TFS checks out the brach (1) updating working directory with contents of the latest commit in that branch, and (2) it indicates that your next commit will reference the current tip commit as its parent.
• Once you commit those changes, Git (1) creates a new commit object with only your edited files and (2) sets that commit's parent to be the last commit that you checked out and advances your local branch to point to this new commit that you just created.
• Finally, you now try to push this branch to the server and Git (1) pushes the new commit(s) you created, uploading the objects and their file contents to the server, and (2) moves the server's branch pointer from the last commit it was pointing to, to the latest commit that you just pushed.

The last person to push their committed changes to the server changes the  position of the DAG pointer, therefor, any person coming after this would then have to get the latest BEFORE pushing their commits.

So a "race" implies that two programmers are trying to check-in their work but don't want to have to "Get latest" twice as is the case with the one that loses the race because their DAG pointer indicates that a merged push has already occurred.

Commit is the Git terminology used to describe the saving of changes to the local branch AND a re-positioning of the DAG pointer.

Simply saving your changes isn't the same as a commit. Think of this as "checking-in" your changes but to a local branch.

Also, understand, that you essentially have two local versions of the application. The one on your hard drive, and the other being a copy of the one you are working on. This copy is the one you are updating with a commit command.

You would have a local branch, make changes, commit those changes to your local branch...then push that change (committed branch) to the remote repository where Git commits and adds them to an existing branch on the remote server.

Once done, Git makes that pushed change available for other developers to pull and merge them into their own local copy of the branch.

Fetch: download the changes from the remote repository but does not apply them to your local code.

Merge: Applies the changes taken from a "fetch" to a branch on your local repository.

Pull: Combine the "fetch" command followed by a "merge" command.

1: Get a local copy of code if they don't have one yet, pulling from the Master copy.

2: Make changes to code to fix bugs or add new features.

3: Once the code is ready, make it available for review by your team by pushing it but not merging it.

4: Once the code is reviewed, merge it into the team's shared codebase (dev).

1. Create a local branch for the changes you plan to make and give it a name

2. Make changes, then commit them (may have committed more than once).

3. Push your branch to the remote repository

4. Create a pull request so that others can review your changes. 

5. Complete your pull request and resolve any merge conflicts from changes made after you created your branch (see Race).

• Commit "saves" your changes to the local repository
• Push commits and then pushes that commit to the remote repository on GitHub as well (so that others can see and pull it)

Sync commits your changes then pushes and pulls (effectively, syncing your local repository with the remote repository).  "Sync" is a GitHub term for performing both pushes and pulls.

Fetch asks the remote repository for the list of changes since you last fetched but does not apply them.  Basically it lets you know "oh, I'm 5 commits behind, and those commits changed files x, y, and z".

Pull does a fetch, but it additionally applies those changes to your local repository.

They are somewhat similar, however, a pull does both a get and merge of the changed remote branch to your local branch.

A fetch would simply determine get the changed remote branch changes and show them, but not merge them with your local branch.

We can think of Git as having 3 local areas and 2 remote areas.

Local .Git Repository: This contains the root master file with all committed work as well as a history of all changes to this branch. When working locally, this repository isn't updated automatically until we commit our changes locally and only those files modified are included in an update to this repository as is the DAG.

Local Working Branch: This resides only on the local machine where a copy of the original was pulled and can now be manipulated freely. We haven't committed but can make as many changes as we would like.

Staging Branch: Once we are happy with our changes, we selectively choose the changes we want to include for our commit. This is our staging area, files changed and selected but not yet committed.

Remote Staging Branch: Once we commit our changes and push them to our remote repository, they are available for other developers to see and pull and critique.

Remote Development Branch: Our final step is to create a new Pull Request which we are essentially asking other developers to view and critique the software, and if accepted, we can then merge this branch into the master branch, and it is our final development branch.

Simply put, Git is a distributed version control system that lets you manage and keep track of your source code history. GitHub is a web-based hosting service that lets you manage and work with Git repositories. Difference is one is the actual program itself (Git) while the other is a web-based version of it that comes with all the bells and whistles, making large distributed projects easier to work with.