|
Oh thank the great Ghu I retired from this sort of crap. You have my sympathies and thankfully I no longer have to think through these disasters.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Michael Breeden wrote: I need fast simple solutions
I've got a quick solution for you: It Jobs | Monster.com[^] 
I wouldn't want to work for a company that doesn't value my skills or contributions because managers think they know better.
|
|
|
|
|
I've thought about that... I have, but right now is not the time and I have a psychological quirk that I'm almost unable to quit a problem. It can be a strength or a weakness. My personal project is now 4 decades in. Ya have to have a need... or an obsession.
The funny thing is that I just realized that my "managers", iteration managers, etc. are in a worse position than me. I worked for manager X who was a DBA kinda guy that spent 20 years building the typical vast Db network, full of business logic, that is typical of big corporations. He knew where everything was and how it worked. He was master of his domain and able to lead lieutenants like me that would go out and conquer whatever he said needed conquering. I could win my battles because he knew the scope of the war. Brilliant guy, great leader. Not perfect but as good as you could hope for.
Three years ago, the changes started with a new CTO that said we needed to up our game and go to the cloud. I've been working for a couple of years to move to do that. I'm an AWS certified Architect, I moved to .Net Core and took a bunch of other classes like the CTO said to. I'm pretty prepared for this... (just not to this insane lambda and not having the team scattered). They haven't prepared. Manager X who is now on the Plan Team, but necessarily works with our build team, needed me to archive 28 TB to S3. He made two large mistakes before doing what I told him was needed in the first place. It wasted over a week of my time, but really it is because he doesn't know cloud. They sell the cloud as being just like your on-prem data center, but it is nothing like it (for us especially because of the lambda). All the leads are now in a worse place than me. I tried to prepare. They didn't... which I understand. Inertia is that way. It is a "re-invention". I've done enough of them to know, but they hadn't. They have been told that Agile and JIRA will solve all their problems so they are working on that, but they are no longer masters of the IT technology as they were. While a pain for me, I suspect it is worse for them. I wonder how much they realize how much they depend on me.
|
|
|
|
|
I dislike Git for its gratuitous complexity and penchant for storing many and large files in your work area.
� Forogar � wrote: if you can't cope with GIT you are in the wrong job.
I'm retired.
Oh yeah and I mostly use CVS and SVN.
If pigs could fly, just imagine how good their wings would taste!
- Harvey
|
|
|
|
|
Well, Git is unusable, so enjoy I guess...
|
|
|
|
|
git is fine but I know I'm going to have a godawful number of branches and features right away in code that is very easy to break and very difficult to tell if it is broken. It was always accepted that regression testing was never really possible due to thousands of different possible inputs. You just had to isolate different business unit code make sure you never broke anything. That was OK when I was the developer and could manage every detail using TFS. Git is going to have far more branches and I am sure that things are going to get broken. I just need a basic organization tool so I know what branches there are, the features in them and the stage of the features. When we can do releases, the problem will be simplified but that ain't yet. I don't know when that will be. Also, one developer is sort of on his own with a feature and he didn't even know to make his own branch. I have no idea what he is going to do toamke his stuff work and I don't think he cares what he breaks of existing code.
|
|
|
|
|
Your easiest option would be to learn something like Mike Hanley suggested. Git is one of those tools where the less you understand the more complicated things become. That being said, I use git log for visualization of branches. A good baseline version is:
git log --oneline --all --graph --decorate
If you've got a hairball of a git repo you'll quickly see why a separate tool might be a better solution. git log has a TON of filtering options though which can help.
References:
git-log | Git
Advanced Git Log | Atlassian
|
|
|
|
|
That's pretty cool. I didn't know about that. Thanks.
The thing is though that I need to know what others are doing in branches they have made on their local machines that aren't on the repository. Not so much details, but so that we all know who is doing something so we will be careful to work together.
|
|
|
|
|
Quote: The thing is though that I need to know what others are doing in branches they have made on their local machines that aren't on the repository.
You cannot. When someone clones a repository (presumably the main repository), the clone is independent of the original. You get to see what they've done only when they make a pull request or, God forbid, when they push their changes to the main repository. Given that your team is just starting with git I'd suggest to have only one person with write access to the main repository. In this case the other members will be forced to do pull requests and only one person will be able to accept those requests. At least you will know who should be hanged if things go south 
Regarding the other branches developers make on their own machines, normally you shouldn't care. Each one can have its own way of managing the development process on their machines, with more branches or less branches depending on their whims. The only thing that matters is what they bring back to the main repository through those pull requests.
Mircea
|
|
|
|
|
Actually I think you could, since Git is designed to work decentralized without a central server you can treat each developers machine as another remote server. I believe all you need to do is set up an SSH server running on each machine, give yourself at least read access to it, and then set up a new remote.
The command would be something like:
git remote add other_dev_workstation username@host:path/to/repository/.git
You just have to be mindful of the fact that you'll get some confusing errors popping up if you're using rebase as part of your workflow.
|
|
|
|
|
Just because you can doesn't mean you should 
|
|
|
|
|
Wow! Just wow! I could use somebody like you on the team 
|
|
|
|
|
Probably take some of the other posts warnings about this seriously though. It would probably make a lot of sense to only grant read only access to other developers machines - which would let you fetch their local branches to view, but not accidentally push changes.
|
|
|
|
|
Maybe this could done on an informal basis (two developers "banding" together like in pair programming: "give me access to your code and I'll show you a cool solution to that problem"). However to base an organization's workflow on having all devs machines available at all times seems risky.
However, I've seen the distributed nature of git used to have many clones of the repository (usually one for each developer) on the same central server (in house or Github or Bitbucket or something else). Then developers can give one another read or write access to their clones of the central project. Again when a feature is ready you create a PR for it.
For me pull requests are a central feature of git. They serve not only to keep crap out of the central repo but also to document what has been done and why. They are also the best time to do the dreaded code reviews and make sure at least two pairs of eyes have looked at the code.
Mircea
|
|
|
|
|
No no no... I need to simplify this.
|
|
|
|
|
Good luck then! Software development is hard not because someone wants to make it complicated but because it is complicated. Some say it's like herding cats and, so far, git seems the best way to let those cats roam and still come home to roost. Sorry for the mixed metaphors 
Mircea
|
|
|
|
|
Bingo. That is the problem but I do need to know so I can explain what needs to move from one place to another. I need to know / organize what people are working on. JIRA is not going to do that for us because it doesn't track branches. This is why GitKraken (sounds amazing) or other Git tools won't do what I need. I need a Gantt Chart or maybe a whiteboard. Even a spread sheet would work but I want colored bars to represent the state of Dev, Test/QA and Release because they are already unsynchronized. Something like Blue for Release. Red for Test (with notation that the log pruning feature is ready for release... but sitting there due to iteration manager hesitance). Green for Dev which is up to date. Then a purple bar for my feature branch, its purpose, its state (needs to be moved to Dev and everyone needs to merge it). Purple bar for Developer1's working branch and purpose. Purple bar for Developer2 branch, purpose and just what the heck he has in mind. ... Then BLACK for what is actually in the Lambda running... I need something I can show to people to quickly show the state of all this nonsense and what needs to move from one place to another.
|
|
|
|
|
> I need to know ...
Beware of the square peg round hole issue here. Git was 'designed' because of the limitations of the command and control methods when used in software development.
In some ways "Agile" is a similar response to the difficulties that command and control methods experience.
Git itself is agnostic to the management method, and includes flexible working approaches. It also include `git stash` should you have to redirect developer work at very short notice to 'drop every thing and fix this NOW'.
Don't try to solve / pre-plan everything at once. Start 'small' by at least just creating a git repo of what you have got.
Maybe think about copying/transferring existing history to git and explore that to get a feel about the quality of the previous system.
Any new system will feel awkward, don't let it become a 737MAX.
|
|
|
|
|
Quote: You get to see what they've done only when they make a pull request or, God forbid, when they push their changes to the main repository.
Why "God forbid"? Where else other than the remote do you want them to push changes to? You're supposed to push to the remote, you're just not supposed to push to remote/main (or remote/master).
Quote: Given that your team is just starting with git I'd suggest to have only one person with write access to the main repository.
I get the feeling that by "main repository" you mean either "main branch" or "remote repository", but I can't tell which it is. "Main repository" is a phrase with no meaning in git.
|
|
|
|
|
Going from the end to clarify what I mean:
Quote: I get the feeling that by "main repository" you mean either "main branch" or "remote repository", but I can't tell which it is.
Let's assume the organization ACMECompany has an account with a Git provider, consider Bitbucket for the sake of argument. Then the project repository will be git@bitbucket.org:ACMECompany/BigProject.git. This is what I call the main repository because everything useful should end up in there.
Quote: Why "God forbid"? Where else other than the remote do you want them to push changes to?
You, as a developer, make a clone of that repository and it will reside at git@bitbucket.org:Developer/BigProject.git. You add a wonderful new feature and you are ready to send it home. You send a pull request to the person responsible of BigProject and now different things could happen:
- if it's a small change or something he can immediately validate, he will push it in the main branch (formerly called master branch).
- if it's something where other people need to contribute, either to validate or to further develop, he will push it on a new branch and other developers or testers will pull the new branch, do their work and make new pull requests when finished.
In the end the person in charge will merge the new branch into the main branch.
Quote: You're supposed to push to the remote, you're just not supposed to push to remote/main (or remote/master).
I know there is an alternate workflow where all developers are allowed to push in the main repository and it works based on an honor system where each one promises to merge into the main branch only stuff that has been thoroughly tested and never make any mistake. However I'm an old, cynical developer who believes that only what you cannot touch you cannot harm 
I also know that both Bitbucket and Github have branch permissions where you can limit who can commit on the main branch but somehow, working only on the main repository, makes me a bit less comfortable. The workflow I described does not depend on any particular Git provided and can be used anywhere.
Mircea
|
|
|
|
|
Quote: I know there is an alternate workflow where all developers are allowed to push in the main repository and it works based on an honor system where each one promises to merge into the main branch only stuff that has been thoroughly tested and never make any mistake. However I'm an old, cynical developer who believes that only what you cannot touch you cannot harm
So? What does "main repository" have to do with that? My team all works off one repo, no one (not even me) is allowed to push to master, everyone works of branches from that one repo, there is no "main repository", there is only one repository that has /master changeable only via PRs from branches on that repository.
I don't know what multiple repositories have to do with protection. We use branches for that, not an honor system.
|
|
|
|
|
Member 13301679 wrote: I don't know what multiple repositories have to do with protection. We use branches for that, not an honor system.
AFAIK branch protection is not a Git feature. Different Git providers implement it in different ways. If that works for you and your team, that's great.
Mircea
|
|
|
|
|
Quote: The thing is though that I need to know what others are doing in branches they have made on their local machines that aren't on the repository
Well, as long as they perform a "git push" once a day (I do pushes maybe every 60m or so), you'll see what's been last committed to a particular branch using any git client (I've heard good things about gitkraken, but bad things about their licence), even the plain old command-line one will present an ascii-art (colored) branch diagram which is easily understood.
Quote: Not so much details, but so that we all know who is doing something so we will be careful to work together.
There's no need to be - this isn't like TFS or CVS or Subversion where you can step on each other's toes and only find out months later, or where conflicts are a pain in the rear to address.
Let's say a new issue comes up - "Implement Baz into the Fob". Dev-A gets assigned to do it. You create a new branch of the current pre-release branch called "feature/baz-into-fob", and tell Dev-A to pull that branch and make his changes.
New issue comes up - "Implement Squiz into Fob". Dev-B gets assigned to do it. You create a new branch of the current pre-release called "feature/quiz-into-fob", and tell Dev-B to pull that branch and make her changes.
Now, daily, as those two devs are working, they will commit+push their respective branches. This lets anyone else (with the correct access) see the changes that are pushed. Yes, you can keep yourself updated if you're too bored to do anything else 
Additionally, they must pull daily as well. If they try to push while there are conflicts it just won't happen and git will issue a message saying "You need to pull and fix the conflicts first", so as long as they are pulling their branch daily, all should be good. To minimise conflicts I also rebase my feature off the parent branch as well, so that there are never any conflicts when sending the eventual PR.
Of course, they're both modifying Fob at some point, so you expect conflicts. Whoever finishes their branch first will send you a PR, you will review it and merge the PR (it passed review! Yay!).
Then the second PR comes in from the second-place dev, and when you (and she) examine the PR you see in the diff that there are conflicts. She pulls the current pre-release, merges (or rebases) into her feature/squiz branch, gets a bunch of reported conflicts which she then fixes, commits her rebased and fixed conflict-free branch to the remote origin/feature/squiz branch and resends the PR. This time there are no conflicts and you approve the PR and perform the merge.
The problem you are going to have is that you're coming from a primitive product with a marvelous interface but few features (TFS, SVN), to an advanced product with a million features but a piss-poor interface (Git).
The git UI is poor, unintuitive, unhelpful, not fail-safe, confusing as hell, etc. Couple that poor interface to the advanced feature set (with tons of features) and the result is a very intimidating product.
The best thing to do is find a GUI client (I only use the git CLI client so I am not much help there, I'm afraid) that doesn't hide the details from you even when it is operating at a high-level.
|
|
|
|
|
While I prefer SmartGit[^] mainly because it specifically does not go color crazy with branches, if you want lots of color, try GitKraken[^]. Both work equally well in our team's experience but there are nuances in how they handle things like commits and pushes. I find GitKraken to be less intuitive but once I'm shown "hey, you just right click and stuff happens", it looks really easy to use.
If you google "GitKraken vs. SmartGit" you might get some useful information before committing to one or the other.
|
|
|
|
|
VS Code with the GitLens extension isn't bad.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
