So you’ve installed git on Windows, now what?
Firstly, set up your credentials and basic preferences. GitHub setup guide is a good reference. All you actually need for now is listed below.
Since we will be working with Windows exclusively, we do not care about keeping line endings unix compatible, nor do we care about filemodes.
git config --global user.name "Billy Everyteen"
git config --global user.email "Billy.Everyteen@mac.com"
git config --global core.autocrlf false
git config --gloabl core.fileMode false
Next, clone a repository. Launch GIT GUI and enter a repository URL, and the local checkout directory. (You may be prompted for a username and password if the repository is secured).
Alternatively, if you are more comfortable with the command line, launch
$ cd "C:\Users\Chui\Projects"
$ git clone http://xyz.com/xyz/xyz.git
You can save the username password in a .netrc file.
See Use netrc on Windows
Customizing configuration files
Next, identify all the files that are not to be checked into the project. In my projects, I usually name them
xyz.sample.ext. Make a copy of the file with the
.sample. omitted. If these are configuration files, the contents need to be adjusted for database connection strings, SMTP server strings etc.
In some cases, if you need to make changes to files that shouldn’t be committed to the source control, you may do the following:
# StarterSite.sdf is a database file. Ignore any changes to this file.
$ git update-index --assume-unchanged App_Data\StarterSite.sdf
Using .gitignore to ignore files
.gitignore can also be used to ignore files. This is only good for files haven’t been checked in before. Once a file has been checked in, .gitignore no longer works.
Making source changes
I recommend the following approach: declare what you wish to change before making any changes. This way, you won’t end up with a bunch of modified files for different issues.
When you’re done with changes, hit the “Rescan” button. That’ll bring up all the changes you’ve made. Then, select each file that should be checked in, and type CTRL+T to “stage” them. (git operates on a two-phase commit system, you stage the changes and then commit them in a single swoop).
Pushing your changes to a central repository
When you make a code commit, the changes are committed to the .git subdirectory. This is a full .git repository with a history of all commits. “Pushing” your changes pushes the incremental changes back to the origin server where you cloned the repository.
This can be done from GIT GUI or from the command line
# Note: master is roughly the equivalent of the "trunk" branch in svn
$ git push origin master
Pushing your changes to a shared central repository (i.e. multiuser)
If there are multiple people pushing to the same central repository, then you will be required to pull the repositories changes before pushing them.
# saves modified files from the working directory to a stash area, reverts files
$ git stash save
# gets latest changes
$ git pull origin master
# At the stage conflicts may occur. See dealing with conflicts.
# retrieves files back into working directory
$ git stash pop
# push changes
$ git push origin master
Dealing with conflicts
The conflicts may appear cryptic but is rather straightforward. See merging conflicts with git