[TUT] Basics: Git & GitHub
#1
~~~~ Hey all, I trust you're well ~~~~

This is going to be another mini-thread of mine that I intend to refer back to in the event that I mention Git in another one of my posts. 
Yes, the reader could just google it, but I personally find that if I can absorb and understand content from a particular person, in a particular style,
 then sticking to that same style for side-points also, makes me have a firmer grasp on what I'm trying to learn. 

For that reason, I've decided to create a Git mini-tut.
 Now, honestly guys, I don't think we'll be covering half of what Git truly has to offer; 
but by the end of this tutorial, you should be able to use Git 
to develop and maintain your projects.


Please note: The section titles will each assume that you have read the one prior to it, which is why the context might seem indefinite if you've jumped around.





Git


Git is a version control system.
 Its purpose is to enable and ease the process for a developer to
 back-up, modify, review, replace, restore, and track changes in their projects.

As @Jurij mentioned in the comment section, Git also has a GUI version if you do not like
the CLI. However, I personally advise you to learn it because not everything has a GUI. Likewise, not 
everything has a CLI; but seeing as we're already familiar with GUI, why not learn CLI, too?





GitHub



GitHub is basically a web-based laboratory for Git functionality.
You sign up, create repos, manage them, take a look
at others' repos, contribute to them, participate,
grow, socialize, and other deviant dilly-dallies :p







Repo?


Repo = Repository.



Remember how we compared GitHub to a laboratory? Imagine now... that every developer's project
is done in a separate room within that lab. Think of those rooms as repos.

People can come in, look at the experiments, look at the progress, read the documentation,
make some suggestions, etc. 

They're literally just the location of every file associated with that particular project. 
So for every folder that one might have in their local ~/desktop/projects/{folders[]} for example,
each folder would (probably) be put in a separate repo, if you
wanted to migrate those projects to GitHub.






Let's make a repo, right now!

Whip up a quick account if you don't already have one...
at the top-right of the page, the right side of the menu bar, you will see 
your avatar, click on it, and you will get a dropdown menu like this:

[Image: f2abc795b7d3427c888a43b4d6f85afb.png]

Click on Your Profile > Repositories > New

[Image: f356dd5fd1054a91b85fc7888b53b5a4.png]



...alternatively, just head over to https://github.com/new whilst signed in:

[Image: 392a942249ff40c19d4cbe8c6e595152.png]



Next...

Name your repository "project" and leave it... we'll get back to this later.






So this is like, a fancy, more social Dropbox?

Yes, but don't say that in public.





Seriously, why Git?

• Makes managing your projects much easier
• No dealing with tonnes of irrelevant folders and directories
• No need to constantly make sure you've backed-up in 7 different places
• Save your progress & re-locate, no need to worry about portability as long as the internet is available
• Extremely user-friendly with fast file management 
• Ultimately time-efficient 
• You commit your work with ease, and with an annotation, no need to separate the two
• With every instance of a saved progress, you have access to the meticulously detailed differences between each instances
• Large community, easy to find support and grow
• It's pretty much industry standard now, it's a nice thing to be familiar with
• Nice and simple interface on GitHub, easy to understand, good experience
• More association with documentation and getting used to learning how to interpret them and navigate through them

So you may think I've oversold it a little and what not - but in all honesty:
I feel that it's not always easy to be conscious of how a particular object of topic benefits you
if you are still to experience its absence; and you cannot truly feel its absence,
if you haven't yet tasted its presence. 

#Poetry2016 #BaredeeAndThePhilosopherStone

I hope I made sense to you.





Commit?


Hmm, think of it like Ctrl-S.

GitHub will show the progress of your project/repository in commits
So every time you committed, it's like you took a screenshot of the entire project...
all files, file sizes, types, names, their contents, directories etc.

If you observe different repositories on GitHub, you'll notice that some developers are very prudent with their repos,
you'll see commits with an annotation like "Added a label" ... "Changed paragraph text",
whilst other developers' commits will consist of somewhat more significant 
changes and/or annotations to their projects.





Push, pull, fork, branch, whaaa?


Anytime you're trying to get familiar with some new technology, 
there's almost always some simple terminology to learn.

I suggest taking a look at glossary link here
Some will definitely be important, others, you can leave off. I think it all depends on what your circumstances are,
are you working alone? Do you intend to contribute? And so on.

But if it's just for you, I'll suggest the following terms:

PullClone, Commit, Push, Branch, and Merge

I thought about briefly going through my array of selected terminology but 
I like how they've worded it, so please do give it a read.






-------------------------------------------------------------------------------------------------------------------

End of Theory









A Practical Demonstration of the use of Git/GitHub





1. Create a GitHub account if you haven't already & Download Git


2. Make sure it's added to your environment variables


3. When you type Git into your terminal, you should get a response like this:


[Image: 1e787a3a41a54b998e8515a87e4d923a.png]

...implying that your system recognizes Git





Usage


Now that we have Git installed and configured, we can start working.





So I have a folder: project



[Image: dadb52364aba4734a1390b926976b605.png]








I have my files inside it : index.html 

[Image: c869a0704ea041a2a68d53827e4412ab.png]







Open your terminal/console/cmd and run command: git init


[Image: 40b41402de344f8fa1c9dc2decd16674.png]

You will be notified that a new repository has been initialized...
and you may notice the .git folder. 
Don't touch that.






Open your terminal/console/cmd (make sure you're cd'd to your projects root dir) 

and run command: git remote add origin https://github.com/{yourName}/project.git
...followed by: touch README.md
...followed by: git add . 
...followed by: git commit -m "first commit"

[Image: 10467aa9ec684e3abcb8cf5ef64d6a2e.png]


1. The first line adds a remote repository (the one created by git init is local)

2. The second one creates an md file (I believe it stands for MarkDown) named README, this is what we use to create documentation
for our repositories, for our projects.

3. The third adds all of our created files to the 'commit queue', 
so that if we push it to a live git server,
those items will exist there. This is referred to as staging.

4. The fourth and final line simply commits the added files with an annotation that says "First commit"




Finally, run the following:

$ git push -u origin master

and you should see something like this...

Counting objects: 3, done.
                          Delta compression using up to 8 threads.

                        Compressing objects: 100% (2/2), done.

                                                       Writing objects: 100% (3/3), 304 bytes | 0 bytes/s, done.

                Total 3 (delta 0), reused 0 (delta 0)

                         To https://github.com/brendon/project.git

                  * [new branch]      master -> master
                                                                       Branch master set up to track remote branch master from origin.

...Or something similar


If we now check our repository:

[Image: 890d37ffc3664fc8b7dd0b244c7a438f.png]


 Again, I cannot stress how important it is that you do some further research after this thread. It will give you

a better understanding of Git and you will have a more dynamic command over it.






From this point onward, just continue to work on your project as you would. 

Whenever you feel like you want to save or mark your current progress,
Open a terminal/console, be sure to be cd'd to your project dir,
run: git add . to stage all of the files and prepare them.

Next, run this: git commit -m "{your comment}".

That will submit your commit to the server.
But this assumes you have a remote repo.
If you don't, connect it. And read more.
...I think that's pretty much it.
Enjoy developing.






Just for something extra, this is what a commit history may look like, on a repository.

[Image: 325886db5a3f4a048c198a8416264ff4.png]





Pardon me for any inaccuracies.  Feel free to share your relevant thoughts, concerns and opinions in the comment section below,
 I'll try to answer you if and when I feel it's appropriate and necessary. 
If I don't, perhaps another member will.

 Thank you for reading my thread, I hope you benefited and or enjoyed. 

Have a nice day. Hat Tip
#2
What a really well typed up and presented thread this is, it made reading it so much easier and I have learned quite a bit on this.
I have heard of some of those websites but never actually visited / used them now it's nice to know what purpose they serve.
Cheers!
Reply
#3
(07-25-2016, 07:12 PM)StrandedBanana Wrote: What a really well typed up and presented thread this is, it made reading it so much easier and I have learned quite a bit on this.
I have heard of some of those websites but never actually visited / used them now it's nice to know what purpose they serve.
Cheers!

I'm glad you learned something from it. :)
Reply
#4
Scott Chacon has an excellent, very detailed and thorough book about git called "Pro Git". A free digital version can be downloaded from here: https://git-scm.com/book/en/v2

Github also has an official GUI version of Git for Windows and Mac (https://desktop.github.com/) if you feel like the CLI version is confusing or something else. You can find a list of clients here: https://git-scm.com/download/gui/linux

Personally I prefer the CLI version. Less hassle in my opinion. Although I will admit that it's nice you don't have to leave your desktop if you are using a desktop client as opposed to the CLI version where you sometimes have to go to GitHub to not get confused.
Reply
#5
(07-26-2016, 09:33 AM)Jurij Wrote: Scott Chacon has an excellent, very detailed and thorough book about git called "Pro Git". A free digital version can be downloaded from here: https://git-scm.com/book/en/v2

Github also has an official GUI version of Git for Windows and Mac (https://desktop.github.com/) if you feel like the CLI version is confusing or something else. You can find a list of clients here: https://git-scm.com/download/gui/linux

Personally I prefer the CLI version. Less hassle in my opinion. Although I will admit that it's nice you don't have to leave your desktop if you are using a desktop client as opposed to the CLI version where you sometimes have to go to GitHub to not get confused.

I totally should have mentioned that Git also has a GUI version, thanks for adding that. I'll edit that in, somewhere.

I too prefer the CLI of Git, mostly because majority of the other development tools I use are CLIs; so it's good to keep them collected somewhere, when I'm working.

As opposed to having a nicely stacked area of CLI windows... and then a random GUI sticking out somewhere in between.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)