How to work with git

We want to start using git, but there are some question about branches.

How it is organized:

  • Git: Adding the full tree of files to the master
  • When I checkout a branch in GIT and then tag without explicity specifying the branch name what happens?
  • Set remote branch to a commit we don't have locally
  • Is there a way to configure Ivy to get dependencies from a branch without editing every dependency concerned?
  • Merge two git repositories into one, keeping (renamed) master branches
  • Where am I? * (no branch)
    1. Each programmer has his own local repository and works in master branch.
    2. Any changes are pushed to bare repository.
    3. Development server has local repository (master branch) and is updated by Post-Push hook
    4. Production server has local repository (branch “production”) and is updated by Post-Push hook

    How to correctly push some commits from master to production?

  • git - find the change history of particular file by one user in oneline
  • amending a single file in a past commit in git
  • Creating a GIT project from specific commit of another GIT project
  • Netbeans + GIT error when trying to clone a project “Algorithm negotiation fail”
  • Give permission for other user to git update remote?
  • How can I get rid of Eclipse Git “conflict” icons after all merges are resolved?
  • 2 Solutions collect form web for “How to work with git”

    In principle, you need to merge the changes from master into production. So in some workspace, switch to the production branch, merge the master branch and then push to the dev and production servers. This can be done in any developer’s workspace.

    Provided no changes are made to the production branch directly, all the merges will be “fast-forwards”- i.e. the “production branch” will basically just be a pointer to a position on your master branch, indicating at which point production was last updated. This means that merging will never produce any conflicts either. Technically you could do a “git push origin master:production” to update the production branch on the remote server in this case.

    Having an intermediate repo (here “Development”) is a good practice in order to consolidate and debug commits which are candidate to be put in production.

    But I would rather create a release branch (for instance ‘rel2.3‘) on the intermediate repo in order to be able to make last fixes/minor adjustment, before pushing ‘rel2.3‘ to ‘production‘ branch of the prod repo (along with a tag, in order to mark the exact commit representing 2.3)

    So an individual dev shouldn’t push into productiob directly: only the ‘integrator’ (or tester) who has validated what has been push on the intermediate repo should push to prod.

    And I would create an ‘rel2.3_hotfixes‘ branch on the prod repo in order to isolate urgent fixes once into production.

    So that would means each repo (devs, and ‘Development’) need to be in sync (ie rebased on) the production branch, which could have added commits after a given release.

    Git Baby is a git and github fan, let's start git clone.