Git is supposed to be a decentralized system, but all the tutorials and best practice workflows I have found on Google suggest using a server (usually GitHub, or else set up your own)
I am using git for small personal projects (2-3 people), where can I find a best practice workflow for syncing changes directly between the team members machines.
Alternatively, what are some compelling arguments for why I should avoid this and instead set up a 'central' server?
Depends on what you mean by "server". Git will work happily without a central server, although many teams find it convenient to have a central repository.
If by "server", you mean "install server software", git will also work (central repository or not) without any special software, through ssh or on the file system.
See this document for possible workflows
The workflow that many use is that all developers "push" (send) their changes to a common repository, and get all the changes from that repository. Something like this:
In this case the central repository can be on one of the Developers computers, on github, or any other place
You can also use git without any server, just using email. In this case the flow would be like this:
This can even be done in a semi-automated way
You can setup git to use more than one "remote" repository. The caveat is that you should never push to a repository that is checked out (that is, a Developer copy on which someone is working). So in this case the flow would be like this:
IMHO this type of workflow will quickly lead to confusion and breakdown.
rsync if I understood correctly, but I am curious. –
Turnabout push to another developer's repository, but you do push to the production server. I don't think that's so hard to remember - that the only time you need to push is when deploying. I'd even argue that it more clearly separates the development and deployment processes from each other, and therefore makes everything safer than in the first scenario. –
Kalk git push to deploy software to a server is a very special case, neither the question nor the answer deals with that at all, and the scenario is not relevant for the original question. Also, your understanding seems to be that everyone works on something like web applications and that it is a standard thing to deploy software with git push. Neither is true: There are still a lot of people who do not work on server-based software at all, and then web applications are deployed in a different way than git push. –
Jara What you need to do first, is to think through what kind of workflow you have already and configure git to work with that. Once you have something up and running, you can fine tune it. There is no need to setup a separate computer as a server. If you are accustomed to have a central repository all you need to do is to create a bare repository that everyone pushes to. Why not on the local network?
Central repo:
mkdir foo.git
cd foo.git
git init --bare
Your repo:
mkdir foo
cd foo
git init
// add files
git add .
git commit -m "Initial commit"
git remote add origin //path/to/central/repo/foo.git
git push origin master
Other repos:
git clone //path/to/central/repo/foo.git
Now anyone can push and pull directly from master branch. This should be enough to get you started.
You should setup a central server as a social construct, not a technical one, so that everyone knows where to find the latest official version, without any possibility for confusion.
You don't necessarily need to put a copy on a physical server somewhere, but it may help to have a 'blessed' repository somewhere -- make one of your team (possibly on a rotation) responsible for collecting and managing people's changes when they are ready to be treated as final. They can either keep a branch in their usual repository or maintain a separate repository on their local system to store the master sources.
As a concrete example, consider Linux and Linus Torvalds -- there's no central repository that everyone pushes to, but Linus maintains a repository which contains all of the code he considers 'ready' (and so do several other people, for different definitions of 'ready'). That way you've got a canonical definition of what code is in, and a place to define what your releases are.
As has been mentioned Git works really well without a centralised server. But a good reason to have a central server is to have an "always on" place to push code once a feature is completed that other developers can pull from without having to have access to your local machine.
For example, currently I work on a 3 man dev team. We all work on laptops. We could have a work flow where we just pull from each other's machines. But if I work on a feature and commit my chances after everyone has left the office and I want them to take a look with this system they can't do anything unless my laptop is on and available on the network. If the guys turn up earlier than me (which they always do) they have to wait until my laptop is back online.
If I push to something like BitBucket or GitHub or just an always on server in the office, any of the other developers can simply pull the changes I've made when ever they are next online.
That to me is the main reason to have a central server, and really it isn't a fault with Git but rather a consequence of working with laptops.
Git works pretty well with this sort of setup, although you'll want to avoid pushing changes to someone else's checked out branch ( https://git.wiki.kernel.org/index.php/GitFaq#Why_won.27t_I_see_changes_in_the_remote_repo_after_.22git_push.22.3F ). You might have an integration branch that you push code to, and merge other people's changes from.
I think the main reason that a central repo is used a lot is that it can be taken as the canonical base for all your code, whereas it can be a little harder to reason about what you should be merging into when you have 3 or more branches of development going on.
Have a look at the Git for beginners: The definitive practical guide
section "How do you set up a shared team repository?"
© 2022 - 2024 — McMap. All rights reserved.