Skip to main content

Home/ learning-git/ Group items tagged public

Rss Feed Group items tagged

Daniel Gregoire

Setting up a new remote git repository - 0 views

  •  
    Great detail on setting up public repo. Read all the way through. It's not chronological.
Daniel Jomphe

Setting up your Git repositories for open source projects at GitHub « Insoshi... - 0 views

  • In setting up the repositories for Insoshi, I’ve applied the version control experience I gained at Discover, where I was technical lead for the software configuration management (SCM) team.
  • Except for that interaction, everyone works within their own repository and on their own schedule. There’s no process waiting to be completed that blocks you from moving on to whatever you need/want to do next. And you’re not forcing anyone to drop what they’re doing to right now to handle your request.
  • One of the major benefits of a distributed version control system like Git is that each repository is on an equal footing; in particular, we would like every fork to have the same master branch, so that if the “official” Insoshi repository should ever be lost there would be plenty of redundant backups.
  • ...14 more annotations...
  • it’s a bad idea in general to work on the master branch; experienced Git users typically work on separate development branches and then merge those branches into master when they’re done
  • Your local repository: The “right” way Keeping the big picture in mind, here are the commands I’ve run to set up my local repository (using the GitHub id long): $ git clone git://github.com/insoshi/insoshi.git $ cd insoshi $ git branch --track edge origin/edge $ git branch long edge $ git checkout long $ git remote add long git@github.com:long/insoshi.git $ git fetch long $ git push long long:refs/heads/long $ git config branch.long.remote long $ git config branch.long.merge refs/heads/long
  • You should note that the Git URL for the clone references the official Insoshi repository and not the URL of my own fork
  • Insoshi also has an ‘edge’ branch for changes that we want to make public but may require a bit more polishing before we’d consider them production-ready (in the past this has included migrating to Rails 2.1 and Sphinx/Ultrasphinx).  Our typical development lifecycle looks something like development -> edge -> master
  • I’m resisting the temptation to immediately start working on the local ‘master’ and ‘edge’ branches. I want to keep those in sync with the official Insoshi repository. I’ll keep my changes separate by creating a new branch ‘long’ that’s based off edge and checking it out
  • I’m starting my changes off of ‘edge’ since that contains all the latest updates and any contribution I submit a pull request for will be merged first into the official Insoshi ‘edge’ branch to allow for public testing before it’s merged into the ‘master’.
  • I’m finally adding the remote reference to my fork on GitHub
  • We should run a fetch immediately in order to sync up the local repository with the fork
  • I’m pushing up my new local branch up to my fork. Since it’ll be a new branch on the remote end, I need to fully specify the remote refspec
  • Now that the new branch is up on my fork, I want to set the branch configuration to track it
  • Setting the remote lets me just simply use $ git push to push changes on my development branch up to my fork
  • I’ve got a shell script for you.
  • The extra work is worth the effort, because with this configuration My changes will be easily identifiable in my named branch I can easily get updates from the main Insoshi repository Any updates I’ve pulled into master and edge are automatically pushed up to my fork on GitHub The last one is a bonus because the default refspec for remotes is refs/heads/*:refs/heads/*. This means that the simple ‘git push’ command will push up changes for all local branches that have a matching branch on the remote. And if I make it a point to pull in updates to my local master and edge but not work directly on them, my fork will match up with the official repository.
  • So what is the benefit of all this to open source projects like Insoshi? The easier it is for the contributor to pull in updates, the more likely it will be that the pull request will be for code that merges easily with the latest releases (with few conflicts) You can tell if someone is pulling updates by looking at their master and edge branches and seeing if they match up with the latest branches on the main repository By getting contributors in the habit of working on branches, you’re going to get better organized code contributions Basically, the less effort that’s required to bring in code via a pull request, the sooner it can be added to the project release. And at the end of the day, that’s really what it’s all about.
1 - 2 of 2
Showing 20 items per page