Once you have the development done, you know how to use the branches and develop each feature there comes the moment in which you want to send your code to a remote repository/branch. In this article you will learn more about how to deal with remote repos, how to push, fetch, create a pull request and merge your feature branch with the remote branch.

How to remote?

You’ve finished the development of the feature and you tested your code, now you want to send the code. For that you will need to firstly add the remote branch to your git settings on your machine, to achieve that you run:

git remote add origin <connection string>

You can also check all the remote branches by running:

git remote -v

After that done you can push the code to the branch, per example master:

git push origin master

In Git, “origin” is a commonly used alias for a remote repository. It’s a way to refer to the remote repository’s URL or location. By convention, “origin” typically points to the remote repository from which you cloned your local repository.

This is the name of the branch you want to push to the remote repository. In Git, “master” is often the default name for the main branch in a repository. However, the main branch may be named differently in some cases (e.g., “main” instead of “master”). If your repository uses a different branch name as the primary branch, replace “master” with the appropriate branch name in the command.

So, when you run git push origin master, you are pushing the changes you’ve made in your local “master” branch to the remote repository referred to as “origin.” This command will update the remote repository with the changes you’ve committed to your local branch, making those changes accessible to others who have access to the same remote repository.

Collaborating with others

You can collaborate in two ways by making part of a repo and having permissions to push to the master and make pull requests. Or you can just read a repo but not interact with it. For each there’s a practice to take.

If you got invited to a repo you can just access and get the ssh link, in which you can run:

git clone <ssh>

This will enable you to download the code and contribute to that project.

Now you don’t have the the permission you can fork to you. This is a feature normally provided by Git hosting platforms, here what you’re actually doing is to duplicate the repo to your account and by doing so you can clone that copy that is now yours.

Besides you can develop new features and send a PR to add new features and contribute to the project, then the PR can be reviewed and accepted or declined.

Conflicts

These can happen quite often so it’s important to communicate and say in which part each person is working on, in which features/files, to avoid a development that then need to be redone.

But in that case what it’s necessary to do is to understand what code fits where, re-run tests, develop adaptations and then deliver the feature to be reviewed.

When Git detects a conflict, it inserts conflict markers into the affected file to indicate the areas where conflicts exist. Conflict markers look like this:

<<<<<<< HEAD 
// Your changes
=======
// Their changes
>>>>>>> branch-name

<<<<<<< HEAD: This marks the beginning of your local changes in the current branch.

=======: This is a separator that separates your changes from the incoming changes from the other branch.

>>>>>>>branch-name: This marks the end of the changes from the other branch (the branch name is usually provided here).

To resolve conflicts, you need to edit the file manually to choose which changes to keep. You can decide to keep your changes, the other branch’s changes, or make a new set of changes altogether. You should remove the conflict markers and make the file consistent and correct.

After resolving the conflicts, save the file, and then stage it using git add. Finally, commit the resolved changes with a commit message that describes how you resolved the conflict.

Once you have resolved all conflicts and committed the changes, you can continue the merge or rebase operation by running git merge --continue or git rebase --continue, depending on what you were doing when the conflict occurred. This tells Git that you have successfully resolved the conflicts and it can proceed with the merge or rebase.

Conclusion

Now you have a good overview about Git, you can check more on the git section about Git and how to perform more complex tasks such as squashing, cherry picking and others.