I keep hearing people say they're forking code in Git. Git "fork" sounds suspiciously like Git "clone" plus some (meaningless) psychological willingness to forgo future merges. There is no fork command in Git, right?
GitHub makes forks a little more real by stapling correspondence onto it. That is, you press the fork button and later, when you press the pull request button, the system is smart enough to email the owner. Hence, it's a little bit of a dance around repository ownership and permissions.
Yes/No? Any angst over GitHub extending Git in this direction? Or any rumors of Git absorbing the functionality?
Fork, in the GitHub context, doesn't extend Git.
It only allows clone on the server side.
When you clone a GitHub repository on your local workstation, you cannot contribute back to the upstream repository unless you are explicitly declared as "contributor". That's because your clone is a separate instance of that project. If you want to contribute to the project, you can use forking to do it, in the following way:
clone that GitHub repository on your GitHub account (that is the "fork" part, a clone on the server side)
contribute commits to that GitHub repository (it is in your own GitHub account, so you have every right to push to it)
signal any interesting contribution back to the original GitHub repository (that is the "pull request" part by way of the changes you made on your own GitHub repository)
Check also "Collaborative GitHub Workflow".
If you want to keep a link with the original repository (also called upstream), you need to add a remote referring that original repository.
See "What is the difference between origin and upstream on GitHub?"
And with Git 2.20 (Q4 2018) and more, fetching from fork is more efficient, with delta islands.
I keep hearing people say they're forking code in git. Git "fork" sounds suspiciously like git "clone" plus some (meaningless) psychological willingness to forgo future merges. There is no fork command in git, right?
"Forking" is a concept, not a command specifically supported by any version control system.
The simplest kind of forking is synonymous with branching. Every time you create a branch, regardless of your VCS, you've "forked". These forks are usually pretty easy to merge back together.
The kind of fork you're talking about, where a separate party takes a complete copy of the code and walks away, necessarily happens outside the VCS in a centralized system like Subversion. A distributed VCS like Git has much better support for forking the entire codebase and effectively starting a new project.
Git (not GitHub) natively supports "forking" an entire repo (ie, cloning it) in a couple of ways:
when you clone, a remote called origin is created for you
by default all the branches in the clone will track their origin equivalents
fetching and merging changes from the original project you forked from is trivially easy
Git makes contributing changes back to the source of the fork as simple as asking someone from the original project to pull from you, or requesting write access to push changes back yourself. This is the part that GitHub makes easier, and standardizes.
Any angst over Github extending git in this direction? Or any rumors of git absorbing the functionality?
There is no angst because your assumption is wrong. GitHub "extends" the forking functionality of Git with a nice GUI and a standardized way of issuing pull requests, but it doesn't add the functionality to Git. The concept of full-repo-forking is baked right into distributed version control at a fundamental level. You could abandon GitHub at any point and still continue to push/pull projects you've "forked".
Yes, fork is a clone. It emerged because, you cannot push to others' copies without their permission. They make a copy of it for you (fork), where you will have write permission as well.
In the future if the actual owner or others users with a fork like your changes they can pull it back to their own repository. Alternatively you can send them a "pull-request".
"Fork" in this context means "Make a copy of their code so that I can add my own modifications". There's not much else to say. Every clone is essentially a fork, and it's up to the original to decide whether to pull the changes from the fork.
Cloning involves making a copy of the git repository to a local machine, while forking is cloning the repository into another repository. Cloning is for personal use only (although future merges may occur), but with forking you are copying and opening a new possible project path
I think fork is a copy of other repository but with your account modification. for example, if you directly clone other repository locally, the remote object origin is still using the account who you clone from. You can't commit and contribute your code. It is just a pure copy of codes. Otherwise, If you fork a repository, it will clone the repo with the update of your account setting in you github account. And then cloning the repo in the context of your account, you can commit your codes.
Forking is done when you decide to contribute to some project. You would make a copy of the entire project along with its history logs. This copy is made entirely in your repository and once you make these changes, you issue a pull request. Now its up-to the owner of the source to accept your pull request and incorporate the changes into the original code.
Git clone is an actual command that allows users to get a copy of the source.
git clone [URL]
This should create a copy of [URL] in your own local repository.
There is a misunderstanding here with respect to what a "fork" is. A fork is in fact nothing more than a set of per-user branches. When you push to a fork you actually do push to the original repository, because that is the ONLY repository.
You can try this out by pushing to a fork, noting the commit and then going to the original repository and using the commit ID, you'll see that the commit is "in" the original repository.
This makes a lot of sense, but it is far from obvious (I only discovered this accidentally recently).
When John forks repository SuperProject what seems to actually happen is that all branches in the source repository are replicated with a name like "John.master", "John.new_gui_project", etc.
GitHub "hides" the "John." from us and gives us the illusion we have our own "copy" of the repository on GitHub, but we don't and nor is one even needed.
So my fork's branch "master" is actually named "Korporal.master", but the GitHub UI never reveals this, showing me only "master".
This is pretty much what I think goes on under the hood anyway based on stuff I've been doing recently and when you ponder it, is very good design.
For this reason I think it would be very easy for Microsoft to implement Git forks in their Visual Studio Team Services offering.
Apart from the fact that cloning is from server to your machine and forking is making a copy on the server itself, an important difference is that when we clone, we actually get all the branches, labels, etc.
But when we fork, we actually only get the current files in the master branch, nothing other than that. This means we don't get the other branches, etc.
Hence if you have to merge something back to the original repository, it is a inter-repository merge and will definitely need higher privileges.
Fork is not a command in Git; it is just a concept which GitHub implements. Remember Git was designed to work in peer-to-peer environment without the need to synchronize stuff with any master copy. The server is just another peer, but we look at it as a master copy.
In simplest terms,
When you say you are forking a repository, you are basically creating a copy of the original repository under your GitHub ID in your GitHub account.
and
When you say you are cloning a repository, you are creating a local copy of the original repository in your system (PC/laptop) directly without having a copy in your GitHub account.
I'm building an app with android studio with another developer. Is there any way in which I can make it so that both my partner and I can work on the project at the same time on different computers (both Windows computers)? I know there is a similar question, but I am looking for a more detailed explanation on how to do it.
My suggestion: Use Version Control preferably git.
This will help both of you to develop Apps without any problems of copying & pasting and manually making changes in all files one-by-one.
Note: Want to use git but do not want to open source your code (since Github allows creating private repository but with some Payment), then use Bitbucket, you can create private repositories for FREE!
EDIT: Github now provides unlimited private repositories.
Hope it helps!
Take a look at git. I will help you and your partner to work on the same project on a different computer (Windows, Mac, Linux...).
https://www.atlassian.com/git/tutorials/comparing-workflows
As others have indicated, you should use a version control system like git for this. This will give you the following features (among others):
The ability to share code between people
Essentially keeps a backup of your code on an external server
Keeps a history of revisions to files (so you can "back out" changes if you need) as well as differences between your local file and the version on the server
Allows you to merge changes between you and people working with you
How you do this will depend on which version control system you use, but some version control providers will allow you to also set up what's known as "Continuous Integration" - basically, if you or your partner check code in, it'll immediately start a build. If this is available to you, I strongly recommend using it. The advantage of that is that it'll give you quick feedback if you did something that'll prevent it from building for the other person (e.g. if you forgot to check in a file or something). This'll prevent a lot of frustration and wasted time. (This happens a lot more often than you'd think; you don't want the other person to have to spend half an hour trying to get the app to build again when they download your code only to find out that you forgot to check in a file).
I also strongly recommend integrating your stuff with each other as often as possible as well as practicing regular "re-baselines" (i.e. downloading each others' stuff and merging it with what you have locally). The longer you wait to integrate your stuff with each other the more complicated it'll become, and waiting too long greatly increases the risk of introducing bugs when merging or forcing unnecessary rework.
I have recently started to look into android development (aosp) and read about "repo" tool/wrapper that takes care of all the android's sub projects .
While I think repo does a fairly good job at what it does, I wanted to know if there are any alternatives to it.
I thought git submodules are sufficient for this but many posts on internet discourage use of submodules ( due to some "drawbacks" which I feel are not drawbacks at all ).
Keeping in mind that the source code for different sub projects should have their own releases or indipendednt code bases I am not sure if git subtree is a good solution for this.
It would be great if someone can point out some alternatives to repo or any other information about this.
The repo tool is the standard way to work with AOSP code base. Sure you can manually manage the repos yourself but that is going to be rather tiresome and error prone.
Otherwise using submodules or subtrees won't let you inter-operate with Google and everyone else working on the AOSP codebase, so unless you are planning to do a one-way fork of AOSP there are no alternatives to the repo tool for working on AOSP.
repo has one huge disadvantage: it detaches HEADs. You can't switch to specific branch under specific subrepo. Unless you do repo start
tsrc, as far as I know, has less functionality but doesn't have this specific problem.
Also, you can use embedded mechanisms of build systems like Bazel (git_repository/new_git_repository).
Imagine mobile application that is planned to be implemented for both iOS and Android.
Development was started from the iOS version only and now the time has come to start with Android one.
iOS application's code is stored at its' own Git repository that named after the apps name, e.g. "MYApp".
Now I would like to create one common repository for both iOS and Android applications and name it again after application's name: "MYApp".
It is not a problem at first glance.
Just create repository, create 2 subfolders there and start working.
But.
I would like that Android developer could work only with his folder and iOS developer only with his one too and both of them could see only their own folders related history (log).
I worked with SVN previously.
Usually I created subfolders and you could checkout any of them to work only with this subfolder.
History was also filtered to your scope.
I'm stuck with implementing the same under Git.
Please, help me to find right direction.
I will sum up solutions suggested.
Use branching for different platforms. I don't think that it is good idea, because branches used for another purpose. It seems to me very "jacky".
Use submodules. Just create as many repos as platforms you are targeting to, name them "MYApp-iOS", "MyApp-Android", etc. and finally end up with "master" repo, that could be names as "MYApp" (without any suffixes). Then add all related repos to "master" one with git submodules feature.
Use git slave. Investigating...
Please, feel free to edit this list to brainstorm the problem.
There is a way to keep to kind-of-related separate projects in a same git repository utilising git branching.
But keep in mind that that is not why branching was implemented into git. One of its uses would be development of a radical new functionality to your app that might not see the release any time soon for example.
On the end: it is a matter of opinion. If you are prepared to administrate a more complex repository just to keep both codes on the same place - you can.
I would definetly make two separate repositories though. Couple of opinions on this topic can also be found here on SO: Git branches with completely different content
EDIT:
gitslave seems to tackle your problem. You might want to give it a try.
I am taking care of an open source project: mixare. It's an augmented reality browser released under the GPLv3.
The source code of the project is on github and I would like to hook the localization part to some web-service a-la pootle. If necessary I can install my own instance of a translation service on our server, but also an hosted solution would be fine. So I would like to know:
Is there a preferred translation web service that syncs using github's service hooks? Any best practice to share?
Thanks a lot!
Git integration is one of major reasons why I started to write Weblate. It also supports remote trigger for git pull using URL, so it nicely integrates with Github (you just need to put the URL there).
PS: I've just noticed that Android string resources are not supported by backend I use for loading translations (translate toolkit), so it probably won't work for you...
While I appreciate your wish for git support, shouldn't you primarily be looking for a solution that will give you many and good translations?
To get many translations I'd recommend Translatewiki, unfortunately their manual setup takes some time though.
Apart from Translatewiki, transifex seems to be one of the better and not least bigger (counting translators) services. They've made their own client that take care of importing and merging translations. For gettext translations it can also pull in updated template (pot) files automatically from github, I don't know if that's also possible with Android style translations.
Both Translatewiki and Transifex are 100% free and open source software.
I've been through the same "nothing good out there" phase, so I've started writing my own, as a symfony2 bundle. Maybe it's of use to you: https://github.com/tvogt/translator-bundle
Why? Because I couldn't get weblate or pootle to work, you probably have to be familiar with all the pip and python and ve and whatever stuff. Translatewiki is only for free software. Transifix is commercial.
In 2020, with GitHub Actions (hooks executed on GitHub side), you now have GitLocalize
GitLocalize is a continuous localization tool built for communities and teams that want to simplify their workflow when translating their content.
GitLocalize automatically keeps translations up to date by syncing with your repository.
That won't apply to the OP's project github.com/mixare/mixare, which was moved to GitLab in 2018.
But it can help other projects with a similar need.
You can have a look at Amanuens - it's able to sync with any Git repository, including Github. It's totally free for open-source projects (contact support for details). Disclaimer: it is my company's service.