I subjected myself to git a lot within the past couple of days, and I think I've understood a big chunk of how git works and how to have a clean workflow. But I still have one "problem" or one question I need to understand:
Git rebase changes the history. So using it on a remote-branch is bad. Yes there is git push --force but when others work on the remote-branch it should not be used.
And here my problem kicks in! The good side of a remote repository is, that you always have a backup of your work and, as stated above that others can also work on it. So splitting up the master into branches for each big feature of the project is a good thing, because 3 people can work on origin/feature/, 2 people can work on origin/feature/ etc. and so on. Having those merged with origin/master at the end (yes with merge commits) is totaly fine, and one can look at the history at the end and see which feature went into which version of the project (tagged commits on the master). But what about the level under each branch?
Let's say of those 3 people working on feature1, 2 shall work on the user-controls. Now person A starts working on it, following this workflow and has his local branch. Now the user-controls is a bigger thing to do and within his work-day he was not able to finnish it and his code is not buildable. Person B shall continue on what Person A did, but pushing non-buildable stuff into the remote is bad!
My dilemma resulting out of this situation is: You have the following possibilities:
You create a sub-feature-branch on the remote: origin/feature/-chat
Then you push your unbuildable changes to that branch. And person B can use your stuff.
problem: Without using git rebase and force-push the changed history to origin/feature/-chat you would have to merge (with commit) the branch into origin/feature/ which makes the git-history unreadable again.
You push the unbuildable changes into the origin/feature/ branch.
problem: Others can pull your changes, and would need to either comment out your code, or reset their local feature/ branch, to the commit before yours.
Same as 1. just that after the chat is done, rebase is used as usual, but the remote branch origin/feature/-chat is deleted after those opperations, so it can't be used anymore.
The first thing is not realy nice in my opinion, since you will end up in a bad history again. At least then, when the remote-repository forbids force-pushes. The second thing would be ok, if Person A marks his commit as not buildable (perhaps tags can be used here, so all buildable commits get a certain tag for example) but still I get the fealing this is not very clean. The third thing is my favorite so far, but it would mean a lot of branch-deletion, especially on the remote, which could get a problem, if a user has not got the right's for deletion. Eventhough those could be given, in case this would be the workflow of choice. But is this realy the cleanest thing to do?
So my question asically is: Is there a fourth option to allow remote backup (via remote branches) of own changes and easy teamwork while having the git-history clean by keeping the amount of branches, finally listed within the history to a minimum? Or is it the third option I gave?
