You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Let's say, there is new change to the master so there is possible a merge conflict with my commit. Then merging master to my branch is too hassle. To avoid merge conflict, is it better to Fetch first then Pull the changes then I proceed to Stage now for my changes?
If you are asking for confirmation, yes this is the best practice to fetch the changed commits from Bitbucket see the changes, and then merge the changes to the branch you are intended to merge.
I guess Other’s practice is to Stage first their changes when there is conflict then they merge the master to branch. That’s a long process right? If there is way to catch the conflict than proceeding to merge master to branch.
Instead of that process, what I did is Fetch first then if there are changes in master, I Pull it, then Stage my changes for commit then Push. It is like I’m avoiding the merge conflict and merging master to my branch.
I’m new to this so I want to understand the process. I’m just a developer and now they’re letting me to deploy and merge my changes for my skills to expand.
It may see long process, but if we have to avoid the merge conflict we have to do this, besides you will have the latest code from other developers too :-)
If you are continuously working on code, its best practice to follow the steps below,
Pull (includes two steps - fetch and merge) the code from remote branch to see if there are any changes.
Regularly commit your changes to code in the branch that you are working on
Once the code is finished, push the code to branch and create a pull request in remote.
If there are say merge conflicts, you will get to see them in pull request itself. It's not much to worry about the merge conflict here :-)
Let me know how branching is done in your development environment..
The branching is like we have our own branch cloned from master branch. Do I need to make a remote branch for my local branch or my local branch is enough already? What’s the use or difference of my local branch and its remote branch? I have only local branch and haven’t push this out and haven’t created my remote branch yet as I don’t know the difference. My team can’t see yet my local branch.
If you push your local branch to remote, your fellow developers can see how the progress was during the development of code, I guess it's best to protect the master branch (without committing to it directly), rather create a pull request every time code has to merged then review the code, after which the code can be merged into the master branch.