I just need to clear my doubt on something. Lets say my colleague and I are working on some code on the same branch called dev. What is the proper way of pulling his code without any conflict ?
This is what I have done, I have done the following
git add .
git commit -m " First Commit"
git pull origin branch dev
After running this, it automatically merges with my existing code without any conflict . Are these the correct steps?
Thank you.
What is the proper way of pulling his code without any conflict
Let’s be clear. Commit pull push is the standard correct procedure for sharing your work. But if you think there’s a way to guarantee that there won’t be a conflict when you pull, think some more. There is no such way. Any time two people work on the same files, conflict can result. Just get past your fear of conflict, is my advice.
As mentioned, "without any conflict" is not something Git will guarantee.
Only good communication between you and your colleague can guarantee that you are not working on the same sections of the same files, removing any chance for conflict.
But regarding your way to integrate your colleague changes, I would recommend using in your repository (since Git 2.6):
git config pull.rebase true
git config rebase.autoStash true
Then your git pull would actually rebase (replay) your local commits (that you have not yet pushed) on top of the updated dev branch.
That will make for a more linear and clearer history.
Some answers here may help you, but I think some things should be more clarified.
the only thing you can do is minimize the chance of conflicts and if they occur you can ease the process of handling them.
Conflicts generally arise when two people have changed the same lines in a file, or if one developer deleted a file while another developer was modifying it. In these cases, Git cannot automatically determine what is correct.
Quoted from Atlassian Git-Merge.
git pull is open for conflicts as well, obsiously:
git pull will download remote content and immediately attempt to change the local state to match that content. This may unintentionally cause the local repository to get in a conflicted state.
Quoted from Atlassian Git-Pull
Beyond the dry definition of conflict, your work culture should lead to minimization of conflicts.
It basically gets down to avoid working on the same files, and if you do, make sure your'e not changing the implementation of the same functions, this will minimize your chance of tackling conflicts.
First of all, try hardly to don't work on the same branch and separate your work to different feature branches, so instead of pulling the same branch, now your merging to the feature/release branch, depends on your gitflow.
"But we are working on the same feature"
Great, split it do different tasks, if you find yourselves working on the same task, you probably doing something wrong.
Try to split your feature to smaller tasks and open a branch for each one of them, so you can work separately.
"But we can't work separately because my work is dependent on his"
No problem, just do your task when your teammate has finished his; if you split your work to smaller tasks, you won't wait much until his finished, and if it comes to a situation you are really ping-ponging between branches in very small time intervals, maybe one of you should take care of the whole feature and the other one work on something else.
Eventually everyone has conflicts, even if you work safely.
If you choose to merge one branch to another, git is checking the whole difference between the source and the target branch, so if you have several conflicts you will receive them all together and be asked to fix them.
Alternative approach is to use rebase, it makes your git tree more flat and instead of differing the whole branches, it starts from the target branch and stars to apply the source branch's commits from the last point the branches were the same, one after another until it committed the last commit of the source branch on the target branch.
This way (rebase), if you had any conflict, you will tackle it on the commit that caused the conflict, being able to alter the specific commit changes; so if you had several conflict from different commits, you will handle them separately.
There is also downside to this:
One caveat to consider when working with Git Rebase is merge conflicts may become more frequent during a rebase workflow. This occurs if you have a long-lived branch that has strayed from master. Eventually you will want to rebase against master and at that time it may contain many new commits that your branch changes may conflict with. This is easily remedied by rebasing your branch frequently against master, and making more frequent commits.
Quoted From Atlassian Git-Rebase
You can read more about the difference between git merge and git rebase.
You can read more about the gitflow workflow.
