Git Workflow in 25 minutes

Git flow is a big part of your daily tasks as a software engineer. Knowing how to manage tickets, when to make pull requests, how to let your team know what tickets you are working on, and how to effectively communicate with members on your team is crucial to developing enterprise level software. In this video, I demonstrate how I work with tickets, use git to create new branches, open new pull requests, and do code reviews.

git pull

Before you get started working on your ticket, make sure you pull in the latest code from the branch you are working off. Typically this is the master branch but in some cases, you could be working off a different branch. Doing a git pull will fetch and merge the latest code from the remote repository.

git checkout -b <BRANCH NAME>

After you have pulled the latest code, the next step is to create a new branch. You create a new branch so all your work is contained with its own commit history. By running git checkout -b <BRANCH NAME>, this will create a new branch and change your current branch to the newly created branch.

git add .

Once the work has been completed and tested, you want to stage your changes. This can be done by running git add . , this will take all the files you have worked on and add them to the staging in git. You can add individuals files by doing git add <FILE NAME> rather than adding all the files at once.

git commit -m “DESCRIPTION OF WORK”

After everything checks out, you are ready to make a commit. The way I think about commits is similar to how video games save. It will take a snapshot of all your code at that particular point and add save it so you can push it up to the remote repository. This is done by running git commit -m “DESCRIPTION”, the -m option allows you to write the description inline in your terminal. If you leave it out you will be sent to a text editor to enter your commit message.

git push <REMOTE> <BRANCH>

You are finally finished with your code and now it is time to push the code to do a PULL REQUEST. To push your new code to the remote repository you will use git push <REMOTE> <BRANCH>. The typical remote will be origin and the branch name will be whatever you called the branch when you ran git checkout -b <BRANCH NAME>.

Pull Request

Once your code is on the remote repository, you’ll want to create a pull request. In Github, you can find the pull request tab on the main page of your repo. Select the branch you’d like to merge your code with and enter some reviewers to notify others on your team to check out your solution. Don’t forget it is your responsibility to merge your pull request.

Code Review

Other members of your team or another developer should review the code for your pull request. This gives them the opportunity to understand your code and leave comments or suggestions to improve your solution. They will not be the one that merges your pull request into the branch. It is your responsibility to respond to all comments and suggestions before the pull request is merged in.

Merge and Test

So you have received a thumbs up and your pull request is approved. It is now time to merge your code into master. If there are any merge conflicts make sure you carefully fix those without introducing new bugs. Once merged, delete the branch and do a git checkout master. Then get the latest changes by running git pull, which should include your new code and test it out. If everything checks out you are ready to start your next ticket.

Please feel free to reach out if you have any questions, also don’t forget to LIKE, COMMENT, and SUBSCRIBE to my channel as well as my newsletter.

‍