-2

Context

We have a team of one active developer and two occasional ones. We are setting up a new project and after reading https://nvie.com/posts/a-successful-git-branching-model I was seduced by the idea of keeping only master and develop branches in the remote git repository and all feature-* branches locally to keep a clean remote.

The manager wants developers to push commits in the remote daily to not lose code even if the state of the code is dirty or in work in progress. It looks incompatible with the previous link flow.

Problem

Pushing commits daily in the remote will certainly pollute it with meaningless commits. After some days, we will have several commits with more or less the same title which will just be some sort of backup of the code.

I thought about a way to amend remote commits to keep only one remote work in progress commit but it does not look possible or not advised. I also thought about pushing with force option the branch so I can amend locally and push my branch to the remote. I am not sure if it is something advised.

Question

Is there a proper way to push the code to the remote daily without creating several commits and potentially pollute the remote repository?

4
  • 2
    Why are you worried about work-in-progress commits? Is there a continuous integration server listening for commits? If you want to keep your development branch clean, you could create a branch from it, labelled "nightly", which you merge and push at appropriate intervals.
    – BobDalgleish
    Commented May 7, 2019 at 17:39
  • There is no continuous integration server at the moment but it is planned to add one. I am worried that committing because I have to instead of committing because I have a meaningful piece of code to add will add several commits to the remote without value. It will just be a list of work-in-progress commits describing the same feature. I would prefer to regroup all those remote work-in-progress commits in only one.
    – Mat.R
    Commented May 7, 2019 at 17:44
  • git is very good about compressing data as required. You can always remove the "nightly" branches after each merge so that only useful commits are kept. You will need to not use the fast-forwarding setting when merging.
    – BobDalgleish
    Commented May 7, 2019 at 17:54
  • I will keep your option in my mind but still wait to see if I get some other answers to my question.
    – Mat.R
    Commented May 7, 2019 at 18:12

2 Answers 2

Reset to default
6

Stop worrying about "polluting" repositories. Commit whatever you like, whenever you like unless it affects other peoples code.

And if you are working in one developer feature branches your commits don't affect anyone but you.

Embrace the goodness of having all your incremental changes saved for posterity, or ignore them by hiding non-merge commits when you view the tree.

2
  • Is there a way to restrict other developers to push commits to "your" remote branch or do you only have to agree all together to only work on your own feature branches and then merge/rebase on shared branches (master, develop)?
    – Mat.R
    Commented May 8, 2019 at 19:37
  • I believe you can do some clever permission stuff. But given that you are pushing inorder to prevent data loss and that its not the end of the world if someone else pushes to your branch I wouldnt do it
    – Ewan
    Commented May 8, 2019 at 21:43
4

You should be doing all your work on feature/bug branches anyway, so you'd only be "polluting" those branches and since only one person is (should be) working on one branch, you're only "polluting" your own branch.

If you squash the commits in individual branches before merging to develop/master all that "pollution" goes away. This is what we do at my company and it works quite well.

3
  • Do you mean we can squash commits directly in the remote?
    – Mat.R
    Commented May 7, 2019 at 19:39
  • @Mat.R with force push and rebase -i you can do anything(be careful with shared branches)
    – Esben Skov Pedersen
    Commented May 7, 2019 at 19:45
  • 1
    I'm not a git expert but yeah, I think that's what I'm saying. If I'm starting a new feature, I branch off develop: git checkout -b NewFeature then as I work on the NewFeature branch, I make commits # do work git commit -m "first commit" # do work git commit -m "second commit" Then that code goes through a merge request/code review but before it does, I squash my commits. If I had pushed my branch to the remote, I would have to do a force push git rebase -i HEAD~2 git push origin NewFeature --force
    – Matthew
    Commented May 7, 2019 at 20:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.