I have been using git for version control for sometime. And as all the software developers around are aware of this fact - to get a merge conflict during the final days of the release-cycle is very common in today's fast business world. Here I will try to list some steps, which if followed regularly, will reduce the chances of getting a conflict during code-merge.
$ git pull
2. Before creating a pull-request, get all the changes from the destination branch to your local branch.
$ git pull
$ git add your-file/files
$ git commit -m "your message"
$ git merge origin/release-branch-name
$ git push origin your-branch-name
The fourth step from the above is the most important - you try to get all other code-changes from the release branch to your local branch. 4th and fifth steps can be interchanged, but after git-merge, if you find some changes in the code, you should always push it. Else the same story of receiving a code-conflict can happen later. After the final push to upstream, create the pull request.
This is what is described in point 2 above, stick to that guideline.
Case 2 - You were about to finish your current work, your manager asks you to look into another critical issue. You finish that critical task first and come back to your old work.
This also should be a cakewalk, if you follow point 2 above. Commit changes in branch-one first. Checkout the critical branch, finish the code, push changes and create the PR ( request to merge to release branch) Come back to your old branch, finish the work, take a pull, merge with release branch, and a create a PR for your branch to release.
Gradually with time, you can master the art of using git for version control. Keep in mind the four kinds of files under git - unstaged, staged, committed and stashed. Git is now the most widely used version control tool in the software industry. And if you are using it at work, you should have more commands on it.
My guidelines
1. Take frequent code updates, this will ensure you are receiving the latest changes in your codebase from all other developers.$ git pull
2. Before creating a pull-request, get all the changes from the destination branch to your local branch.
$ git pull
$ git add your-file/files
$ git commit -m "your message"
$ git merge origin/release-branch-name
$ git push origin your-branch-name
The fourth step from the above is the most important - you try to get all other code-changes from the release branch to your local branch. 4th and fifth steps can be interchanged, but after git-merge, if you find some changes in the code, you should always push it. Else the same story of receiving a code-conflict can happen later. After the final push to upstream, create the pull request.
Some typical cases
Case 1 - You working on your branch, you finished coding and testing, want to merge your changes to release branchThis is what is described in point 2 above, stick to that guideline.
Case 2 - You were about to finish your current work, your manager asks you to look into another critical issue. You finish that critical task first and come back to your old work.
This also should be a cakewalk, if you follow point 2 above. Commit changes in branch-one first. Checkout the critical branch, finish the code, push changes and create the PR ( request to merge to release branch) Come back to your old branch, finish the work, take a pull, merge with release branch, and a create a PR for your branch to release.
Gradually with time, you can master the art of using git for version control. Keep in mind the four kinds of files under git - unstaged, staged, committed and stashed. Git is now the most widely used version control tool in the software industry. And if you are using it at work, you should have more commands on it.
External links
1. https://git-scm.com/docs/gittutorial
