I need a tool to visually track branches in git
-
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.
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
-
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 ;P 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
-
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 :~ X| :confused:. 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.
-
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 :~ X| :confused:. 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.
Assuming you are using Windows, see: best-git-clients-for-windows[^] If you are looking for a Git server with a nice GitHub like interface, I can recommend Gitea[^] it's free and open-source.
-
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 ;P 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.
-
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 X|
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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.
Wow! Just wow! I could use somebody like you on the team :)
-
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.
Michael Breeden wrote:
I need fast simple solutions
I've got a quick solution for you: It Jobs | Monster.com[^] X| I wouldn't want to work for a company that doesn't value my skills or contributions because managers think they know better.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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.
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
-
Michael Breeden wrote:
I need fast simple solutions
I've got a quick solution for you: It Jobs | Monster.com[^] X| I wouldn't want to work for a company that doesn't value my skills or contributions because managers think they know better.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
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.
-
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.
-
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 ;P 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
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.
-
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 :laugh:
Mircea
-
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 :~ X| :confused:. 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.
To Git or not to Git that is the question. Is the right place for this post, or should it be in Ask a Question forum?
"I'm a mean old man, a dirty old man" - paraphrasing the Beatles.
-
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 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
-
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.
-
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 :~ X| :confused:. 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.
I found Visual Studio rather helpful in working with Git, including it's visual history display (including branches). It gets better, you get a note about who worked on this method and what did they change right in the code editor! Of course is there nothing about Git in the agile manifesto and/or agile methodogies! The first line in the agile manifesto is "people & interactions>processes" and Git is just a tool. Granted, it's the default go-to tool for code management, but it's still just a tool.
-
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 :~ X| :confused:. 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.
I will consider also Sourcetree, easy to use and good UI.
-
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 :~ X| :confused:. 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.
to flip the question Why do you need to visualise? Are you creating to many branches, or are branches open to long creating many changes per branch? Simplify: Create Branch, make code, Pull Request (PR tools like devops, help show what changes going to do), Delete Branch on Pull New branch per feature change. Delete on complete Pull Request. As for history tools: Visual Studio 2019 built in Git history ok. SourceTree was great when used it, but Im in on VS Pro 2019 git change tool.
-
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 :~ X| :confused:. 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.
From the ProGit text (publicly available), in Appendix A, there are a few excellent conceptual tools: 1: git-prompt that you can display your current directory and current branch via command line prompt 2: git-completion: just like normal shell text completion, but git call specific 3: GitHub for Windows or Mac 4: gitk and git-gui: this is what you're looking for. Although, not sure it illustrates remote.
