How to lose your fear of using Github as a beginner

Git and Github scare some people, and it's something understandable: it's learning curve is steep, and there's lots of simple commands that can easily turn into complicated and scaring problems and conflicts. This article will not be a step-by-step Git and Github lesson, but here I'll share some things that I do in college group projects to avoid headaches while dealing with a Github repository used by multiple people at the same time.

1. Create your group project repository

• Don’t mark the “Add a README file” right now. This will make your life easier later on.
• Using a .gitignore file is very important to avoid conflicts in your repository. It’s basically a “ignore this files here” type of document, but it depends on your project purpose, so here's a link to a .gitignore tutorial.

Gitignore Explained: What is Gitignore and How to Add it to Your Repo

2. Link your remote repository to your machine

Now that the remote repository is created, we need to link it to your own computer, and that’s why I said above not to mark the option “add a README file”: when you mark this option, the repository is created without the link-to-machine tutorial below.

Follow these steps on your terminal and link your machine to the remote repository.

3. Call your mates to collaborate in this repository

For this repository to become a group repository, you need to invite your group members to be collaborators: go to Settings → Collaborators → Click on “Add People” and search your group member’s github username.

4. Set your development strategy

Now we can talk about the development strategy implemented in your group, and I'll use an example of my own. We usually:

• Set development tasks using kanban or some agile method. More about kanban here:

Kanban - A brief introduction | Atlassian

• Divide those tasks between your group
• Create branches according to the tasks taken. For example, if you took the "Home Screen" task, you'd create a "feature/homeScreen" branch, like this:

git checkout -b "feature/homeScreen"

• Now the goal is to finish this task before you merge this branch to the main branch. Once you're finished, you can upload those changes with these commands on terminal:

git status //that's a must-do to git/github beginners
git add .
git commit -m "feature(homeScreen): <I usually put here what I did>"
git push -u origin feature/homeScreen

5. Initiate your pull request proccess

Now you have pushed your changes into your feature/homeScreen branch. As soon as you do that, this type of message will appear in your repository:

This message appears to indicate that you can initiate the pull request procedure. A pull request — also referred to as a merge request — is an event that takes place in software development when a contributor/developer is ready to begin the process of merging new code changes with the main project repository. A pull request works by allowing developers to create new features or squash bugs without affecting the main project code or what the users are seeing. This way, they are able to write and test code changes locally without having to worry about breaking the overall product.

Clicking in “Compare & Pull Request” will lead you to a page like this one below.

It’s important to comment your pull request. Normally, I’d write something like “What I’ve done: A, B, C and D and also fixed X, Y and Z”.

Note that the pull request has a message saying "Able to merge. These branches can be automatically merged", which means that your changes don't collide with the code inside the main branch. But sometimes your changes impact the main code, creating a merge conflict. Merge conflicts happen when you merge branches that have competing commits, and Git needs your help to decide which changes to incorporate in the final merge. Git can often resolve differences between branches and merge them automatically.

6. Merging into main branch

If your task branch doesn't create merge conflicts, this message below will appear, and you or any other collaborator of the repository can accept it (in terms of small college projects, at least), merging your changes to the main code. It's encouraged to let other group member accept your pull request, as this method engages communication and group alignment. If you accept yourself, don't forget to communicate to the other group members before merging your code.

After merging, follow these commands to get the updated code:

git checkout main //changing from your task branch to the main branch
git pull // fetching all the changes combined into your local machine

Then you can go on to your next task, which follows the same steps showed.

But, as I said, sometimes we come across some merge conflict issues. As this type of problem is particular to each merge situation, I'll link an article that shows the easiest way I found to deal with conflicts: using vscode and dealing with the conflicts there. To my fellow portuguese speakers, I'll also link an awesome article made by my good friend Lorena that shows how to do the same procedure, but in a more didactic way.

Resolving Merge Conflicts with Visual Studio Code

Como dar merge em branches usando GIT?

Lastly, I'll share a Git and Github cheat sheet, that mentions and explains essential command lines.

Git and Github Guide

And that's all! I hope this simple article helps you and your friends to deal with github as a team. Good studies!