|
We've just transitioned to Open source, git, agile, AWS, etc. all at once with no preparation so I have a problem. I need to know what is going on in branches, both remote and local. We don't seem to be doing releases so that creates a log jam or maybe a back log. I see the writing on the wall. I want something that will do color bars that can be labeled by branch, person, feature, etc. A Gantt Chart might do it but I figure something is out there already. This is not a web site. A false move could wipe out the entire system as it is a 150 plus C# file lambda    . Testing is, well, it runs or it doesn't. Anything else will come as a surprise. Oh... Agile has no provision for git so we're on our own.
|
|
|
|
|
|
Looks awesome but is just one more advanced tool to learn. Maybe later. Not sure I could get permissions to connect it to the corporate git repository. Like I said, I just need something like a Gantt chart for now until we get our brains together a little bit.
|
|
|
|
|
Mike's suggestion is a good one. If you can't get your brains together a little bit then I suggest you try again. Do some Googling, YouTubing and reading until you get a better idea of what you are doing. if you don't want to risk losing all this source code then:
1. Make sure you have a backup.
2. Figure out how to use the tool Mike suggested.
...or take up another profession - if you can't cope with GIT you are in the wrong job.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
I'm looking for suggestions of what to Google, YouTube and reading.
I'm not worrying about losing source code. I'm worried about keeping it organized. git is not the problem. I have two junior developers: one python, one .Net Foundation making the jump to working as a .Net Core team in AWS with wicked YAML and corporate cloud requirements. Try it some time. There is a huge learning curve that upper folks deny exists. The iteration manager folks don't want any time spent trying to track branches and changes because it's not development of the project. The iteration managers aren't allowing releases... because "they haven't had their training meeting about releases yet". We already have a backlog. There will be too many branches to keep track of without something. ... What makes you think that I can get permissions to use that tool with our corporate repository? What we are doing is ridiculous. One week we were doing what we had done for years, on prem with SQL Server, iSeries, TFS, C++ and .Net Framework. The next week we were plan, build, run; agile; open source; and the contractor is out of the picture leaving me with a .Net Core; AWS Lambda monstrosity. The team was scattered with me remaining and two new hires. Have you ever even heard of an AWS lambda that included 150+ C# source files? I'm in the wrong job, but not because of git. It's lambda that is going to be my demise. I need fast simple solutions to organize this. I'll probably be able to make the code to do what I want. It's the rest I worry about.
modified 25-Jun-21 15:52pm.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
