git workflow question

[David Schwartz 430]

Well, let me try asking this here and see if anybody has any suggestions. It's about our workflow. It's probably more info than is needed, but it gives a broad overview of what we're dealing with.

 

I know that git itself is neutral as far as workflows go. Someone published a guide called "gitflow" that is designed for a workflow followed by typical software development organizations. That fits for the last few places I've worked, but it does not fit the organization I'm currently with at all, nor any of the similar models targeting that kind of environment.

 

Unlike gitflow, we do not have a team of people working on a core set of code that evolves over months and months. We have a few people, sometimes just one person, working on a constant stream of very small, independent quick-turnaround requests that get updated and pushed into production in a matter of hours or days.

 

THE BUSINESS MODEL

 

If you're interested, here's the business model: This is a business that started out to do high-volume printing of bills, statements, and invoices, and got pulled in a different direction by every client they got. On the surface, it's a simple mail-merge process. In practice, it's a nightmare. Every client submits data to us in a different format. Most of our "clients" are resellers, like a property management company that manages apartment complexes, or condos, or rental properties. Apartments here send out two or three things a month: an invoice for rent, a statement for water and maybe trash, and some send out a newsletter. The management company uses the same templates for all of the properties they manage, but they'll each have different names, logos and return / remit addresses. So they send us a file with account data and whatnot and we have to consolidate that into a page-by-page printable stream that's sent to what amounts to a huge laser printer. It starts with a 5' roll of 18" wide paper at one end, and spits out USPS trays of sealed envelopes (pre-sorted by zip code) that contain folded materials with whatever else is needed, often with inserts like return envelopes and other kinds of coupons. The same thing everybody gets from their utility companies, gas company, water folks, department stores, etc. No two are alike.

 

That's what the business DOES.

 

THE WORK

 

As far as the work goes, it's a little hard to describe. They SAY it's "programming" but I don't really know what to call it. It's mostly clerical work IMO. Aside from new account setups, eg, a property mgt company brings on a new client of theirs, most of our work consists of changing logos, return / remit addresses, and verbiage on statements -- like "here's what we want in the message box for September's statements: _____" kind of stuff.

 

Back around 2004, a team built this rather convoluted framework in Delphi that handles every aspect of this business. It has been running very nicely since then. An investment company came along in 2012 or so and bought the existing company and most of the developers left. Nothing much has changed since then.

 

The core of all our work is the data import process. As I said, every one of our clients use a different format, although the data for individual accounts from the same client / management company is pretty much the same since it all comes from the same management company.

 

The import process for each account is handled by a Delphi app that runs by an automation process. One of these lives in a folder designated for either a single account (eg., property) or group of accounts managed by the same client.

 

We get requests almost every month to tweak the bills. In a perfect world, we'd bring up a WYSIWYG tool that looks like Word, make a few changes, and save it. We're far from that. 

 

Changes to data displayed on printed materials can occur in a half-dozen different places, some static, some dynamic, some in-between. 

 

Input files are in a variety of formats: XLS, TXT, PDFs (that we scrape or use OCR to read), and lots of indescribable proprietary formats. The import apps are in Delphi. The intermediate files are mostly PDFs. The page markup language is TeX. 

 

When we get a request in, our first task is to figure out which file or files needs to be modified. We make the changes, do some testing, then finally create a "proof" (a PDF file) with some test data from the client to show them the results. When they say it's OK, then we "push it into production". From start to finish, it can take 10 minutes to several hours to do the work needed to process a single change request. Frequently this work spans several days due to questions or issues that come up. Once work is done and we send a proof out, it can take hours to days to get approval back. We don't push anything into production until we get approval.

 

We use git to track all of the changes in our files. Our work is focused on "tickets" where we need to make the changes requested in a given ticket. So we set up a branch in git to capture file changes for each ticket.

 

We can alternate work on different tickets throughout the day. We can put work on a given ticket "on hold" for a day or more.

 

It's rare that we can work on a ticket and get it approved by a client and pushed into production the same day, but it happens. It's usually the approval process that causes the greatest delays.

 

Larger clients will submit tickets for several different accounts the same day, and they can be handled by different people in parallel. Their data is all in the same folder, so we're all working with different data, but sometimes it's in common files. Many clients keep a list of accounts in a single CSV file, for example, that our software reads to get static data for a given account number. This acts as a very simple database. Obviously, it needs to be updated in Excel or a special editing tool someone made for us to use. 

 

Some of these files eg., common CSV files, some template files, etc.) are pushed into production b/c they're read at run-time. Actual "source code" files are either compiled or generated on-the-fly so are not pushed into production. Either way, they need to be captured by git.

 

Everybody works on a local copy of the data that resides on our own computer. We rely on git to handle merges and merge conflicts.

 

The problem is that from time to time, get gets confused. We recently found something pushed into production where the file that was changed had been reverted to the previous version of the file. Somehow git messed things up. Git showed the previous version as "current" and it replaced the modified version that was actually newer.

 

In another case, a guy went through a common client file and commented out about 1/3 of the lines in the file, saved it, and pushed it into git. Two weeks later, we discovered everybody had the unedited version on our local stores that git decided was "current" and we were changing and pushing into the repo. We don't know how that happened, but it caused problems.

 

In summary, we have lots of quick-turnaround work that's done for individual accounts. Some common files can be changed by the same or different people actively working on different tickets.

 

We can also have multiple tickets in the same folder that we work on the same day that are for different accounts but touch one or two of the same common files, so we need to switch branches between tickets to ensure we only capture changes made for individual tickets.

I should also mention that we have a couple of folder trees mapped to local drives that we use to isolate things for git purposes. All of the folders in which we keep files for client accounts are contained in the I: drive. It has a .git file in its root so everything we do applies to the whole drive / folder tree. This is quite annoying at times b/c a lot of files show up as changed that we never touched, are not interested in for a given ticket, and are often forced to deal with for conflicts before we can work on our tickets that are totally unrelated.

 

It would be really great if we could get git to let us focus only on a specific folder and ignore everything else on the drive. I don't mind conflicts, but let me deal with them when I'm working on a ticket related to those files, not something totally unrelated.

Edited September 3, 2020 by David Schwartz

[FPiette 385]

Maybe a direct question would be better in front of your message. Maybe everybody have no time to read such a long text 😉

[Anders Melander 1815]

I can't see anything in what you describe that is out of the ordinary. Looks like a pretty standard workflow to me.

 

One thing I would do is make sure that very few people have rights to push to Master or whatever you call your primary branch. Instead use pull requests to merge into Master. This avoids the situation where someone forces a push and rewrite history and then later claim that "git must have messed something up".

 

I'm not sure what to do about your I: drive if you really want to have all the files there at all time, regardless of the branch you're working on. If you're okay with pulling the files for a given branch to I: when you work on that branch, then you could reference you I: repository as a submodule in your main Git project. Then each customer could get their own branch in the I: repository.

 

HTH

[David Schwartz 430]

8 hours ago, Anders Melander said:

I can't see anything in what you describe that is out of the ordinary. Looks like a pretty standard workflow to me.

I've never really seen any discussions about this kind of a workflow in git, and it's very different from anything I've been around before. A couple of the others at work find it very unusual as well. But if it's familiar to you, then you can probably help.

 

8 hours ago, Anders Melander said:

One thing I would do is make sure that very few people have rights to push to Master or whatever you call your primary branch. Instead use pull requests to merge into Master. This avoids the situation where someone forces a push and rewrite history and then later claim that "git must have messed something up".

This is exactly what we're running into. Not just me, but others.

 

I don't understand what's meant by "use pull requests to merge into Master". I see people on GitHub say that if someone wants to make changes, ask for a pull request. Anybody can download files and change them. I don't get why you ask for a pull request when you basically want to "push" stuff up to the repo.

 

I did do something in master after making some changes in a branch, and effed everything up. I think I collapsed origin onto master with a "git pull origin master" from master when I thought I was in a branch.

 

I think in pictures, and I've never seen any good illustrations about what goes on when you're working in git. Everything is text. I just haven't had that "aha!" moment yet where I can visualize what's going on in my head. It seems to be like you're interviewing yourself. You start out in one chair, do some stuff, switch seats, talk for a while, switch to the other seat and process what you said earlier, then say some stuff, go back to the other seat and process that, and so on.

 

8 hours ago, Anders Melander said:

I'm not sure what to do about your I: drive if you really want to have all the files there at all time, regardless of the branch you're working on. If you're okay with pulling the files for a given branch to I: when you work on that branch, then you could reference you I: repository as a submodule in your main Git project. Then each customer could get their own branch in the I: repository.

Nobody likes that we do work in one folder and git is constantly shuffling around files in other folders, and throwing up conflicts because someone else is in the middle of doing some work that has nothing to do with what you're working on. Branches only seem to make things worse. When I do a branch, I only want to focus on a given folder. What happens is we pull along a ton of other unrelated crap, and if someone happens to push an update to any of it while we're working, it can cause a conflict with stuff we didn't touch.

 

I'm trying to figure out if we could reorganize things so that each client (reseller) has their own repo and folders beneath them for each of their customers, rather than at the I:\ root. So we'd go into a folder and then create a ticket there and it would only affect that repo. I don't know what would happen if we switch to another folder / repo and work on a ticket there.

 

Honestly, having a file system with no history and a history manager that fiddles with the file system is quite confusing to me because it leaves it up to you to remember to tell the history manager that you moved somewhere else in the file system or the history manager gets totally confused.

Edited September 4, 2020 by David Schwartz

[Cristian Peța 107]

3 hours ago, David Schwartz said:

Nobody likes that we do work in one folder and git is constantly shuffling around files in other folders, and throwing up conflicts because someone else is in the middle of doing some work that has nothing to do with what you're working on. Branches only seem to make things worse. When I do a branch, I only want to focus on a given folder.

In this case I think it would be better to have all that folders in one repo. Then a branch would not be disturbed because all is there.

You will have to deal with conflicts only at merge.

Edited September 4, 2020 by Cristian Peța

[Anders Melander 1815]

3 hours ago, David Schwartz said:

I think in pictures, and I've never seen any good illustrations about what goes on when you're working in git.

First of all: Get a GUI Git client. I rarely use the command line during my daily work.

I came from Svn and found the transition to Git very confusing because the terminology is different and because you're basically working with two repositories (the local and the one on the server) at once.

 

What Git server do you use?

 

4 hours ago, David Schwartz said:

I don't understand what's meant by "use pull requests to merge into Master".

A pull request is just a request to merge a branch into another. The "pull" is from the perspective of the target so it's a request that the target pull the supplied changes.

 

I'm guessing the way you work now is something like this:

1. Create a local branch.
2. Work on the files in the branch.
3. Commit changes to the branch.
4. Merge the branch into Master.
5. Push Master to the server.

With a pull request you would work like this:

1. Create a branch (either locally or on the server, doesn't matter).
2. Work on the files in the branch.
3. Commit changes to the branch.
4. Push the branch to the server.
5. Create a pull request on the server.
6. Review the pull request on the server (should be done by someone else). Accept or Reject the pull request.
7. Apply the pull request on the server thereby merging the branch into Master.

 

4 hours ago, David Schwartz said:

Nobody likes that we do work in one folder and git is constantly shuffling around files in other folders, and throwing up conflicts because someone else is in the middle of doing some work that has nothing to do with what you're working on

I'm still not sure I understand the problem but I'll try with a solution anyway.

 

Let's say your main project is in the Projects repository and that you have this mapped locally to C:\Project.

Your client data is in the Clients repository and you have this mapped to I:\.

 

Within the Projects repository you have a branch for each client and the same for the Clients repository.

The Master branch of each repositories contains the changes that are common for all clients and the individual client branches contains the client specific stuff.

When you make changes to Master you will have to merge that back into each of the client branches to keep them up to date. You can create a script that automates this task.

Now if you make Clients a submodule of Projects then you can make the individual project branches track the corresponding branch in Clients. This means that when you check out a Projects branch then the corresponding Clients branch will automatically be checked out as well so your I:\ data will contain the correct files.

[David Schwartz 430]

Boy, this terminology is making mincemeat of the discussion....

 

We have 850+ project folders that are used to build standalone EXEs for parsing unique input data formats and turning them into something similar to PDFs. The original developers could just as easily have chosen to make them DLLs since they all have the exact same "footprint". They're all for "clients" of one kind or another. All 850+ of them. Our routine work involves very little with Delphi, however. I may need to change a logo, or a return / remit address, or a monthly greeting on a statement. There's virtually no programming involved, although they call us "programmers". 

 

I suspect they see the value of having Delphi experts on hand is exemplified by a request I got today: we have a data file that aborts; after looking closely at the data, I can't find anything unusual. Please spend some time stepping through the code and let us know what the problem is." Such fun.

 

Back to git ... personally speaking, I think the repos should be set up on a per-project / import EXE / folder basis. That way there would be no interference with other projects when it comes to managing the stuff we do on a day-to-day basis.

[David Heffernan 2353]

850 repos for every client specific variation sounds kinda crazy. I suspect that you aren't getting great feedback here because your organisation's work flow is, er, unique. 

[David Schwartz 430]

23 hours ago, Cristian Peța said:

In this case I think it would be better to have all that folders in one repo. Then a branch would not be disturbed because all is there.

You will have to deal with conflicts only at merge.

I think you're thinking we spend months working on stuff. Our work is very quick turnaround -- sometimes less than an hour. We can be faced with git conflicts several times a day. I've spent more time "resolving" conflicts on code I had no hand in than it took me to do my ticket. It's a serious distraction.

[David Schwartz 430]

8 minutes ago, David Heffernan said:

850 repos for every client specific variation sounds kinda crazy. I suspect that you aren't getting great feedback here because your organisation's work flow is, er, unique. 

no, there's ONE repo -- it handles EVERYTHING in the whole virtual I: drive. It's certainly an unusual approach based on my experience. I'd set up a repo in each folder that only captures changes for that project, because they're independent of all others. Why mash them all together?

 

In the bigger picture, most of the work is the same: changing things like branding (logos, colors, etc.); changing the monthly message on statements; address / phone# changes; and verbiage for things that changes to local laws require be adjusted. (We support a lot of collection agencies, for example, and we are constantly updating those little paragraphs on the back of their notices that specify your rights and whatnot depending on what state you're residing in.)

 

Virtually none of it is programming.

Edited September 5, 2020 by David Schwartz

[Anders Melander 1815]

4 hours ago, David Heffernan said:

you aren't getting great feedback

Hrmph!

[aehimself 399]

With all respect, I don't think Git structure is the root cause here; refactoring the 850 EXEs to one single application plus modules (not necessarily .DLLs) would worth more on the long run in my opinion.

Most of us, Delphi developers were hired to maintain old, large (and often poorly written) legacy applications; I know how likely the management approves 1-2 devs to "break free" and start re-designing everything.

But, with properly structured and divided code, you'll quickly see that there will be no need of mapping one git repository to a number of drives.

 

Thus, achieving your current goal to reduce merge conflicts.

[David Heffernan 2353]

7 hours ago, David Schwartz said:

I think the repos should be set up on a per-project / import EXE / folder basis.

Oh. I took that to mean you want one repo for each of the 850 different variants. 

[David Schwartz 430]

6 hours ago, David Heffernan said:

Oh. I took that to mean you want one repo for each of the 850 different variants. 

I did. You don't seem to like that idea. Why? They're all independent.

 

Actually, what I have in mind more specifically is moving towards a folder structure more like this:

 

<client>/<account>/<type>

 

Where each <client> would have their own repo. I'm guessing we have maybe 75 active clients at the moment. Some of them only have one or two accounts, but some have 50. The accounts a given client manages sort of cross-pollinate each other because there's a lot of stuff the client sets up that's common across several accounts. Otherwise, there's virtually nothing shared between the clients other than structural stuff (eg., they all use the same types of files, etc.)

 

The <type> relates to the thing getting printed, like a Statement, Letter, Invoice, Flyer, etc. Right now, everything is flat: ABC035_stmt_imp would be ABC/035/stmt in this new scheme. We have around 850 of these folders (like ABC035_stmt_imp) right now, and there's on repo that manages all of them.

 

In my mind, having a single repo per client makes a lot more sense. At the moment, management is totally opposed to any changes at all, but the last man standing who knows how all of this works left recently and all of the plates he has been juggling for so long are starting to come crashing down around us.

 

This is all process-oriented stuff that has very little to do with Delphi other than that's what the import apps are written in. 

[David Schwartz 430]

9 hours ago, aehimself said:

 refactoring the 850 EXEs to one single application plus modules (not necessarily .DLLs) would worth more on the long run in my opinion.

Nope. I think if you understood the problem better, how our solution is organized, and the environment more, you wouldn't say that. Some of our other facilities take that approach, and our effective down-time is an order of magnitude lower than theirs, if not more.

 

[Dalija Prasnikar 1404]

I have to say I have trouble visualizing your actual problem with Git workflow (or any workflow). Also, whatever problem you do have I don't think it is related to Git. If your problem are merges, then without Git your would still have problem, you just would not know you have it, until something would not work correctly.

 

Having everything in single repo is a bit odd, but if the parts are really independent then you should not have any issues.

 

Short lived branches and features are actually better than long term feature branches as they create less conflicts - I am not talking about develop and master in that context, but creating some feature branch that takes long time to develop and that changes code other people might change in between.

 

Your main problem seems to be having conflicts in short term features that sound like they are independent. If that is true, then your tickets are not actually independent and working on multiple tickets means adding changes to same files (even though Git is good in merging code) that is usually recipe for disaster (or at least constant merge struggles).

 

To fix that, you should either split offending parts of code to smaller pieces (files) because that will decrease chance of more people working on same code at the same time. If that is not possible, then you need to introduce some other level of discipline here. If there is some common file that needs to be updated, you need to coordinate that change between your developers. Probably the best would be that such common files are not fixed inside ticked feature branch, but as separate feature, then merged back to common base branch (develop) from which everyone can get changes.

 

Next, when I say merge branch, that is not just straight forward merge. For every merge, you need to rebase on top of branch you are going to merge to, make sure your code still works as intended and then merge (if there are changes in that branch in the meantime, you need to rebase again).  Same goes for getting changes - if you know there is some change in base branch, you need to take, rebase your feature branch on top of it to apply those changes. 

 

For any more detailed advice, you would need to be more exact with description of the problem - for instance, what is exact scenario where you have conflict - like ticket A changes files 1, 2 and 3 and ticket B changes files 1, 4 and 5 and why you cannot separate changes to file 1 or similar. 

[David Schwartz 430]

I'm not clear enough in what git is doing to explain this much better, but here's what I think is happening...

 

You make some changes to code in folders A, B, and C, while I'm working in P, Q, and R.

 

I set up a branch and do a pull from master. It updates the files in my local A, B, and C folders, because you made changes to them. I'm not touching them.

 

I make some changes to P then go home. 

 

In the morning I come in and do a git pull and get a bunch of stuff from A and C that you've been working on today.

 

I finish up work on P, commit it, try to push it, and then I get a warning from git saying it cannot push because of a conflict in some files in A.

 

So I have to stop what I'm doing and figure out what in the hell is the problem with files in a unit I had nothing to do with that's preventing me from pushing my changes in P into master. I've got customer service people pestering me to get these changes pushed into production ASAP, and you're at lunch, and whatever I do to proceed is going to screw up your work.

 

This is what we're running into. 

 

I'm probably not even explaining it fully accurately, and it probably suggests we're doing something wrong.

 

But all that sticks in my mind is that this issue is arising because of timing dependencies between when you pushed some stuff to git, when it got copied down to my local repo, when you then made some updates, caused a conflict yourself, and that got pulled to my local repo before you resolved it. So that left it to ME to resolve locally.

 

In these situations (which have come up at least a dozen times in the past couple of weeks), I can neither pull nor push anything until I "resolve" the issues in YOUR code on MY local repo.

 

I notify my boss who goes haywire, immediately sets up an emergency video conf call with 8 people, and we all spend 45 minutes trying to fix this mess. And the bottom-line is that people point their fingers at ME for screwing something up. All I know is, I did not touch any of the files in either A, B, or C, and everybody gets their knickers in a wad when I say that because it makes me sound defensive and trying to shift the blame.

 

From MY perspective, I just keep asking, "Why in the world can't I just work on the files in folders assigned to me and not have to deal with all these other folders getting their files updated and having issues when they have nothing to do with anything I'm working on?"

 

I'm still relatively new here, and the guy who has been single-handedly maintaining this code for the past several years left, but he made it all look like a walk in the park. We are now tripping over ourselves every other day with weird stuff like this that everybody says should not be happening.

 

I'm pretty sure we're doing something wrong in how we're interacting with git. But we've been given three different scripts to follow now, and they all seem to result in the same problems coming up, but at different times and contexts.

[David Heffernan 2353]

If you are not working in A, B and C then you simply should never see any conflicts. My guess is that someone in your organisation is using git incorrectly. No reason at all that you should have any troubles with all this in a single repo. 

[David Schwartz 430]

Personally speaking, I'd rather not have to deal with things in other folders than what I want to be working in.

I can see situations where that kind of behavior (updating files everywhere) would be helpful. But in this case, it's not. It slows things down, it creates a distraction, and unfortunately it leads to conflicts that you have to deal with before you can continue doing your own work.

 

If someone else is misusing a tool, why should you be impacted by it?

[David Schwartz 430]

Someone earlier asked about the flow we follow. Here's the current iteration.

------------------------------------------------------------------------------------------------------------

Start day

Open git bash from I: or V:

> git checkout master   ...if not in master

> git pull   ...resolve conflicts

> cd /i    … or /v, I.e. CD to the other drive

> git checkout master   ...if not in master

> git pull   ...resolve conflicts

 

Create a new branch – only create a ticket branch from master

> git checkout master

> git pull  

> git checkout -b <ticket-branch-name>

 

Interrupt current work to change context

> git commit [-m"<comment>"]   ...changed files as work-in-progress

> git checkout master

> git pull   … should be current

 

Continuing work in existing branch

> git checkout <ticket-branch-name>

> git pull origin master   ...resolve conflicts

 

Commit branch changes (while in branch)

> git add file1 [file2] […]

> git commit -m"<commit message>"

 

Commit branch to the repository

> git checkout <ticket-branch-name>    ...switch to the ticket branch

> git pull origin master    ...resolve conflicts

> git checkout master    ...switch to master

> git pull    ...pull changes from repo, resolve conflicts

> git merge <ticket-branch-name>    ...merge the branch into the local master

> git push origin master    ...merge local master into remote master

> git branch –D <ticket-branch-name>   ...delete the branch

------------------------------------------------------------------------------------------------------------

Would it make sense to set these up as macros that can be triggered by buttons in a tab that's got a memo set up as a command prompt window?

 

Or have them done automatically in certain situations?

For example, I have something I'm fiddling with that lets me manage things I'm working with for a given ticket. It records contextual info (project name, folder, files, notes, etc) for a that ticket.

 

So if I were to create a new ticket in this tool to respond to a ticket I got in my ticketing system, it could set up a new git branch and enter it. And if I switched to work on another ticket, it could do the necessary saving and context switching in git. If I close the app, it could prompt me to do a commit of my current work and switch back to master, or just leave things as-is.

 

Edited September 6, 2020 by David Schwartz

[Anders Melander 1815]

I don't understand why you have all these "pull   ...resolve conflict".

When you are doing a pull you shouldn't have any local changes that aren't pushed so there should be nothing to resolve.

Ordinarily I only have conflicts when I merge two local branches. There's never a conflict on pull and I don't even think my tool (SourceTree) allows me to do a pull if there are conflicts.

 

Also, if I had to interrupt my work to change context I would stash my changes, not commit them.

 

11 hours ago, David Schwartz said:

If someone else is misusing a tool, why should you be impacted by it?

Because it's possible to break the rules. For example by doing rebase on a branch that has already been pushed.

See: Peter Parker Principle.

[David Schwartz 430]

I didn't come up with this. The guy who made it added the "... resolve conflicts" bit because we keep getting conflicts arising in stuff we're not working on. Our boss has even experienced that and he can't even explain it. Our so-called "git experts" said, "Well, you shouldn't be getting any conflicts". That's nice to know, but we are.

 

At one point I _did_ stash some changes, then 5 minutes later I tried to pop them and got an error saying there were conflicts.

 

I do not understand this stuff very well, obviously. I'm being told to "follow the scripts" and we get problems. Then I'm told the same thing you're saying, "Well obviously you DID mess something up and so you need to FIX it!"

 

No, all I did was edit some files in the one folder that was associated with what the ticket I was working on related to. I did not touch anything else. And again, when I say that last bit, everybody hears "he's being defensive and trying to blame someone else!"

 

I'm just trying to get ahead of this a little bit. I'm fed up with all this crap happening in other folders that I'm not visiting, and people suggesting that it's something I did. They don't want to listen to my explanations. From my standpoint, I just want to get rid of all these other folders and just focus on the few I need to do m work. But that will cause other problems. 🙂

[Mike Torrettinni 198]

I've been using Git for a few weeks only, so I could be way off base here... but doesn't every conflict have details on who changed what that conflict occurred in the specific file? Is it your username for all the changes?

[Anders Melander 1815]

You should only get conflicts when trying to apply a stash if the files you've stashed have changed since you stashed them. If you haven't changed them then something's broken. If you have, well, then there's your conflict.

 

I really would suggest that you try to use a GUI Git client. That would make it much more clear what's going on.

[David Heffernan 2353]

Why would there be conflicts in files that you have not modified? My advice to you is that before you try to change the process to fix the problem, you make sure that you have fully diagnosed the problem.