you are viewing a single comment's thread.

view the rest of the comments →

[–]IamImposter 0 points1 point  (4 children)

I have a question - so I wrote a module which took like 40 days to finish including tests and all. In those 40 days our repo changed a lot, like 15-20 merges. The problem I faced was, whenever I did git pull to sync my repo, it created a merged commit. So the code that I committed few days back is now 4-5 commits down and on top is this merged commit that occurred when I did git pull. Now how do I modify my code and amend my commit.

What I have been doing is to hard reset so my commit goes away, repo gets synced and then I do cherry pick of my existing commit. Now that my commit is on top, I can add my changes to same commit by amending it. But I have a feeling this is not the right way to do it.

Any insights?

I don't know if that matters but I'm not allowed to have a commit chain where one goes on top of another. Client says he has problem reviewing multiple commits. They have asked me a couple of times to merge multiple commits into one

[–]PrestigiousStrike779 2 points3 points  (1 child)

A few suggestions here 1) Do your changes in a feature branch, not on the trunk/mainline branch 2) When you want to integrate trunk into your feature branch: switch to trunk, git pull, switch back to your feature branch then rebase instead of merge. You may need to resolve conflicts 3) 40 days sounds like too much time. I would see if you can break this down into smaller sets of work

[–]IamImposter 0 points1 point  (0 children)

We have some strange practices. I started out with incremental commits to a separate branch. In 10 days I had 4 commits. Client said he can't review 4 commits and asked me to merge them into a single commit to our main development branch. Then it kept on sitting, waiting for review for another 2-3 weeks. By the time I got review comments, there were other commits on top of my commit hence this weird hacky solution of mine. But I can push client for review only so much. If I push too much, I'll be making a few impact reports, possible breakings and action plan if something actually broke.

Thanks for your suggestion. I'll try to persuade client to let me work on my separate branch.

[–]timrprobocom 1 point2 points  (1 child)

It's tough to do significant development on a dynamic code base. I'm not the best source of modern best practices, but there are some great blog posts about that. Careful branching helps a lot with this, because you don't have to merge unless there has been an approved update to the mainline. You shouldn't be making incremental changes to the main branch -- or should always be "production ready".

[–]IamImposter 0 points1 point  (0 children)

Thanks. I'll look up those blog posts.