GIT For Beginners

Target Audience

Programmers that need a good source code repository and versioning system.

Expected Knowledge Level:

Beginner through Advanced. You do not necessarily have to have experience with other version control systems, but it helps, of course. Your knowledge of programming is of minimal importance to this article. But if you’re reading this, you’re most likely a programmer, and that’s all that really matters.

Purpose of this article:

To give you a head start with Git. This is not a complete tutorial. This will give you critical pieces of information that are usually lacking in other documentation that experienced GIT users forget that non Git users don’t already know.

What IS Git?

Git is a source code repository and versioning system. It’s free and open source. It lets you keep track of your source code projects, have them backed up on zero or more remote storage locations, share your source code (if you want), keep track of versions of your source code, branch from your source code to work on special features without interfering with the main branch, merge branches together, provide opportunities to review source before merging it back into an important branch (for teams), allows teams of programmers to easily work on the same project without undue burdens of coordination and synchronization.

What Problems is GIT a Solution For? (Why GIT?)

First, let’s answer what version control systems, in general, solve, not just GIT:

Provides a backup for your source code.
Allows collaboration with other programmers.
Allows keeping track of versions of your source.
Allows branching and/or forking of your source to work on specific features or bugs or experimental releases without contaminating the main source branch.
Replication of your source for safety.
Many other reasons.

So, why GIT in particular? I’m not an advocate for GIT in particular. I like it and I use it. What’s important is that you’re using a modern source code control system and have policies in place to prevent problems and provide standardized solutions. GIT is one of many solutions. However, GIT has risen in popularity and seems to be the defacto go-to source control software these days. And there’s good reason for that. It was created by Linus Torvalds (the creator of Linux) and is actively maintained. GitHub.com, arguably the most popular source code repo on the planet is based on GIT. And like most source control systems, GIT is multi-platform.

Again, I’m not advocating for GIT. I’m writing a quick-start guide with a little bit of background. I’ve written plenty of articles on subversion too. Note also that Mercurial is a Git derivitive, so pretty much everything I cover here applies to Mercurial as well.

Things You Need to Know:

GIT is not easy to get started with if you’re not familiar with it, and by definition, if you’re getting started with it, you’re NOT familiar with it. For one: GIT is not a single product. Since it’s open source, there are MANY products that are GIT compatible and you have options for command line, GUI, embedded into your favorites IDE or source editors, plus multiple server options as well.

1. Terminology

“Repo”: A managed database of a source code project. Unlike other source control solutions like Subversion, where a “repo” is a centralized database where you store all your projects, in GIT, a “repo” is where you store ONE source code project. For example, say you’re writing a game. You’d have a dedicated repo just for that game. On your local machine, you’ll have a complete repo folder named “.get” inside your primary source code folder.
“Project”: A centralized server can host multiple software projects. Each project is generally set up for a single software application being worked on by programmers. Programmers will “clone” or “check out” the project to their local machine, creating a local “repo”.
“Check Out”: The process of retrieving source code from a branch in a repo. That repo could be a remote repo or your local repo.
“Clone”: Pretty much the same thing as “Check Out”. In other source code providers, “checking out” a project informs the server that you have it checked out. In GIT, the server is never aware of who has what and doesn’t care and doesn’t need to know. You’ll simply “clone” the project to get a local copy of the database and work on it locally, committing locally, then eventually push your changes back up.
“Check in”: This is not a term used in the world of GIT.
“Commit”: The act of submitting your local source code edits into your local repository.
“Push”: The act of sending all of your commits from one of your local repositories up to a remote server. If someone else committed and pushed code in on any of the same files you worked on, chances are you’ll have a conflict and will be forced to perform a merge.
“Merge”: The act of you being presented with two conflicting versions of the same source file. You’ll be asked to pick and choose which differing lines from both versions should be merged into a single file version before committing.
“Pull”: The act of you pulling down the latest changes from a remote repository into your local one. Note that “pull” is in the direction of the machine in which the code is moving to. Whoever triggers a pull, does so from the location of the machine in which the code moves to. For example you “pull” from the server to your local machine. You log onto the server’s web interface and request a “pull request” to move your code into the central repository.
“Pull Request”: The act of a programmer requesting that their committed and pushed changes be merged with a more important branch. One or more other programmers (frequently the project lead) will review your changes and decided whether or not to allow them to become part of the bigger project. You may be asked to make some minor changes and re-submit your pull request or it may be rejected out-right.

2. Storage

Unlike Subversion and the much older Microsoft Visual SourceSafe, you don’t have 1 server and multiple clients. Instead, GIT has no “real” central server. Though most people use it in a way that sets up one repo as the understood central repo.

You don’t simply check out from the server, edit, then check back in. Instead, your local machine, itself, becomes a server. You become a client to your own server. So, when you check out and commit your code, you’re doing it from and to your local repository. At any time, you can push all your commits from your local repo up to another repo. You can “pull” from a remote repo to yours to get yours up to date.

But while writing code, you’ll create branches locally in your own repo, then checkout from those local branches, edit, commit. You may do this many times. Eventually, you’ll want to push your changes up to the shared repo.

3. Branching

If you’ve ever tried branching in things like subversion, you’re probably aware of how difficult it is and how easy it is to screw things up badly.

SUBVERSION BRANCH: HOW TO

In GIT, it becomes ridiculously easy. It’s so easy, in fact, that branching will become your common, every day practice. Everything you do… every feature you add, every bug you fix, will be done in a branch.

In all fairness though, it’s still hard if you’re not using the right tools. If you’re a command-line junky (which I do not recommend, nor should anyone be impressed by someone insisting on sticking with the command-line), you can implement best-practices like GitFlow. Better yet, are plugins for GitFlow that are made for Visual Studio, GitKraken, and many other Git clients. This removes the complexity of branching and merging down to a couple of clicks and removes the human error component, making your workflow incredibly powerful and easy at the same time.

4. GitFlow

Make your life much less complicated. Start using the GitFlow best practice. Just because GIT supports branching, doesn’t mean that everyone’s going to do it the same, nor that everyone’s doing it “good”. What’s your policy on how code moves from developers to production? There are just about an infinite amount of hodge-podge plans using GIT to make that happen. GitFlow is a standardized way of doing it. In short (very short) explanation, here it is:

When you create your project, you create a “main” or “master” branch. The becomes the gold standard for finished, polished code. You will most likely build what’s in there and publish it.
Create a branch off of “master” called “develop”. This will be the main, working branch where programmers will branch from and merge back into. This isn’t necessarily the “best” version of the code, but it’ll be the “latest” version that all developers use as their developing silver standard.
If you are tasked with fixing a bug or creating a new feature, you’ll create a new branch derived from the develop branch. You’ll work on your fix or feature until done, then merge it back into develop.
Some coding shops like to have a “bug fixes” branch, a “features” branch, and “hot fixes” branch from the develop branch. Then the developers never branch directly from the “develop” branch. They’ll instead branch from one of those 3 branches.

Making this happen is a chore if you don’t have tools that are designed for this and you are likely to introduce big mistakes without using GitFlow tools. If you’re using Microsoft Visual Studio, go to the Extensions and search for GitFlow. Install that, then you can very very easily automatically create, pull, and work on a feature or bug or hot fix branch. Then when you’re done, you simply click “finish” and it’ll do all the committing, pushing, and merging for you (except for the merging where human intervention is required). Your F-Up rate will greatly decline and your co-workers will appreciate it!

If you’re using GitKraken, there’s a plugin for GitFlow there too. You can use both Visual Studio’s GitFlow and GitKraken’s GitFlow interchangeably, at the same time, on the same project.

No joke! Go get GitFlow now!

Resources/Tools:

The base GIT software: https://git-scm.com/downloads
GIT Bash
GitFlow
Git Clients
- Git GUIs
- Inside Microsoft Visual Studio
  - VS directly supports GIT
  - Install the GitFlow extension.
- Eclipse
- Sublime
- Android Studio
- Stand-Alone clients
  - GitKraken
  - SourceTree
  - GitExtensions
  - Git Bash
GIT Servers
- BitBucket.com
- GitHub.com
- VisualStudio.com

Thank you for sharing this article. See this image?

You’ll find actual working versions of them at the top and bottom of this article. Please click the appropriate buttons in it to let your friends know about this article.

2015-10-19

Error: “Interface name is not valid at this point”

If you ever get the Visual Studio error: “Interface name is not valid at this point”, it’s a simple fix. You have a simple typo. See the example here:

container.RegisterType<IUser, User);

Notice the closing parenthesis? There’s no open parenthesis. Notice the open angled bracket? There’s no closing angled bracket.
Once you see that, the fix is obvious: Replace the “)” with “>()”.

Thank you for sharing this article. See this image?

You’ll find actual working versions of them at the top and bottom of this article. Please click the appropriate buttons in it to let your friends know about this article.

2015-04-20

Add a web.config transform and a publish profile in Visual Studio 2013

If you need to deploy your app to multiple environments, like in most corporate IT shops (dev, QA, Staging, Training, Production, etc…), then you’ll need to have multiple versions of your config files, or better yet, one config file and “transform” files (one for each deployment environment) that describe ONLY the differences between the main config file and that particular environment.

For example, the connection string in the QA environment is likely different than the connection string in your Dev environment, which is different than your QA environment and again different in your live Production environment.

[GARD]

I’m not going to explain how to WRITE a config transform (how to tell it what needs to change). At least, not in THIS article. But I will tell you how to tell Visual Studio that you have multiple environments and how to make Visual Studio create the basic config transforms for you.

In this example, I’m creating a WCF Service application (works the same with pretty much any web type of application).

Are you deploying a NON Asp.Net app (like a click-once app or a WinForms or WPF app)? If so, install the Nuget package “Slow Cheetah”. Why? Because Visual Studio has built in support for all this for web.config files, but NOT for app.config files. Slow Cheetah lets you make transforms for ANY file in your project.
Right-Click your project and choose “Publish…”
In the “Publish Web” dialog, choose “Custom”
Give it a name. NOTE! If you have a different admin managing your deployment and/or build servers, you may want to check with them on what name to use, because it will make a difference between whether your stuff works or doesn’t! For this example, I’ll call the transform “QA”
Choose your deployment method (web publish, file copy, etc…). For this example, I’m choosing “File System” since it requires fewer settings to fill out and I’m going to leave “Target location:” blank. My deployment admin will fill that in later, so I don’t even need to know this. Click “Next”.
Choose whether this deployment should be a “Release” or a “Debug” deployment. This will cause it to build it as debug or release. (You will also have a debug and a release transform of your web.config file and this new QA transform will inherit from either of those).
1. Expand “File Publish Options” and check the items you need, then click “Next”
Final screen in the wizard. Click “Close”. You can’t click “Publish” if you left the target path blank above.

[GARD]

You’ve now successfully created a publish profile.

Now you’ll need to create a Web.config transform for this profile.

Rich-Click your QA.pubxml file and choose “Add Config Transform”. Do NOT choose “Add Transform” if you have Slow Cheetah installed.

You now have a new Web.QA.config file.

You can now code your base Web.config file the way you need it to run locally during development. In your Web.QA.config file, you can add transforms to modify settings in your web.config file so that when you build for that environment, Visual Studio will produce a web.config file that’s right for that environment.

You can repeat these steps to add as many publish profiles as you need.

See these images?

You’ll find actual working versions of them at the top and bottom of this article. Please click the appropriate buttons in it to let your friends know about this article.

Check back later for updates too!

2015-02-05

Creating a NuGet package

This is a short and dirty post, which does NOT cover every possibility. This post assumes you’re done writing and testing your project and are now ready to deploy as a NuGet package, that you’re on a Windows PC, and are using Visual Studio.

[GARD]

Open a PowerShell command prompt and CD into your project folder where your .csproj file lives.
type nuget spec
1. You might have to do: nuget spec -f to overwrite an existing nuspec file.
Edit the *.nuspec file created and change the variables you need. Note that the ones with $stuff$ are pulling from your Assembly.cs file. Edit your Assembly.cs file to have the right stuff so you don’t have to re-enter it every time here.
Some things in .nuspec don’t have attributes in the Assembly.cs file, so you’ll have to manually enter them, such as:
1. Update text
2. Tags
Save the .nuspec file.
From the PowerShell command line, type: nuget pack MyProjectName.csproj
1. or nuget pack MyProjectName.csproj -IncludeReferencedProjects to make sure it includes the stuff it references.
Now, copy your package file to your nuget repository and it should be available to other developers from within Visual Studio’s NuGet package manager.

2014-10-08

An error occurred while signing: SignTool.exe not found.

Ever get either of these two errors while trying to deploy a .Net app? Specifically, while trying to publish a Click-Once deployed app (it can happen in other cases too)?

I’ve got a freshly built PC with Visual Studio 2013 installed and one of the first apps I created was a simple WinForms app with Click-Once deployment and I got this error.

After much frustrated Googling, I found no answers, so I figured this one out myself.

Here’s why this error happens

[GARD]

The signtool.exe file is actually missing. But, that doesn’t mean you don’t have it on your PC. There are multiple SDK versions likely installed on your machine, but the signtool.exe isn’t in all of them and where ever Visual Studio is looking for it is NOT one of the locations that has it.

Solution

I searched my hard drive for signtool.exe and found it here:

C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin

Then I noticed that in C:\Program Files (x86)\Microsoft SDKs\Windows

there were multiple version folders. I placed a copy of signtool.exe in each one of them inside their bin folder. If they didn’t have a bin folder, I created one.

Turns out, the v7.0A\bin folder is where it needed to be (at least, on MY machine). After placing a copy of signtool.exe there, it solved the problem.

[GARD]

See these images?

You’ll find an actual working versions of them at the top and bottom of this article. Please click the appropriate buttons in it to let your friends know about this article.

Check back later for updates too!

2012-01-29

Setting up SQLite on 64bit Windows 7

If you try to install the 64 bit version of SQLite on your Windows 7 64 bit system, you’ll find that your code will break. It simply won’t work. You’ll also find that when you try to add a connection in “Server Explorer” inside of Visual Studio, that there’s no option for making a SQLite connection.

Click here to follow me on Google+.

Follow me on Twitter @CSharpner.

This is because, for some reason, none of the current versions have the install for a SQLite connector. For that, you’ll have to install the really old version 1.0.66.0 executable first. After that, you can install the latest 32bit version (the 64bit version doesn’t work). Once 1.0.66.0 is installed, you’ll have SQLite available in Visual Studio:

You can get v 1.0.66.0 from here:

You can download the 32bit DLLs here sqlite-netFx35-setup-bundle-x64-2008-1.0.77.0.zip:. It’s under the section titled “Precompiled binaries for Windows”.

See these images?

You’ll find an actual working versions of them at the top and bottom of this article. Please click the appropriate buttons in it to let your friends know about this article.