Git Workflow | Bondar Academy
Course: Git and GitHub Fundamentals
Module: Working with Git and GitHub
Instructor: Artem Bondar
Lesson Summary
This lesson covers the fundamentals of Git , a version control system that helps manage changes to projects over time. The session begins with an analogy of working on a simple text document to illustrate the importance of version control. Key Concepts of Git Version Control : Unlike traditional document saving, Git allows you to create commits , which are snapshots of your project at various points in time. Git Branches : Each project typically has at least one branch, usually named master or main . Commits are saved to these branches. Collaboration : Git enables multiple developers to work on a project simultaneously, tracking who made changes and when. Collaboration Example In a collaborative scenario, developers can create their own branches to work on features. For instance: John creates a login feature branch for a new login functionality. Mary creates a login test branch to write tests for John's feature. They merge their changes back into the main branch after testing. Handling Merge Conflicts Merge conflicts occur when two developers make changes to the same part of the code. For example, if John and Nick both modify a cancel button in different ways, Git will require them to resolve the conflict before merging. Common Git Commands git init : Initializes a new Git repository. git add : Stages changes for commit. git commit -m "message" : Commits staged changes with a message. git push : Pushes changes to a remote repository. git pull : Fetches and merges changes from the remote repository. Best Practices Commit often and make small changes. Use branches for new features. Write descriptive commit messages. Engage in code reviews for feedback. Understanding these concepts and practices is essential for effective use of Git in collaborative software development.
Video Transcript
In this lesson, we're gonna talk about Git theory, how Git works overall, and what is the Git workflow looks like. And then later in the course, we will use all this concept into practice. All right, so let's jump into it. So let's begin with Git, source control management. And in order to better explain this concept, how Git works, let me start with some simple example. For example, working with a simple text document. And what can you do with a simple text document? You can create the document, you can save the document. Then you can edit this document and save this document again. And you can repeat this process again and again. Once you make a little change, you save this document in order to save your changes and not lose it. And if we put these activities in the timeline, where the time is this horizontal line and saving points, we can call it like this. For example, first saving point, you created the document and you clicked Save button, right? Then you update the title and you save this document again. Then you added the first paragraph, you save the document. Then you, let's say, deleted the second phrase in the first paragraph. Then you created a new paragraph and save the document again. And when you was working on the third paragraph, you realize that, right now, I need that second phrase that I deleted, let's say, yesterday in this saving point. But how to get it? Well, unfortunately, there is no way you can recover this information. Because when you're working with a simple save of your document, there is no way to go back in time and recover the changes or modifications that you made in the past. But not if you would use a version control system of Git. And this is how it would look like if you would use Git version control system. So you created the document and you created commit. Commit in the Git language is the saving point of your document or the saving snapshot of the current version of the document that you are working with. So then you update the title and made the commit again. Then you added first paragraph, you made a commit. Then you deleted the second phrase, you made a commit. Then the new paragraph created, you made a commit. And then later, working on third paragraph, you realized, I need that phrase that I deleted right here. And how can I recover it? Well, very easy, because we have a version control system. And we can simply go back in time to the commit where we added a first paragraph, which had the information about deleted second phrase. And we can simply recover this information from our past commit that we did before. So this is what Git can do, saving the version history of the changes of your document. And speaking about Git commits. So the timeline that I mentioned before on my previous slide in Git called Git branch. And usually each project that has Git has at least one branch. And usually this branch by default is named as master or main branch. But you can rename your branch however you want. And then when you create a commit, those changes saved into the branch in form of the snapshot. So you create commit number one, commit number two, three, four, and so on. And then later in the time, you can go back in time to a different commit, reviewing those changes in the Git branch. So one more time, commit in Git is a saving point or the snapshot on the Git branch. But what also Git can do is not only reviewing the snapshot, also the power of Git is collaboration. That several people can contribute to the project, adding their own changes into the main project. And Git will save information about what was changed, when it was changed, and who made the change. So it is very easy to manage and understand the progress of project changes over time. And let me show you the example about collaboration a little bit more in details. So for example, we have a new application. And this application, simple web application with a homepage, and we have a master branch in this application. And then we have a John, who decides to develop a new login functionality for this application. And John wants to develop a simple functionality, such as username, password, and just submit button. So John creates his own branch and call it login feature. According to the Git, it's considered a best practice to create own branch, when you begin working on something. You can work also directly into the master branch. But as I mentioned, just as a best practice, you need to create your own branch to contribute to a project. So John creates login feature branch and create a first commit. For example, in his first commit, he create input fields. Then he continue working on his project and add a submit button. And at this point, John thinks, okay, I think this project can now be tested. And we can write test automation for this project. And then he tells another engineer, who is Mary, test automation engineer, to write the test automation code for the already created functionality, running the application on the local host. So Mary will create her own branch and we'll call it login test. And we'll begin working on this project, creating the test for the functionality that John was created. And then she created a positive test and created commit. John, in the meantime, continue working on his own branch. For example, John updated some phones. John updated some colors on the page, while Mary at this time created some negative tests for the previous functionality. And John, for example, at the same time added logo. And then John said, okay, my work is completely done. We can test it. And Mary says, yeah, I already wrote the test. So now let's test everything together. And then Mary merged her code into the login feature branch to test everything what John created. Because at this point, when Mary was working on positive test and negative test, all code that she had was only input fields and submit button. Mary's branch didn't have information about phones update, colors change, logo edit. So she doesn't know for sure if her positive test and negative test will work, including the changes that John added later on. So she merged her code into his branch, and then John write everything together. John runs his entire code that he created, including the test that Mary is created. And if everything works fine, then John merged all those changes into the master branch. And now all the code that John and Mary was working on was merged back into the main branch of the application. So let me show you a little bit more in details this example, how exactly this collaboration possible using Git. So this is exactly the same example, but we are introducing a new concept called Origin Master or GitHub repository or server. So we have three boxes. GitHub repository is the server where we have our application hosted, where the repository with our source code. Then we have John's computer and Mary's computer who wants to begin contributing to this application. So in order to begin contribution, John execute command git clone and clone master branch to his computer. And now John computer has exact copy of the application that is stored in the GitHub repository. The only difference is a branch name. So all branches that located on the server, they have a prefix as origin. So it is origin master. And the John's branch is just a master branch, but this is essentially a copy or a clone of the entire application. So John cloned the master branch, the entire project. Then he created a login feature branch and began to work. So he created the first commit. He created the second commit. In our previous example, it was input fields and submit button. And now he wants Mary to begin contribution to this project and write the test for the code that he already created. In order to share this code with Mary, what John is doing, he performing a git push and all code that John has created is pushed to GitHub repository. And at the same time, a branch on the remote server also created with exactly the same name that John has, but it also has a prefix origin, origin slash logging feature. And all the work that John performed on his computer right now is available on the server. Now Mary can clone this project and get all this code. So Mary execute command git clone. And when she does that, she clone entire project as well. So she cloned master branch and she also cloned automatically login feature branch. At this point of time, all three locations have exactly the same code. GitHub repository, John's computer and Mary's computer have all the same code at this point of time. And now Mary continue. So she creates login test branch. She create a first commit and John is keep working on his own computer. Then he creates another commit and another commit. And then he realized, okay, his job is done. He is ready to perform integration test with the login test that Mary is working on. And he execute another git push and pushing all his changes to the remote repository into the branch. Mary in the meantime is keep working. So she is created another commit. And when she is done, she perform also command git push and push her changes to the GitHub repository. Now at this point, remote repository have three branches. Master branch, login feature branch, and login test branch. Login feature branch has all the code that John has created and login test branch has all the test code that Mary wrote for this functionality. Now, in order to test this, we need to merge all these changes together. And Mary creates an event called pull request or PR. So pull request is a procedure in Git when the code can be reviewed before merging into the certain branch. So since login test was created by Mary, and since she's merging this code to login feature branch that belongs to John, John will perform a review of those changes just to make sure that the code that Mary wants to merge into his branch will not break anything. John performs the pull request. He validates that everything is fine and confirm the merge. Then after that, John just want to validate how everything works together on his computer, the code and the test that Mary created. So he execute command git pull, and then all the changes that were merged on the GitHub repository is now available in login feature branch on his computer. So John run the test. He validates the test are working. All the code together is working just fine. And then John create another pull request at this time from login feature branch to a master branch. And usually this pull request is reviewed by Tech Lead or other developers just to make sure one more time that the code that was created by the entire collaboration of John is Mary is not breaking anything, that it is according to the coding standards and follows the practices that established within this team for the code quality. So this is how the typical collaboration of two and more developers perform using GitHub repository. And let me show you another example. What is merge conflict? So this is the situation when two or more changes performed at the same version of the code and Git simply does not know which version is correct. So this is the example. So we have exactly the same project, the same repository. We have two engineers, John and Nick, and both of them begin working on this project. But with the difference that John will work on login feature and Nick will work on sign up feature. So both of them work on the similar functionality and what they did is that John implemented the cancel button of the green color and the Nick decided to implement cancel button as a purple button. So that John completed his work, he created commit and then he pushed his changes to the remote repository. After that, he created a PR and merge his changed into the master branch. Then Nick was working on his sign up feature. He added one more commit doing something and then he pushed his change to the remote repository to his own branch. And Nick, I remind you, created also cancel button and now he want to merge his cancel button into the master branch. Nick creates a PR, but unfortunately we have a merge conflict. And why do we have it? Because master branch already have a cancel button which is a green color, but Nick want to merge his cancel button which is a purple color and Git simply does not know, okay, which button have to be there, green or purple. And that's why we have a merge conflict. This conflict was created because the version of the branch that Nick was working on at the time this branch was created did not have any information about the cancel button. But at the time Nick was trying to merge his changes into the master branch, the cancel button was already there. So that's why Git was confused. Hey, wait a second, cancel button is already there. Why are you trying to push another cancel button to the same repository? So sorry, I got confused, you need to figure out this. So how the merge conflicts are resolved? Usually you can do it in two ways. One way is just directly on the GitHub or another way you can merge the changes of the master branch into your working branch and then manually resolve those conflicts. And this is what Nick is decided to do. So Nick execute command git merge and now both cancel buttons are available in his signup feature branch. We have two cancel buttons, so how do you think we should proceed about this? Which one we should keep? Nick and John, after certain negotiations, they decided, you know what, let's go with the yellow button as a result. And Nick creates a new resolution as a commit that cancel button will be a yellow color. After this merge conflict is resolved, Nick create git push. He pushed the changes to his signup feature and then after that he can create PR without a merge conflict because the merge conflict was successfully resolved in his branch resulting in the new commit. And this new commit does not have any conflict in the master branch. So this is how the typical merge conflict situation look like. So let's talk about the most popular git commands. So some of them I already mentioned in this presentation because when you work with git, you usually use command line, but you also can use some UI interfaces to help working with git. So git init is a command to initialize git in the certain folder. If you don't have git for the project and you want to initialize git, you can perform it with this command. Git add is to add files into git. Which one would you like to add? And space dot means that you want to add all the files. And if you want to add some particular files in the folder, you just put git add and name of the file. Git clone and repository URL is the command to clone the copy of the repository that is stored on the server, such as GitHub. Git branch space branch name is the command to create a new branch inside of your git project. Git checkout branch name is the command to switch between the branches. For example, you created a branch login feature and then you want to switch back to the master branch. You type git checkout master and you switch back to the master branch. Git commit dash M and message. When you perform a commit within the git, you execute this command. And instead of message, you type a descriptive message, what exactly was saved inside of this commit. Git pull and git push is update the code. Git pull is you pulling the changes from the server. Git push is you pushing your changes to the remote server. And git merge with a branch name is the command when you want to merge this branch into your particular branch. And if there is a merge conflict, you will see those merge conflicts that you will need to resolve. And some of the git best practices. So commit often. This is the most important best practice. Perform commits as often as possible and do not accumulate unsaved changes in your code, creating a big pile of changes at once. When you're working on code and know that this change is working, make a commit. Made another change and you know that this change is right, made a commit and so on. And second thing, make small changes at the time. So when you work on the project and made some small changes, create a pull request right away and merge those changes into the master branch. The longer you hold your changes from pushing back to the master branch, the higher probability that you will have a merge conflicts or other incompatibilities with your code and the master branch source code. Use branches. This is also considered a best practice. Always use branches, create your own branches, give a good naming to your branches when you work on certain features and functionalities. Write descriptive commit message. When you perform a commit, provide a good description. This helps a lot when you need to go back in time in your timeline and to realize, okay, which commit do you need to find out what do you changed in the past? By providing a good commit messages, it gives you a good clue which commit you will need to pick. And obtain feedback through the code reviews. So performing pull requests and making code reviews is the way how you actually learn how to write a good code because when you perform PR and code review, the more experienced developer will give you some advices and suggestions how you can improve your code and write your code better. And the last thing is identify a branching strategy. Usually each team or organization have their own branching strategy. So you need to identify this branching strategy and follow this branching strategy along with the team. All right, that's it and see you in the next lesson.