GIT quick reference guide (also answering questions)

A forum to store posts deemed exceptionally wise and useful
Post Reply
REDDemon
Developer
Posts: 1044
Joined: Tue Aug 31, 2010 8:06 pm
Location: Genova (Italy)

GIT quick reference guide (also answering questions)

Post by REDDemon »

After you initialize/clone your repository, you are going to work on a branch at any time (it could be the "master" branch wich is on by default, or any other branch).


The usual workflow while you are inside a branch is "make local changes and commit them to LOCAL REPO".
The Idea is that you work until you get something done (done => compilable, possibly with some tests testing the new functionality, in other words a FEATURE)
It is good idea to never commit code that cannot be compiled and also that you do from time to time a pull to reduce as soon as possible merging conflicts

STAGE&COMMIT: Aplly local changes to local repo (those are NOT yet sent to the server)
goal: document developing process without sending broken (Work in progress) code to server
GITHUB-GUI: select "changes at top" it will show a list of changes made by you, you can select wich files commit and do that with a comment
TORTOISE-GIT: right-click on folder-> commit (then select files, press "OK", usual stuff)

GIT: git add <file> (basically you are selecting a file for the commit, repeat for each file)
git commit (you are sending all SELECT files to local repo: just use "git commit -a" to select all changed files)
PULL: Get changes from a branch into working copy
goal :A git pull is what you would do to bring a local branch up-to-date with its remote version (detect changes by other people early by doing PULL periodically so that you can quickly resolve conflicts into your local branh)
TORTOISE-GIT: right-click on folder->TortoiseGit-> pull
GIT: git pull
PUSH: Get changes from a branch into working copy
goal: send local repo to the server. It finally makes visible to other people your changes on your branch, also they will see the previous history of your commits

TORTOISE-GIT: right-click on folder->TortoiseGit-> push
GIT: git push
PULL&PUSH
GITHUB-GUII: this is a peculiarity of github gui instead of pulling and pushing, you just press "SYNC" and a background job will be runned once. (same as calling pull followed by push except that if you made no changes push will not be runned ^^)
PULL REQUEST
This is where GIT really shines and is differente from mercurial:
This is most usefull in opensource projects:
You basically create a branch that is peer-reviewed before becoming merged to master branch,
_________________

BRANCHING


For now I link to this GUIDE
I hope I'm back soon to maintain these thread as it deserves:D

_________________

possible branch strategies


Note that different files systems threaths uppercase differently, it is highly suggested that all branchnames are lower case

Branching strategies depends mostly on wanted management: Do you want mostly strict rules for deployment in a development with pre-fixed phases, or do you want to stay agile?

Most projects have at least 2 branches
  • master
  • develop
master: it is updated from develop branch only before doing a build, usually it is advisable to continuosly build both master and develop, but having master as another branch allows to easily follow "big snapshots".

develop: sometimes shortened as "dev" is the main branch where most features are pushed/pulled on a daily basis


Hotfixes: some teams use a specific hoftix branch to do necessary fixes for master, those fixes are hacks and intended to stabilize a build and are usually short-lived. The real fix will happens inside dev (after having added test cases for that) with proper thought and design), the hotfixes should be on a separated branch to avoid polluting master with hackish code. So basically for each master build there may be 1 hotfix branch (If you have 4 builds in example your hotfix branches are <= 4)-

features: when you work alone on a feature your current local repo is the branch already, and will be merge when you pull/push. If you are working on a team then there could be a branch for that, usually branches should live short enough because having them opened for long is a problem.

when develop is not enough: If there are thousand people committing continuosly (there are reasons for doing small commits, but there are also reason for keep fewer commits), it is likely you will never be able to pull/push (becaues in the time you pulled someone else pushed and you have to pull again before pushing, it could also be a endless chain).

long living branches: are to be used if and only if there is a good reason for that, and there should be at least 1/2 team members that are very confident with GIT to repair eventual problems. Even a 3/4 days branch can become a problem if team is committing very fast and regularly.

The alternative to hotfixes is to do releases on separate branches, the problem with that is that usually there's much more effort into the release than in continuing the roject.

A example of a long living branch: You are developing a new framework for your project => that will require to change everything, then you start doing the framework and once it is done you can start refactoring existing code (keeping it in a branch avoid to start a new repository just for that, which is anyway an alternative).
When framework is ready we merge develop branch into the longliving branch and start the refactoring, there should be some discipline in the team (in example every new feature on develop should be merged back also in the long living branch etc.), when finally it is finished you can merge the long living branch again in develop.

________________
After you have some basics you have to
TRY GIT <-- LINK

enjoy!
Junior Irrlicht Developer.
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
REDDemon
Developer
Posts: 1044
Joined: Tue Aug 31, 2010 8:06 pm
Location: Genova (Italy)

Re: GIT quick reference guide (also answering questions)

Post by REDDemon »

added some more info :), however GIT is no better than Mercurial, both are equivalent. The difference is in the tools/websites support for one of the 2 protocols, in example in Github you have the pull request feature that allows to automatically merge a external change only after approval, for doing the same in SVN you should create a patch (manually creating the .diff file), and someone with write access should review (apply the .diff manually) it before committing.
Junior Irrlicht Developer.
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
Cube_
Posts: 1010
Joined: Mon Oct 24, 2011 10:03 pm
Location: 0x45 61 72 74 68 2c 20 69 6e 20 74 68 65 20 73 6f 6c 20 73 79 73 74 65 6d

Re: GIT quick reference guide (also answering questions)

Post by Cube_ »

git handles conflicts slightly better than mercurial in my general opinion, it also merges branches better [again, opinion] but to each his own.
"this is not the bottleneck you are looking for"
REDDemon
Developer
Posts: 1044
Joined: Tue Aug 31, 2010 8:06 pm
Location: Genova (Italy)

Re: GIT quick reference guide (also answering questions)

Post by REDDemon »

I don't know Mercurial enough, so If Mercurial expertes says it is equivalent to GIT I believe them :D good to know you like GIT (which I'm using too).
Junior Irrlicht Developer.
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
Post Reply