Timeline for Is it wrong to git push force branches?
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 6, 2021 at 10:00 | comment | added | Askdesigners | Never pushing a feature branch is a terrible idea. Do you not ever review other people's code? Or have 100% confidence that your machine will never fail/get stolen or lost? Do you never hand off feature branches? Or use branches as POC or to explore ideas that will never go into main? | |
| Jun 16, 2020 at 10:01 | history | edited | CommunityBot | Commonmark migration | |
| Mar 2, 2020 at 13:26 | comment | added | Tiago Medici | i wonder why people don't use git flow ... the flow starts and finishes features, you never push feature branch, or any other kind like hotfix, bugfix etc ... remote branches must be 2 dev and master | |
| Apr 12, 2017 at 7:31 | history | edited | CommunityBot | replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/ | |
| Mar 14, 2016 at 15:32 | answer | added | chtenb | timeline score: 4 | |
| Mar 14, 2016 at 14:44 | history | edited | chtenb | CC BY-SA 3.0 | Give reason for uniqueness. |
| Mar 14, 2016 at 14:02 | review | Close votes | |||
| Mar 29, 2016 at 3:04 | |||||
| Mar 14, 2016 at 13:54 | comment | added | enderland | @gbjbaanb but... he didn't, and so we have to work with what we have. To me it is far more useful to have a single commit on the master branch instead of 30+ individual and incremental commits from each feature branch. But everyone will have a different workflow, I guess... | |
| Mar 14, 2016 at 13:53 | comment | added | gbjbaanb | @enderland everyone wants pretty history, its still the wrong (and dangerous) thing to do as shown by the link. Torvalds should never have put it in, he should have allowed commits to be "compressed" on display instead. | |
| Mar 14, 2016 at 13:52 | comment | added | chtenb | @gbjbaanb That's a matter of opinion I think. Many teams use a rebasing strategy to keep their history clean. | |
| Mar 14, 2016 at 13:52 | comment | added | enderland | @gbjbaanb if you make WIP commits, a rebase is very useful to avoid having many commits for a single days worth of work. I often make commits for small changes just so I have a "undo to a state I remember" option if needed - most of these are irrelevant/noise to the main history of the repo (which is why rebase is so useful). | |
| Mar 14, 2016 at 13:47 | comment | added | gbjbaanb | The problem is rebasing. Push normally and do not worry about history, SCMs are supposed to preserve history - its their entire purpose. When merging, use merge instead of rebase. The close-duplicate link shows why. | |
| Mar 14, 2016 at 13:45 | comment | added | gbjbaanb | Possible duplicate of Is the git "Golden Rule of Rebasing" so essential? | |
| Mar 14, 2016 at 13:44 | answer | added | enderland | timeline score: 7 | |
| Mar 14, 2016 at 13:41 | comment | added | Doval | You could back up your repository the old-fashioned way every night. Git being distributed has the nice side effect of doubling as a backup but you shouldn't be pushing unfinished work to public repositories as a backup measure. | |
| Mar 14, 2016 at 13:33 | history | asked | chtenb | CC BY-SA 3.0 |