Another git tutorial

Before I started working in classmates, I thought I knew how to use a version control system. But there they gave me a link to the git documentation . This book can be read endlessly, but in my opinion, in order to start using git, it is absolutely useless. This is not a problem, you will say and you will be absolutely right. On the same habre there are a bunch of articles on how to use git. But a couple of days ago, a friend of mine asked me to explain some moments that he did not understand. I explained how I could and I want to share just another cheat sheet on the topic “10 simple steps to use git in daily work”. Not so small, it turned out, so for now I’ll write only how to work with git for your working draft, and then, separately, what to do if you want to make changes to someone else’s project.


And further. For some unknown reason, I almost never use the IDE to work with git. If you use IDE, then I do not care what version control system to work with.

10 steps to work with the project

I want to write what to do if you work for a company that uses git. As a rule, for each task that you do you will need to start a separate branch (branch), call it by the name of the task in your task management system (for example, by the name of the task in JIRA), and after completing the task and passing the code verification procedure by other employees merge your branch with common code.

1. Create a local copy of your project.
   ')
   

   # git clone "project_url" 

   
   For github project_url, you can find it by clicking the green “Clone or download” button on the project page.
   
2. We update the local copy - we load the changes made by other members to this thread.
   
   

    # git pull 

   
   
   Note - git swears that he doesn’t know where to update from

   If you yourself created a branch with the default settings, git will say that it doesn’t know exactly where to update the branch from, but it guesses and offers an option. Just use his hint.
   
   
   
   Note - a conflict has occurred

   git stupidly won't allow you to pull if you have locally modified files and update modifies them. You can use git stash / git pull / git shash pop here.
   Let's say you made changes and made commit. There are 2 options - if your changes and deleted ones do not conflict, then git will create another additional commit and prompt you to edit the message of this newly created commit.
   
   If there are conflicts, then I do it.
   
   We look at what files conflict (both modified)
   
   

    # git status 

   
   , correct them, add
   
   

    # git add "conflict_file_name" 

   
   , commit
   
   

    # git commit -m "Merge master" 

3. Find out the name of your current branch, see which files have been changed locally, what kind of commits (commits) you have not sent to the common server
   
   

    # git status 

4. Throw out all your local changes. Apply carefully, you can shoot in the foot.
   
   

    # git reset --hard 

   
   Note: modern IDEs keep a history of changing files locally, so no big deal. Shoot it.
   
5. Create a branch, usually by task name in JIRA. Note: a branch is created from the branch in which you are currently located (see the previous paragraph), therefore, as a rule, you must first switch to the master branch. If there are modified files, then nothing terrible - they will not disappear anywhere.
   
   Switch to master branch:
   
   

    # git checkout master 

   
   Create a new thread:
   
   

    # git checkout -b "task_name" 

   
   
6. If you want to make changes to the branch that your friend is sawing, then you must first upgrade, and then switch to its branch
   
   

    # git fetch # git checkout "task_name" 

   
   
7. Periodically, we suck in the changes that other participants have made to the main branch, so that later they won't get into trouble with inconsistencies.
   
   

    # git fetch 

   
   

    # git merge origin/master 

   
   
8. After making local changes, they should be "commited" as it were. It should be noted that git makes changes (creates a new commit) to your local version, does not send anything to the server. There is another command to send to the server. Personally, I'm a comedic from an IDE. But you can and hands.
   
   We tell git which files we want to commit:
   
   

    # git add file_list 

   
   Or all the files at once
   
   Commit:
   
   

    # git commit -m "Commit message" 

9. We send files to the repository on the server
   
   

    # git push 

   
   Note - git swears that he does not know where to send - see the note to item 2.
   
   
   Note - git swears that the files are not updated.

   Usually the git server settings are such that you cannot send your changes if someone has sent their changes to your branch. Therefore, you need to update the status of your branch - see point 2.
   
10. We send changes on viewing (review) to other participants. This is a UI thing, it has nothing to do with git. In github, for example, you just need to go to your branch in the UI and create a Pull request (PR)
    
11. Merge your changes into the main branch. There are several options. By default, git will simply embed all your commits into a common thread. That is, everyone will see your ridiculous attempts to correct an unassembled build, falling tests, and just the evening commits that you made in order not to lose the results of painstaking day labor. This is good if you are an exhibitionist, but as a rule, it is rewarding to assemble all the committees into one and embed it into a common branch with just one commit (so-called squash commit) - it will be easier for others to figure out what you did before something went Do not undo your changes. Therefore, it is advisable to do squash:
    

    1. github ui magic

       In the github interface there is a green squash & commit button. Through the UI, go to your branch, create a Pull request (PR), and then in the PR interface, select and press “squash & commit”.
       

    2. squash commit

       Go to the main branch (master)
       
       

        # git checkout master 

       
       updated
       
       

        # git pull 

       
       make squash commit
       
       

        # git merge "branch name" --squash 

       . All changes from our branch will appear as local, but already in the main branch. Look what we navyali. See the changes - point 3. Commit - point 8, send to the server - point 9. You can not make a squash commit to the main branch, but start a new one, make a squash commit into it and make a merge into the main one (see the next item).
       

    3. merge

       Your commit in this case will not stick together in one. Go to the main branch (master)
       
       

        # git checkout master 

       
       updated
       
       

        # git pull 

       
       do the usual commit
       
       

        # git merge "branch name" 

       
       , send to the server - point 9.
       

    4. rebase

       You can rebase the branches and, for example, glue all your comets into one.
       
       
       I personally don't do that

       Because they need magic to choose all of your komits and separate yours from non-martyrs (from those that were added from the master) and then during the rebase you can still run into a change of the committee that was pulled from the master. You can rebase each time you pull up changes from the wizard. So I also do not do it because if you work together as a tea on one branch and rebase, then conflicts are likely.

Notes:

• A common branch is usually called master.
• You can hide all your local changes - see the git stash command.
• You can apply a commit to your branch from some other one — see git cherry-pick.
• Magic. rebase. Merge several commits into one or move commits from a local branch to the top of the list — so that it is easy to splice them together — git rebase.