Question

I have one dev branch and several feature branches. I found this git workflow on Atlassian. THe idea is the dev branch will be read only for all developers except for the moderator(s). All developers will work only off of the feature branches. But here's the problem -

Dev A starts working on a feature branch A (FB-A). The Dev branch will get progressed in the mean time. Dev A finishes his work on FB-A and commit and pushes code to FB-A (Commit #1). He will then do a pull from Dev to FB-A to get the latest. All changes from the Dev will get added/modified to FB-A. He will then commit and push these files to FB-A as well (Commit #2). Now, the files are ready to be merged to dev branch. When I tried to do it, it commits Commit #1 and Commit #2. Is this normal practice?

Is it possible to have only the first commit merged to Dev as it has the developer's actual changes? Am I missing something here?

Was it helpful?

Solution

From your description, it seems like commit #2 is a merge commit. This is good practice, because if you already have recently merged dev into FB-A by the time you merge FB-A into dev, you will likely have little to no merge conflicts. Commit #2 will have important information on how to merge updates in dev and FB-A together, so it is normal practice to keep the merge commit. It is also normal for this merge commit to land on the dev branch when you merge it in, since you are adding commits from FB-A that weren't in dev to dev.

Note: Even if you wanted to remove commit #2 before merging into dev, you would likely need to create another merge commit anyway to resolve conflicts.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top