I need a tool to visually track branches in git
-
Try Free Git GUI for Windows, Mac, Linux | GitKraken[^]
The less you need, the more you have. Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load? JaxCoder.com
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.
-
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.
-
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.
Well, Git is unusable, so enjoy I guess...
-
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.
-
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.
-
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.
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 logfor visualization of branches. A good baseline version is:git log --oneline --all --graph --decorateIf you've got a hairball of a git repo you'll quickly see why a separate tool might be a better solution.git loghas a TON of filtering options though which can help. References: [git-log | Git](https://git-scm.com/docs/git-log) [Advanced Git Log | Atlassian](https://www.atlassian.com/git/tutorials/git-log) -
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 logfor visualization of branches. A good baseline version is:git log --oneline --all --graph --decorateIf you've got a hairball of a git repo you'll quickly see why a separate tool might be a better solution.git loghas a TON of filtering options though which can help. References: [git-log | Git](https://git-scm.com/docs/git-log) [Advanced Git Log | Atlassian](https://www.atlassian.com/git/tutorials/git-log)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.
-
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.
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.
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions -
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.
-
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
