I previously worked with GitHub, but I was the only one doing commit commit.

And how to work in a team? Suppose I put a solution on GitHub and several people downloaded it.

  1. One made libu

  2. Other something else

(These are 2 different projects inside the solution)

Both programmers take turns committing to each other without waiting for each other.

What will be in the githaba as a result? Will one commit rewrite another commit and in the end only 1 project will be in solution?

How to work?

  • 6
    Read at least something about git and mergi. Well, how can I ask a question without looking for information? - Monk
  • Googling - git pull and git push, but in general there is a good tutorial . - triplustri
  • I recommend reading: Why do I need a pull request if there is a push? - Nick Volynkin ♦

2 answers 2

In the simplest case, when everyone commits and pushes into one branch, push will be rejected from the second. He will have to first make git pull and combine the changes made remotely before sending his own. By default, Git does not allow rewriting fragments of the commit tree, only to supplement it.

If they changed different projects, then conflicts are unrealistic, and just git pull will suffice (so that remote changes merge with local ones), and then re- git push .

There is a particularly harsh technique for keeping a straight story, git pull --rebase , but before using it, it’s worth exploring how it works and how it can be dangerous.

In the normal case, it is better to work in separate branches (which can even exist in different repositories, in the case of forks).

Everyone reaches a stable state in his branch and makes a pull request (PR) (merge request or MR in some places) and according to the procedure adopted in the command (say, if at least two people except the author voted for ) accept it.

If the changes to the second PR / MR are based on outdated code, and the upper version in the main branch is different from the one on which the new changes are made, the web interface will report that the merge generates the conflicts you need:

  • either locally when manually merging
  • or ask the author of the code to rebase a new version of the main branch, as a result the author of the new branch will solve the conflicts (therefore this is a more popular solution)

One variation of this process is called Github Flow .

    If commits do not interfere with each other, then they may well be used both. If not - the conflict, it is still manual to resolve it.

    In general, the flow-flow should be:

    1. Fork both of the basic projects (or, each of them make your own branch from the basic one)

    2. In parallel, everyone is working on their part.

    3. Uploads changes to the server.

    4. With the help of pull-request, everyone pours their changes into the main branch.

    5. PROFIT !!!

    Naturally, there is one solution. Somehow it is not necessary to beat him to pieces.