From the course: Git for Teams

Best practices: Committing and syncing - Git Tutorial

From the course: Git for Teams

Start my 1-month free trial

Best practices: Committing and syncing

“

- Following a few best practices when starting to use Git can set your team up for success. Let's take a look at a best practice that will make life easier for your team. The golden rule of Git and any version control system you might use is to commit your source code frequently. When making these frequent commits, you should keep them small in scope and focus on a single feature per commit. Small and frequent commits are very beneficial. First, you're less likely to lose code because it's safely stored within source control. Second, it gives you the opportunity to push those changes to your teammates more frequently. Small-scoped commits are so much easier to share with your team members than these large, sweeping changes to a system. By frequently pushing small commits, you're going to improve the visibility of your changes, you're going to reduce the potential for merge conflicts, and it's going to make integrating much easier. At the same time, it's important that you stay up to date with the changes that your team members are making, so you need to sync frequently with shared repositories using pulls or fetches. Syncing often reduces the chances of a merge conflict. Nobody wants to deal with those. It also keeps you informed of the changes that your team members are making because they could be potentially impacting the code you're working on. Let's revisit one of the scenarios we walked through earlier to see how it could have easily been avoided by syncing. Okay, so we're back to our two team members, User1 and User2. User1 is going to make changes to the demo file. So, they open the file with Vim and then they add their changes. At this point, they're happy with the changes, they write the file, and then they make the commit, adding the changes to the stage, and providing their commit message. At this point, they're then going to push these changes to the central repository shared by the team. Now, if you remember the scenario, User2 also wants to make changes to the demo file. This time, instead of just making their changes, they're going to come in at the beginning of the day and they're going to perform a pull. This is going to give them the changes that User1 just made, so they're now free to make changes to the demo file without fear of a merge conflict. So, let's go in. We can add User2's changes, write the file, and then we'll commit those changes, and then User2 can push them without any problems, such as a merge conflict. So, let's review. By committing frequently and pulling often, you will stay current on the latest changes of your repository and those changes made by your team. I recommend doing several commits a day and syncing several times a day. At least do it once a day, and this is going to help you and your team avoid a lot of challenges like merge conflicts and large integrations.

Contents