-
Hey Guest. Check out your NeoGAF Wrapped 2025 results here!
I deleted everything
- Thread starter Makai
- Start date
- Status
Spoiled Milk
Banned
I feel... weird...
Hah so true.
D
Deleted member 12837
Unconfirmed Member
Why not just open a PR with a merge of the feature branch into dev? Why do your commits *have* to always come after everything on the current dev branch? Re-writing Git history all the time seems silly to me. That's way less sane and comprehensible for a team than just creating branches and merging them back in.
1) I can type a lot faster than I can move my mouse and click around
2) I already have my terminal open and am doing other things in it. Using another app requires context-switching to
3) It's yet another tool to learn, but all the tool does is input commands into another tool I already know how to use.
ST and others have a fairly solid market share, and are useful tools for a lot of cases, but the majority of devs still use the command line.
Astral Dog
Member
...uh, ok, seems you already resolved most of it.
i freaked out for a bit.
i freaked out for a bit.
Your IT staff should be using back up solutions with hourly snapshots/increments like Veeam, Shadowprotect or Datto, especially for devops
Our guys accidentally delete really important items almost weekly and it's no big deal as we just restore the file from 30 minutes ago, or since last estimated modified.
Peace of mind for everybody.
Our guys accidentally delete really important items almost weekly and it's no big deal as we just restore the file from 30 minutes ago, or since last estimated modified.
Peace of mind for everybody.
D
Deleted member 12837
Unconfirmed Member
Gitar hero
You base your dev process on what a visual representation of your commit graph looks like?
Everything should be merging back into the same single branch so that isn't even a good example image.
edit: for example, http://nvie.com/posts/a-successful-git-branching-model/ is quite popular
Possible to find the origin of bugs caused by the interaction between two merges (nothing wrong with either individually) if the tree is a straight line.
butzopower
proud of his butz
git merge spaghetti is bad in my opinion as well. Much harder to revert and bisect a large weave of merge commits. PR model makes sense for large distributed teams and open source stuff, but not for your normal 2 - 10 engineer project.
That said, I have no idea why OP has to force push every time when rebasing remote master into local master. Sounds like it's being done backwards of how it should be. If you are force pushing every time, git will be a terrible experience for everyone on your project.
D
Deleted member 12837
Unconfirmed Member
Reverting on your master branch should be a rare occurrence, unless your code reviews are rushed and/or you don't have good test suites.
I don't think 2 layers of branching off and merging back is really spaghetti, but that's subjective I suppose.
Also I would think that a 2-10 engineer project is in the minority, not the norm. Open source + larger teams are more common, right? 2-10 is startup size. I worked at a company that over the years ranged from 2 devs to 8, and PRs worked well for us still, but YMMV.
I am always interested in seeing the different variations of Git workflows that other people come up with and use, though.
butzopower
proud of his butz
Most of my projects are colocated and we pair program, so PRs don't make a lot of sense in that context. Each of us is also committing numerous times a day, so we usually just work off master, and maybe rebase pull a few remote commits between pushes. Anything long lived for a day or more, I'd probably make a branch for and merge instead of rebasing, since it might be like 20 commits behind or so, but I try to make that an exception rather than the rule. I just don't like that the merge commit holds any conflict resolutions and feel like it puts your code in 3 places. I think rebasing master on your feature branch can be a good compromise so that you have to resolve the conflicts on your branch, and then do a clean merge. Pretty sure that's how a lot of the larger OSS projects roll.
Cetra Yoshi
Neo Member
Shhh, I felt like crap for doing that.
Luckily nobody freaked out and stayed calm which kept me calm while I fixed my screw up.
Sounds like your colleagues are keeping calm OP, so just take your time and fix it. Everything will be okay.
Binary files are diff-able people. Lots of version control systems use binary differencing algorithms and handle them fine. Git doesn't. But Git simply isn't good at certain things. Like handling large binary files or ease of use.
Abandon your DVCS and Return to Sanity
Abandon your DVCS and Return to Sanity
Providing a sane history is one of the primary motivations for using version control in the first place.
If you have 50+ feature branches per release and support multiple releases in parallel your ability to make sense of commit history is an important issue.
I've lost an entire lab report when an old computer in the University lab froze up. I was already hard pressed on time and trying to cram it in between classes. The screen locked up in a way where I was able to see and copy about a page and a half worth. My rewrite was better...
I also accidentally kicked out a power cord for a whole row of PCs in the main University library when I was stretching my legs. I played it off stupid like It just happened out of nowhere. People were crying out over lost work.
I also accidentally kicked out a power cord for a whole row of PCs in the main University library when I was stretching my legs. I played it off stupid like It just happened out of nowhere. People were crying out over lost work.
D
Deleted member 12837
Unconfirmed Member
Right. And a drawing like that isn't a good way of getting an overview of commit history, regardless of what your team's Git strategy is. It's not like a single line (the output if you're rebasing everything before merging back) is any better, lol.
A single line is as clear as it gets.
butzopower
proud of his butz
I've always felt like the git-flow model based on this article was adding an unnecessary extra branch. If you tag your releases with git tag, then you can keep master and dev as the same branch. You get all the benefits of being able to hotfix, etc, without having to maintain a new workflow that requires new devs to know that master is not canonical.
D
Deleted member 12837
Unconfirmed Member
Except when trying to split the timeline up by feature. And all of the commits are out of order chronologically. And you lose any idea of where/when a branch was started. You only know when it was completed.
It's nice to have one branch that reflects prod exactly (master is still canonical in that sense), and another that's for dev that matches what's on your staging server, but yes you can duplicate much of that using a single branch and tags. Some companies don't have a staging server, there's also continuous release vs scheduled releases, etc. There's no one-size fits all solution.
Hm? The issue is figuring out who broke what when and how many branches it affects. Once it's merged it doesn't really matter what branch it came from (in our workflow).
I'll echo the others because I'm curious, what source control tools do you find easier? I've only used git/svn/clearcase/perforce.
Klaymator14
Member
D
Deleted member 12837
Unconfirmed Member
I find it easier to just jump from merge commit to merge commit than to parse through and figure out where the boundaries are between features on a single timeline of commits. Branches keep commits for each feature grouped together in an easily parsible format.
Do you guys not ever review what work was done over a given time period (sprint, quarter, etc)? That's where I find having branch history to be particularly useful. You can see the full chunk of time a feature was worked on, what features were worked on in parallel, etc. An issue tracker can help with some of that, but won't give the full, granular picture.
Subpar Scrub
Banned
American cops, at least.
Yeah, that would make sense in a saner org but we always end up having a bunch of unrelated shit go in a "feature branch" because of political/organizational reasons. It's pretty much a giant mess, which is not gits fault per se, but it helps to enable the clusterfuck.
D
Deleted member 12837
Unconfirmed Member
Finding a good place for small, random changes is definitely a weak point in our approach. Creating a branch for a single one-line change feels like a lot of overhead.
codswallop
Member
I was once managing a server which hosted a number of VMs (virtual machines / virtual servers) running off a NAS (network attached storage) which in turn had file shares running from that NAS. There was one partition for VMs, and another for the file shares.
Well, I clicked the wrong button (and the confirmations) to delete the partitions on which the VMs were hosted. It was immediate. With no option to undo.
It was certainly character-building recreating half a dozen VMs as quickly as possible. At least the file shares and their contents remained. Luckily for me I had also recently setup a process to backup the VMs elsewhere so restoring only took a day or so of work.
Lesson learned: Even when I'm 100% familiar with something, I always, always double-check what I'm doing if the thing I'm doing is critical.
Well, I clicked the wrong button (and the confirmations) to delete the partitions on which the VMs were hosted. It was immediate. With no option to undo.
It was certainly character-building recreating half a dozen VMs as quickly as possible. At least the file shares and their contents remained. Luckily for me I had also recently setup a process to backup the VMs elsewhere so restoring only took a day or so of work.
Lesson learned: Even when I'm 100% familiar with something, I always, always double-check what I'm doing if the thing I'm doing is critical.
Leona Lewis
Banned
As educational as this thread has been, I still have no idea what the fuck 90% of you are posting.
And yet I'm still having secondhand anxiety attacks reading it
And yet I'm still having secondhand anxiety attacks reading it
butzopower
proud of his butz
- Status