Do I understand correctly how to use Git in the development team?

Question

git

I'm afraid to mess something up, that's why I'm clarifying. For example, I already have everything installed, I wrote to myself - git init
- registered global config user.email and user.name
- then git remote add origin ssh://[email protected]/var/git/example.git
- after which I can do git clone ssh://[email protected]/var/git/repository-name
- then I go to the folder of this repository, change files, etc., after that I write
- git-commit -a - m "new commit"
- and I send a git push to the server (specifying the repository and branch)
- To get the updated files, I need git pull
I have questions:
1) When indexing a file, should I index only those that I changed? Because maybe someone else has already made changes there, made a push and it turns out that I will overwrite his changes with my push?
2) If I am a new member of the development team, how will my connection to the team still take place, will they give me a login and password for the project, give me read and write permissions, and then everything is as usual?
3) I am a layout designer, the first day of work is coming soon, they said the workplace will be prepared, as I understand it, that the main things will be configured or is it still not? (Yes, I know, I should have asked right away, stupid)
4) And yet, after git pull, do I need to do git commit?
Thank you all for any replies and advice.

Answer 1

1. They won't mess up, there will be a conflict either when pushing or pulling (pull before push is a good idea, as for me). Then either git will merge these changes itself, or it will require you to do it manually. In any case, it’s impossible to overwrite something just like that (otherwise, what would be the point in git at all?).
2. Exactly.
3. And this already depends on the employer. They can limit themselves to an account in the domain, and then, like, set up a workplace for yourself according to your needs.

Answer 2

In large offices there is such a position as "Assembly Manager". Usually, all the rules for working with the repository and the nuances of working with GIT are specified through it.
Must read: https://githowto.com

Answer 3

In normal offices, developers work in different branches and do not interfere with each other.
And the process of merging branches is one of the most boring jobs for more experienced developers.

Answer 4

Because maybe someone else has already made changes there, made a push and it turns out that I will overwrite his changes with my push?

No, you can only overwrite with the push command with the -f switch if you have rights to edit the history. With a normal push command, the server will not accept your commits into the branch if the commits currently on the server are not the parent of yours. In other words, your commits and the commits currently on the server must be related by a parent-child relationship.
If by indexing you mean the staging area, then of course only what you have changed (and also removed/added). The essence of the staging area is the preparation of the contents of the commit.
Briefly - yes. In detail - from the one who does this in the company.
You will be given a username/password, or you will be given a username and asked to generate a public/private key pair, and you will have to pass the public key to the administrator to link to your account. git config will help you put down the corporate email and name under which you will have to make commits to the common turnip - all this can also be checked with the administrator.
Now your question is akin to "should I have breakfast after brushing my teeth?". Those. although these actions are of course often performed together with each other, they are completely different and they achieve different goals. Therefore, recommendation 1: study git more, if you ask this, you don’t understand anything about it at all. Or ask a specific question if something specifically remains unclear.
And yes, do you think that you will be fired if you ask the admin / team leader all this? I don't think so, especially since you are a typesetter. Recommendation 2: stop panicking.