Documentation

gitHub

Push local commits

Once you have committed the changes made in your local repository, you need to push your local commits to the remote repository in order to make your changes available to other people.  Hackolade Studio makes it easy for you to push commits to a remote repository: you just need to open your own local repository (if not already opened) and navigate to "Push local commits".

Image

All your local commits that you haven't pushed yet are listed with their date, author (you), and message.

 

Git will not let you push commits if you still have remote commits to pull.  You need to pull the remote commits that you don't have yet in your local repository, prior to pushing your own commits. This is because Git will only merge changes, and potentially trigger conflicts, when you pull changes.  When you push changes, Git just replaces the existing content with your content, which does not trigger conflicts.

 

For users new to Git, let us explain why a pull action is necessary, possibly with a merge of remote changes into the local repo, before a push action can be performed.

 

If I am making changes in the lower green branch below, based on a model originally in the remote, Git will reject my push at the end because changes were made to the same model.  That's because my changes would otherwise write over the changes by the other users.

 

Workgroup push denied

 

 

It is the responsibility of the last user who pushes changes to do the merge first and ensure that no conflicts exist, before pushing the merged model to the remote:

Workgroup pull before push

 

Best practice: to reduce the risks of facing conflicts, we recommend that you regularly pull remote commits.  This will ensure that your local repository is up-to-date with all the changes that have been recently pushed by other team members to the remote repository.  If you are about to start modifying a data model, then you should definitely pull first from the remote repository. 

 

You will have less headaches if you pull regularly from the remote and merge with your yet-be-pushed changes, so you merge smaller increments and deal with less complexity if conflict resolution turns out to be necessary.

 

Workgroup pull often before push