Trying to get started with git

Question

I'm trying to get started using git, but I'm having some troubles right away. I'm using Git GUI for Windows. Keep in mind I've never used version control before and don't really know how it works.

What I have is a Code::Blocks C project in a folder on my laptop's hard drive. I opened Git and created a new repository on a USB hard drive. I figured, I could create a branch, which led to the already-existing directory of my project, and then commit all the code in it to the repository. Then every time I wanted to work on this project, I could check out my code, open up the Code::Blocks project and edit. And then get into different branches and stuff, you know, all that jazz.

So I created this repository, and went to create a branch from the menu. I got this dialog, which asked me for either a branch name, or to "Match Tracking Branch Name (whatever that means)." Then, under "Starting Revision," it has a few options. One is "Revision expression" next to a text box, and no matter what I enter it is an invalid revision expression. So I tried the other options, "Local Branch," "Tracking Branch," and "Tag." These enable another text box, but even if "Revision expression" isn't selected, it still says I have entered an invalid one. What is a revision expression? How do I just, check out code, to a directory on my hard drive?

Oh, and then, there is an "Options" section with "Update Existing Branch: [ ] No [x] Fast Forward Only [ ] Reset,"
and two check boxes, "Fetch Tracking Branch" and "Check Out After Creation (this one is obvious)." What do all of these mean? What's a tracking branch? What does "Fast Forward Only" and "Reset" refer to? I have no idea what I'm doing or what I've gotten myself into.

Answer 1

Lets start with the branching. When you first create a new repository (which you always create within your working directory) the first branch you work on is master.

Good practice is to create a second branch develop and do a checkout. A checkout means you are working in this branch.

From the development branch you could do two things

1. You could keep working in your development branch ... or
2. You can branch out to feature branches or bug-branches

Let's say you are to work on an order system. YOu would need at least three feature branches: add an order, update an order and print an order so you create feature-branch add-order (I believe you can use dashes in git), and featurebranch edit-order. You can create them so it becomes a tree (feature/add-order)

inside add-order you do you add-order stuff. When you want to store your work in GIT you add and commit your work - meaning storing the work in GIT.

When you are all done, you merge this feature into the development branch. A good practice here is to merge develop into your feature-branch. The reason for this is that you avoid having a development-branch that fails. If all works, you check out the development branch and you merge the feature branch in.

You can choose to delete the add-order branch, or you can keep the branch.

So, you are "done" with the add order feature and you start develop the edit-order feature. You create the feature/edit-order branch and do a checkout (meaning you are working in the edit order branch).

Someone who do QA-testing for you tests the add-order and notices something is missing or not working as expected. You save your code. you commit your code to the feature/edit-order branch.

Now you can do two things.

1. Create a bug branch (bug/fix-add-order for instance) and do what you have to do. Then add, commit, merge development to bug/fix-add-order), checkout development and merge (into development) .. or ..
2. if you kept the feature/add-order branch, you can do your additions or bug-fixes there.

When you have fixed whatever was missing/not working. Do the merge and then you can go back to edit-order.

Back in the days this process was difficult with other version control systems (like subversion and so on) and has become much easier with git.

Here are a few links to git and git workflow: https://www.atlassian.com/git/tutorials/learn-git-with-bitbucket-cloud

https://danielkummer.github.io/git-flow-cheatsheet/

https://nvie.com/posts/a-successful-git-branching-model/

Hope this information was helpful.

Answer 2

I have only skimmed through The Git Parable mentioned at Simon Edwards' blog post, but it looks very promising in getting a nice conseptual overview without too much details, so I would reccomend reading it for learning git. It is high on my "to read" list, even if I have been using git for some time.

Answer 3

I'm a little confused about what you're trying to do.

First of all, if your code is on your laptop, then why are you creating a repository on your USB drive? With git, unlike CVS or SVN, the repository always exists in your project's root directory.

Here's what I think you want: Create a new git repository on your laptop hard drive at the root of your C project. Then check the files in to the repository and commit. Now you want to create a branch so you can add color to all the dialog boxes (for example), so you create a new local branch called "color-dialogs". You're not tagging and you're not tracking. Tagging is what you do when you release version 1.0: you mark a particular revision as "1.0" so you can go back to it. Then later you make a "1.1" or "2.0" tag. Tracking is what you do when you want your branch to be the same as someone else's. For example, I want my project to have all the latest color dialog boxes so I track your branch named "color-dialogs" but I don't call it that, I just call my branch "master" because I don't care about the old black and white dialogs. Whenever I do a pull from your repository, since I'm tracking your "color-dialogs" branch, I'll pull in all the updates you've made to that branch.

Fast-forwarding is when you pull updates to a branch that you haven't made changes to.

So a summary: create the repository on your laptop HD in your project folder. Create local branches if you want in there, and you can switch back and forth between branches at the touch of a button (using git checkout). If you want a repository on a different drive, what you do is you clone the repository from your internal HD to your USB stick. Then you can pull changes from one repository to the other (each is a complete standalone repository).