Hello, GitHub, I recently got a project from a client, multiple developers working on the same project from different locations. the owner of the website asks me to work on GitHub. but I am totally new on GitHub, I have been watching GitHub tutorial on youtube for 1 hour but no success. the website is built in WordPress, and files are hosted on Namecheap. is this website support GitHub? how I can sync all file of this project on my local machine and work as a team member. though the owner gave me some video links that are not beneficial for me. any guidance will be highly appreciated please help. I need to start work by tomorrow morning.
Hi @triviaquestions ,
GitHub is a place where code is hosted to work on it collaboratively. GitHub is built on the foundations of Git, a highly popular version control system for code. GitHub does not host the sites itself (except static sites, just look up GitHub Pages), but as you’ve explained in your post Namecheap does that.
Just Google some Git + GitHub tutorials, like these: https://product.hubspot.com/blog/git-and-github-tutorial-for-beginners . If you have specific questions you’re welcome to post back.
Learn the basics of version control, particulsrly using Git. Take note: Git is not the same as GitHub. However, GitHub uses Git.
Thank you for the kind response
I’d avise you to try to ask specific well defined questions, perhaps prefix the post’s title with "Git - <some question> or "GitHub - <some question> which will get people’s attention better.
I’d also advise you get a Git GUI tool (I strongly recommend SmartGit and I can help with questions about this tool).
The emphasis on command line usage for Git is one of the barriers to working with Git, whereas a visually meaningful interface makes is much easier to understand so go and grab that (it’s free for non-commerical use).
SmartGit will let you see your repo (which is basically just a folder) a bit like the Windows file explorer where you can navigate sub-folders and so on. Unlike the Windows explorer it only shows changed files or new files or deleted files which is a great aid when learning.
Finally a short overview.
A repo is a folder (that contains a special sub folder and some special files) that folder can be on your PC or it can be hosted in GitHub or it can be a fork (a per-user “copy”, created within GitHub) of another GitHub repo or it can be all three.
Typically users work like this:
- There is a central repo in GitHub (not a fork) - this is owned by either a user or an organization.
- There is the user’s fork of that repo which is also in GitHub (and created using GitHub)
- There is the user’s local repo on their hard drive.
You create a fork within GitHub just by going to the main repo and using the fork button. You create the local repo by doing a “clone”, this is done using SmartGit (or command line), you usually clone the main repo.
There are things called “workflows” which are different standard ways of working with GitHub, but basically you work like this, imagine you are fixing a bug and you already forked and cloned the repo (and setup what are termed “remotes” which despite their name are purely local entities inside your local repo but they “point” to remote repos - in GitHub, you add these to your local repo using SmartGit or command line, you create two remotes, one remote points to the main repo and the other remote points to your fork). SmarTGit then “knows” about all three repos: the local one, the remote fork and the remote main repo.
- Edit your files locally, build test etc - this could be any tool, Visual Studio, notepad or whatever.
- As you do this you’ll see the changed files appear in SmartGit’s main window.
- In SmartGit you select all modified files and click to create a “commit” give that some name etc and do the commit.
- You then “push” to your fork (which is in GitHub) that will copy the commit into GitHub onto your fork.
- In GitHub you then create a pull request which is designed to copy commits from a fork into the main repo. You don’t have to do this every time you push to your fork, you do it when you are ready, usually after working for a while and creating perhaps several commits.
- Assume that is approved by the repo owner, they will then “merge” the pull request and it now appears in your fork and the main repo, this operation creates another commit called a “merge commit” (so now there are two commits added to the main repo).
- Then locally you issue a “pull” command and that will pull down the new merge commit from the main repo and add it to your local repo. Your local repo is now 100% up to date with the main repo.
- Finally you again push to your fork and the merge commit finally appears in your fork.
- At this point all three repos are in step with each other and all three repos contain the commit you created from your editing plus the merge commit that was created by the pull request.
This is just an overview and I haven’t mentioned different branches or other developers or rebasing but this should help you get an overall understanding of the way things work.
Some solid advice from @korporal ! Thanks for sharing it with the community!