Github - using repositories

I have many projects to put on Github but have not much experience working with this source code system.
I use mostly TFS or SVN but want now Github to integrate to VSCode and Visual Studio.
Can anyone direct me with tutorials for newbies and good examples how to control repositories and projects with Git? I prefer more UI side than console )
Thanks

You could try here;

Or you could download the free O'Reilly book on Github https://gist.github.com/augbog/d65f6600188fece854cb341734c5fd12

Beyond learning a basic Git/GitHub workflow, I never found the tutorials very helpful.

This is what you really need to know.

Workflow for working on your own repositories (repositories where you have push rights):

  • clone a local copy of the online repo, or if you already have a clone then pull to make sure it's up to date. GitHub does allow you to work on the online copy via the web interface but this is very limiting and so it shouldn't be used for anything but the most simple changes.
  • Make changes to the repo's files.
  • commit changes.
  • push commit to the online repo.

Workflow for contributing to repositories where you don't have push rights:

  • fork your own copy of the repo to work in.
  • clone a local copy of the fork to work on.
  • branch a development branch for the specific feature/bug request you want to propose. Remember to make a branch for each one.
  • Make changes to the repo's files.
  • commit the changes.
  • push the commit(s) to your online repo.
  • Submit a pull request from your development branch to the target branch in the parent repo. I find it easiest to just do this step via the GitHub web interface.

Once you understand the workflow you can simply do a search for any specific process for more information.

After a while you'll probably find the need to do other more advanced processes but when that time comes you can just search for how to do exactly what you need rather than trying to understand the entirety of Git, which will include a lot of information you'll never use or forget before you do need it. For the processes that I do rarely enough to forget in the interim I keep a notes file that contains instructions for each process. Usually for the advanced processes I find it's easiest/necessary to use Git commands rather than the GUI I normally prefer for the standard processes.

The other processes I find most useful are:

  • rebase: I use this to copy commits from one branch to another.
  • rebase -i: (interactive rebase) I use this when I need to make fixes to commits in my local copy of the repo that I haven't yet pushed to the online repo. You can reword a commit to change the commit message. You can fixup to merge two commits together. You can edit to modify a commit. You can drop to delete commits.
  • reset: Set the repository back to a previous point in the commit history.
  • stash: Store the uncommitted changes to the repository.

You should be aware those are available but don't worry about learning them until you actually have the need for it.

Since you prefer a GUI, you might consider starting with GitHub Desktop. It's a pretty good program that's very beginner friendly. Once you start needing to do more advanced processes you'll find that you can't do them via GitHub Desktop. You always have the command line for these processes but you might want to upgrade to a new application that allows you to do more of these processes via the GUI (and thus has a less beginner friendly GUI). I had a hard time finding a replacement for GitHub Desktop because I found that most of the alternatives had really crappy UI. A lot of them (e.g. GitKraken, SourceTree) seem to focus more on being "pretty" than being useful. After trying every single one I found GitExtensions to be the best by far. The UI is definitely much less beginner friendly than GitHub Desktop and that's why I don't necessarily recommend using it from the start.

Github could be on death row (Micro$oft take-over).

I think it likely that Microsoft’s ownership will be harmful but that’s going to be a slow process. For the foreseeable future GitHub is going to still be the best choice for a Git hosting service by far. Saying it’s on “death row” is certainly a huge exaggeration.

For years I’ve been waiting for the slightest excuse (e.g. fix bug or submit issue report on a project hosted there) to create an account (not migrate) on either of the major competitors: BitBucket and GitLab. I have not found one. I’ve only come across mention of two Arduino projects on BitBucket and none on GitLab, compared to thousands on GitHub.

If the time comes to leave GitHub, the transition to a competing service should be fairly easy since to compete they will need to make it so. I noticed GitHub did a bunch of work on the “Migration API” just before the sale. The most difficult part of the transition will be leaving behind the huge user base of GitHub.

Definitely check out tortoise git
It integrates into Windows File explorer. This is what makes it really nice.
It changes the icons in the explorer window so you can instantly tell the status of files and which files have been modified.
You can right click to do all the needed git functions including being able to show the diff of where a file is vs the branch where it came from.

For linux there is rabbitVCS

--- bill

bperrybap:
Definitely check out tortoise git
It integrates into Windows File explorer. This is what makes it really nice.
It changes the icons in the explorer window so you can instantly tell the status of files and which files have been modified.
You can right click to do all the needed git functions including being able to show the diff of where a file is vs the branch where it came from.

For linux there is rabbitVCS

--- bill

Yes - Tortoise is my favorite but for SVN. Thanks!
I will try it

Deous:
Yes - Tortoise is my favorite but for SVN. Thanks!
I will try it

If you are familiar with tortoise then you are mostly there as it works pretty the same for git.
You just need to get a little familiar with how git works vs svn.
While similar there are some significant differences - however pretty much all differences are for the better.
The one that simply isn't really possible with git is the use of SCCS/RCS/CVS/SVN keywords.
If you are using them, you will need to abandon their use.

The beauty of git over SVN is that you have a full local copy of the repository so you don't have to have a connection to the remote repository to do many operations like you need with SVN.
That and branches are trivial with git which is its advantage over pretty much all its predecessors going all the way back to SCCS.

You can do most of what you need to do with the GUI, occasionally you may need to step out and use the command line to do some of the more intricate operations. Not sure how well the command line git stuff works these days on Windows.

--- bill