Git Question

[aslco]

Hi All

I recently cloned a repository to my PC. I understand the idea of add, commit, push etc, but I am slightly confused at the idea of a "working directory" and what is actually happening in detailed terms when a commit is made.

Is a "commit" actually updating a file which lists an index of other files and "time stamps"? and In turn that file is used by the remote repo to decide what to upload upon the next push? Or is a commit simply copying files from one directory on the PC, to the other one (that in turn is configured to push to remote) ?

Am I doing something wrong if I simply clone a repo, open files directly from the local repo, edit and save them (with a commit in due course...)? What's the standard working practise?


Thanks,

 

[marc2003]

A commit does nothing to the files except create backup of the changes made so a) you can view them and b) you can undo any changes later. Timestamps are irrelevant. There are tools such as touch which can change timestamps without changing the content and git will ignore that. Only the file contents matter.

All changes are stored inside a hidden folder named .git and there is never any reason to poke around inside. Leave it alone.

I know it's unmanly but you really should start with the docs.

https://git-scm.com/doc

Am I doing something wrong if I simply clone a repo, open files directly from the local repo, edit and save them (with a commit in due course...)?

That's pretty much it if working on your own repo. However, if you were looking to contribute to someone else's repo, you'd fork it and then create a new branch. The docs will explain that.

 

[ZombieFan]

Just to add, the Pro Git book from the link above is fantastic. Read that and it will all become clear.

 

[Dj_Jestar]

The chief difference between git and something like SVN is it is a distributed repository, so when you clone a repository - really you are cloning the entire repository (i.e. all of the history, too). In SVN all you do is "checkout" a copy of the current state, make changes, and check them back in.

This means when you git-commit, you are committing just the same as you do in SVN (ignoring under-the-bonnet differences for now) - but the commit goes to your local repository, not the repository you originally cloned from - then when you "push" you are pushing your commits to the remote repository (which is typically the repository you cloned, but may be other repository - including a different local repository for some scenarios).

This may seem pointless, and tbf it often is in most use cases because the typical central-repository-is-god model is used by most teams, but it is nice to know that if, for example, I've got some changes I want my colleage to see before I push to "origin" I can push to my colleague's repo directly if I needed to avoid making a new branch.

In short it's just how distributed repos work, and is another level of tools in the toolbox for developers.

 

[aslco]

Thanks all. I understand forking, branch etc. It was just whether i was doing something wrong in opening files in the local repo on my PC, (rather than some other workspace folder elsewhere on my PC) but it doesn't sound like i've done anything wrong. I understand that the .git folder contains the clever stuff and ultimately git is logging changes, and is never actually uploading / downloading files on each change so that makes a bit more sense to me for the need for a "commit" rather than just a normal "save" before a push.

 

[AHarvey]

Going to look over that link later on.

Heavily involved with Application Support now but there's so many areas that need improvement so I need to get my head down and focused on development. Github has always baffled me