A simple git workflow demonstration under Windows

git_workflow.md

Preparation

• Download Git from here: https://git-for-windows.github.io/

• Click Next, Next, blah, blah...until you get a proper Git environment in your Windows box

• Open Git Shell, or any other command prompt that has access to your Git path (if unsure, check System Environment Settings)

Initialize Repository

• For a new Git Repository type:

    mkdir YOUR_REPO
    cd YOUR_REPO
    git init
    git remote add origin YOUR_REMOTE_ORIGIN_SERVER_URL
  

  You have now successfully initialized a new repo and added a remote origin!

  Let's add some files into it!

  • Type following command to create a new file (this is the equivalent of the Unix 'touch' command...but hey, you're using Windows, so it has to be complex!)

      echo $null >> my_dotnet_code.cs
    

Tracking Changes

• Well, currently Git knows nothing about your files as it isn't tracking them. To track files we first have to put them on stage. Let's do this by typing the following command:

     git add my_dotnet_code.cs
  

  You'll immediately get an answer that this file's now being actively tracked by Git.

• However, your origin master doesn't know anything about your local changes because Git is a distributed version control system where each developer has its own local copy of the central code base. The central repository where all local changes come in is called origin and is usually some external box (in a cloud or as a separate on-premise server).

  And by the way: Under Git it's normal to have a single master branch where everything comes in that should belong to the final software product. If you have some separate developments, like feature branches then just create a new branch and play with the code as you like. Later you can merge the changes with the master and delete the branch, or simply delete the branch without any merge.

  These things are rather simple under Git (unlike other version control systems. Subversion, I'm lookig at you!)

Commits

• Now, back to business: How do we let the origin know about our changes?

  By creating a new commit that contains our local changes. :-)

  Type in this:

  git commit -m 'adding my new dotnet code' (the -m is the message that describes your changes)

  Again, Git will respond with some detailed info comprising of several entries.

  One of them is the automatically generated hash-code that points to your new commit. You can use it later as a reference.

Logs, Diffs, and Shows

• For example, if you want to inspect a certain commit simply use first few alphanumeric chars from the commit's hash to display the log-info:

  git show YOUR_COMMITS_HASH

  For a full log of all changes either use:

  git log

  or

  git log --oneline for a more dense output.

  For a diff between two versions of a file:

  git diff my_dotnet_code.cs

Pushing Changes to remote Origin

• Now it's time to push changes into our origin master.

  Type in:

  git push -u origin master (the -u means upstream which will track/show changes between origin and your local copy)

  Again, Git will respond with several messages and also with some hash values denoting the change between the last master version and the new one.

  Congratulations! You have successfully pushed your local changes to the remote origin.

Switching to some older revision

• Sometimes you'll have to switch back to some older revision. This is done by using the hash of the revision you want to go back to.

  git checkout [hash-of-revision] .

Branching

• And what should be done when there are some local changes that should for now not go into the current master? The answer is simple: use branches by typing in:

  git checkout -b my_feature_branch_1

  The above command is actually a combo of:

  git branch my_feature_branch_1 (to create a new branch -> without automatically switching into it)

  git checkout my_feature_branch_1 (to switch into another branch)

* Now change files as you like, or add them, or delete...whatever. Everything you commit from now on will go into this branch and **not** into master. 

This is good because you can very easily test new code without affecting the ongoing development.

To list all available branches and in which of those you're currently in just type:

`git branch`

To delete a branch you no longer need: 

`git branch -d my_feature_branch_1`

However, if a branch isn't in sync with its remote counterpart the above command will lead to a failure. To forcefully delete a branch you could use the more dangerous version: 

`git branch -D my_feature_branch_1`  (you have been warned!)

Preventing Chaos

* However, if you encounter problems while working in **master branch** you can very easily *put away* your current changes by using:

  `git stash`

  This would effectively put your changes on the shelf until your later decide to get them back into current source tree:

  `git stash pop`

Merging Branches

* So, what should be done to **merge** successfully your branches with the current master? The answer is remarkably simple: use the *merge* option ;-)

  First, **switch** to your master with: 
    
    `git checkout master` 
    
  and then do a **merge** with: 
  
    `git merge my_feature_branch_1`.
  Again, you'll get a detailed response about the merging process. 
   
  **IMPORTANT** 
  
  In most cases you'd want to keep the history of your changes intact. 
  Therefore use the flag **--no-ff** to preserve the topology of your branches.
  Just open a GUI tool, for example **gitk**, to see the difference. Without
  **--no-ff** git would detect that the current HEAD is the ancestor of your 
  branch and move your *branch pointer* to point at the *incoming commit*. 
  This behavior is what we call **fast-forward** as git simply brings everything 
  into **a single straight line**.
  
  `git merge --no-ff my_feature_branch_1`

Well, this is it. You can now use Git!