|
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.
|
|
|
|
|
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.
modified 26-Jun-21 8:04am.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
I will consider also Sourcetree, easy to use and good UI.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
The 'gitk' tool is pretty good for showing history and is typically packaged with Git. It can take command line options that limit which lines of development are shown, and where they should start and end, though the documentation is minimal..
Likewise the git-gui is a nice developer front end for those who aren't 100% head-in-a-terminal.
The key aspects will be to set ground rules, and to decide on the server/remote structure (or set rules based on the one you are given, e.g. single central repo, or repo [fork] per dev plus a golden repo).
Remember that Git distributes 'control' to the developer, away from the manager.
But that is good! Because the manager no only has to decide if contributions are acceptable for inclusion on the main/master/trunk.
It is also good because the developer can now keep all their wip revisions on their own machine with many and varied branches, and you don't care! Finally they start using version management because it helps them!
Key rules:
* Small commits often, with imperative style concise comments (try looking at the git repo itself).
* merge relatively often, or rebase long running dev branches (minimal in-work tech debt)
* All file names must be valid Windows file names. No Directory/File name (Linux) conflicts (i.e. no Readme/Readme, foo/foo) Git won't accept them.
* Give devs their own branch namespace prefix `dev1/`, or use initials like my `po/`
* Use a hook on the central repo to ensure simple common sense (branch separation).
* Keep focus on the prize.
* Don't tell senior management. They will only misunderstand even worse! (Job for Direct Implementation - JFDI)
|
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
