Is it just me or is Github as unnecessarily confusing as possible?! I just installed the local side (GitShell and GitHub). The front end is just completely confusing - I've used CVS and SourceSafe for years and went with Github because of how simple it's reputation is.
Does anyone know of any nice and easy step-by-step tutorials I can follow for the front end (I'd prefer to use the front end instead of the shell).
Thanks
Do you mean, you want to use git? Github is a web service you use with git. There's plenty resources on how to use git on the web. You don;t need something from GitHub or even any other commercial product to use git. You don't even need GitHub.
I guess I need an even simpler tutorial on git itself then. I've set up an account on Github on the premise it boasted how straight forward it was and my short research on it sealed the deal. When you get down to the nitty gritty, however, some of it looks very unintuitive.
Hi,
I used this tutorial for getting into git.
https://www.atlassian.com/git/tutorials/setting-up-a-repository
Best Regards
Olaf
Github is easy to use if you are already familiar with a typical git workflow, or some other decentralized source control system.
If you are coming from a centralized system like cvs or svn it will look confusing at first.
I guess I need an even simpler tutorial on git itself then. I've set up an account on Github on the premise it boasted how straight forward it was and my short research on it sealed the deal. When you get down to the nitty gritty, however, some of it looks very unintuitive.
Assuming you are already a git user, then github is very straight forward!
If you want to learn git, you don't need a fancy server on the interwabs. You can create a git repo on your local drive and learn to work with it there.
You also don't have to use github's client. I personally use TortoiseGit, plus the command line. I would definitely recommend learning git from the command line, as it really helps to understand how it all works. There's only half a dozen different commands you need day-to-day.
With CVS/SubVersion/etc, you "update" to fetch changes from the server into your repo, and you "commit" to send your changes back to the repo. When updating, you might get conflicts if you've also got local changes.
With Git, you "fetch" to fetch changes from the server, BUT, these changes aren't immediately applied, just downloaded and kept in the background.
When you want to apply those remote changes, you "rebase", which rewinds the log to the most recent common ancestor (the log entry that both your local version, and the servers version descend from), then it applies the server's changes, and then it re-applies your local changes (which might cause conflicts).
With Git, "commit" takes all your local changes and adds them to the log/history... but does not send them to the server. You can commit many times locally before you decide to send your changes back to the central repo.
When you're happy with your local commits, you can "push" to send them to the central server.
So - instead of "update" you perform "fetch & rebase", and instead of commit your perform "commit & push".
There's a lot more to it than that... but I found this to be the biggest thing to get used to -- that you've got a full history log locally, and you can perform loads of local changes to it!
I guess I need an even simpler tutorial on git itself then. I've set up an account on Github on the premise it boasted how straight forward it was and my short research on it sealed the deal. When you get down to the nitty gritty, however, some of it looks very unintuitive.
Assuming you are already a git user, then github is very straight forward!
If you want to learn git, you don't need a fancy server on the interwabs. You can create a git repo on your local drive and learn to work with it there.
You also don't have to use github's client. I personally use TortoiseGit, plus the command line. I would definitely recommend learning git from the command line, as it really helps to understand how it all works. There's only half a dozen different commands you need day-to-day.
With CVS/SubVersion/etc, you "update" to fetch changes from the server into your repo, and you "commit" to send your changes back to the repo. When updating, you might get conflicts if you've also got local changes.
With Git, you "fetch" to fetch changes from the server, BUT, these changes aren't immediately applied, just downloaded and kept in the background.
When you want to apply those remote changes, you "rebase", which rewinds the log to the most recent common ancestor (the log entry that both your local version, and the servers version descend from), then it applies the server's changes, and then it re-applies your local changes (which might cause conflicts).
With Git, "commit" takes all your local changes and adds them to the log/history... but does not send them to the server. You can commit many times locally before you decide to send your changes back to the central repo.
When you're happy with your local commits, you can "push" to send them to the central server.
So - instead of "update" you perform "fetch & rebase", and instead of commit your perform "commit & push".
There's a lot more to it than that... but I found this to be the biggest thing to get used to -- that you've got a full history log locally, and you can perform loads of local changes to it!
Thanks all
I've just been playing around with it getting my project uploaded and once you've figured out the Fetch and rebase logic and pushing and pull requests, it feels a bit more intuitive.
Syncing seems to take forever though!
Thanks Hodgman
In addition to the information others have provided, this book is freely available online. The first three chapters alone will cover 95% of what your day-to-day Git usage patterns will likely include. Later in the book a few tools for various environments are covered if you don't want to work on the command line.
