7 minutes ago, Alberth said:

Not sure how feasible that is with git.

I think one can spend a decent amount of time as a beginner using git with a single "master branch" and just understanding that "push origin master" is the magic incantation to push one's changes to GitHub without having to dive really deep into either the technical details of what a branch is, or the broad range of applicable branching and branch-management techniques and processes.

And in think in this case, that's what I'd recommend the OP do. (Until it's demonstrated he needs to do something more involved.)

For single person I agree that's definitely the right solution. However I thought the idea was to have a  multi-person project?

If not, then please Josheir, ignore my ramblings

Just now, jpetrie said:

If you are only going to use a GUI tool, you'll have to restrict yourself to documentation and support forums for that tool which, depending on the tool, may be sparse.

For now I would like to use a graphical tool.  Can anyone suggest one to use that perhaps is not sparse in it's support?  And while I'm asking perhaps an easy git terminal too?

Thanks,

Josheir 

How does git handle the history of the project?  Both remote and server if this makes sense?

Thank you,

Josheir

33 minutes ago, Josheir said:

For now I would like to use a graphical tool.  Can anyone suggest one to use that perhaps is not sparse in it's support?  And while I'm asking perhaps an easy git terminal too?

GitHub Desktop is probably the simplest thing I've seen. It hides a lot of the complexity from you and integrates tightly with GitHub itself.

There's no such thing as a "git terminal." The git command-line tool is the git command-line tool. It doesn't have training wheels. If you're instead referring to a replacement for cmd.exe or whatever, the bash executable that comes with the Git for Windows package is probably where you want to start.

25 minutes ago, Josheir said:

How does git handle the history of the project?  Both remote and server if this makes sense?

By default, a git repository contains the entire history of the project. This includes the clone of that repository on your machine and the clone of that repository on any other servers, such as GitHub. This is, in part, what makes it "distributed" version control. There is no authoritative, backing server for the repository except one you may establish by convention.

Here's this:  http://rogerdudler.github.io/git-guide/

or simple google "git for beginners" ...

And NO you do NOT need to use gitflow or some other pull request, branch heavy strategy to use git with SMALL teams.

But if you are going to use ANY source control with other people AT ALL ... then you really need to learn to make small commits (and push them) very often.

the default branch in git is called master.  that will be the branch that you and everyone else either commits to ... or merges into ... that will show up on the sites (ie githubs) web portal as the "current" version of the code.  anytime some new person downloads the code ("git clone" a repository - in git lingo), they will initially be on the current version of the master branch.

The absolute minimum workflow on git is basically like this:

1.  ONCE - Clone a repository to have a local working copy. "git clone https://PROJECT_URL_HERE"

2.  EACH TIME YOU START WORKING - pull the latest code "git pull"

3.  MAKE A SET OF CHANGES

4.  COMMIT THOSE CHANGES - "git commit" via a graphical tool that selects things for you, or "git add ." followed by "git commit -m "your checkin message here"" (this saves all your change as a commit, that you can see in your history and such)

5. UPLOAD THOSE CHANGES TO THE TEAM "git push" (this sends all your commits to the server - usually the place you cloned from).

Repeat step 2 whenever you want to update your local code with the latest version that every has pushed.

Repeat steps 2-5 whenever you want to do more work and then share it.

DONT EVER FORGET STEP 2 before you start working on a new change set.

DONT EVER FORGET STEP 5 when you finish a good set of changes that has any value anyone might ever want (including yourself)

don't be afraid to break code, you can always go backward.  it is better to commit and push bad code a few times a month, and spend a few minutes or hours making it good code ... then to forget to pull or commit or push good code and spend hours and hours in merge conflict hell!

Pull early, pull often. That's what I always said. It's much easier to do many small merges than one big one.

On 5/7/2017 at 10:11 PM, Josheir said:

For now I would like to use a graphical tool.  Can anyone suggest one to use that perhaps is not sparse in it's support?

• Visual Studio 2015 or 2017 should be supported enough.
• Git support in Eclipse would be another well-supported option.
• The "command line" git tool actually includes git gui and gitk, two simple and serviceable GUI tools.
• The Magit plug-in for Emacs has many fans, but I've been unable to install it on Windows due to its assumptions about paths; it should work fine on Linux and OSX.

Other options include SourceTree (requires Atlassian account), TortoiseGit, and GitKraken.

I think you won't be using more than 5-6 git shell commands, if you decide using git.

Also github provides you useful GUI tools: issue tracker, pull request manager... on top of that github provides you a GUI version of git commands, if you don't want to touch the shell. Finally you have tons of github integrations(travis ci, appveyor...).