Git is one problem

Question

git

I decided to try Git version control. I don’t understand one thing - I organized the central repository and my local one (I clarify. I work through TortoiseGit, I create the central repository with the command Git Create repository here .., local by cloning the central Git clone. Maybe I misunderstand what here? ). And everything seems to be committing (I commit and push to the central one), but no real sources appear in the central repository. How can I get/use them?

PS (This logic is different from SVN, but somehow I did not find where this issue is given attention when describing GIT)

Answer 1

Judging by what is written above, your central repository is bare, that is, the repository that stores data about commits, but does not store any version of the working tree in an explicit form (in fact, it stores, but in a slightly peculiar way, read here habrahabr. ru/post/143079/ ). When you push to such a repository, git pushes the data of all commits to this repository.
In addition to the bare repository, you can also push to a regular repository. Make a clone to another folder and try to push there from your local one (to do this, add another remote repository, where the address is the .git folderin a new, just cloned copy), only in this case you will not immediately receive the modified files (the data about them is already in this copy of the repository, but you need to “impose” them from there - do a pull in this repository).
Now about the customer. When developing, despite the fact that git is a distributed system, there is a central repository that stores most of the branches and changes. When the customer says "GIVE", the person responsible for the release takes the data of a certain commit (from which the new version is built) and forms an installer / package / something else.
And about the question on the topic “how to get not bare”. When you click "Create new repository here" a window appears in which you need to uncheck "Create bare repository". In this case, only the hidden .git folder will appear in your folder. That's all - it will be a new repository in which you can create and edit files, commit, and so on.
PS. I also realized that you have worked with Subversion before. I also came to git myself. At first it will be difficult and incomprehensible, but, in my opinion, it is worth it.

Answer 2

Just because you've pushed changes to some other repository doesn't mean that if you go to that repository's folder, you'll see your changes there. That is, in that repository, the working copy will not automatically go to that commit. To make this happen, you need to do it git checkouton the machine where your "central" repository is located.

Answer 3

in terms of git, I would formulate the answer as follows:
there is no working tree in the bare repository, that's why it is bare

Answer 4

They write to you absolutely correctly - the central repository should be bare and you should not do anything with it.
If you need to build something, you make a clone on the build machine and collect it there.

Answer 5

To update a remote repository, it’s not enough for you to commit, you also need to do a git push.
See for example here .

Answer 6

Indeed, I do not need the sources to be copied to the central repository every time

If you wish, you can also push outside the turnip bar. Bare differs from non-bare in the presence of a *local branch* of master (copies of origin/master at some point). Pushing to any remote (remote) turnip is done in its origin / master, and in order to update its local files (“sources” they are also working copy), you must also go in and update the local master (for example, git fetch && git reset --hard origin/ master, with this command, all local edits will be canceled, but you, from the “central turnip” with which no one ever pushes, this is what is required). How to make this update happen automatically depends, but you can do it manually (or by cron) periodically.

Answer 7

anarsoul, pushing to a non-bare repository is fraught with problems, especially if someone works with it directly.
imagine a situation where you are working on a feature and your colleague pushes to the same branch in the same feature and removes the lines that your current work is based on.
the third bare repository should be and be cumulative - this is a generally recognized scheme of work.
and you can hang hooks in it to do anything with the working tree