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)
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
Well, currently Git knows nothing about your files as it isn't
trackingthem. 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.
origin masterdoesn't know anything about your local changes because Git is a
distributed version control systemwhere each developer has its own local copy of the central code base. The central repository where all local changes come in is called
originand 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 branchesthen 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!)
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 --onelinefor 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.
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] .
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!)
* 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`
* 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!