If you followed my last post, you’ve got Git installed. You can initialize and commit to a repository. What now?
You could constantly type git branch to see which one you’re on, and git status to see how many adds / mods / deletes you have, like this:
Alternatively, you could just see those bits of information in your prompt:
This magic comes from posh-git, and here’s the way I got it installed. These are just about the same instructions as on the github page linked above, but I make a few assumptions. For example, you’re using a decent version of Powershell and you added Git to your path as instructed in my last post.
1 2 3
What does this do?
- First we get the code. We’ll talk more about git clone later.
- Next we set an execution policy. This might already be set. You could use Get-ExecutionPolicy to find out, but a set is quicker than a check plus a set.
- Finally we run the install script that is in the directory that git clone created.
If you still have that “demo” dir/repo we created last time, you can cd into it, change some files, and see the fruits of our labor!
If you’ve been using TFS, SVN, Fortress, or Visual SourceSafe, you’ve probably become accustomed to Visual Studio deciding what goes into source control and what doesn’t. Add a file to the project? That’s included. Build? Those binaries are not.
Git is file system based, which means if it’s a file, it’s included. How can we prevent junk from getting into our repository? Tell Git to ignore what doesn’t belong!
Note that I’ve been using this handy dandy trick to make projects automatically restore NuGet packages before each build. If you do this as well, you probably want to kill the two negations at the bottom of the file that tell Git to include NuGet package DLLs.
You may not fully appreciate this one until we talk about branching, merging, and the strategies surrounding this topic, but let’s get it setup anyway. You can wait and do this later (after you’ve seen why you’ll want it), or you can trust me and get this out of the wayÂ
First, we needÂ to collect two dependencies that gitflow utilizes.
- Navigate to http://gnuwin32.sourceforge.net/packages/util-linux-ng.htm
- Get the Binaries zip and copy the getopt.exefile to your git\bin
- Get the Dependencies zip and copy the libintl32.dll to your git\bin
Now, from the command line
1 2 3
So what does this do?
- First, get some code again. Do not forget the –recursive flag!
- Change to the gitflow directory that git clone just created
- Run the installation
Like I said, what gitflow does and why you’ll want it will come into play later, as we explore some of the more popular branching strategies in the Git universe. In the next post, we’ll learn how Git differs from SVN, TFS (or heaven forbid Visual SourceSafe), and take a look at the strategy upon which gitflow was based.
Alright…if you’re already familiar with Git but not with gitflow, check this out.
This post originally appeared on The DevStop.