When working on a programming project, you'll more than likely use Github. A cloud-based Git repository hosting service that makes it easy to use Git for version control and collaboration.
Working and collaborating with other team members during projects is a common practice in software development and having a clean flow of who is in charge of what, is so important. Let's talk about some good Git practices to use to get into an organized and efficient work flow.
BRANCH OUT
One of the "golden rules" of collaborating is to create a new branch off the default Main branch. If everyone is writing code on top of each other in the same branch, it can cause unnecessary extra work, create bugs, and maybe even break the code. When you create your own branch you are able to test your code before submitting it to the main branch and ensure it works.
It is best practice to create a new branch from your forked and cloned copy of the repo, after you finish your portion of the code, then push it up to Github to be reviewed and then merged.
To create your own branch you can enter the following into your terminal and it will create and direct you to your new branch:
git checkout -b <NewBranchName>
After you get done with your code, you want to add the new changes by running:
git add .
Then, you'll want to run a commit command:
git commit -m "message with what is being committed"
Once, you've done that and you're ready to push up your branch you'll run:
git push origin <NewBranchName>
When you go back to your repo on Github you should see the newly added branch and an alert with a button to "compare and pull request". Click it and sync your new branch with your repo.
Hopefully, so far this is something you're already familiar with. In the next part, we're going to talk about how to merge all the work you've just done into your main branch to be put together.
Pull Requests
Pull requests are when the collaborating really starts to come together. In Github there is a tab to start a pull request. A pull request is important for two reasons.
It allows your fellow collaborators to review and discuss your branch before it gets committed to the main branch.
This request is also how you will merge your new branch into the main branch.
Merging 101
The above is an example Github page that shows the steps of how to merge those branches as well as leave comments about the branch that's intended to be merged. Let's go over it.
- Create the pull request.
- Leave any comments or overview of what is being added.
- Go to the "Files Changed" tab to review the files that have been changed.
- Check to resolve any merge conflicts and complete the prompts to merge the pull request.
- Once your merged branch has been confirmed successful, it is typically best practice to delete that branch. You can do this by running
git branch -d <NewBranchName>
Okay, let's go over a scenario.
You're working on a group project and you have already successfully merged your branch in Github. Now it's time to work on a new branch but once you open your Visual Studio Code you'll notice that it doesn't have your newly merged code added. To pull down your newly merged code, you're going to direct yourself to your main branch. Then run the following: git pull origin main
This will pull down your newly updated main branch you just merged.
Conflict Resolution
To prevent merging conflicts with your branches it is important to make sure that you use your main branch for merging purposes only. Try and not make edits directly in your main branch if you can help it. Why is this best practice? Because in the case you create a new branch, add some code and commit, then go back to the main branch, add some code and commit, when you go to merge you will get an alert to resolve the conflicts. This creates confusion because now there will be changes on your main branch that won't be on your new branch you just made.
Now sometimes things happen and you get merging conflicts.
IT'S OKAY!
With a few steps you can fix it.
Click the "command line" on the prompt in Github.
Ensure your main branch is up to date in your repo. To do this, run
git pull origin mainin your terminal.Switch over to your new branch and run
git merge mainto merge the new branch into main.You will be prompted to resolve the conflicts. You can find instructions on how to merge those conflicts here.
After you have resolved any conflicts, you'll need to re-push your new branch.
Navigate to Github and refresh the page and you should now be able to merge in your new branch successfully.
As you can probably assume, that can get tedious quickly.
Following clean Github flow and having great communication with your team mates will help keep you from doing unnecessary work.
Happy Coding!
SOURCES:
Flatiron Canvas
Top comments (3)
Another piece of the git workflow that is pretty common and can help reduce some of the possible code conflicts as well as sometimes making reviews easier is rebasing.
It is a fairly common practice to rebase your code before creating a pull request. By rebasing you are essentially taking your branch and moving the point at which it split from the main branch up to the most current state of the that main branch. (Assuming you rebase onto the main branch).
This is done like so
git rebase main. Similar tomergeyou may have to resolve conflicts but you can be sure that you are resolving them with reference to the most recent state of themainbranch.Hello Katie N,
thank you for your article.
In my opinion it is easy to understand and short enough not to ask too much of a beginner.
"Once your merged branch has been confirmed successful, it is typically best practice to delete that branch..." This is good advice as I remember having so many branches that I lost track of which ones they were and it didn't really matter to keep the older ones.
"Following clean Github flow and having great communication with your team mates will help keep you from doing unnecessary work."
This is the most important part in my opinion as it can be frustrating to resolve issues on a regular basis due to the chaotic, non-communicative workflow.
Excellent