Vault7: CIA Hacking Tools Revealed

Navigation: » Directory » Git Distributed Version Control » Git Distributed Version Control Home » Git Tutorials

Git For Visual Studio Users

As an essentially new Git user (and a lazy one, who prefers using GUIs over CLIs), I've found that the following workflow seemed to be the easiest one to pick up:

Prerequisites – install Visual Studio, install and set up Git Extensions:

Prerequisites – install Visual Studio, install and set up Git Extensions:
Install Visual Studio: (2010: "\\FS-01\share\Windows Software Development Resources\Visual Studio 2010") (2011: "\\FS-01\share\Windows Software Development Resources\Visual Studio 2012") Install Git Extensions: ("\\FS-01\share\Windows Software Development Resources\git\git Extensions") Launch Git Extensions on your development machine. After choosing your preferred UIUser Interface language, you should have to configure some basic settings: You will probably have to configure Git to ignore SSLSecure Socket Layer certificate errors (boo!). You'll need to open the following config. file: "C:\Users\<Username>\.gitconfig" ...and then add the following lines: `[http] sslVerify = false` For more info, see here: SSL certificate is invalid

Install Visual Studio:
(2010: "\\FS-01\share\Windows Software Development Resources\Visual Studio 2010")
(2011: "\\FS-01\share\Windows Software Development Resources\Visual Studio 2012")
Install Git Extensions:
("\\FS-01\share\Windows Software Development Resources\git\git Extensions")
Launch Git Extensions on your development machine. After choosing your preferred UIUser Interface language, you
should have to configure some basic settings:
You will probably have to configure Git to ignore SSLSecure Socket Layer certificate errors (boo!).

You'll need to open the following config. file: "C:\Users\<Username>\.gitconfig"
...and then add the following lines:
```
[http]
	sslVerify = false
```
For more info, see here: SSL certificate is invalid

Project Setup – create a new project on the EDGEngineering Development Branch Stash server, and clone the repository locally:
Create a new project on the EDGEngineering Development Branch Stash server: (For a step-by-step process, read 1-8 on Create a New Project using Visual Studio) Visit your new project page. It should look something like this: Open Git Extensions, and choose the "Clone Repository" link: Copy the "Clone" URLUniform Resource Locator from the Stash repository (green circle below) into the Git Extensions dialog box (red circle below that): Type in an appropriate subdirectory name for your local working directory, and hit the "Clone" button: Congratulations! Your project is now set up! Once you've got some code written in your working directory, you can push up your first commit. So go write some code!

Project Setup – create a new project on the EDGEngineering Development Branch Stash server, and clone the repository locally:

Create a new project on the EDGEngineering Development Branch Stash server:
(For a step-by-step process, read 1-8 on Create a New Project using Visual Studio)
Visit your new project page. It should look something like this:
Open Git Extensions, and choose the "Clone Repository" link:
Copy the "Clone" URLUniform Resource Locator from the Stash repository (green circle below) into the Git Extensions dialog box (red circle below that):

Type in an appropriate subdirectory name for your local working directory, and hit the "Clone" button:
Congratulations! Your project is now set up!
Once you've got some code written in your working directory, you can push up your first commit.
So go write some code!

Preparing your first commit – setting up your ".gitignore" file:
So you've got some code written? Excellent! Let's get your repository set up to receive it. First, open Git Extensions and bring up your repository again: Click the large "Commit" button (circled below): It should bring up a window that looks like the following: Unfortunately, if you look closely, you'll see that there's a ton of log files, and temporary files, and object code files, and debugging symbol files, and stuff like that. Watch out – we certainly don't want to check those in!! Follow along to figure out how to get rid of them If you right-click on any of the undesirable files (I chose the first 'tlog' file, below), you should bring up a context menu with a very helpful option: "Add file to .gitignore". For example: After clicking on that option, the "Add files(s) to .gitIgnore" (sic) dialog box comes up: One nice thing about this dialog box that you can edit the file pattern in the upper box, and it will show you all of the files that match said pattern in the lower box. For example, I don't just want to ignore "Common/Debug/cl.command.1.tlog" – I want to ignore all of the ".tlog" files. So I'll type in a wildcard pattern: " .tlog ". Now the dialog box looks like this: In fact, you can enter patterns on multiple lines. You can even paste in an entire file! (Like the Visual Studio .gitignore file I found on Stack Overflow! Here it is below, after I sorted a few things and added comments.) # OSOperating System junk files: # [Tt]humbs.db .DS_Store # Build output files: # .exe .dll .lib # Visual Studio project files: # .vcxproj.filters .user .aps _i.c _p.c .ncb .suo .tlb .tlh .bak .[Cc]ache .ilk .log .sbr .sdf .opensdf ipch/ [Oo]User #?/ [Bb]in [Dd]ebug/ [Rr]elease/ # Visual Studio build files: # .idb .pch .pdb .ipch .tlog .lastbuildstate .unsuccessfulbuild .[Oo]User #? # MonoDevelop # .pidb .userprefs Ankh.NoLoad # Tooling # _ReSharper/ .resharper [Tt]est[Rr]esult .sass-cache # Project build files: # [Bb]uild/ # Subversion and SourceSafe files: # .svn .vspscc .vssscc # Office temp. files: # ~$ # Vim temp. files: # ~ # NuGet: # packages/ .nupkg # ncrunch # ncrunch crunch.local.xml # Visual Studio database project files # .dbmdl # Test files # .testsettings After pasting the entire file into the dialog box, mine looked like this: I clicked "Ignore", and then I had a much more appropriate-looking list of files to check in: The next set of instructions will cover using Git Extensions to "stage" things, and commit them to the repository.

Preparing your first commit – setting up your ".gitignore" file:

So you've got some code written? Excellent! Let's get your repository set up to receive it.

First, open Git Extensions and bring up your repository again:
Click the large "Commit" button (circled below):

It should bring up a window that looks like the following:

Unfortunately, if you look closely, you'll see that there's a ton of log files, and temporary files, and object code files, and
debugging symbol files, and stuff like that. Watch out – we certainly don't want to check those in!!
Follow along to figure out how to get rid of them
If you right-click on any of the undesirable files (I chose the first 'tlog' file, below), you should bring up a context menu
with a very helpful option: "Add file to .gitignore". For example:
After clicking on that option, the "Add files(s) to .gitIgnore" (sic) dialog box comes up:

One nice thing about this dialog box that you can edit the file pattern in the upper box, and it will show you all of the
files that match said pattern in the lower box. For example, I don't just want to ignore "Common/Debug/cl.command.1.tlog" –
I want to ignore all of the ".tlog" files. So I'll type in a wildcard pattern: " *.tlog ". Now the dialog box looks like this:

In fact, you can enter patterns on multiple lines. You can even paste in an entire file!
(Like the Visual Studio .gitignore file I found on Stack Overflow! Here it is below, after I sorted a few things and added comments.)

# OSOperating System junk files:
#
[Tt]humbs.db
*.DS_Store

# Build output files:
#
*.exe
*.dll
*.lib

# Visual Studio project files:
#
*.vcxproj.filters
*.user
*.aps
*_i.c
*_p.c
*.ncb
*.suo
*.tlb
*.tlh
*.bak
*.[Cc]ache
*.ilk
*.log
*.sbr
*.sdf
*.opensdf
ipch/
[Oo]User #?/
[Bb]in
[Dd]ebug*/
[Rr]elease*/

# Visual Studio build files:
#
*.idb
*.pch
*.pdb
*.ipch
*.tlog
*.lastbuildstate
*.unsuccessfulbuild
*.[Oo]User #?

# MonoDevelop
#
*.pidb
*.userprefs
Ankh.NoLoad

# Tooling
#
_ReSharper*/
*.resharper
[Tt]est[Rr]esult*
*.sass-cache

# Project build files:
#
[Bb]uild/

# Subversion and SourceSafe files:
#
.svn
*.vspscc
*.vssscc

# Office temp. files:
#
~$*

# Vim temp. files:
#
*~

# NuGet:
#
packages/
*.nupkg

# ncrunch
#
*ncrunch*
*crunch*.local.xml

# Visual Studio database project files
#
*.dbmdl

# Test files
#
*.testsettings

After pasting the entire file into the dialog box, mine looked like this:

I clicked "Ignore", and then I had a much more appropriate-looking list of files to check in:

The next set of instructions will cover using Git Extensions to "stage" things, and commit them to the repository.

Executing a commit – staging files and committing them to the repository:
It's important to remember that Git makes a distinction between "staged" and "unstaged" files. For example, maybe you modified 20 files in your project, but you only want to commit 10 of them. (Perhaps you're still working on the other 10, and they're not ready to commit yet?) Git allows you to check in only the subset you're interested in – this process is called "staging" files before a commit. In Git Extensions, you stage and commit files as follows: First, I've opened the Commit windows I've selected all of the files I want to commit (in my case, all of them, because this is my initial check-in), and now I'm about to click the "Stage" button, (circled below) : After clicking the 'Stage' button, the Commit window now looks like this: The next thing we're going to do is very important – we need to write a "Commit message". Always write a Commit Message! (How come? Because five months from now, when your project is in testing, you – or someone else! – may need to go back through the project history and answer a question like, "Why on earth did we edit SecureHeapMgr.cpp back in December???") Reference: A Note About Commit Messages (Tim Pope Blog) available Git Reference . You should especially take note of 2 conventions in particular: – Make sure the 1st line is a concise, single-line summary, 50 characters or less. – If you have additional detail about the files you're checking in, add additional paragraphs below the initial summary, separated by blank lines. Make sure the paragraph lines are wrapped around 72 characters or less. Write your commit message in the following field: Finally, we're ready to commit the files we've staged, along with the commit messages we've written. You'll see there are two (2) different Commit buttons circled in the figure below: What's the difference between these two buttons? – Commit: Commits your changes to your local repository only, whereas – Commit & push: Commits your changes to your local repository and pushes your changes up to the EDGEngineering Development Branch Stash server (so your colleagues can see them and merge them, if desired). Which one you choose will depend on how you and your colleagues decide to manage your project. Some projects have their developers commit locally and then run unit tests before committing changes to the central repository; some projects have their developers commit their changes to the central repository for a colleague to review them. As for me, at the moment I'm the only developer on this project. So yes, I will push my changes up to the Stash server Since there's no existing "master" branch on the remote server (or any branches for that matter), Git Extensions is going to ask if I want to create a new branch on the remote server: I click "Yes", and the following dialog box appears: Followed shortly by my repository window again: And that's it! The code has been checked in to the repository and pushed up to the remote server, and we're good to go! Now I have to get back to work and write some more code to commit

Executing a commit – staging files and committing them to the repository:

It's important to remember that Git makes a distinction between "staged" and "unstaged" files.

For example, maybe you modified 20 files in your project, but you only want to commit 10 of them.
(Perhaps you're still working on the other 10, and they're not ready to commit yet?)

Git allows you to check in only the subset you're interested in – this process is called "staging" files before a commit.
In Git Extensions, you stage and commit files as follows:

First, I've opened the Commit windows I've selected all of the files I want to commit (in my case, all of them, because this is my initial check-in),
and now I'm about to click the "Stage" button, (circled below) :
After clicking the 'Stage' button, the Commit window now looks like this:
The next thing we're going to do is very important – we need to write a "Commit message". Always write a Commit Message!
(How come? Because five months from now, when your project is in testing, you – or someone else! – may need to go back through
the project history and answer a question like, "Why on earth did we edit SecureHeapMgr.cpp back in December???")

Reference: A Note About Commit Messages (Tim Pope Blog) available Git Reference . You should especially take note of 2 conventions in particular:

– Make sure the 1st line is a concise, single-line summary, 50 characters or less.

– If you have additional detail about the files you're checking in, add additional paragraphs below the initial summary, separated by blank lines.
Make sure the paragraph lines are wrapped around 72 characters or less.

Write your commit message in the following field:
Finally, we're ready to commit the files we've staged, along with the commit messages we've written.
You'll see there are two (2) different Commit buttons circled in the figure below:

What's the difference between these two buttons?

– Commit: Commits your changes to your local repository only, whereas

– Commit & push: Commits your changes to your local repository and pushes your changes up to the EDGEngineering Development Branch Stash server
(so your colleagues can see them and merge them, if desired).

Which one you choose will depend on how you and your colleagues decide to manage your project.
Some projects have their developers commit locally and then run unit tests before committing changes to the central repository;
some projects have their developers commit their changes to the central repository for a colleague to review them.

As for me, at the moment I'm the only developer on this project. So yes, I will push my changes up to the Stash server

Since there's no existing "master" branch on the remote server (or any branches for that matter), Git Extensions is going to ask
if I want to create a new branch on the remote server:

I click "Yes", and the following dialog box appears:

Followed shortly by my repository window again:
And that's it! The code has been checked in to the repository and pushed up to the remote server, and we're good to go!
Now I have to get back to work and write some more code to commit

Comments:

2013-12-05 11:04 [User #524297]:

Great stuff User #?, keep it coming.

My only suggestion, regarding:

As for me, at the moment I'm the only developer on this project. So yes, I will push my changes up to the Stash server

This way of thought seems like it might be true, but a better way to distinguish the two is to think of git commit as "tracking the changes", and git push as "publishing the changes". Sometimes, your changes that you track might not be ready for prime time public consumption, but you still want to track them locally. Typically developers will take the opportunity to polish ongoing changes locally, running tests and so forth, before publishing (e.g. using git rebase). The thing is, once you publish your changes, you can't (easily) make those polishing changes anymore... the genie is out of the bottle, and you're trying to rewrite history.

Now, given that your [Klaxon project on Stash is not readable by others (*cough* you should change this), you can probably make these edits anyway without too much concern.

Additionally, I recommend to everyone starting in Git that they not do active development out of master. The articles at Git Workflows will really help outline some basic workflows on how to use Git for maximum effectiveness, solo or grouped.

Attachments:

Previous versions:

| 1 empty | 2 | 3 |

Contact

Tor

Tails

Tips

1. Contact us if you have specific problems

2. What computer to use

3. Do not talk about your submission to others

After

1. Do not talk about your submission to others

2. Act normal

3. Remove traces of your submission

4. If you face legal action

Submit documents to WikiLeaks

Vault7: CIA Hacking Tools Revealed

Git For Visual Studio Users

Comments:

Attachments:

Previous versions:

e-Highlighter