As I understand it, the git system serves to control library versions, etc.

But if there is another task: intermediate copies when the library is not ready at all. For example, added a class, it has several functions. The library is not ready, it is not working, but I need to make a restore point. (Let's say I'm not sure exactly which way to go next so that you can return to this state, or just a backup copy of the case of failure). To commit, it seems to me impractical, are there any other ways for this task?

    3 answers 3

    My version of work - the repository is on the Internet, I work from several places. Commits are stored locally before pushing, so they are more for history. Push to the repository in the test branch in any state - so that when you continue from another place, the current state is available. In any case, thanks to the history of commits, you can always return to any stage.

    But at the same time, all development is carried out in a separate branch, before uploading the working version to the combat server - merging with the master, before the final push to the repository an additional test.

    The correct ideology is to start a testing branch in which a commit is unlimited, push by mood, but merging with the master only in a workable version.

    At a possible fork, you can create a new branch, then the winning option is added to testing, tested and goes to the master.

    And as the previous speaker wrote - use tags for individual milestones.

    • "Commits to push are stored locally ..." - and what, happens somehow differently? They are always created locally. - Nick Volynkin ♦
    • I just said the obvious thing - Alexey Prisyazhnyy

    Just for this git also exists. A commit is the preservation of local changes; it is not a publication. You can view the commit history at any time and roll back to the desired one. By and large, a commit is a β€œrestore point”.

    And you can make a branch, and work on some feature in this branch. Switching between branches, you get two options - the code is stable and the code with features. After debugging, you can merge and delete the branch. If you could not get the feature to work, simply delete the branch and return to the main one.

      To commit, as it seems to me impractical

      The git was created precisely to make commits and to do them often. You can take commits as saving in a dangerous shooter - you can save in every convenient situation, in front of every corner and door. And do not make a bagel from the design, in which a mistake will lead to the fact that you need to start all over again. Just try to preserve meaningful names, otherwise they will be useless. Limits you only disk space (which is spent quite effectively, there is compression and reuse).

      Let's say I'm not sure exactly which way to go next so that you can return to this state, or just a backup copy of the case of failure)

      Backup - each commit is a backup.

      git add <ΠΈΠΌΠ΅Π½Π° Ρ„Π°ΠΉΠ»ΠΎΠ² ΠΈ ΠΏΠ°ΠΏΠΎΠΊ> git commit -m'ΠΊΠ°ΠΊΠΎΠ΅-Ρ‚ΠΎ сообщСниС, ΠΎΡ‚Ρ€Π°ΠΆΠ°ΡŽΡ‰Π΅Π΅ ΡΡƒΡ‚ΡŒ ΠΊΠΎΠΌΠΌΠΈΡ‚Π°'

      View the commit history and select one:

       git log

      Return to the desired commit / status:

       git checkout <sha1 ΠΊΠΎΠΌΠΌΠΈΡ‚Π°> git checkout <имя Π²Π΅Ρ‚ΠΊΠΈ>

      Which way to go further - create a branch, it is an alternative way.

       git branch new-branch-name

      to control library versions

      When your library reaches release status, you can make another commit and mark it with a tag

       git tag Release-1.0