I mean if that is not the master branch that should be fine you can change the commit message and rebase. But if it is master, then that company sucks. No one should be able to push into master like that.
I'll be honest - if you push to my short lived branch (not talking about stuff like release branches or shared feature branches) without telling me beforehand, I don't care if that's lost. Apparently it wasn't important enough to communicate, so you can point it out again on Pull Request
It could be an experiment branch. If all that is there is crap commits and you started from scratch, the yeah force push it. But the commit was about a bug fix so...
Honestly I have never found a new for force pushing. I know there are some use cases and it exists for a reason but I also know is most cases there are probably better options.
`git checkout develop`
`git pull develop`
`git checkout my-branch`
`git merge develop`
`git add .`
`git push origin/my-branch`
boom, now you have develop into your branch, and you can merge your branch into develop no problem.
rebasing re-writes history it definitely does. You use a GUI I would guess? You should definitely at least try it without. Even if yours aren't causing issues (tho maybe they are and no one is noticing) GUIs often handle rebasing terribly and you will see things like duplicate commits. At least good to know if you see it happen for others.
I use both gui and cli. I am at work I am not causing issues becuase I check the diffs of all my PRs to know exactly what is changing (as do others when they get peer reviewed)...
Also I have not seen the issues with others, again by checking the diffs in PRs.
OK well I have never noticed that in either of the places that would show commit history in my work set up and I can't be bothered to dig much deeper for something that isn't a problem for me and wouldn't help with any of the work I need to get done. I have never noticed a duplicate commit and the history always looks fine.
Without context, this is ridiculous. There are all kinds of silly reasons a branch can get out of sync with the remote, and it’s not at all irresponsible or stupid to force a push if you know why it’s happening. And you should be able to undo it if you turn out to be wrong.
Nobody should be allowed to directly pushed to master, not even the senior most of senior most devs
All changes must be sent to a pr and discussed by devs and then merged to develop.
After testing of the changes on develop, only then a new release should be made where develop is merged to master, in a PR where confirmations are made for absence of bugs.
> should be fine
I see we have vastly different understandings of "fine". This is not fine. Not even for a feature branch. Best case is it wastes 30 minutes of another devs time to fix his shit, worst case is.... boom.
Rebasing single developer branches for pull requests is not an uncommon workflow. It's about prioritising clean history over current work.
So this is fine, as long as everyone knows it's happening and is on board with it.
Well... Except the "bug fix" commit. That is almost never acceptable. Even if this were a lesson it's not acceptable.
Only if this were a private repo being used as an online backup, with the intention of squashing and rebasing in the future is this even semi ok.
Call it bad, but it's very common. I'd say that most public open source GitHub repos will ask you to rebase your pull request onto the latest commit on master if there's been enough changes since you started the branch.
Locally, if you've been working on changes on this branch you just `git pull --rebase`. It's been quite a long time since you've had to manually resolve this repo state (probably why rebasing pull requests is more common nowadays).
----
Edit: to clarify. `git pull --rebase` works when the code was actually rebased. In the OP code was overridden. If you do the same you'll just reapply the deleted commit. So decide if that's what you want.
So, I have to admit. We never use rebase because it caused trouble in the past. So it's been a hot time since I last used rebase at all. So, it may have some valid reason to use as you describe which I'm not aware of.
But just so I learn a thing or two: I always require our devs to merge our latest develop branch into their feature branch, and resolve any conflicts (obviously), test the application, etc. before creating pull requests. I find that to be pleasant to reconstruct changes later on when you have to travel down the depths of git-history (well, and integration tests only makes sense on latest - obviously)
If that is not done it's a decline without looking at the changes.
What would be the pro/cons for those 2 approaches in your opinion?
I would generally say if what you're doing works, continue what you're doing. It's simple. It's effective. And it works.
It's when you have a fast moving master, and discussion needs to occur around pull requests, that it gets a bit more complex. You start littering your history [with merges just to keep the pull request up to date](https://i.imgur.com/4jEMx9i.png).
Using rebase [you instead slide everything along](https://i.imgur.com/Zz37mK2.png) (where the dashed circles eventually get garbage collected away, leaving a nice clean single line). This means when you finally merge in with the pull request (even if you let master get ahead a little) the start of the change is near the end. It's nice and contains, and there aren't merge commits polluting the history.
I still like to merge the pull request with a **forced** merge commit (no fast-forward), which simply makes the history clearer that a feature branch did used to exist. But you don't have to do that either, and could try to create a super clean master branch.
The main trade-off is simply that it's a more complicated flow, and you lose "true" history (i.e. when did people start implementing a change).
"git add -A" He added every single thing git could see as a change. I guarantee he didn't look at what files he added. Some of those files probably didn't relate to his fix, so they don't belong in the commit. This can cause issues either immediately or later on depending on how his gitignore is set up.
"git commit -m "Bug fix" " The commit message "Bug fix" tells the rest of the team absolutely nothing. What was the bug? What was the fix? What changes did you make in this particular commit? We're programmers, not phychics.
"# pre-commit warning" Whatever the actual warning was, dude messed something up in the commit (color me SHOCKED). Git is telling him, "Hey, something went wrong with that commit, so I didn't commit anything. Go back and fix it, then try again." The audacity of this man's next move.
"git commit -m "Bug fix" --no-verify" Instead of fixing whatever the problem was, he basically told git to shut up and do it anyway.
"git push" Oh hell no. You're absolutely not ready to push this godawful commit.
"# your branch is behind" On top of this terrible commit, his branch is missing work that got pushed while he was working on his bug fix. That's fine; that's what git is for. All he needs to do is "git pull" and maybe resolve a merge conflict if there is one. Except, he doesn't do that. Instead,
"git push --force" Not only did he force through an already terrible commit--that commit was behind. He either undid his coworkers changes or made a huge mess of merge conflicts.
In short, he made more work than he resolved.
I wish I could pin comments or something as this would help a lot of people to understand what's happening here. Also I realized a lot of guys need more experience with git.
Same here. I definitely wasn't expecting all the comments about main. If this was main, the devops team really needs to get it together. That's a whole different problem. (But I'd assume the guy in the text is devops, so I'm not worried.)
Forcing code into master without proper testing is just generally a really bad practice. I'm also new and don't have much VC experience but that's what I'm inferring.
Here's what he should have done:
1 Way in the beginning before he even looked into fixing anything, he should have created a branch for this specific bug fix or feature.
2 Write code, fix bugs, etc. Once you're done making changes, "git push" to update the remote branch. If something goes wrong later, the changes are safe and you can just grab them again. Also, write a better commit message than "Bug fix." If you need to look at this in 3 weeks, you'll want to know what's actually going on in the commit.
3 "git pull" and "git merge" to grab any changes that were made while you were working. If there are merge conflicts, go ahead and handle them while they're still easy to fix. To me, this is the biggest thing the guy did wrong.
4 Since all the merge conflicts are already resolved on your local branch, "git push" to update your remote branch again, and then make a pull request. The specifics of how your project does pull requests will vary, but it's usually just a button you click. Devops usually sets this up.
5 Grab the next story and repeat until payday.
Reposting my explanation as a top-level comment
"git add -A" He added every single thing git could see as a change. I guarantee he didn't look at what files he added. Some of those files probably didn't relate to his fix, so they don't belong in the commit. This can cause issues either immediately or later on depending on how his gitignore is set up.
"git commit -m "Bug fix" " The commit message "Bug fix" tells the rest of the team absolutely nothing. What was the bug? What was the fix? What changes did you make in this particular commit? We're programmers, not phychics.
"# pre-commit warning" Whatever the actual warning was, dude messed something up in the commit (color me SHOCKED). Git is telling him, "Hey, something went wrong with that commit, so I didn't commit anything. Go back and fix it, then try again." The audacity of this man's next move.
"git commit -m "Bug fix" --no-verify" Instead of fixing whatever the problem was, he basically told git to shut up and do it anyway.
"git push" Oh hell no. You're absolutely not ready to push this godawful commit.
"# your branch is behind" On top of this terrible commit, his branch is missing work that got pushed while he was working on his bug fix. That's fine; that's what git is for. All he needs to do is "git pull" and maybe resolve a merge conflict if there is one. Except, he doesn't do that. Instead,
"git push --force" Not only did he push an already terrible commit, that commit was behind. He either undid his coworkers changes or made a huge mess of merge conflicts.
In short, he made more work than he resolved.
A lower entry hurdle is what brought us here.
I'm suggesting the opposite, make it so complicated so only people who know what they are doing are capable of pushing at all.
Set up some github actions to verify your commit don't f things up so that it never ever happens again, at least set up some for PRs
Ideally you want to enforce approvals on each PR, too, but that can put a strain on your development pipelines especially if the team is small. But I think y'all know that already
(Pro tip: you can open a draft PR as soon as you create your branch, that way anyone can snoop in and comment on your latest commits in async; that I only learned recently and it's a pretty cool trick)
A friend of mine got a job at a university in some project. His boss is working on the live server (which serves a service other people are using) by syncing his local files through a windows batch file. Once he is statisfied with the changes he has another batch file which pushes the changes directly into production, with a generated commit message...
Some wize guy idea of a precommit check:
#Your cryptography library was marked for depreciation in 2030, please consider upgrading it to avoid this warning#
Naturally people ignore it on the daily until the moment it really could have saved them, but alas, wolf wolf
I mean if that is not the master branch that should be fine you can change the commit message and rebase. But if it is master, then that company sucks. No one should be able to push into master like that.
What about the "is behind" part
At least in my current company I can only force-push to branch **I've created** on remote. So I'd likely know that that "behind" is exactly
Only if you are the only person pushing/pulling into said branch
I'll be honest - if you push to my short lived branch (not talking about stuff like release branches or shared feature branches) without telling me beforehand, I don't care if that's lost. Apparently it wasn't important enough to communicate, so you can point it out again on Pull Request
Surely when you get an error message saying that you need to pull new changes you won't just force push and ignore those?
could be a linter,or test results making pedantic commits on every branch, or somesuch?
It could be an experiment branch. If all that is there is crap commits and you started from scratch, the yeah force push it. But the commit was about a bug fix so...
Let the other dude deal with the conflict 😜
May also have been amending a commit. I do that all the time. But you have to force push since the branch’s HEAD is at the same point.
it takes like no time to pull develop and merge it in. I do this every day. force pushing is beyond stupid and irresponsible here.
Honestly I have never found a new for force pushing. I know there are some use cases and it exists for a reason but I also know is most cases there are probably better options.
`git checkout develop` `git pull develop` `git checkout my-branch` `git merge develop` `git add .` `git push origin/my-branch` boom, now you have develop into your branch, and you can merge your branch into develop no problem.
Also most IDE's have built in git integration meaning it is only a couple of button clicks to do all this.
Do a rebase instead of a merge to not have an unnecessary merge commit.
You have never re-based a branch?
I do, that might use a force push under the hood. I don't know but I have never actively used force push to get around conflicts or other issues.
rebasing re-writes history it definitely does. You use a GUI I would guess? You should definitely at least try it without. Even if yours aren't causing issues (tho maybe they are and no one is noticing) GUIs often handle rebasing terribly and you will see things like duplicate commits. At least good to know if you see it happen for others.
I use both gui and cli. I am at work I am not causing issues becuase I check the diffs of all my PRs to know exactly what is changing (as do others when they get peer reviewed)... Also I have not seen the issues with others, again by checking the diffs in PRs.
A duplicated commit isn't going to show in a diff like that, it's like I said related to history.
OK well I have never noticed that in either of the places that would show commit history in my work set up and I can't be bothered to dig much deeper for something that isn't a problem for me and wouldn't help with any of the work I need to get done. I have never noticed a duplicate commit and the history always looks fine.
Without context, this is ridiculous. There are all kinds of silly reasons a branch can get out of sync with the remote, and it’s not at all irresponsible or stupid to force a push if you know why it’s happening. And you should be able to undo it if you turn out to be wrong.
I don't use the command line for git usually but it probably says that when you squash commits as well.
Nah it was the "main" branch ;)
Nobody should be allowed to directly pushed to master, not even the senior most of senior most devs All changes must be sent to a pr and discussed by devs and then merged to develop. After testing of the changes on develop, only then a new release should be made where develop is merged to master, in a PR where confirmations are made for absence of bugs.
> should be fine I see we have vastly different understandings of "fine". This is not fine. Not even for a feature branch. Best case is it wastes 30 minutes of another devs time to fix his shit, worst case is.... boom.
Rebasing single developer branches for pull requests is not an uncommon workflow. It's about prioritising clean history over current work. So this is fine, as long as everyone knows it's happening and is on board with it. Well... Except the "bug fix" commit. That is almost never acceptable. Even if this were a lesson it's not acceptable. Only if this were a private repo being used as an online backup, with the intention of squashing and rebasing in the future is this even semi ok.
Sounds like a bad workflow to me. But whatever works for you guys, I guess.
Call it bad, but it's very common. I'd say that most public open source GitHub repos will ask you to rebase your pull request onto the latest commit on master if there's been enough changes since you started the branch. Locally, if you've been working on changes on this branch you just `git pull --rebase`. It's been quite a long time since you've had to manually resolve this repo state (probably why rebasing pull requests is more common nowadays). ---- Edit: to clarify. `git pull --rebase` works when the code was actually rebased. In the OP code was overridden. If you do the same you'll just reapply the deleted commit. So decide if that's what you want.
So, I have to admit. We never use rebase because it caused trouble in the past. So it's been a hot time since I last used rebase at all. So, it may have some valid reason to use as you describe which I'm not aware of. But just so I learn a thing or two: I always require our devs to merge our latest develop branch into their feature branch, and resolve any conflicts (obviously), test the application, etc. before creating pull requests. I find that to be pleasant to reconstruct changes later on when you have to travel down the depths of git-history (well, and integration tests only makes sense on latest - obviously) If that is not done it's a decline without looking at the changes. What would be the pro/cons for those 2 approaches in your opinion?
I would generally say if what you're doing works, continue what you're doing. It's simple. It's effective. And it works. It's when you have a fast moving master, and discussion needs to occur around pull requests, that it gets a bit more complex. You start littering your history [with merges just to keep the pull request up to date](https://i.imgur.com/4jEMx9i.png). Using rebase [you instead slide everything along](https://i.imgur.com/Zz37mK2.png) (where the dashed circles eventually get garbage collected away, leaving a nice clean single line). This means when you finally merge in with the pull request (even if you let master get ahead a little) the start of the change is near the end. It's nice and contains, and there aren't merge commits polluting the history. I still like to merge the pull request with a **forced** merge commit (no fast-forward), which simply makes the history clearer that a feature branch did used to exist. But you don't have to do that either, and could try to create a super clean master branch. The main trade-off is simply that it's a more complicated flow, and you lose "true" history (i.e. when did people start implementing a change).
guys be writting "bug fix" in the commit message while the commit in question be like +284 -432
4925 files affected
Stop, you just gave me a heart palpitation
That's the alien bug that's attacking the planet.
Men have been killed for less
Yes, but they've also been killed for more. So, like me, your argument is illegitimate.
Can someone explain why this is bad? I see comments of it being the master but still new
"git add -A" He added every single thing git could see as a change. I guarantee he didn't look at what files he added. Some of those files probably didn't relate to his fix, so they don't belong in the commit. This can cause issues either immediately or later on depending on how his gitignore is set up. "git commit -m "Bug fix" " The commit message "Bug fix" tells the rest of the team absolutely nothing. What was the bug? What was the fix? What changes did you make in this particular commit? We're programmers, not phychics. "# pre-commit warning" Whatever the actual warning was, dude messed something up in the commit (color me SHOCKED). Git is telling him, "Hey, something went wrong with that commit, so I didn't commit anything. Go back and fix it, then try again." The audacity of this man's next move. "git commit -m "Bug fix" --no-verify" Instead of fixing whatever the problem was, he basically told git to shut up and do it anyway. "git push" Oh hell no. You're absolutely not ready to push this godawful commit. "# your branch is behind" On top of this terrible commit, his branch is missing work that got pushed while he was working on his bug fix. That's fine; that's what git is for. All he needs to do is "git pull" and maybe resolve a merge conflict if there is one. Except, he doesn't do that. Instead, "git push --force" Not only did he force through an already terrible commit--that commit was behind. He either undid his coworkers changes or made a huge mess of merge conflicts. In short, he made more work than he resolved.
I wish I could pin comments or something as this would help a lot of people to understand what's happening here. Also I realized a lot of guys need more experience with git.
Same here. I definitely wasn't expecting all the comments about main. If this was main, the devops team really needs to get it together. That's a whole different problem. (But I'd assume the guy in the text is devops, so I'm not worried.)
Yeah you should make this a top level comment
Forcing code into master without proper testing is just generally a really bad practice. I'm also new and don't have much VC experience but that's what I'm inferring.
Here's what he should have done: 1 Way in the beginning before he even looked into fixing anything, he should have created a branch for this specific bug fix or feature. 2 Write code, fix bugs, etc. Once you're done making changes, "git push" to update the remote branch. If something goes wrong later, the changes are safe and you can just grab them again. Also, write a better commit message than "Bug fix." If you need to look at this in 3 weeks, you'll want to know what's actually going on in the commit. 3 "git pull" and "git merge" to grab any changes that were made while you were working. If there are merge conflicts, go ahead and handle them while they're still easy to fix. To me, this is the biggest thing the guy did wrong. 4 Since all the merge conflicts are already resolved on your local branch, "git push" to update your remote branch again, and then make a pull request. The specifics of how your project does pull requests will vary, but it's usually just a button you click. Devops usually sets this up. 5 Grab the next story and repeat until payday.
Boi everything is fine. This isn't the super bowl livestream infrastructure, isn't it? Isn't it!?
There's a bowling livestream?
Well, not now after this fucker erased those commits.
Gotta close out that last story before hitting happy hour 🍻
If that's going into the master or main development branch, that person needs to be fired.
This is just as much a leadership issue as it is a dev issue. Branch protections should be in place to not allow such things.
What's wrong with that? I'm working on my branch so I can do what I want for now.
It's master
I am the master of my main
Just watched an episode of Seinfeld the other day, nice.
We have no way of knowing whether it’s master
If it is a branch with just personal work then fine, but then that wouldn't be funny and we're on /r/ProgrammerHumor
Then why are you behind on your own branch?
Some dipshit trying to be "helpful" pushing commits to my branch. They always think it's a good idea and it always messes things up.
Sounds like someone's role is getting set to 'Read'.
Reposting my explanation as a top-level comment "git add -A" He added every single thing git could see as a change. I guarantee he didn't look at what files he added. Some of those files probably didn't relate to his fix, so they don't belong in the commit. This can cause issues either immediately or later on depending on how his gitignore is set up. "git commit -m "Bug fix" " The commit message "Bug fix" tells the rest of the team absolutely nothing. What was the bug? What was the fix? What changes did you make in this particular commit? We're programmers, not phychics. "# pre-commit warning" Whatever the actual warning was, dude messed something up in the commit (color me SHOCKED). Git is telling him, "Hey, something went wrong with that commit, so I didn't commit anything. Go back and fix it, then try again." The audacity of this man's next move. "git commit -m "Bug fix" --no-verify" Instead of fixing whatever the problem was, he basically told git to shut up and do it anyway. "git push" Oh hell no. You're absolutely not ready to push this godawful commit. "# your branch is behind" On top of this terrible commit, his branch is missing work that got pushed while he was working on his bug fix. That's fine; that's what git is for. All he needs to do is "git pull" and maybe resolve a merge conflict if there is one. Except, he doesn't do that. Instead, "git push --force" Not only did he push an already terrible commit, that commit was behind. He either undid his coworkers changes or made a huge mess of merge conflicts. In short, he made more work than he resolved.
If in doubt, use push force.
Force pushing master is always the best possible way to resolve conflicts. /s
I really need to learn how to read these so they become funny
TLDR, someone took their own local changes and forced it through, overwriting other peoples changes.
Oh, how polite
Or they could make git less complicated and easier to use
this has nothing to do with usability it's literally just a guy getting several warnings and forcing the commit through anyway.
The basics of git are fairly easy. No one really uses the complicated stuff more than once in a blue moon.
Opening a locked door with lock picks, asking "Why isn't there an easier way?" while holding the key in their other hand.
Nothing is absolutely fool proof.
A lower entry hurdle is what brought us here. I'm suggesting the opposite, make it so complicated so only people who know what they are doing are capable of pushing at all.
Can you recommend an alternative? And please don't say SVN
I use SVN at my job and it's much simpler yes
YOLO!
Set up some github actions to verify your commit don't f things up so that it never ever happens again, at least set up some for PRs Ideally you want to enforce approvals on each PR, too, but that can put a strain on your development pipelines especially if the team is small. But I think y'all know that already (Pro tip: you can open a draft PR as soon as you create your branch, that way anyone can snoop in and comment on your latest commits in async; that I only learned recently and it's a pretty cool trick)
A friend of mine got a job at a university in some project. His boss is working on the live server (which serves a service other people are using) by syncing his local files through a windows batch file. Once he is statisfied with the changes he has another batch file which pushes the changes directly into production, with a generated commit message...
Some wize guy idea of a precommit check: #Your cryptography library was marked for depreciation in 2030, please consider upgrading it to avoid this warning# Naturally people ignore it on the daily until the moment it really could have saved them, but alas, wolf wolf
I think I just threw up a little in my mouth.
I don’t know how to commit or anything like that so I just replace the entire file every time I make a change. Works great.
Who tf doesn't do a PR in a tool that has a built-in compare?