GIT Workflow for a cloned GitHub Repo

I have a workflow question but it’s not really based on anyone’s opinion, but more on the exact abilities of GIT in terms of keeping projects up to date with a master repo.

I’m building a version of Backbone-Boilerplate that will use Ratchet for building PhoneGap apps.

  • Why I can't add this remote GitHub repository to my local GIT repository as remote?
  • TortoiseGit vs Git Extensions
  • Remove an Openshift server from RHC
  • Can git retain file owner, permissions, ACLs, and file attributes on a local Windows NTFS machine?
  • Git - Log commits of dev except which are cherry-picked into main
  • What does “Auto packing the repository for optimum performance” mean?
  • I’ve set up my own GitLab installation for storing our company code and added the clone there as a master branch.

    So my question is, what is the best way to go about this in order to keep everything up to date with the origin master?

    I want to keep the master BBB repo up to date with the origin, but should I do a fork of this repo to build the Ratchet version, or should I create a “ratchet” branch (and any other versions ie: bootstrap, etc.) and then merge or rebase the master into the branches as changes are committed?

    If I create a fork, is it possible to merge upstream changes into a fork? I’ve never actually worked with forks before and I’m unclear at this point which method I should use.

    So to be clear, the ultimate goal is to be able to update any version we create to match the master BBB repo on GitHub, minus the additional files we create.

    Thanks.

  • Openshift redhat for Windows: rhc command error
  • Showing git tag message
  • How to search git branch for a file name once committed?
  • How to delete a git remote that no longer exists
  • Git: rewriting history to collapse commits with the same message and time (merging submodules)
  • Get remote name from local branch
  • One Solution collect form web for “GIT Workflow for a cloned GitHub Repo”

    You create a fork only if you don’t have the possibility to push to the repo you fork.

    If you can push, then create a branch and work within the same repo: this is much easier to maintain that way.

    If you cannot push back (mainly to a repo on GitHub you don’t own), then yes, you can:

    • fork it (on GitHub)
    • clone it
    • push it to your GitLab server if you want.

    At any point, you can add to your local repo a remote called “upstream” referring to the original GitHub repo (the one your forked) in order to fetch from it and update your own branches based on the up-to-date fetched upstream.

    See “Git fork is git clone?” for more.


    In your case:

    So since I’ve already cloned this locally from GitHub, then uploaded that clone into my GitLab, I can rename “origin” to “upstream” for the GitHub remote, then use the “origin” alias for my GitLab version?

    Yes:

    cd /your/local/repo
    git remote rename origin upstream
    git remote add origin /url/to/your/GitLab/repo
    

    With this I can then pull changes from upstream, which would merge them into local, then push to origin and I’ll be up to date on my master branch?

    Yes.

    It is important that you don’t work on master directly, since it is a branhes updated by upstream.

    Then I could merge local master into local “ratchet” or other without overwriting new local files?

    Then I could merge local master into local “ratchet” or other without overwriting new local files?

    I would recommend rebasing the local branch you are using to isolate your new commits on top of upstream/master:

    git checkout myBranch
    git rebase upstream/master
    git push --force
    
    Git Baby is a git and github fan, let's start git clone.