Another git tutorial

Before I started working in classmates, I thought I knew how to use the 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 say, and you will be absolutely right. On the same hub 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 to him some incomprehensible moments. I explained how I could and want to share just another cheat sheet on the topic “10 simple steps to use git in everyday work”. It turned out not so small, so for now I will only write how to work with git for your working project, 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 the IDE, then I think it doesn’t matter which version control system to work with.

10 steps to work with the project

I want to write what to do if you work in a company that uses git. As a rule, for each task that you do, you will need to start a separate 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 Combine your branch with common code.

1. Create a local copy of your project
   
   

   # git clone "project_url"

   
   For github project_url can be found by clicking the green button "Clone or download" on the project page.
   
2. Updating the local copy - loading the changes that other participants made to this thread
   
   

   # git pull

   
   
   Note - git swears that it does not know where to update

   If you yourself created a branch at the default settings, git will say that it does not know exactly where to update the branch from, but guesses and will offer an option. Just use his tip.
   
   
   
   Note - Conflict Occurred

   git stupidly will not allow pull if you have locally modified files and update modifies them. You can use git stash / git pull / git shash pop here.
   Suppose you make changes and commit. There are 2 options - if your changes and deleted ones do not conflict, then git will create another additional commit and offer you to edit the message of this newly created commit.
   
   If there are conflicts, then I do so.
   
   See which files conflict (both modified)
   
   

   # git status

   
   , edit them, add
   
   

   # git add "conflict_file_name"

   
   commit
   
   

   # git commit -m "Merge master"

3. We will find out the name of your current branch, see what files have been changed locally, see what commits you did not send to a shared server
   
   

   # git status

4. Throw away all your local changes. Apply carefully, you can shoot in the leg.
   
   

   # git reset --hard

   
   Note: modern IDEs store the file change history locally, so no big deal. Shoot.
   
5. We create a branch, usually by the name of the task in JIRA. Note: the 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 there is nothing to worry about - they will not disappear anywhere.
   
   Switch to the master branch:
   
   

   # git checkout master

   
   Create a new branch:
   
   

   # git checkout -b "task_name"

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

   # git fetch
   # git checkout "task_name"

   
   
7. We periodically suck in the changes that other participants made to the main branch, so that later they would not have problems with inconsistencies
   
   

   # git fetch

   
   

   # git merge origin/master

   
   
8. After making local changes, they must be so-called “commit”. It should be noted that git makes changes (creates a new commit) in your local version, does not send anything to the server. There is another command to send to the server. Personally, I comedic from the IDE. But you can do it with your hands.
   
   We tell git which files we want to commit:
   
   

   # git add file_list

   
   Or at once all the
   
   Commit files :
   
   

   # git commit -m "Commit message"

9. We send files to the repository on the server
   
   

   # git push

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

   Typically, the git server settings are such that you cannot post your changes if someone posted their changes to your branch. Therefore, you need to update the status of your branch - see point 2.
   
10. We send the changes to the review (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 of your commits in a shared branch. That is, everyone will see your ridiculous attempts to fix the non-assembled build, the falling tests and just the evening commits that you made so as not to lose the results of painstaking day labor. This is good if you are an exhibitionist, but as a rule it is eager to collect all the commits into one and embed them into a common branch with just one commit (the so-called squash commit) - so it will be easier for others to figure out what you did before something went wrong and roll back your changes. Therefore, it is advisable to do squash:
    

    1. github ui magic

       The github interface has a green squash & commit button. Through the UI, go to our 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

       
       do squash commit
       
       

       # git merge "branch name" --squash

       . All changes from our branch will appear as local, but already in the main branch. We look what we pile up. View changes - item 3. Commit - item 8, send to the server - item 9. You can make a squash commit not in the main branch, but make a new one, make a squash commit in it and make merge from it in the main one (see the next paragraph).
       

    3. merge

       Your commits 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 branches and, for example, glue all your commits into one.
       
       
       Personally, I do not

       Because there you need magic to select all of your commits and separate yours from yours (from those that were added from the master) and here during rebase you can still run into changing the commit that was pulled from the master. You can rebase every time you pull changes from the wizard. So I don’t do it either, because if you, as tea, work together on the same branch and do rebase, then there is a high probability of conflicts.

Notes:

• A branch with common code 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 branch - see git cherry-pick.
• Magic. rebase Glue several commits into one or move the commits from the local branch to the top of the list - so that later it is easy to glue them - git rebase.