What GIT is and what it is not.. version control?

Question

Ok so I am having trouble understanding what git does or what it does not do.

When I hear version control, I think I no longer have to store different files on my computer of basically the same code with minor changes.

For example if I have a C file where I am generating a PWM with timer1 but then I want to test it with timer2. I would normally either comment code out and try it. Or I would copy the C file and modify it and not worry about breaking my working code. Then I would go on and try other things again always having my original file and working code.

Now with git I think I can have my code and do all these commits and if I feel like going back to the original version it will be there nice and safe, hence version control. But I am trying some things out with an online tutorial on codecademy.

I have a local repo which I sent to github. I have a read me file and i edit it and send to git hub and it shows up. Then I did more changes and send it again.

Then I did a reset using the commit sha..and i tried pushing that and it said that the head of my local doesnt match the remote. and then I check the read me file and I was expecting it to revert to my version 1 and it did not... so I do not have these multiple versions of my file?

So I am not understanding the version control part... can I have multiple versions of a file and git keeps track of all the versions and the ability to revert my files back to version 1 for example...or am I missing something here?

Because what i thought this did was:

1. I have a file

2. I modify my file

3. I use git to have version control
4. I edit my file and git will somehow index this as version 2 and it will have a back up version of my version 1.
5. I keep editing and committing and git keeps track of all the changes to my file and I can always go back to an old version of my file.

I thought it was amazing how it did this with out just copying my file which is what I did but it seems to me we are not there yet and this is not what git does.

Answer 1

Q: Can I have multiple versions of a file and git keeps track of all the versions and the ability to revert my files back to version 1 for example?

A: Yes. Absolutely yes. That, and much, much more.

Q: Do I really need Github at all?

A: No. You can take full advantage of Git entirely locally. Unlike version control systems (VCS) like SVN or Visual Sourcesafe, Git is NOT client/server. Every Git repository is complete and self-sufficient.

Q: Then why bother with GitHub?

A: Simply because it's sometimes useful to be able to sync your local repository any where you want, from "the cloud". Or to be able to share your repository with whoever you want, regardless of whether or not they have access to your workstation.

In Git parlance, Github is an example of a "remote repository".

SUGGESTION:

Try some tutorials that illustrate basic Git workflows (checkin, checkout, diff changes, create and merge branches) WITHOUT messing with Github.

I think that might be less confusing, and give you a much clearer idea "Why Git".

In fact, there's a good introductory article in this month's issue of Linux Magazine:

http://www.linux-magazine.com/Issues/2018/216/Version-Control-with-Git

PS:

Why were you getting errors? A number of possible reasons. Basically, your remote (Github) had fallen out of sync with your local repo. There are a lot of ways you could fix it; none of them difficult.

git status is one way to get more info.

But probably the best thing is to just not mess with Github, until you feel a bit more comfortable with Git itself.

Answer 2

Yes, Git is for version control. Although there are many other tools for the same purpose, Git is a distributed version control, which means that every user can maintain a local Git repository which can be stored in his/her filesystem. Now changes made to the code will have to be added to a staging area and committed. From each commit, different branches can be checked out, branches can be merged and various other tasks can be performed, e.t.c. What problem you are referring to is that the remote repository (which can be on Github) is one branch ahead of your local repository. First you have to pull the latest code from remote repository, revert it and then commit the reverted code on top of the latest commit on the remote repo. But there may be better solutions to this.

Generally, relying on commit history and making frequent reverts is not a good idea - instead, keeping separate branches of each feature and merging them one way is a better procedure in most cases. Git has a very strong branching support.

Edit: By one way I mean once branches are merged, you don't go back unmerging them - that will be relying on commit history all over again.