I have never worked with code control systems. Now I am connected to the existing bitbucket repository for working with the site (I chose clone when connecting). There are many articles about these systems, but they are replete with various details that I do not need at the moment. I do not use the command line and do not work with files locally (I use the Coda editor and edit it directly on the server via ftp). I need the simplest instruction: I changed the file, what next to do to save the changes to the repository? I thought that I had to click for this Commit, but for some reason this item in my menu is inactive for me, only Push / Pull changes to / from origin are active, but Push doesn’t work for me as I expected (and I’ve expected that if I click Pull, the file will be restored to my altered state, but it was restored to the state before I changed it). In the branches list, I selected master.

  • The commit button was inactive, because I changed the file via ftp, and to push such a file into the repository, you must first download it to a local copy. - baduga
  • if it's still relevant :), here it is: goloburdin.blogspot.com/2013/11/git-bitbucket-20.html - slavutich_red

1 answer 1

Git is a distributed system, a repository on a computer and a server are two completely different repositories, and push / pull simply synchronizes these repositories over the network. When working with the repository (let's keep synchronization aside), we need three commands - git add adds files to the next commit (the operation is called stage , the command for the reverse operation is git rm --cached %file% ), git commit records the changes as a separate commit, git reset performs a simple rollback to the selected commit (here I am floating), git revert is similar to git reset , only its changes can be represented by a commit (while the reset simply rolls back to some commit). Thus, an ordinary flow might look like this:

 geany superfile.py geany secondfile.py git add . # указывается директория или файл git commit -m "Commit message" # Без сообщения в том или ином виде ничего не уйдет

After the local repository has changed, you can send it to the remote

 git push -u origin master # отправляем ветвь master на remote c название origin и выставляем его главным. Мастер-ветку вроде бы можно и не указывать

Next time it will be enough just to do git push.

 git push

And all new commits (but not changes) will go to the server.

git pull merge the repository from the server as it is, and most likely will overwrite the changes (if the stage operation was not performed on them - in this case, git will refuse to perform the operation until the stage-area is empty or the --force key --force not make it).

Long story short

  1. Files are created / changed.
  2. Files are added to the upcoming commit with git add %path%
  3. A git commit , if you do not specify the -m option, the editor will pop up, where you will need to enter a message with a description of the changes.
  4. git push sends fresh commits to the server
  5. git pull pulls turnips in the state of the last commit on the server
  • Already made, but not sent commit can be corrected with the git commit --amend . An already sent commit is also possible, but in no case do not need to do this , it's okay if the fixes fly away next.
  • Unnecessary files are excluded from .gitignore using the .gitignore file. You can configure it once to ignore any *.log , *.pyc and other garbage, and then safely do git add . .
  • The IDE will very often mix git add and git commit commands to make it indistinguishable.

In fact, the book on the gita explains everything in a very accessible language: http://git-scm.com/book/ru/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8B-Git-%D0%97%D0%B0% D0% BF% D0% B8% D1% 81% D1% 8C-% D0% B8% D0% B7% D0% BC% D0% B5% D0% BD% D0% B5% D0% BD% D0% B8% D0 % B9-% D0% B2-% D1% 80% D0% B5% D0% BF% D0% BE% D0% B7% D0% B8% D1% 82% D0% BE% D1% 80% D0% B8% D0 % B9
Therefore, it may be worthwhile to skip this post altogether and immediately go there.

Well, the last. Git can be (and will be) complicated, but this is only for the better; it is a very flexible system.

  • Thank you, but not exactly what I asked :) I am not interested in the command line and theory, which is why I asked this question, the key word in it is SIMPLE. Personally, I think that you can find a lot of interesting activities if you don’t want to deal directly with business - and code control systems are not the best choice in this regard. It’s just that the customer’s request for one project is to work with git, and I only need to know how these unfortunate files that I changed, cram into the repository :) Although there can be a lot of complexity in an automatic backup with a pair of add. functions, I also do not understand. - baduga
  • one
    @baduga I am not familiar with this particular editor. But the essence of this does not change much: the files are added to the stage area - a commit is made - the commit is sent to the server (push). Before a commit you need to do a pull to avoid conflicts. And yes, without studying some theory (its minimum here) will be difficult. - etki
  • Actually, I waited for this answer - you need to press the Commit button, then Push. Well, after all, what is so difficult about this - pushing two buttons, and why is there a theory at all?))) If I understood correctly, then the Stage Area is a local copy of the site or something like a cache? - baduga
  • @baduga closer to the cache. A copy of those files that should go to the commit. In the IDE, you can usually not remember about it, since it is created and immediately flies to the commit. - etki