397 liens privés
Pour github uniquement pour l'instant
bitbucket:
import os
from sys import platform as _platform
from flask import Flask
from flask import request
app = Flask(__name__)
@app.route('/webhook', methods=['POST'])
def tracking():
data = request.get_json()
commit_author = data['actor']['username']
commit_hash = data['push']['changes'][0]['old']['target']['hash'][:7]
commit_url = data['push']['changes'][0]['old']['target']['links']['html']['href']
print 'Webhook received! %s committed %s: %s' % (commit_author, commit_hash, commit_url)
return 'OK'
if __name__ == '__main__':
app.run(host='0.0.0.0', port=5000, debug=True)
git remote add upstream git@github.com:thoughtbot/dotfiles.git
git fetch upstream
git rebase upstream/master
Une fonctionnalité intéressante apparue dans git 2.5.
2 cas d'utilisations sont cités:
Say you are on a feature branch, and want to make a bug fix in master. You can create a whole new working copy based on master as follows:
git fetch git worktree add -b bugfix-1234 ../bugfix origin/masterAnother use case for the worktree feature is when you have long running tasks (say, running build, unit tests, integration tests and functional test) that you want to run while continuing to work on the codebase. In that case, you can:
git worktree add --detach ../project-build HEAD cd ../project-build ./run_build.sh
avec "Tenacious D: Master Exploder" dedans (https://www.youtube.com/watch?v=80DtQD5BQ_A)
scène tirée du film "Tenacious D: The Pick Of Destiny"
http://yourserver/git/notifyCommit?url=<URL of the Git repository>[&branches=branch1[,branch2]*][&sha1=<commit ID>]
A l'appel de cette URL, tous les jobs qui ont le repo Git spécifié se lancent.
Les jobs doivent être configurés avec "Poll SCM" activé.
La fonctionnalité dont je parle est fournie par le plugin Git de jenkins (https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin).
"""
git-appraise - Distributed code review system for Git repos
This tool is the first distributed code review system for git repos.
By "distributed", we mean that code reviews are stored inside of the repository as git objects. Every developer on your team has their own copy of the review history that they can push or pull. When pulling, updates from the remote repo are automatically merged by the tool.
This design removes the need for any sort of server-side setup. As a result, this tool can work with any git hosting provider, and the only setup required is installing the client on your workstation.
"""
joli!
Gérer ses dotfiles dans git facilement, sans effort, grâce à vcsh et myrepos.
C'est le genre de truc qui m'intéresse car, pour ma part aujourd'hui, j'ai des liens symboliques de partout: du repo qui contient ces dotfiles vers l'endroit où j'en ai besoin.
Outil similaire encore plus simple: https://github.com/capr/multigit EDIT: ça ne supporte pas zsh visiblement.
Construire un serveur git en 3 minutes chrono, grâce à SSH et un user unix dédié.
La mise en place + la création d'un premier repo remote tiennent en 7 commandes.
Testé et adopté.
Pour se forcer à écrire des commits bien documentés.
A noter que ça peut devenir vite casse-couille.
"""
gitfiti - abusing github commit history for the lulz
"""
mais vous avez que ça à fouttre ? :D
Procédure pour merger la branche d'un repo distant.
Admettons que je travaille sur https://github.com/UtahDave/salt-vagrant-demo
"""
$ git clone https://github.com/UtahDave/salt-vagrant-demo.git
$ cd salt-vagrant-demo
"""
Je veux merger la branche 'vagrant_1.7.4' du fork https://github.com/cjhenck/salt-vagrant-demo qui intègre le patch qui m’intéresse dans ma branche 'master' locale.
J'ajoute le remote en indiquant la branche qui m'interesse avec -t. 'patch-vagrant-1.7.4' est ici une sorte de tag que je donne au remote.
"""
$ git remote add patch-vagrant-1.7.4 -t vagrant_1.7.4 https://github.com/cjhenck/salt-vagrant-demo.git
"""
Je me mets sur ma branche locale master si je n'y suis pas déja
"""
$ git checkout master
"""
Je merge le remote, que j'ai précédemment taggué 'patch-vagrant-1.7.4', dans master:
"""
$ git pull patch-vagrant-1.7.4 master
"""
Pour ceux qui n'ont jamais touché à git, et qui veulent commencer à l'utiliser ;
Voici un tuto vidéo en français, en plusieurs parties.
Pour ceux qui n'ont jamais touché à git, et qui veulent commencer à l'utiliser ;
Voici un tuto vidéo en français, en plusieurs parties.
Supprimer une branche remote
"""
$ git push origin :mabranche
"""
Supprimer une branche locale
"""
$ git branch -d mabranche
ou
$ git branch -d mabranche
"""
La différence entre les 2 (man git-branch) :
"""
-d, --delete
Delete a branch. The branch must be fully merged in its upstream branch, or in
HEAD if no upstream was set with --track or --set-upstream.
-D
Delete a branch irrespective of its merged status."""
Des GIF pour valider une code review ;)
(LGTM : Looks Good To Me)
très bon rappel.
faut que je teste ce qui est dit dans la partie 'Fix an earlier commit'.
https://github.com/cjb/GitTorrent/blob/master/README.md
Quand on utilise la commande git avec 'toto://' comme protocole, ça appele 'git-remote-toto'. Pour ces 3 cas, ça va donc taper sur git-remote-gittorrent:
"""
gittorrent://some.git.hosting.site/somerepo -- we connect over git:// to find out what the latest commit is, then perform the download using that commit's sha1. This is kind of like a CDN for a git server; the actual download of objects happens via peers, but the lookup of which objects to downloads happens in the normal Git way.
gittorrent://<hex sha1>/reponame -- the sha1 corresponds to a gittorrent user's "mutable key" (hash of their public key) on our DHT -- we look up the key, receive JSON describing the user's repositories, and then perform the download using that commit's sha1. This doesn't use any resources outside of GitTorrent's network.
gittorrent://<username> -- the username is converted into a mutable key sha1 as above. The mapping from usernames to happens on Bitcoin's blockchain in OP_RETURN transaction."""
