What is the conceptual framework of Git? [closed] - linux

Question

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I want to become a Git expert since I use it at work but only half understand it and several times have lost over a day's work because I ran some wrong commands. I've found several tutorials on the internet, but I don't feel like any of them help me actually understand how the application works. All the tutorials say "Here's how to initialize a repo, here's how to make a commit," etc., but they never explain what's happening behind the scenes.
For example, I still don't understand what happens when I push: am I actually replacing the entire repository at the remote location with the one in my commit? By the way, is a commit and actual copy of a version of the repository or is it just information about the changes between my copy and some other version? I want to understand those types of things and I haven't found a tutorial that helps much.

Answer 1

I've recently found myself in the same boat and did a whole bunch of research.
The first thing you need to conceptually understand is that basically, Git works with three areas:
The Development Area, The Staging Area, and finally The Repository (Repo)
The Development Area:
This is where your files are held on your computer. When you install Git you essentially get a framework of commands that will allow you to designate what directories on your computer are to be considered a development area (along with the rest of the commands to do things -- we will get to that in a bit). To designate a Directory on your system as a place you want Git to keep track of you use 'git init'.
The Staging Area:
So this is what threw me off at first. When you make a change to a file in the Development area, you send it to the Staging Area before you send it to the Repository. Thing of this as a temporary space for changes. The reason this is done is so that you can make a number of changes and Commit them as a Set of changes for a Project. This is actually really helpful because it allows you to control what updates and commits you send out. To send a file you change in your Development Area to the Staging Area type "git add filename.ext" or if all the files in a directory are ready to go to the Staging Area just type "git add ."
The Repository:
When you are ready to send all of your changes from the Staging Area to the Repository you use the command: git commit -am "Message explaining the changes / what your are adding, etc." Then "git push"
Let Git Help You!
Things in Git can be confusing at first, so I also recommend letting Git help you out a bit. You can always ask Git what the status of your Working Area / Development Area by using the command "git status". This will guide you.
As you know, one of the biggest appeals of Git is getting someone's code from an Open source project, working on it locally, making changes and then asking them if they will take the changes you have made - adding them into the project.
The concept behind this is to clone a project to your local system, then do everything above.
Look, that is a simple overview and you obviously will have to supplement it. I recommend checking out Derek Banas' Youtube tutorials on Git here: https://www.youtube.com/watch?v=r63f51ce84A&list=PLGLfVvz_LVvQHO1PfyscjIPkNJjgHsLyH

Answer 2

So you want to be a GIT expert...
First, let me say that when I began switching over to GIT from Subversion I had the same questions. My first recommendation is a textbook, this one got me over the hump Version Control with GIT (looks like it's $3 now!). I have found tutorials on GIT to be very command-centric.
About particulars you mentioned:
git init : initializes the current directory as the root directory for the project; basically it puts a .git/ directory there which where all the inner-workings of the repo are stored.
Pushing : you are not replacing the repository, you are PUSHING your lasted commits (git objects,files,modifications,etc) so remote is aware of the target branches history log
What is a commit? Think of a commit like a saved state that you can always go back too, but it's a little more than that since it can be compared against, and retain other info like who did the work and what time it was done.
I'd like to know if your switching over from another VCS cause if not it would make sense to do primary research on VCS concepts. GIT has fundamental differences which make it superior most of the time.
Last note is GIT doesn't store your files, it stores hashes of your files. -Good luck.