1

I'm new to the Git world but I realize that, since my programmer and I are going to be working on files at the same time, we need to establish a Git workflow. I have very minimal experience with Git from a 3 month project I did last year so I need help setting this up.

Currently, I have an account at a web host where all the current project files exist. I typically modify the files remotely using Coda connected to the server.

We purchased a month of service at Github to create a private repository so that we can use the GUI feedback of Github to solve bugs using the pretty UI to see the diffs.

On the web host account, no Git repository is setup yet. I do not completely understand how to transfer the files to Github but I assume I would need to create a repository on the web host account first and then push this to the Github account.

Does this sound correct? Which account would we set as the master repository? Beyond what I wrote, I am not sure I completely understand how to do every or if there's a better way to do what I've explained.

I'd appreciate your feedback and if possible someone to write explicit instructions on how to do this. Thanks!

micah
  • 1,937
  • 6
  • 27
  • 40

2 Answers2

1

When working with GitHub repo, you have two choices:

  • add your team as collaborator for your repo (they can push directly to said repo)
  • ask them to fork your repo (clone on the GitHub side), then making pull requests in order for you to integrate their changes.

Since we are talking private repo, the first solution is more practical (to avoid having to setup different private, i.e. not free, repos for each developers).

From there you need to setup a branch/merge workflow decide if you want, for a given development effort where several people work on the same set of files, if:

  • each developers will work on the same common branch (in which case they need to rebase and resolve any conflict locally, before pushing their commits)
  • each developers will work on a user-specific branch (in which case, they can push whenever they want, but an integrator will have to pull said branches and do the merge).

(see also "when should you branch?" and the second part of "Why uses git fast-forward merging per default?")

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Oh man, this is more involved than I thought it would be! Yikes. Okay, so we should go ahead and create a new repo for the web host account files? If so, would we clone the repo to Github after this? I'm still trying to figure out HOW to start this since right now all we have is a half-developed project on the web host account. – micah Apr 26 '11 at 06:28
  • @Micah: any DVCS adds a "publication workflow" orthogonal to "branching workflow", so it needs to be taken into account. (http://stackoverflow.com/questions/2563836/sell-me-distributed-revision-control/2563917#2563917) – VonC Apr 26 '11 at 06:30
  • @Micah: setting up a GitHub repo for this allows for historization and parallelizations (the classic VCS features), as well as collaboration. A DVCS means you have to clone a repo locally to work on it, then push back, for others to see your work. But that leaves you with a RM (Release Management) or "deployment" issue. You would still need to copy/transfer those files on your live server (GitHub repo or no GitHub repo). – VonC Apr 26 '11 at 06:33
  • @VonC: I have a lot of reading to do to get my head wrapped around thse concepts. I appreciate your opinions. I guess, from thinking about it more, is using Github even necessary in this whole process? We could, theoretically, just do all of this from the hosting account without the transfer to Github. I initially thought Github would be a good way to visualize everything since it provides some easy diff displays. – micah Apr 26 '11 at 06:36
  • @Micah: you could work directly on files, but you would loose the VCS features (http://stackoverflow.com/questions/1056912/source-control-vs-revision-control/1056947#1056947) about history, labels and branches, that allows you to know what has been delivered, what has been modified, by whom and when. – VonC Apr 26 '11 at 06:40
  • @VonC: So the benefit of using Github vs. just using Git on the hosting account is that Github also provides history, labels and branches, user modifications, etc.? As far as I can see, we can try to implement Git on the web host itself OR we can do everything on Github and then push it to the web host. Right? – micah Apr 26 '11 at 06:45
  • @Micah: if you have access to the web host, you could setup a Git repo directly on it, and use one of the supported Git protocol to directly clone/pull/push said repo on the team's workstations. (http://progit.org/book/ch4-1.html). Note that there is no "authentication" per se with a DVCS (i.e. you can sign off you commit as "anyone"; this is just a string). And there is no authorization either (you can push/modify anything by default, unless you setup some hooks or config to limit what your team is allowed to do). – VonC Apr 26 '11 at 06:49
  • @Micah: if only your team have access to the server, you can disregard the authorization/authentication issues. If not, Gitolite is the answer (see http://stackoverflow.com/questions/5683253/distributed-version-control-systems-and-the-enterprise-a-good-mix/5685757#5685757) – VonC Apr 26 '11 at 06:51
  • @VonC: We do have access and they have Git installed on the server. However, we are on a shared server so there's the chance of the repo being accessed by others on the server. I guess that's the main benefit of ONLY using Github's private repo? Or are there other reasons we really should consider using Github instead of just the web host's Git installation? – micah Apr 26 '11 at 06:59
  • @Micah: if you have access and have Git on the server, an external GitHub is not needed in my opinion. If you access the git repo through a simple network path (UFS share), you can change the ACL on that share in order to make sure only your team members can access said repo. Or you can have a more elaborate setup (with Gitolite, as mentioned in my last link in my previous comment). – VonC Apr 26 '11 at 07:04
  • @VonC: Okay, I think it's starting to make a little more sense. So, just to be clear, if we DO decide to use Github, there's no reason for us to also have a repo on the web host, correct? Everything should be pushed to and pulled from Github. Further, I'm guessing that we will need to start working on everything locally, pushing to Github, rather than working directly on the server and pushing to Github. Is my logic correct? – micah Apr 26 '11 at 07:08
  • @Micah: yes, if you have a GitHub repo, you wouldn't need one on the web server, since your task with said web server would be a deployment one (Release Management), where a VCS has no role to play (except to extract the right version to deploy). – VonC Apr 26 '11 at 07:21
  • @VonC: You have been extremely helpful and I really appreciate your prompt replies. I will do a lot more reading and try to come up with a good solution, whether it's through Github or just plain Git on the host. Thanks again! – micah Apr 26 '11 at 07:26
0

Here's a great guide on github:

http://help.github.com/create-a-repo/

I'd download the content from the web host first, so you have everything locally, and then push up to github.

rtn
  • 127,556
  • 20
  • 111
  • 121