Skip to content

Example GitHub workflow and how to update Git sub modules

Jump to bottom
Michael Hulse edited this page Dec 9, 2016 · 3 revisions

Clone repo locally ...

... and recurse submodules:

# A development location on your local drive:
$ git clone --recursive git://github.com/registerguard/marketplace.git
$ cd marketplace

Update Git sub-module in parent repo and push everything back up to GitHub.

Make sure you're working on the right branch.

Technique #1:

$ git submodule update --remote

Technique #2:

First, cd to the directory that contains the sub-module. For example:

$ cd ~/github/registerguard/django-ad-manager/ad_manager/static/ad_manager

Next, run:

$ git pull

If you get an error like:

Not currently on any branch.

... then run:

$ git checkout master

Alternatively, you could run:

$ git status

... to see if you're on "a branch", then run:

$ git pull

Finally, open GitHub for Mac/Windows app and you should see that there's a change to commit (the hash for the sub-module will be different and needing to be committed). Commit and sync your changes. Alternatively, if you prefer command line, cd to the parent repository and run:

$ git commit -am 'Set sub-module version to x.x.x'

For related information on how to setup a sub-module, see here:

Update repo on live server (including sub-modules).

ssh to production/live/test server (whatever), cd to folder that houses your GitHub repository.

$ git pull --recurse-submodules && git submodule update

--[no-]recurse-submodules[=yes|on-demand|no] This option controls if new commits of all populated submodules should be fetched too (see git-config(1) and gitmodules(5)). That might be necessary to get the data needed for merging submodule commits, a feature git learned in 1.7.3. Notice that the result of a merge will not be checked out in the submodule, "git submodule update" has to be called afterwards to bring the work tree up to date with the merge result.

Because this example is a Django app, we'll need to collect static and clean up leftover files.

cd to your Djanog project's root and run:

$ python manage.py collectstatic --dry-run

You have requested to collect static files at the destination
location as specified in your settings file.

This will overwrite existing files.
Are you sure you want to do this?

Type 'yes' to continue, or 'no' to cancel: yes
Pretending to copy '/foo/ad_manager/static/ad_manager/benjamins/js/ad_manager.js'
Pretending to copy '/foo/ad_manager/static/ad_manager/benjamins/js/onmediaquery.js'
Pretending to copy '/foo/ad_manager/static/ad_manager/benjamins/demo/demo.css'
Pretending to copy '/foo/ad_manager/static/ad_manager/benjamins/demo/index.html'
Pretending to copy '/foo/ad_manager/static/ad_manager/benjamins/demo/plugins/js/respond.src.js'
Pretending to copy '/foo/ad_manager/static/ad_manager/benjamins/demo/plugins/js/jquery.jsonp.js'
Pretending to copy '/foo/ad_manager/static/ad_manager/benjamins/demo/plugins/js/onmediaquery.js'
Pretending to copy '/foo/ad_manager/static/ad_manager/benjamins/demo/plugins/css/wiffle.css'
Pretending to copy '/foo/ad_manager/static/ad_manager/benjamins/demo/plugins/css/normalize.css'
Pretending to copy '/foo/ad_manager/static/ad_manager/benjamins/demo/plugins/css/onoff.css'
Pretending to copy '/foo/ad_manager/static/ad_manager/benjamins/css/ad_manager.css'
Pretending to copy '/foo/ad_manager/static/ad_manager/benjamins/css/onmediaquery.css'

12 static files copied to '/baz/static/' (81 unmodified).

Using --dry-run option will test the command without actually moving any files.

If everything looks good, go ahead and run the command without the --dry-run option.

That's it!

Some misc. notes that are outdated (kinda)

Workflow notes

Pushing and pulling

While not mandatory, it’s always best to think of version control as a one-way street. That is to say, make edits on your local machine, push to your DVCS server, and then pull to your dev/production machines.

While you can edit the dev or production machine’s repository, and push those changes back to your DVCS server, it more likely you’ll run into conflicts based on the experience of your team (and the number of people working on the project).

So, while it’s not breaking any rules, I always try to edit my project on my local development machine and go through the process of pushing to dev/production. It may take longer, but it will save you a bunch of potential headaches down the line.

Branches

When making changes to your code, remember that it can’t hurt to create a develop (for example) branch. This would allow you to make changes without wiping the master branch. When you are ready, you can merge develop into master; this workflow is useful in that you are not disturbing a working master branch during your development process and it makes it easier to fix things if you need to revert.

Some workflows consider the master branch to be the release branch. From there, you work on development/feature branches and can merge when tests on development branches pass and the master code reviewer has approved the new changes.

For smaller projects, depending on the needs of the project, I typically just work on my main branch.

For large open source projects, branches are used to apply patches; it’s considered bad form to apply your patch to the designated master.

Merging and switching branches can be done easily via GitHub for Mac (my preference).

Creating and changing a branch via the command line:

# Create a new branch:
$ git checkout -b new-branch-name
# Checking out a new branch:
$ git checkout new-branch-name

More info here.

Clone this wiki locally